Re: ANTLR packages and i686
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.
--
Sincerely,
Demi Marie Obenour (she/her/hers)
OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Re: ANTLR packages and i686
On 7/19/22 21:59, Jerry James wrote: On Wed, Jul 6, 2022 at 8:13 PM Jerry James 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/778d6190e6b411e5be92c73407b7754af55779dc?branch=rawhide ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: ANTLR packages and i686
On Wed, Jul 20, 2022 at 11:48 AM Maxwell G 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.
--
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Re: ANTLR packages and i686
(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
--
Thanks,
Maxwell G (@gotmax23)
Pronouns: He/Him/His
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Re: ANTLR packages and i686
On Wed, Jul 6, 2022 at 8:13 PM Jerry James 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. -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: ANTLR packages and i686
On Thu, Jul 14, 2022 at 7:06 AM Jiri Vanek 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. -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: ANTLR packages and i686
On Sun, Jul 10, 2022 at 11:31 PM Mikolaj Izdebski 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. -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: ANTLR packages and i686
On 7/11/22 07:31, Mikolaj Izdebski wrote: On Thu, Jul 7, 2022 at 4:15 AM Jerry James 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-le...@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-le...@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:
Re: ANTLR packages and i686
On Thu, Jul 7, 2022 at 4:15 AM Jerry James 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-le...@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-le...@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
ANTLR packages and i686
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/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
