The various ANTLR packages will be impacted by https://fedoraproject.org/wiki/Changes/Drop_i686_JDKs. The parser generators, which are written in Java, will no longer be available on i686. If absolutely necessary, we could continue to package the various language runtimes for i686. That would be a major pain in the neck. WIth ANTLR 4 in particular, the version currently in Rawhide (4.10.1) is not compatible with previous runtimes. Most of the consumers we have in Rawhide ship parsers that were generated with ANTLR 4.6 through 4.9 generators, so they are not compatible with the 4.10.1 runtimes. (We regenerate the parsers at build time.) Continuing to support i686 would therefore mean packaging old versions of the language runtimes, just for i686.
My preference is to stop building everything ANTLR-related on i686. This has consequences for packages written in C, C++, Go, and OCaml, at least. I'll omit Java packages other than the ANTLR packages from the lists below, since they will disappear from i686 on their own.
Affected packages with maintainers: - antlr3 (jjames, mizdebsk, dchen, mjakubicek, walters): we could conceivably keep the C, C++, and JavaScript runtimes if absolutely necessary - antlr4-project (jjames, mhayden, @go-sig): we could conceivably keep the C++, Go, JavaScript, Python3, and Swift runtimes, but see above - azure-cli (mhayden, @python-sig): needs the Python3 runtime from the antlr4-project package - belle-sip (nucleo, sdgathman): needs the C runtime from the antlr3 package - coq (amdunn, jjames): needs the Python3 runtime from the antlr4-project package - cvc4 (jjames, brouhaha): needs the C runtime from the antlr3 package - flocq (jjames): depends on coq - frama-c (jjames): depends on why3 - gappalib-coq (jjames): depends on flocq - golang-github-google-cel (eclipseo, @go-sig): needs the Go runtime from the antlr4-project package - golang-google-grpc (eclipseo, @go-sig): needs golang-github-google-cel. Is consumed by a TON of other Go packages, so many that I did not attempt to trace them. - ocaml-menhir (jjames): we can remove the coq subpackage only on i686; it isn't consumed by anything in Fedora - why3 (jjames): depends on flocq
Packages by maintainer: @go-sig: antlr4-project, golang-github-google-cel, golang-google-grpc, numerous consumers of golang-google-grpc @python-sig: azure-cli amdunn: coq brouhaha: cvc4 dchen: antlr3 eclipseo: golang-github-google-cel, golang-google-grpc jjames: antlr3, antlr4-project, coq, cvc4, flocq, frama-c, gappalib-coq, ocaml-menhir, why3 mhayden: antlr4-project, azure-cli mizdebsk: antlr3 mjakubicek: antlr3 nucleo: belle-sip sdgathman: belle-sip walters: antlr3
I am going to be mostly offline starting Saturday, so I intend to deal with this when I get back, approximately July 18. That is just before the mass rebuild, of course. If anybody has a problem with dropping i686 builds for the above packages, please come up with a plan to deal with the situation by then.
On Thu, Jul 7, 2022 at 4:15 AM Jerry James loganjerry@gmail.com wrote:
The various ANTLR packages will be impacted by https://fedoraproject.org/wiki/Changes/Drop_i686_JDKs. The parser generators, which are written in Java, will no longer be available on i686. If absolutely necessary, we could continue to package the various language runtimes for i686. That would be a major pain in the neck. WIth ANTLR 4 in particular, the version currently in Rawhide (4.10.1) is not compatible with previous runtimes. Most of the consumers we have in Rawhide ship parsers that were generated with ANTLR 4.6 through 4.9 generators, so they are not compatible with the 4.10.1 runtimes. (We regenerate the parsers at build time.) Continuing to support i686 would therefore mean packaging old versions of the language runtimes, just for i686.
My preference is to stop building everything ANTLR-related on i686. This has consequences for packages written in C, C++, Go, and OCaml, at least. I'll omit Java packages other than the ANTLR packages from the lists below, since they will disappear from i686 on their own.
I agree. That would be my preference too.
Affected packages with maintainers:
- antlr3 (jjames, mizdebsk, dchen, mjakubicek, walters): we could
conceivably keep the C, C++, and JavaScript runtimes if absolutely necessary
- antlr4-project (jjames, mhayden, @go-sig): we could conceivably keep
the C++, Go, JavaScript, Python3, and Swift runtimes, but see above
- azure-cli (mhayden, @python-sig): needs the Python3 runtime from the
antlr4-project package
- belle-sip (nucleo, sdgathman): needs the C runtime from the antlr3 package
- coq (amdunn, jjames): needs the Python3 runtime from the
antlr4-project package
- cvc4 (jjames, brouhaha): needs the C runtime from the antlr3 package
- flocq (jjames): depends on coq
- frama-c (jjames): depends on why3
- gappalib-coq (jjames): depends on flocq
- golang-github-google-cel (eclipseo, @go-sig): needs the Go runtime
from the antlr4-project package
- golang-google-grpc (eclipseo, @go-sig): needs
golang-github-google-cel. Is consumed by a TON of other Go packages, so many that I did not attempt to trace them.
- ocaml-menhir (jjames): we can remove the coq subpackage only on
i686; it isn't consumed by anything in Fedora
- why3 (jjames): depends on flocq
Not sure why your list does not include these, but the following packages also build-require antlr-C++: * gdl - already has java bcond; BR on antlr would need to be wrapped into bcond * nco - seems to have ability to be built without antlr (with limited features) * sqlitebrowser - looks like application (and we don't ship i686 kernel) * vfrnav - likewise
Packages by maintainer: @go-sig: antlr4-project, golang-github-google-cel, golang-google-grpc, numerous consumers of golang-google-grpc @python-sig: azure-cli amdunn: coq brouhaha: cvc4 dchen: antlr3 eclipseo: golang-github-google-cel, golang-google-grpc jjames: antlr3, antlr4-project, coq, cvc4, flocq, frama-c, gappalib-coq, ocaml-menhir, why3 mhayden: antlr4-project, azure-cli mizdebsk: antlr3 mjakubicek: antlr3 nucleo: belle-sip sdgathman: belle-sip walters: antlr3
I am going to be mostly offline starting Saturday, so I intend to deal with this when I get back, approximately July 18. That is just before the mass rebuild, of course. If anybody has a problem with dropping i686 builds for the above packages, please come up with a plan to deal with the situation by then. -- Jerry James http://www.jamezone.org/ _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 7/11/22 07:31, Mikolaj Izdebski wrote:
On Thu, Jul 7, 2022 at 4:15 AM Jerry James loganjerry@gmail.com wrote:
The various ANTLR packages will be impacted by https://fedoraproject.org/wiki/Changes/Drop_i686_JDKs. The parser
Thanx a lot for sharing the thoughts.
generators, which are written in Java, will no longer be available on i686. If absolutely necessary, we could continue to package the various language runtimes for i686. That would be a major pain in the neck. WIth ANTLR 4 in particular, the version currently in Rawhide (4.10.1) is not compatible with previous runtimes. Most of the consumers we have in Rawhide ship parsers that were generated with ANTLR 4.6 through 4.9 generators, so they are not compatible with the 4.10.1 runtimes. (We regenerate the parsers at build time.) Continuing to support i686 would therefore mean packaging old versions of the language runtimes, just for i686.
That sounds like no go.
My preference is to stop building everything ANTLR-related on i686. This has consequences for packages written in C, C++, Go, and OCaml, at least. I'll omit Java packages other than the ANTLR packages from the lists below, since they will disappear from i686 on their own.
I agree. That would be my preference too.
+1
Affected packages with maintainers:
- antlr3 (jjames, mizdebsk, dchen, mjakubicek, walters): we could
conceivably keep the C, C++, and JavaScript runtimes if absolutely necessary
How to find they are absolutely necessary? if-in them back if theirs maintainers rise hand?
Because that sounds like the way to go. Seeing the depndece chain, There seems to be no pure show stopper.
- antlr4-project (jjames, mhayden, @go-sig): we could conceivably keep
the C++, Go, JavaScript, Python3, and Swift runtimes, but see above
- azure-cli (mhayden, @python-sig): needs the Python3 runtime from the
antlr4-project package
- belle-sip (nucleo, sdgathman): needs the C runtime from the antlr3 package
- coq (amdunn, jjames): needs the Python3 runtime from the
antlr4-project package
- cvc4 (jjames, brouhaha): needs the C runtime from the antlr3 package
- flocq (jjames): depends on coq
- frama-c (jjames): depends on why3
- gappalib-coq (jjames): depends on flocq
- golang-github-google-cel (eclipseo, @go-sig): needs the Go runtime
from the antlr4-project package
- golang-google-grpc (eclipseo, @go-sig): needs
golang-github-google-cel. Is consumed by a TON of other Go packages, so many that I did not attempt to trace them.
- ocaml-menhir (jjames): we can remove the coq subpackage only on
i686; it isn't consumed by anything in Fedora
- why3 (jjames): depends on flocq
Not sure why your list does not include these, but the following packages also build-require antlr-C++:
- gdl - already has java bcond; BR on antlr would need to be wrapped into bcond
- nco - seems to have ability to be built without antlr (with limited features)
- sqlitebrowser - looks like application (and we don't ship i686 kernel)
- vfrnav - likewise
Packages by maintainer: @go-sig: antlr4-project, golang-github-google-cel, golang-google-grpc, numerous consumers of golang-google-grpc @python-sig: azure-cli amdunn: coq brouhaha: cvc4 dchen: antlr3 eclipseo: golang-github-google-cel, golang-google-grpc jjames: antlr3, antlr4-project, coq, cvc4, flocq, frama-c, gappalib-coq, ocaml-menhir, why3 mhayden: antlr4-project, azure-cli mizdebsk: antlr3 mjakubicek: antlr3 nucleo: belle-sip sdgathman: belle-sip walters: antlr3
I am going to be mostly offline starting Saturday, so I intend to deal with this when I get back, approximately July 18. That is just before the mass rebuild, of course. If anybody has a problem with dropping
i guess that will happen after the mass rebuild as alwyas.
i686 builds for the above packages, please come up with a plan to deal with the situation by then.
If you can, please do the exclusion change and build before 20th (exclusive) as 20th starts mass rebuild (As you know), jdk will be already disabled on i686 and FTBFS bugs willbe auto filled.
TYVM!!
J.
-- Jerry James http://www.jamezone.org/ _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Thu, Jul 14, 2022 at 7:06 AM Jiri Vanek jvanek@redhat.com wrote:
How to find they are absolutely necessary? if-in them back if theirs maintainers rise hand?
Because that sounds like the way to go. Seeing the depndece chain, There seems to be no pure show stopper.
Yes, since none of the maintainers has spoken up, I'm going to proceed with dropping i686 support. If somebody really, really needs it back, we can talk about how to do that. If nobody really, really needs it back, then it will just stay gone.
On Sun, Jul 10, 2022 at 11:31 PM Mikolaj Izdebski mizdebsk@redhat.com wrote:
Not sure why your list does not include these, but the following packages also build-require antlr-C++:
- gdl - already has java bcond; BR on antlr would need to be wrapped into bcond
- nco - seems to have ability to be built without antlr (with limited features)
- sqlitebrowser - looks like application (and we don't ship i686 kernel)
- vfrnav - likewise
antlr-C++ is an ANTLR 2.x package. I don't maintain it, and don't intend to touch it or packages that depend on it. I've had a lot of catching up to do since returning from my trip 2 days ago, so I'm going to have to scramble to get the ANTLR 3.x and 4.x work done tonight.
On Wed, Jul 6, 2022 at 8:13 PM Jerry James loganjerry@gmail.com wrote:
The various ANTLR packages will be impacted by https://fedoraproject.org/wiki/Changes/Drop_i686_JDKs. The parser generators, which are written in Java, will no longer be available on i686. If absolutely necessary, we could continue to package the various language runtimes for i686. That would be a major pain in the neck. WIth ANTLR 4 in particular, the version currently in Rawhide (4.10.1) is not compatible with previous runtimes. Most of the consumers we have in Rawhide ship parsers that were generated with ANTLR 4.6 through 4.9 generators, so they are not compatible with the 4.10.1 runtimes. (We regenerate the parsers at build time.) Continuing to support i686 would therefore mean packaging old versions of the language runtimes, just for i686.
My preference is to stop building everything ANTLR-related on i686. This has consequences for packages written in C, C++, Go, and OCaml, at least. I'll omit Java packages other than the ANTLR packages from the lists below, since they will disappear from i686 on their own.
Affected packages with maintainers:
- antlr3 (jjames, mizdebsk, dchen, mjakubicek, walters): we could
conceivably keep the C, C++, and JavaScript runtimes if absolutely necessary
- antlr4-project (jjames, mhayden, @go-sig): we could conceivably keep
the C++, Go, JavaScript, Python3, and Swift runtimes, but see above
- azure-cli (mhayden, @python-sig): needs the Python3 runtime from the
antlr4-project package
- belle-sip (nucleo, sdgathman): needs the C runtime from the antlr3 package
- coq (amdunn, jjames): needs the Python3 runtime from the
antlr4-project package
- cvc4 (jjames, brouhaha): needs the C runtime from the antlr3 package
- flocq (jjames): depends on coq
- frama-c (jjames): depends on why3
- gappalib-coq (jjames): depends on flocq
- golang-github-google-cel (eclipseo, @go-sig): needs the Go runtime
from the antlr4-project package
- golang-google-grpc (eclipseo, @go-sig): needs
golang-github-google-cel. Is consumed by a TON of other Go packages, so many that I did not attempt to trace them.
- ocaml-menhir (jjames): we can remove the coq subpackage only on
i686; it isn't consumed by anything in Fedora
- why3 (jjames): depends on flocq
Packages by maintainer: @go-sig: antlr4-project, golang-github-google-cel, golang-google-grpc, numerous consumers of golang-google-grpc @python-sig: azure-cli amdunn: coq brouhaha: cvc4 dchen: antlr3 eclipseo: golang-github-google-cel, golang-google-grpc jjames: antlr3, antlr4-project, coq, cvc4, flocq, frama-c, gappalib-coq, ocaml-menhir, why3 mhayden: antlr4-project, azure-cli mizdebsk: antlr3 mjakubicek: antlr3 nucleo: belle-sip sdgathman: belle-sip walters: antlr3
I am going to be mostly offline starting Saturday, so I intend to deal with this when I get back, approximately July 18. That is just before the mass rebuild, of course. If anybody has a problem with dropping i686 builds for the above packages, please come up with a plan to deal with the situation by then. -- Jerry James http://www.jamezone.org/
These 3 packages are the only ones that have not been dealt with. These packages will fail the mass rebuild: - azure-cli: mhayden, @python-sig - belle-sip: nucleo, sdgathman; see https://src.fedoraproject.org/rpms/belle-sip/pull-request/1 - golang-github-google-cel: eclipseo, @go-sig
BCC to the affected maintainers.
On 7/19/22 21:59, Jerry James wrote:
On Wed, Jul 6, 2022 at 8:13 PM Jerry James loganjerry@gmail.com wrote:
The various ANTLR packages will be impacted by https://fedoraproject.org/wiki/Changes/Drop_i686_JDKs.
These 3 packages are the only ones that have not been dealt with. These packages will fail the mass rebuild:
- azure-cli: mhayden, @python-sig
- belle-sip: nucleo, sdgathman; see
https://src.fedoraproject.org/rpms/belle-sip/pull-request/1
- golang-github-google-cel: eclipseo, @go-sig
BCC to the affected maintainers.
The azure-cli package is now dealt with[1].
[1] https://src.fedoraproject.org/rpms/azure-cli/c/778d6190e6b411e5be92c73407b77...
(Sorry for the messed up line wrapping. I wanted to get this out.)
Hi Jerry,
On 22/07/06 08:13PM, Jerry James wrote:
- golang-github-google-cel (eclipseo, @go-sig): needs the Go runtime
from the antlr4-project package
- golang-google-grpc (eclipseo, @go-sig): needs
golang-github-google-cel. Is consumed by a TON of other Go packages, so many that I did not attempt to trace them.
I'm replying as a member of the go-sig, as the primary maintainer is pretty busy lately.
At least 289 source packages (recursively) BuildRequire golang-github-google-cel-devel[1]. Some of these packages only provide `-devel` subpackages that should've been included in the above query, but there are likely also some that provide binaries that could be used by other packages (go or otherwise; runtime and/or buildtime). The dependents of those packages aren't included in the count above. I am working on querying for those packages and asking maintainers to remove the leaves.
The go-sig is also considering entirely removing go stack from i686, but we have not made a lot of progress yet. My preference would be to wait to remove all go packages from there by removing %ix86 from %golang_arches instead of adding `ExcludeArch: %ix86` to just the golang packages that need golang-antlr4-runtime-devel. Non go packages can probably be `ExcludeArch`ed first.
Please do not remove golang-antlr4-runtime-devel until we've dealt with at least the packages affected by removing this one. I understand that this probably isn't the answer you want to hear. We are in a similar situation; we'd like to remove the go stack from i686, as it adds extra maintenance burden, but there are other packages that depend on go stuff that need to be dealt with first (and some go packages that don't follow the packaging guidelines and are missing ExclusiveArch: %{golang_arches}`).
[1]: sudo dnf repoquery --repo=rawhide{,-source} --recursive --whatrequires | grep '.src$' | pkgname | sort | uniq
On Wed, Jul 20, 2022 at 11:48 AM Maxwell G gotmax@e.email wrote:
I'm replying as a member of the go-sig, as the primary maintainer is pretty busy lately.
At least 289 source packages (recursively) BuildRequire golang-github-google-cel-devel[1]. Some of these packages only provide `-devel` subpackages that should've been included in the above query, but there are likely also some that provide binaries that could be used by other packages (go or otherwise; runtime and/or buildtime). The dependents of those packages aren't included in the count above. I am working on querying for those packages and asking maintainers to remove the leaves.
The go-sig is also considering entirely removing go stack from i686, but we have not made a lot of progress yet. My preference would be to wait to remove all go packages from there by removing %ix86 from %golang_arches instead of adding `ExcludeArch: %ix86` to just the golang packages that need golang-antlr4-runtime-devel. Non go packages can probably be `ExcludeArch`ed first.
Please do not remove golang-antlr4-runtime-devel until we've dealt with at least the packages affected by removing this one. I understand that this probably isn't the answer you want to hear. We are in a similar situation; we'd like to remove the go stack from i686, as it adds extra maintenance burden, but there are other packages that depend on go stuff that need to be dealt with first (and some go packages that don't follow the packaging guidelines and are missing ExclusiveArch: %{golang_arches}`).
[1]: sudo dnf repoquery --repo=rawhide{,-source} --recursive --whatrequires | grep '.src$' | pkgname | sort | uniq
I'm afraid that I already removed i686 support from antlr4-project last night. In any case, it wouldn't have done you any good if I hadn't, as the antlr4 package would have been uninstallable on i686 due to the lack of a JDK. And even if you had suppressed that BuildRequires on i686, it still wouldn't have done you any good, because then you would have had a parser that didn't match its runtime, causing it to break if you tried to actually run the code.
There were no good options, so I chose the one that seemed least harmful to me. The golang stack would have been broken no matter what. I don't think anybody realized that would be a consequence of dropping the i686 JDKs, but here we are.
On 7/20/22 13:48, Maxwell G via devel wrote:
(Sorry for the messed up line wrapping. I wanted to get this out.)
Hi Jerry,
On 22/07/06 08:13PM, Jerry James wrote:
- golang-github-google-cel (eclipseo, @go-sig): needs the Go runtime
from the antlr4-project package
- golang-google-grpc (eclipseo, @go-sig): needs
golang-github-google-cel. Is consumed by a TON of other Go packages, so many that I did not attempt to trace them.
I'm replying as a member of the go-sig, as the primary maintainer is pretty busy lately.
At least 289 source packages (recursively) BuildRequire golang-github-google-cel-devel[1]. Some of these packages only provide `-devel` subpackages that should've been included in the above query, but there are likely also some that provide binaries that could be used by other packages (go or otherwise; runtime and/or buildtime). The dependents of those packages aren't included in the count above. I am working on querying for those packages and asking maintainers to remove the leaves.
The go-sig is also considering entirely removing go stack from i686, but we have not made a lot of progress yet. My preference would be to wait to remove all go packages from there by removing %ix86 from %golang_arches instead of adding `ExcludeArch: %ix86` to just the golang packages that need golang-antlr4-runtime-devel. Non go packages can probably be `ExcludeArch`ed first.
Please do not remove golang-antlr4-runtime-devel until we've dealt with at least the packages affected by removing this one. I understand that this probably isn't the answer you want to hear. We are in a similar situation; we'd like to remove the go stack from i686, as it adds extra maintenance burden, but there are other packages that depend on go stuff that need to be dealt with first (and some go packages that don't follow the packaging guidelines and are missing ExclusiveArch: %{golang_arches}`).
Have you considered bundling the runtimes and generated code? That would allow dropping the java dependency.
-
Ben Beasley -
Demi Marie Obenour -
Jerry James -
Jiri Vanek -
Maxwell G -
Mikolaj Izdebski