On 7/11/22 07:31, Mikolaj Izdebski wrote:
On Thu, Jul 7, 2022 at 4:15 AM Jerry James <loganjerry@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
--
Jiri Vanek Mgr.
Principal QA Software Engineer
Red Hat Inc.
+420 775 39 01 09
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
