Re: [gentoo-dev] dev-python/cryptography to use rust, effectively killing alpha, hppa, ia64, m68k, s390
On Mon, Feb 8, 2021 at 1:35 PM Brian Evans wrote: > > On 2/8/2021 12:53 PM, Brian Evans wrote: > > On 2/8/2021 6:19 AM, Michał Górny wrote: > >> Hi, > >> > >> FYI the developers of dev-python/cryptography decided that Rust is going > >> to be mandatory for 1.5+ versions. It's unlikely that they're going to > >> provide LTS support or security fixes for the old versions. > >> > >> Since cryptography is a very important package in the Python ecosystem, > >> and it is an indirect dependency of Portage, this means that we will > >> probably have to entirely drop support for architectures that are not > >> supported by Rust. > >> > > > > For the portage indirect dependency, can it be swapped for pycurl? > > > > AFAICT, it is just used to pull GPG sigs in gemato via dev-python/requests. > > > > This at least would at least keep the arches in question with some > > support but not necessarily all of python world until a clearer plan can > > be made. > > > > Brian > > > > After discussion in #gentoo-dev and simple chroot testing, it seems like > dev-python/requests nor dev-python/urlllib3 needs > dev-python/cryptography at all (when run with stable Python, tested with > 3.8). So unless there's a really good reason outside of gemato sync, > this looks to be a non-issue for portage and more of a dependency fix. I created a PR to drop this and related deps from dev-python/urllib3 and dev-python/requests. Please review. https://github.com/gentoo/gentoo/pull/19383
Re: [gentoo-dev] dev-python/cryptography to use rust, effectively killing alpha, hppa, ia64, m68k, s390
On Mon, Feb 08, 2021 at 10:02:43AM -0800, Alec Warner wrote: > On Mon, Feb 8, 2021 at 9:56 AM Alessandro Barbieri > wrote: > > > > Il Lun 8 Feb 2021, 12:19 Michał Górny ha scritto: > >> > > > > Should we shed tears for those legacy architectures or move forward? Does > > anyone really use them in production? > > Many users don't use gentoo in 'production' so I'm not sure how that > matters in our decision making. I'm not sure the trade off here > (taking rust as a core dep) is reasonable and it looks like we can > avoid it. > Do we have anything to support this claim? -Aaron signature.asc Description: PGP signature
Re: [gentoo-dev] dev-python/cryptography to use rust, effectively killing alpha, hppa, ia64, m68k, s390
On Mon, 2021-02-08 at 18:56 +0100, Alessandro Barbieri wrote: > Il Lun 8 Feb 2021, 12:19 Michał Górny ha scritto: > > > Hi, > > > > FYI the developers of dev-python/cryptography decided that Rust is going > > to be mandatory for 1.5+ versions. It's unlikely that they're going to > > provide LTS support or security fixes for the old versions. > > > > Since cryptography is a very important package in the Python ecosystem, > > and it is an indirect dependency of Portage, this means that we will > > probably have to entirely drop support for architectures that are not > > supported by Rust. > > > > According to upstream platform support information [1], this probably > > means (eventually) entirely removing the following architectures: > > - alpha (stable) > > - hppa (stable) > > - ia64 (stable) > > - m68k (exp) > > - s390 (except for s390x, exp) > > > > Furthermore, the Gentoo Rust packages are missing support > > for the following platforms, apparently supported upstream: > > - mips (exp) > > - ppc (32) (stable) > > - sparc (stable) > > - s390x (exp) > > - riscv (stable) > > > > Apparently it's non-trivial to bootstrap Rust on these platforms, > > so it's unclear when Gentoo is going to start providing Rust on them. > > > > I've raised a protest on the cryptography bug tracker [2] but apparently > > upstream considers Rust's 'memory safety' more important than ability to > > actually use the package. > > > > Honestly, I don't think it likely that Rust will gain support for these > > platforms. This involves a lot of work, starting with writing a new > > LLVM backend and getting it accepted (getting new code into LLVM is very > > hard unless you're doing that on behalf one of the big companies). You > > can imagine how much effort that involves compared to rewriting the new > > code from Cryptography into C. > > > > If we can't convince upstream, I'm afraid we'll either have to drop > > these architectures entirely or fork Cryptography. > > > > > > [1] https://doc.rust-lang.org/nightly/rustc/platform-support.html > > [2] https://github.com/pyca/cryptography/issues/5771 > > > > -- > > Best regards, > > Michał Górny > > > > Should we shed tears for those legacy architectures or move forward? Does > anyone really use them in production? I'm pretty sure people do use them in production. Whether we want to really continue supporting them is a separate topic. But the last thing I'd like to do is drop support for arches because of a single upstream maintainer being a Rust lover. -- Best regards, Michał Górny
Re: [gentoo-dev] dev-python/cryptography to use rust, effectively killing alpha, hppa, ia64, m68k, s390
On 2/8/2021 12:53 PM, Brian Evans wrote: On 2/8/2021 6:19 AM, Michał Górny wrote: Hi, FYI the developers of dev-python/cryptography decided that Rust is going to be mandatory for 1.5+ versions. It's unlikely that they're going to provide LTS support or security fixes for the old versions. Since cryptography is a very important package in the Python ecosystem, and it is an indirect dependency of Portage, this means that we will probably have to entirely drop support for architectures that are not supported by Rust. For the portage indirect dependency, can it be swapped for pycurl? AFAICT, it is just used to pull GPG sigs in gemato via dev-python/requests. This at least would at least keep the arches in question with some support but not necessarily all of python world until a clearer plan can be made. Brian After discussion in #gentoo-dev and simple chroot testing, it seems like dev-python/requests nor dev-python/urlllib3 needs dev-python/cryptography at all (when run with stable Python, tested with 3.8). So unless there's a really good reason outside of gemato sync, this looks to be a non-issue for portage and more of a dependency fix. Brian OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] dev-python/cryptography to use rust, effectively killing alpha, hppa, ia64, m68k, s390
On Mon, 2021-02-08 at 12:53 -0500, Brian Evans wrote: > On 2/8/2021 6:19 AM, Michał Górny wrote: > > Hi, > > > > FYI the developers of dev-python/cryptography decided that Rust is going > > to be mandatory for 1.5+ versions. It's unlikely that they're going to > > provide LTS support or security fixes for the old versions. > > > > Since cryptography is a very important package in the Python ecosystem, > > and it is an indirect dependency of Portage, this means that we will > > probably have to entirely drop support for architectures that are not > > supported by Rust. > > > > For the portage indirect dependency, can it be swapped for pycurl? > > AFAICT, it is just used to pull GPG sigs in gemato via dev-python/requests. I'll probably switch it to built-in urllib.request. The py3 versions should be good enough (previously urllib3 had better TLS support than old urllib AFAIR). -- Best regards, Michał Górny
Re: [gentoo-dev] GTK:2 EOL and incoming migration to GTK:3
John Helmert III wrote: > > Until there's a relevant flaw that will remain unfixed or there is > > significant incompatibility with infrastructure (recurse my argument) > > no signs actually exist. > > Waiting until such a problem pops up and bites everyone before doing > anything about it doesn't sound like a good way to handle it. I guess that's a matter of opinion. But more importantly, "anything" can mean a lot, and removing gtk2 is the ultimate sledgehammer. Deciding to certainly use it at an unknown point in the future seems unneccessary and premature to me. > If an application never ports, do you expect the distribution to > maintain that package ad infinitum? As always it depends on the required effort. When keeping the package requires little or no effort I *do* expect it to not be removed solely because there will be no more releases, which is really what was stated in the announcement, and why I piped up. Alec Warner wrote: > - I expect gtk2 (the library) to be around for a while. As written it > gets at least one more release. Ack. My point isn't about immediate action, rather about what drives decisions. > - I expect Gentoo to come after gtk2-only leaf packages pretty hard; > either to get upstream to port, or to remove them. >- This is true even if the packages are fully functional with gtk2, > or don't have other bugs. >- This is because we will eventually remove gtk2 from the tree > (which will make these packages unbuildable, and cause their removal.) That's indeed what I'm trying to give more perspective to. If there's in fact no other reason to "come after packages hard" and "remove gtk2" than "no more releases" then I'm strongly against doing so. > I'm less clear why we would keep libgtk2 in the tree for years and > years (just to keep nominally unmaintained gtk2 leaf packages buildable?) This assumes that "maintained" neccessarily means "will port from gtk2" which I don't agree with at all. There are many reasons to not port from gtk2 to something else. As long as there are no concrete problems, especially if one knows the relevant parts of gtk2 well and is convinced that they are free of issues, there is in fact no reason *to* port from gtk2. Except if distributions create one. It's awfully unneccessary to do that without good reason. > > Assuming that there will be a significant maintenance burden which > > affects all uses doesn't seem rational - hence my question. > > I think you need to keep gtk2 (the library) for a fair bit (just like > we kept python2.7; the interpreter; for a fair while after its EOL.) I'd argue that python2.7 should remain until demonstrably untenable, ideally indefinitely. At some point probably no longer within Gentoo's Python infrastructure - but at a minimum as a trivial package. //Peter
Re: [gentoo-dev] dev-python/cryptography to use rust, effectively killing alpha, hppa, ia64, m68k, s390
On Mon, Feb 8, 2021 at 9:56 AM Alessandro Barbieri wrote: > > Il Lun 8 Feb 2021, 12:19 Michał Górny ha scritto: >> >> Hi, >> >> FYI the developers of dev-python/cryptography decided that Rust is going >> to be mandatory for 1.5+ versions. It's unlikely that they're going to >> provide LTS support or security fixes for the old versions. >> >> Since cryptography is a very important package in the Python ecosystem, >> and it is an indirect dependency of Portage, this means that we will >> probably have to entirely drop support for architectures that are not >> supported by Rust. >> >> According to upstream platform support information [1], this probably >> means (eventually) entirely removing the following architectures: >> - alpha (stable) >> - hppa (stable) >> - ia64 (stable) >> - m68k (exp) >> - s390 (except for s390x, exp) >> >> Furthermore, the Gentoo Rust packages are missing support >> for the following platforms, apparently supported upstream: >> - mips (exp) >> - ppc (32) (stable) >> - sparc (stable) >> - s390x (exp) >> - riscv (stable) >> >> Apparently it's non-trivial to bootstrap Rust on these platforms, >> so it's unclear when Gentoo is going to start providing Rust on them. >> >> I've raised a protest on the cryptography bug tracker [2] but apparently >> upstream considers Rust's 'memory safety' more important than ability to >> actually use the package. >> >> Honestly, I don't think it likely that Rust will gain support for these >> platforms. This involves a lot of work, starting with writing a new >> LLVM backend and getting it accepted (getting new code into LLVM is very >> hard unless you're doing that on behalf one of the big companies). You >> can imagine how much effort that involves compared to rewriting the new >> code from Cryptography into C. >> >> If we can't convince upstream, I'm afraid we'll either have to drop >> these architectures entirely or fork Cryptography. >> >> >> [1] https://doc.rust-lang.org/nightly/rustc/platform-support.html >> [2] https://github.com/pyca/cryptography/issues/5771 >> >> -- >> Best regards, >> Michał Górny > > > Should we shed tears for those legacy architectures or move forward? Does > anyone really use them in production? Many users don't use gentoo in 'production' so I'm not sure how that matters in our decision making. I'm not sure the trade off here (taking rust as a core dep) is reasonable and it looks like we can avoid it. -A
Re: [gentoo-dev] dev-python/cryptography to use rust, effectively killing alpha, hppa, ia64, m68k, s390
On 2/8/21 7:53 PM, Brian Evans wrote: > > AFAICT, it is just used to pull GPG sigs in gemato via > dev-python/requests. > And it that's true, isn't this only relevant when syncing the tree using rsync? So using git would still be viable? -- juippis OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] dev-python/cryptography to use rust, effectively killing alpha, hppa, ia64, m68k, s390
Il Lun 8 Feb 2021, 12:19 Michał Górny ha scritto: > Hi, > > FYI the developers of dev-python/cryptography decided that Rust is going > to be mandatory for 1.5+ versions. It's unlikely that they're going to > provide LTS support or security fixes for the old versions. > > Since cryptography is a very important package in the Python ecosystem, > and it is an indirect dependency of Portage, this means that we will > probably have to entirely drop support for architectures that are not > supported by Rust. > > According to upstream platform support information [1], this probably > means (eventually) entirely removing the following architectures: > - alpha (stable) > - hppa (stable) > - ia64 (stable) > - m68k (exp) > - s390 (except for s390x, exp) > > Furthermore, the Gentoo Rust packages are missing support > for the following platforms, apparently supported upstream: > - mips (exp) > - ppc (32) (stable) > - sparc (stable) > - s390x (exp) > - riscv (stable) > > Apparently it's non-trivial to bootstrap Rust on these platforms, > so it's unclear when Gentoo is going to start providing Rust on them. > > I've raised a protest on the cryptography bug tracker [2] but apparently > upstream considers Rust's 'memory safety' more important than ability to > actually use the package. > > Honestly, I don't think it likely that Rust will gain support for these > platforms. This involves a lot of work, starting with writing a new > LLVM backend and getting it accepted (getting new code into LLVM is very > hard unless you're doing that on behalf one of the big companies). You > can imagine how much effort that involves compared to rewriting the new > code from Cryptography into C. > > If we can't convince upstream, I'm afraid we'll either have to drop > these architectures entirely or fork Cryptography. > > > [1] https://doc.rust-lang.org/nightly/rustc/platform-support.html > [2] https://github.com/pyca/cryptography/issues/5771 > > -- > Best regards, > Michał Górny > Should we shed tears for those legacy architectures or move forward? Does anyone really use them in production? >
Re: [gentoo-dev] dev-python/cryptography to use rust, effectively killing alpha, hppa, ia64, m68k, s390
On 2/8/2021 6:19 AM, Michał Górny wrote: Hi, FYI the developers of dev-python/cryptography decided that Rust is going to be mandatory for 1.5+ versions. It's unlikely that they're going to provide LTS support or security fixes for the old versions. Since cryptography is a very important package in the Python ecosystem, and it is an indirect dependency of Portage, this means that we will probably have to entirely drop support for architectures that are not supported by Rust. For the portage indirect dependency, can it be swapped for pycurl? AFAICT, it is just used to pull GPG sigs in gemato via dev-python/requests. This at least would at least keep the arches in question with some support but not necessarily all of python world until a clearer plan can be made. Brian OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] GTK:2 EOL and incoming migration to GTK:3
On Mon, Feb 8, 2021 at 6:59 AM Peter Stuge wrote: > > Hanno Böck wrote: > > > "It does mean, however, that GTK 2 has reached the end of its life. > > > We will do one final 2.x release in the coming days, and we encourage > > > everybody to port their GTK 2 applications to GTK 3 or 4." > > > > I read that as there will be one more gtk2 release and none after that. > > > > This seems to imply: > > * When there's a security flaw in gtk2 there won't be a fix from > > upstream. > > * When there's an incompatibility with new infrastructure (e.g. new gcc > > version / new glibc / changing API of libraries gtk depends on) there > > will be no updates from upstream. > > > > This means in all those instances maintainers will have to get patches > > from somewhere. We'll likely end up with some form of > > gtk-2.x-r[largenumber] with a large patchset at some point. > > Maintaining that will be an increasing burden. > > > > No urgency, but a sign to slowly move off gtk2. > > Until there's a relevant flaw that will remain unfixed or there is > significant incompatibility with infrastructure (recurse my argument) > no signs actually exist. So I think as the next post in the thread hints at: - I expect gtk2 (the library) to be around for a while. As written it gets at least one more release. - I expect Gentoo to come after gtk2-only leaf packages pretty hard; either to get upstream to port, or to remove them. - This is true even if the packages are fully functional with gtk2, or don't have other bugs. - This is because we will eventually remove gtk2 from the tree (which will make these packages unbuildable, and cause their removal.) I'm less clear why we would keep libgtk2 in the tree for years and years (just to keep nominally unmaintained gtk2 leaf packages buildable?) > > Assuming that there will be a significant maintenance burden which > affects all uses doesn't seem rational - hence my question. I think you need to keep gtk2 (the library) for a fair bit (just like we kept python2.7; the interpreter; for a fair while after its EOL.) > > The blog post shouldn't be misunderstood. The intended audience seems > to be application developers, encouraging them to port applications, > not so much distributions. > > Distributions quite often overlook that they wield much power, and > thus also have much responsibility. > > Of course, GTK maintainers in Gentoo choose what to work on, and have > made many (only?) excellent choices. > > I'm merely pleading for rational choices based on actual problems. > > > //Peter >
Re: [gentoo-dev] GTK:2 EOL and incoming migration to GTK:3
On Mon, Feb 08, 2021 at 02:59:45PM +, Peter Stuge wrote: > Hanno Böck wrote: > > > "It does mean, however, that GTK 2 has reached the end of its life. > > > We will do one final 2.x release in the coming days, and we encourage > > > everybody to port their GTK 2 applications to GTK 3 or 4." > > > > I read that as there will be one more gtk2 release and none after that. > > > > This seems to imply: > > * When there's a security flaw in gtk2 there won't be a fix from > > upstream. > > * When there's an incompatibility with new infrastructure (e.g. new gcc > > version / new glibc / changing API of libraries gtk depends on) there > > will be no updates from upstream. > > > > This means in all those instances maintainers will have to get patches > > from somewhere. We'll likely end up with some form of > > gtk-2.x-r[largenumber] with a large patchset at some point. > > Maintaining that will be an increasing burden. > > > > No urgency, but a sign to slowly move off gtk2. > > Until there's a relevant flaw that will remain unfixed or there is > significant incompatibility with infrastructure (recurse my argument) > no signs actually exist. Waiting until such a problem pops up and bites everyone before doing anything about it doesn't sound like a good way to handle it. > > Assuming that there will be a significant maintenance burden which > affects all uses doesn't seem rational - hence my question. > > The blog post shouldn't be misunderstood. The intended audience seems > to be application developers, encouraging them to port applications, > not so much distributions. If an application never ports, do you expect the distribution to maintain that package ad infinitum? > > Distributions quite often overlook that they wield much power, and > thus also have much responsibility. > > Of course, GTK maintainers in Gentoo choose what to work on, and have > made many (only?) excellent choices. > > I'm merely pleading for rational choices based on actual problems. > > > //Peter > signature.asc Description: PGP signature
Re: [gentoo-dev] GTK:2 EOL and incoming migration to GTK:3
Hanno Böck wrote: > > "It does mean, however, that GTK 2 has reached the end of its life. > > We will do one final 2.x release in the coming days, and we encourage > > everybody to port their GTK 2 applications to GTK 3 or 4." > > I read that as there will be one more gtk2 release and none after that. > > This seems to imply: > * When there's a security flaw in gtk2 there won't be a fix from > upstream. > * When there's an incompatibility with new infrastructure (e.g. new gcc > version / new glibc / changing API of libraries gtk depends on) there > will be no updates from upstream. > > This means in all those instances maintainers will have to get patches > from somewhere. We'll likely end up with some form of > gtk-2.x-r[largenumber] with a large patchset at some point. > Maintaining that will be an increasing burden. > > No urgency, but a sign to slowly move off gtk2. Until there's a relevant flaw that will remain unfixed or there is significant incompatibility with infrastructure (recurse my argument) no signs actually exist. Assuming that there will be a significant maintenance burden which affects all uses doesn't seem rational - hence my question. The blog post shouldn't be misunderstood. The intended audience seems to be application developers, encouraging them to port applications, not so much distributions. Distributions quite often overlook that they wield much power, and thus also have much responsibility. Of course, GTK maintainers in Gentoo choose what to work on, and have made many (only?) excellent choices. I'm merely pleading for rational choices based on actual problems. //Peter
Re: [gentoo-dev] dev-python/cryptography to use rust, effectively killing alpha, hppa, ia64, m68k, s390
On 2/8/21 2:27 PM, Michael Orlitzky wrote: > Not only that, but you will be dropping support for at least two of my > machines that are literally incapable of building the 10+ GiB bundled > rust package due to the amount of disk space and RAM required. > Pardon my intervention, but there is rust-bin available at least for amd64, x86, arm, arm64 and ppc64. Just a PSA to anyone not aware. -- juippis OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] dev-python/cryptography to use rust, effectively killing alpha, hppa, ia64, m68k, s390
On Mon, 2021-02-08 at 12:19 +0100, Michał Górny wrote: > > Since cryptography is a very important package in the Python ecosystem, > and it is an indirect dependency of Portage, this means that we will > probably have to entirely drop support for architectures that are not > supported by Rust. > Not only that, but you will be dropping support for at least two of my machines that are literally incapable of building the 10+ GiB bundled rust package due to the amount of disk space and RAM required.
Re: [gentoo-dev] dev-python/cryptography to use rust, effectively killing alpha, hppa, ia64, m68k, s390
> On 8 Feb 2021, at 11:19, Michał Górny wrote: > > Hi, > > FYI the developers of dev-python/cryptography decided that Rust is going > to be mandatory for 1.5+ versions. It's unlikely that they're going to > provide LTS support or security fixes for the old versions. > > Since cryptography is a very important package in the Python ecosystem, > and it is an indirect dependency of Portage, this means that we will > probably have to entirely drop support for architectures that are not > supported by Rust. > It seems that there was no mention of this in release notes or the changelog - neither to warn packagers or consult with them for their views on this, which would’ve been the best place to do so. > [snip] > > Furthermore, the Gentoo Rust packages are missing support > for the following platforms, apparently supported upstream: > - mips (exp) > - ppc (32) (stable) > - sparc (stable) > - s390x (exp) > - riscv (stable) We also need to add support for armv4/armv5. > > Apparently it's non-trivial to bootstrap Rust on these platforms, > so it's unclear when Gentoo is going to start providing Rust on them. > > [snip] Filed a Gentoo bug too: https://bugs.gentoo.org/769482. > [1] https://doc.rust-lang.org/nightly/rustc/platform-support.html > [2] https://github.com/pyca/cryptography/issues/5771 > > -- > Best regards, > Michał Górny > > > signature.asc Description: Message signed with OpenPGP
Re: [gentoo-dev] dev-python/cryptography to use rust, effectively killing alpha, hppa, ia64, m68k, s390
On Mon, 08 Feb 2021 12:19:13 +0100 Michał Górny wrote: > Hi, > > FYI the developers of dev-python/cryptography decided that Rust is going > to be mandatory for 1.5+ versions. It's unlikely that they're going to > provide LTS support or security fixes for the old versions. > > > > Honestly, I don't think it likely that Rust will gain support for these > platforms. This involves a lot of work, starting with writing a new > LLVM backend and getting it accepted (getting new code into LLVM is very > hard unless you're doing that on behalf one of the big companies). You > can imagine how much effort that involves compared to rewriting the new > code from Cryptography into C. I do know that there is ongoing work to get Rust going on m68k but it's very slow and I'm not entirely confident they'll get there. At least I don't have this package on my m68k system! -- James Le Cuirot (chewi) Gentoo Linux Developer pgpEXub3MDL7c.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] dev-python/cryptography to use rust, effectively killing alpha, hppa, ia64, m68k, s390
El lun, 08-02-2021 a las 12:19 +0100, Michał Górny escribió: > Hi, > > FYI the developers of dev-python/cryptography decided that Rust is going > to be mandatory for 1.5+ versions. It's unlikely that they're going to > provide LTS support or security fixes for the old versions. > > Since cryptography is a very important package in the Python ecosystem, > and it is an indirect dependency of Portage, this means that we will > probably have to entirely drop support for architectures that are not > supported by Rust. > > According to upstream platform support information [1], this probably > means (eventually) entirely removing the following architectures: > - alpha (stable) > - hppa (stable) > - ia64 (stable) > - m68k (exp) > - s390 (except for s390x, exp) > > Furthermore, the Gentoo Rust packages are missing support > for the following platforms, apparently supported upstream: > - mips (exp) > - ppc (32) (stable) > - sparc (stable) > - s390x (exp) > - riscv (stable) > > Apparently it's non-trivial to bootstrap Rust on these platforms, > so it's unclear when Gentoo is going to start providing Rust on them. > > I've raised a protest on the cryptography bug tracker [2] but apparently > upstream considers Rust's 'memory safety' more important than ability to > actually use the package. > > Honestly, I don't think it likely that Rust will gain support for these > platforms. This involves a lot of work, starting with writing a new > LLVM backend and getting it accepted (getting new code into LLVM is very > hard unless you're doing that on behalf one of the big companies). You > can imagine how much effort that involves compared to rewriting the new > code from Cryptography into C. > > If we can't convince upstream, I'm afraid we'll either have to drop > these architectures entirely or fork Cryptography. > > > [1] https://doc.rust-lang.org/nightly/rustc/platform-support.html > [2] https://github.com/pyca/cryptography/issues/5771 > It will also affect non-SSE2 x86 setups as upstream is neither providing prebuilt package for them :/ https://bugs.gentoo.org/741708 signature.asc Description: This is a digitally signed message part
[gentoo-dev] dev-python/cryptography to use rust, effectively killing alpha, hppa, ia64, m68k, s390
Hi, FYI the developers of dev-python/cryptography decided that Rust is going to be mandatory for 1.5+ versions. It's unlikely that they're going to provide LTS support or security fixes for the old versions. Since cryptography is a very important package in the Python ecosystem, and it is an indirect dependency of Portage, this means that we will probably have to entirely drop support for architectures that are not supported by Rust. According to upstream platform support information [1], this probably means (eventually) entirely removing the following architectures: - alpha (stable) - hppa (stable) - ia64 (stable) - m68k (exp) - s390 (except for s390x, exp) Furthermore, the Gentoo Rust packages are missing support for the following platforms, apparently supported upstream: - mips (exp) - ppc (32) (stable) - sparc (stable) - s390x (exp) - riscv (stable) Apparently it's non-trivial to bootstrap Rust on these platforms, so it's unclear when Gentoo is going to start providing Rust on them. I've raised a protest on the cryptography bug tracker [2] but apparently upstream considers Rust's 'memory safety' more important than ability to actually use the package. Honestly, I don't think it likely that Rust will gain support for these platforms. This involves a lot of work, starting with writing a new LLVM backend and getting it accepted (getting new code into LLVM is very hard unless you're doing that on behalf one of the big companies). You can imagine how much effort that involves compared to rewriting the new code from Cryptography into C. If we can't convince upstream, I'm afraid we'll either have to drop these architectures entirely or fork Cryptography. [1] https://doc.rust-lang.org/nightly/rustc/platform-support.html [2] https://github.com/pyca/cryptography/issues/5771 -- Best regards, Michał Górny
[gentoo-dev] Last-rites: media-gfx/gqview
# Sergei Trofimovich (2020-02-08) # Abandoned upstream. Was never ported from gtk-2. # A possible alternative is media-gfx/geeqie (gqview fork). # Removal in 3 months. Bug #769440. media-gfx/gqview -- Sergei
Re: [gentoo-dev] GTK:2 EOL and incoming migration to GTK:3
On Mon, 8 Feb 2021 10:22:21 + Peter Stuge wrote: > "It does mean, however, that GTK 2 has reached the end of its life. > We will do one final 2.x release in the coming days, and we encourage > everybody to port their GTK 2 applications to GTK 3 or 4." I read that as there will be one more gtk2 release and none after that. This seems to imply: * When there's a security flaw in gtk2 there won't be a fix from upstream. * When there's an incompatibility with new infrastructure (e.g. new gcc version / new glibc / changing API of libraries gtk depends on) there will be no updates from upstream. This means in all those instances maintainers will have to get patches from somewhere. We'll likely end up with some form of gtk-2.x-r[largenumber] with a large patchset at some point. Maintaining that will be an increasing burden. No urgency, but a sign to slowly move off gtk2. -- Hanno Böck https://hboeck.de/
Re: [gentoo-dev] GTK:2 EOL and incoming migration to GTK:3
Peter Stuge wrote: > We will do one final 2.x release in the coming days, and we encourage > everybody to port their GTK 2 applications to GTK 3 or 4." > > > The recommendation in the blog post is for application developers to > port to 3 or 4, nothing more and nothing less. Correction: It /encourages/ porting to 3 or 4. It's not even a recommendation. > What's the reasoning for this driving "killing off GTK:2" in Gentoo? > > Are there (presently or foreseeable) technical issues with GTK:2? > > > Many thanks and kind regards //Peter
Re: [gentoo-dev] GTK:2 EOL and incoming migration to GTK:3
Aisha Tammy wrote: > We are now in the process of cleaning up GTK:2 ebuilds and moving the > packages to use GTK:3 and drop GTK:2 support. Quoting the blog post you linked to: (thanks for including the link!) "It does mean, however, that GTK 2 has reached the end of its life. We will do one final 2.x release in the coming days, and we encourage everybody to port their GTK 2 applications to GTK 3 or 4." The recommendation in the blog post is for application developers to port to 3 or 4, nothing more and nothing less. What's the reasoning for this driving "killing off GTK:2" in Gentoo? Are there (presently or foreseeable) technical issues with GTK:2? Many thanks and kind regards //Peter
Re: [gentoo-dev] GTK:2 EOL and incoming migration to GTK:3
> On 8 Feb 2021, at 00:52, Aisha Tammy wrote: > > Hi all, > [snip] > This transition is expected to take a long time so there shouldn't be a worry > about sudden > changes in packages. We are going to keep some of the more important old > GTK:2 ebuilds, > such as the CJK ebuilds, around as long as we have GTK:2 in the tree. Newer > packages are > encouraged to be GTK:3 only. > The starting point of the transition are packages which have GTK:3 support > and optional GTK:2 > support. Most of the bugs of this kind have already been filed[1] and is the > safest > place to start killing off GTK:2. This is completely fair, but I’d just like to add that dropping GTK 2 should ideally be done in revbumps and given time before stabilisation & cleanup to ease the pain for users. Yes, it’s been a long time coming, and this is only the first step, but some people have a sentimental attachment to it, so we should give them time to get used to the new interfaces rather than yanking it entirely from all versions in the tree where it’s possible. TL;DR: Great, let’s just not rush to cleanup old so people can revert if issues arise with new designs or whatever in the GUI. > > Best, > Aisha > > [1] https://blog.gtk.org/2020/12/16/gtk-4-0/ > [2] https://bugs.gentoo.org/768993 > > signature.asc Description: Message signed with OpenPGP
