https://bugzilla.redhat.com/show_bug.cgi?id=1795470 --- Comment #7 from Jerry James <loganjerry@xxxxxxxxx> --- (In reply to Fabio Valentini from comment #5) > Small first suggestion: If you use the %{expand:} trick for the description, > you'll have to put "%description (-n foo) %_desc" on the same line, > otherwise you introduce a leading newline at the beginning of the resulting > description text. Good catch. Fixed. (In reply to Fabio Valentini from comment #6) > Wow, with all that language support, it's a pretty gnarly package ... :D It sure is, and I even punted on the JavaScript runtime. > - Why not use the "standard method" of installing go "packages" (with the go > macros)? 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. > - 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. > - 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. > - 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. :-) > - Patches are commented, but no reference to upstream issues or something > like that (adding that would be great) Added. > 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: 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 -- 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
