Spec URL: https://dridi.fedorapeople.org/review/hare.spec SRPM URL: https://dridi.fedorapeople.org/review/hare-0.25.2-7.fc43.src.rpm Description: Hare is a systems programming language. Fedora Account System Username: dridi A few noteworthy things about this package. It ships the Hare build driver and the Hare standard library, and RPM macros to automate RPM dependency management for Hare modules (Requires, Provides, %generate_buildrequires). This package bootstraps itself, such that it relies on the RPM macros to configure the build, or generate a 'Provides: hare_mod(...)' for each Hare module from the standard library. The bootstrap happens in a single pass, because the upstream build system for this package will first manually bootstrap the Hare build driver, and then rebuild it such that it honors HAREFLAGS, LDFLAGS, and other influential environment variables. All of the bootstrap and dependency automation relies on patches I submitted upstream. Unfortunately, this single pass bootstrap means that fedora-review will fail to parse the spec, because of the RPM macros both packaged and loaded by the spec. Apologies for the inconvenience. This package submission is part of this Fedora change: https://fedoraproject.org/wiki/Changes/HareProgrammingLanguage
Can the spec file be modified to conditionally run the slow tests? See https://rpm-software-management.github.io/rpm/manual/conditionalbuilds.html Can the spec file be modified to produce a macro package first, thereby allowing for a two stage bootstrap? It is helpful to be able to run the review tool when updating, not just on initial import.
Apologies for coming back later than I'd hoped, my spare time was scarcer than anticipated. > Can the spec file be modified to conditionally run the slow tests? I let the XXX comment and eventually forgot about it, but that was my intention. > Can the spec file be modified to produce a macro package first, thereby allowing for a two stage bootstrap? > > It is helpful to be able to run the review tool when updating, not just on initial import. I don't dispute the value of recurring reviews of a package, since packaging guidelines are a moving target. I'm reluctant to the idea of introducing a bootstrap step in the process. I made some effort to enable automatic dependency management and managed to upstream all the changes needed to support that. I added a hare-filesystem sub-package for a SHOULD NOT entry in the guidelines, at the expense of potentially running dependency generator more than once (not changing the final results). If I'm spending time on this fedora-review problem, I'd rather take it the other way around and teach it to parse the spec with sources. For example with the -r option since the spec is extracted alongside other sources in an srpm-unpacked directory. It is unfortunate that fedora-review fails in the presence of a %load macro, but I'd rather keep it and optimize for maintenance rather than review (or fix fedora-review). If the ruby package was submitted today, it would run into the same problem. It's probably possible to kick-start an automated review by manually expanding the %load macro in a copy of the spec, to get the initial template and supported checks. It's just not a seamless 'fedora-review -b 2385991` invocation.
*** Bug 2262452 has been marked as a duplicate of this bug. ***
Ok, updating fedora-review tool would be good.
You can check out my branch: https://pagure.io/FedoraReview/pull-request/533 Then this should be enough to kick-start a review: python3 try-fedora-review -b 2385991 At least it WorksOnMyMachine™. I had a quick look and there is a lot of rpmlint noise that I addressed with this: $ cat hare.rpmlintrc # Empty READMEs allow empty modules to have submodules addFilter("zero-length /usr/src/hare/stdlib/.*/README") # Empty "tagged" source files can override "default" files addFilter("zero-length /usr/src/hare/stdlib/.*[.].*") # Multiple tags may need the same sources addFilter("files-duplicate /usr/src/hare/stdlib/.*") # False positive for hare-rpm-macros addFilter("only-non-binary-in-usr-lib") # This warning should be case-sensitive addFilter("name-repeated-in-summary Hare") There is also one failing check out of the box: [!]: Spec file according to URL is the same as in SRPM. Note: Spec file as given by url is not the same as in SRPM (see attached diff). But again, it looks like a false positive that could be automated away: --- /home/dridi/fedora/FedoraReview/2385991-hare/srpm/hare.spec 2025-09-20 00:05:47.623689505 +0200 +++ /home/dridi/fedora/FedoraReview/2385991-hare/srpm-unpacked/hare.spec 2025-07-28 02:00:00.000000000 +0200 @@ -1,2 +1,12 @@ +## START: Set by rpmautospec +## (rpmautospec version 0.8.1) +## RPMAUTOSPEC: autorelease, autochangelog +%define autorelease(e:s:pb:n) %{?-p:0.}%{lua: + release_number = 7; + base_release_number = tonumber(rpm.expand("%{?-b*}%{!?-b:1}")); + print(release_number + base_release_number - 1); +}%{?-e:.%{-e*}}%{?-s:.%{-s*}}%{!?-n:%{?dist}} +## END: Set by rpmautospec + %undefine _auto_set_build_flags And another diff for %autochangelog. I have not looked at the remaining criteria myself.
Hello, I do realize that this is possibly an old ticket. I am sorry that it hasn't been reviewed yet. Let me trigger the Fedora Review Service to see if the package builds successfully. Hopefully, a green check mark will attract some reviewer. If I am resurrecting an old ticket that you are not interested in anymore, my apologies, feel free to close it. [fedora-review-service-build]
Copr build: https://copr.fedorainfracloud.org/coprs/build/9820242 (succeeded) Review template: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2385991-hare/fedora-rawhide-x86_64/09820242-hare/fedora-review/review.txt Please take a look if any issues were found. --- This comment was created by the fedora-review-service https://github.com/FrostyX/fedora-review-service If you want to trigger a new Copr build, add a comment containing new Spec and SRPM URLs or [fedora-review-service-build] string.