https://bugzilla.redhat.com/show_bug.cgi?id=1795470 --- Comment #8 from Fabio Valentini <decathorpe@xxxxxxxxx> --- (In reply to Jerry James from comment #7) > I can't use %gometa, because that adds an incorrect ExclusiveArch tag (hence > the bare BR on go-rpm-macros). I can use %goname to generate the package > name, but go-rpm-macros alone does not seem to be enough to get that macro. > What do I need to BR for it? And after that I'm lost. If you know how to > integrate more of the go macros into the spec, I am happy to take your input. > > And speaking of macros that can't be used, it turns out that %mvn_install > cannot be used, because it uses %{name} everywhere, and I need "antlr4", not > "antlr4-project", to be what it uses. I've manually expanded the macro for > that reason. That's enough of a reason for me. I think %gometa also sets up some other variables that are probably needed by goinstall, and as you said, it sets an incompatible value for ExclusiveArch, so I'm fine with the current approach. > > - Did you consider requiring java-1.8.0-openjdk-aarch32 (don't depend on my > > spelling this correctly) on %ifarch %{arm}? > > I did not know about that. Thanks for the tip. Let's see if it helps once the mass rebuild is over and the dependencies are in koji :-) > > - License correct and permissible (3-Clause-BSD), and looks like the > > LICENSE.txt file is installed for every subpackage combination (please > > check). > > I have checked and double checked this, so I'm pretty confident it is right. Great! > > - BuildRequires look correct and are even sorted alphabetically :) > > I like to do that because it makes it easy for my slow human brain to decide > if something is in the BuildRequires already. :-) Yeah, I do the same. > > - Patches are commented, but no reference to upstream issues or something > > like that (adding that would be great) > > Added. Thanks! > > I'd just still like to see a successful koji scratch build (which means > > waiting for the dependencies to be imported into rawhide). > > Not because I don't trust local builds, but because we still need to check > > whether "noarch" subpackages are actually built identically on the different > > architectures. > > I understand and agree. New URLs: I mean, it's not blocking the review, but if it causes build failures you'll have to fix it either way, before or after the import. > Spec URL: > https://jjames.fedorapeople.org/antlr4-cpp-runtime/antlr4-cpp-runtime.spec > SRPM URL: > https://jjames.fedorapeople.org/antlr4-cpp-runtime/antlr4-cpp-runtime-4.8-2. > fc32.src.rpm > RPMLINTRC URL: > https://jjames.fedorapeople.org/antlr4-cpp-runtime/antlr4-cpp-runtime. > rpmlintrc Those links return 404s for me. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-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/package-review@xxxxxxxxxxxxxxxxxxxxxxx
