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.
Hi, Thought I would help a little and look at this package for you. * Can this be brought up to latest upstream 0.26.0? * Builds: - Local: Good - COPR: Good Will dig deeper if we move to latest upstream.# Regards Phil
Spec URL: https://dridi.fedorapeople.org/review/hare.spec SRPM URL: https://dridi.fedorapeople.org/review/hare-0.26.0-1.fc45.src.rpm Description: Hare is a systems programming language. Fedora Account System Username: dridi Hi Phil, Your help is very much appreciated. I updated my COPR repository with new builds of harec and hare 0.26.0, I just recently updated my local packages. A formal update of harec on rawhide should take little effort, this was enough for my local and COPR builds: --- harec.spec +++ harec.spec @@ -1,6 +1,6 @@ %undefine _auto_set_build_flags -%global srcver 0.25.2 +%global srcver 0.26.0 %global pkgsrc %{srcver}%{?srcpre:-%{srcpre}} Name: harec For the hare package, I added an upstream patch to fix a regression that would prevent automatic dependency management. Please note that you can't use fedora-review out of the box because of the single-step bootstrap. See in a previous comment, I submitted a pull request to allow such a bootstrap in fedora-review, and meanwhile I closed it because another one solves this problem and then more. Unfortunately nothing got merged since then. Cheers
Created attachment 2131478 [details] The .spec file difference from Copr build 9820242 to 10180924
Copr build: https://copr.fedorainfracloud.org/coprs/build/10180924 (failed) Build log: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2385991-hare/fedora-rawhide-x86_64/10180924-hare/builder-live.log.gz Please make sure the package builds successfully at least for Fedora Rawhide. - If the build failed for unrelated reasons (e.g. temporary network unavailability), please ignore it. - If the build failed because of missing BuildRequires, please make sure they are listed in the "Depends On" field --- 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.
Hi, Looks good building both. Once 'harec' has been updated to '026.0', we can give this one the final test around and push it for sponsorship. Regards Phil
Benson could you please upgrade harec to 0.26.0 in Rawhide?
Phil, do you need a sponsor to approve packages? I'm already part of the packager group.
Dridi, updated in Rawhide. You have commit rights to make changes to harec, so feel free to also update as needed.
I'll take over this review, as it seems to be stalled. Fedora review template at <https://fedorapeople.org/~gotmax23/reviews/hare-0.26.0/hare/>. I applied https://pagure.io/FedoraReview/pull-request/533 locally so this would work. Search for "NOTE" for my comments. Package Review ============== Legend: [x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated ===== MUST items ===== Generic: [x]: Package successfully compiles and builds into binary rpms on at least one supported primary architecture. Note: Using prebuilt packages [x]: Package is licensed with an open-source compatible license and meets other legal requirements as defined in the legal section of Packaging Guidelines. [!]: License field in the package spec file matches the actual license. Note: Checking patched sources after %prep for licenses. Licenses found: "Unknown or generated", "*No copyright* Mozilla Public License 2.0", "Mozilla Public License 2.0", "BSD 3-Clause License and/or Mozilla Public License 2.0", "MIT License", "GNU General Public License, Version 3", "MIT License and/or Mozilla Public License 2.0". 201 files have unknown license. Detailed output of licensecheck in /home/gotmax/dev/packaging/reviews/hare-0.26.0/built/hare/licensecheck.txt I see that the main package is licensed under GPL3 and the stdlib is licensed under MPL. As for the rpm-macros package, it's fine to license it under MIT, but the package needs to include the MIT license text in %license, in that case. For the filesystem package, I'd choose LicenseRef-Not-Copyrightable as the license, since it doesn't include any code at all. In the future, you may also want to consider splitting the macros and filesystem package into a separate SRPM to make them easier to maintain. Feel free to ping me for future package reviews. For now, I am focussing on the packaging itself. I gave the RPM macro/generator code a cursory look and will leave the rest of that review to the FPC Guidelines PR review. It looks like there's some other code with MIT and BSD license headers. See <https://fedorapeople.org/~gotmax23/reviews/hare-0.26.0/hare/licensecheck.txt>. You need the appropriate AND statements to account for these and a short comment above the License: statement outlining which license applies to which code. [!]: License file installed when any subpackage combination is installed. NOTE: Not entirely. See the above note. [x]: Package must own all directories that it creates. Note: Directories without known owners: /usr/lib/rpm/fileattrs, /usr/lib/rpm/macros.d, /usr/lib/rpm NOTE: This is fine. The rpm package owns these directories. [x]: %build honors applicable compiler flags or justifies otherwise. [x]: Package contains no bundled libraries or specifies bundled libraries with Provides: bundled(<libname>) if unbundling is not possible. [x]: Changelog in prescribed format. [x]: Sources contain only permissible code or content. [-]: Package contains desktop file if it is a GUI application. [-]: Development files must be in a -devel package [x]: Package uses nothing in %doc for runtime. [x]: Package consistently uses macros (instead of hard-coded directory names). [x]: Package is named according to the Package Naming Guidelines. [x]: Package does not generate any conflict. [x]: Package obeys FHS, except libexecdir and /usr/target. [-]: If the package is a rename of another package, proper Obsoletes and Provides are present. [x]: Requires correct, justified where necessary. NOTE: Where does the tzdata requirement come from? Can you add a comment above it? Does it need to be repeated in both hare and hare-stdlib? [x]: Spec file is legible and written in American English. [-]: Package contains systemd file(s) if in need. [x]: Useful -debuginfo package or justification otherwise. [!]: Package is not known to require an ExcludeArch tag. NOTE: %hare_arches is used. This is fine. [x]: Package complies to the Packaging Guidelines [x]: Package installs properly. [!]: Rpmlint is run on all rpms the build produces. Note: There are rpmlint messages (see attachment). NOTE: "name-repeated-in-summary Hare" should be fixed (i.e., remove "hare" from the package Summary). [x]: If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package is included in %license. [x]: The License field must be a valid SPDX expression. [x]: Package requires other packages for directories it uses. [x]: Package does not own files or directories owned by other packages. [x]: Package uses either %{buildroot} or $RPM_BUILD_ROOT [x]: Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the beginning of %install. [x]: Macros in Summary, %description expandable at SRPM build time. [x]: Dist tag is present. [x]: Package does not contain duplicates in %files. [x]: Permissions on files are set properly. [x]: Package must not depend on deprecated() packages. [x]: Package use %makeinstall only when make install DESTDIR=... doesn't work. [x]: Package is named using only allowed ASCII characters. [x]: Package does not use a name that already exists. [x]: Package is not relocatable. [x]: Sources used to build the package match the upstream source, as provided in the spec URL. [x]: Spec file name must match the spec package %{name}, in the format %{name}.spec. [x]: File names are valid UTF-8. [x]: Large documentation must go in a -doc subpackage. Large could be size (~1MB) or number of files. Note: Documentation size is 3640 bytes in 2 files. [x]: Packages must not store files under /srv, /opt or /usr/local ===== SHOULD items ===== Generic: [x]: Reviewer should test that the package builds in mock. [!]: If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it. This is not a requirement but it would be good if the embedded MIT and BSD headers were in separate text files that could be marked with %license. [x]: Final provides and requires are sane (see attachments). [-]: Fully versioned dependency in subpackages if applicable. Note: No Requires: %{name}%{?_isa} = %{version}-%{release} in hare- stdlib , hare-rpm-macros , hare-filesystem NOTE: This check is wrong. All those subpackages are noarch, so we can't use %__isa dependent Requires. [?]: Package functions as described. [!]: Latest version is packaged. NOTE: Please update to 0.26.0.1 [x]: Package does not include license text files separate from upstream. [!]: Patches link to upstream bugs/comments/lists or are otherwise justified. NOTE: A short comment above the Patch invocation would be suitable. [-]: Sources are verified with gpgverify first in %prep if upstream publishes signatures. Note: gpgverify is not used. [!]: Package should compile and build into binary rpms on all supported architectures. NOTE: hare/qbe does not support every arch. This is fine. [x]: %check is present and all tests pass. [!]: Packages should try to preserve timestamps of original installed files. NOTE: It'd be preferable to sed or patch the Makefile so -p is passed to install to preserve timestamps. [x]: Spec use %global instead of %define unless justified. [x]: Buildroot is not present [x]: Package has no %clean section with rm -rf %{buildroot} (or $RPM_BUILD_ROOT) [x]: No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin. [x]: Packager, Vendor, PreReq, Copyright tags should not be in spec file [x]: Sources can be downloaded from URI in Source: tag [x]: SourceX is a working URL. ===== EXTRA items ===== Generic: [!]: Spec file according to URL is the same as in SRPM. Note: Bad spec filename: /home/gotmax/dev/packaging/reviews/hare-0.26.0/built/hare/srpm- unpacked/hare.spec See: (this test has no URL) [x]: Rpmlint is run on debuginfo package(s). Note: No rpmlint messages. [x]: Rpmlint is run on all installed packages. [x]: Large data in /usr/share should live in a noarch subpackage if package is arched. Other notes: - I see there's a `# XXX: HARETEST_INCLUDE=slow` comment. What's the story there? - Definitely not a blocker, but I prefer the var:method(...) syntax in lua over the type.method(var, ...) syntax (e.g., macros.hare_arches:gmatch(...) instead of string.gmatch(macros.hare_arches, ...)) Rpmlint ------- Checking: hare-0.26.0-1.fc45.x86_64.rpm hare-stdlib-0.26.0-1.fc45.noarch.rpm hare-rpm-macros-0.26.0-1.fc45.noarch.rpm hare-filesystem-0.26.0-1.fc45.noarch.rpm hare-0.26.0-1.fc45.src.rpm ============================ rpmlint session starts ============================ rpmlint: 2.8.0 configuration: /usr/lib/python3.14/site-packages/rpmlint/configdefaults.toml /etc/xdg/rpmlint/fedora-legacy-licenses.toml /etc/xdg/rpmlint/fedora-spdx-licenses.toml /etc/xdg/rpmlint/fedora.toml /etc/xdg/rpmlint/scoring.toml /etc/xdg/rpmlint/users-groups.toml /etc/xdg/rpmlint/warn-on-functions.toml rpmlintrc: [PosixPath('/tmp/tmpwib85_tt')] checks: 32, packages: 5 hare-stdlib.noarch: E: zero-length /usr/src/hare/stdlib/rt/+aarch64/cpuid.s hare-stdlib.noarch: E: zero-length /usr/src/hare/stdlib/rt/+riscv64/cpuid.s hare.spec: W: patch-not-applied Patch0: 0001-hare-parse-fix-crash-on-invalid-input.patch hare-rpm-macros.noarch: W: only-non-binary-in-usr-lib hare-filesystem.noarch: W: no-documentation hare-rpm-macros.noarch: W: no-documentation hare.src: W: name-repeated-in-summary Hare hare.x86_64: W: name-repeated-in-summary Hare 5 packages and 0 specfiles checked; 2 errors, 6 warnings, 208 filtered, 2 badness; has taken 1.4 s Rpmlint (debuginfo) ------------------- Checking: hare-debuginfo-0.26.0-1.fc45.x86_64.rpm ============================ rpmlint session starts ============================ rpmlint: 2.8.0 configuration: /usr/lib/python3.14/site-packages/rpmlint/configdefaults.toml /etc/xdg/rpmlint/fedora-legacy-licenses.toml /etc/xdg/rpmlint/fedora-spdx-licenses.toml /etc/xdg/rpmlint/fedora.toml /etc/xdg/rpmlint/scoring.toml /etc/xdg/rpmlint/users-groups.toml /etc/xdg/rpmlint/warn-on-functions.toml rpmlintrc: [PosixPath('/tmp/tmpy7jyw232')] checks: 32, packages: 1 1 packages and 0 specfiles checked; 0 errors, 0 warnings, 11 filtered, 0 badness; has taken 0.4 s Rpmlint (installed packages) ---------------------------- (none): E: there is no installed rpm "hare-stdlib". (none): E: there is no installed rpm "hare-debuginfo". (none): E: there is no installed rpm "hare-rpm-macros". (none): E: there is no installed rpm "hare". (none): E: there is no installed rpm "hare-filesystem". There are no files to process nor additional arguments. Nothing to do, aborting. ============================ rpmlint session starts ============================ rpmlint: 2.9.0 configuration: /usr/lib/python3.14/site-packages/rpmlint/configdefaults.toml /etc/xdg/rpmlint/fedora-spdx-licenses.toml /etc/xdg/rpmlint/fedora.toml /etc/xdg/rpmlint/scoring.toml /etc/xdg/rpmlint/users-groups.toml /etc/xdg/rpmlint/warn-on-functions.toml checks: 32, packages: 5 0 packages and 0 specfiles checked; 0 errors, 0 warnings, 0 filtered, 0 badness; has taken 0.0 s Source checksums ---------------- https://git.sr.ht/~sircmpwn/hare/archive/0.26.0.tar.gz#/hare-0.26.0.tar.gz : CHECKSUM(SHA256) this package : 72a0f05e172523df333b2cce4c3bf8181a05d71a62531b89565e9913b2430cae CHECKSUM(SHA256) upstream package : 525ee699bdbade390eb1e35525ab9b5b3032c5f42cddce49d9176bbdc9172d04 However, diff -r shows no differences Requires -------- hare (rpmlib, GLIBC filtered): binutils hare-filesystem hare-rpm-macros hare-stdlib harec libc.so.6()(64bit) qbe rtld(GNU_HASH) tzdata hare-stdlib (rpmlib, GLIBC filtered): hare-filesystem tzdata hare-rpm-macros (rpmlib, GLIBC filtered): /usr/bin/sh hare-filesystem (rpmlib, GLIBC filtered): Provides -------- hare: hare hare(x86-64) hare-stdlib: hare-stdlib hare-rpm-macros: hare-rpm-macros rpm_macro(_hare_dynamic) rpm_macro(build_hareflags) rpm_macro(hare_buildrequires) rpm_macro(hare_ldlinkflags) rpm_macro(hare_moddir) rpm_macro(hare_srcdir) rpm_macro(hare_stdlib) rpm_macro(hare_tooldir) hare-filesystem: hare-filesystem Generated by fedora-review 0.11.0 (05c5b26) last change: 2025-11-29 Command line :/usr/bin/fedora-review -prn hare Buildroot used: fedora-rawhide-x86_64 Active plugins: Shell-api, Generic Disabled plugins: Python, SugarActivity, C/C++, Perl, Haskell, fonts, Java, R, Ocaml, PHP Disabled flags: EXARCH, EPEL6, EPEL7, DISTTAG, BATCH
> [!]: Spec file according to URL is the same as in SRPM. This check is also wrong. You can ignore it.
Thanks a lot for this initial review, I'll reply to the items with notes now, and I will later work on a new spec/SRPM submission, using this reply as a task summary for my future self. > [!]: License file installed when any subpackage combination is installed. > NOTE: Not entirely. See the above note. Good catch. I must admit that I followed upstream's licensing model with MPL2 for the standard libraries and GPL3 for programs, looking at SPDX comments for those only, not checking every single source file. I'll look at the details and bring this topic upstream if I find inconsistencies. In particular, I'm surprised to see more than one MPL2 variant. Regarding the RPM macros and my choice of MIT, I actually went with Fedora's licensing for spec files and packaging-related deliverables. If there are also MIT licensed sources in Hare, I will of course take that into account in license tags, but I'll have my closer look offline. > [x]: Requires correct, justified where necessary. > NOTE: Where does the tzdata requirement come from? Can you add a comment above it? > Does it need to be repeated in both hare and hare-stdlib? This one is tricky, and I have not tried to automate it yet, but I probably should. It should be required at least by hare-stdlib, because the time::date Hare module needs it. The hare package can get it indirectly from hare-stdlib and frankly I don't remember why I put it in both, maybe I forgot to remove it from the hare package. Now, any program using the time::date module should include this as a dependency. This is something I'd like to automate, but it's unrealistic to generalize to other modules loading specific system-wide resources in the future... I'll probably add a comment for starters, and something to the packaging guidelines draft. > [!]: Rpmlint is run on all rpms the build produces. > Note: There are rpmlint messages (see attachment). > NOTE: "name-repeated-in-summary Hare" should be fixed (i.e., remove "hare" from the package Summary). This is what my local hare.rpmlintrc file looks like: # 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") I didn't see a point in "name-repeated-in-summary Hare" especially when it's the capitalized form. Regarding empty READMEs, I think that meanwhile this has become a non-issue as all modules got at least a one-liner description at the beginning of the README. > [!]: Latest version is packaged. > NOTE: Please update to 0.26.0.1 TIL! > [!]: Patches link to upstream bugs/comments/lists or are otherwise > justified. > NOTE: A short comment above the Patch invocation would be suitable. This patch comes from the master branch, so I didn't feel the need for a comment. In fact, it's the very first patch that landed after the 0.26.0 release, but it did not make it in 0.26.0.1. > [!]: Packages should try to preserve timestamps of original installed > files. > NOTE: It'd be preferable to sed or patch the Makefile so -p is passed to > install to preserve timestamps. I think I will submit a patch upstream and add it to the spec. This time there will be a comment with a link to the mailing list thread, as there was with previous iterations of this package submission ;-) I already upstreamed changes to the build driver to support automatic dependency generators. > [!]: Spec file according to URL is the same as in SRPM. > Note: Bad spec filename: > /home/gotmax/dev/packaging/reviews/hare-0.26.0/built/hare/srpm- > unpacked/hare.spec > See: (this test has no URL) This looks like a side effect of patching fedora-review to feed it the SRPM's spec instead of a separate one. I'm not sure my own patch had this problem, I don't remember. > - I see there's a `# XXX: HARETEST_INCLUDE=slow` comment. What's the story there? I didn't want to waste time waiting for tests feeding GBs of zeros to hash functions while I was iterating, so I kept a reminder. That would be something like '%make_build check HARETEST_INCLUDE=slow', or maybe via the environment. > - Definitely not a blocker, but I prefer the var:method(...) syntax in lua over the type.method(var, ...) syntax (e.g., macros.hare_arches:gmatch(...) instead of string.gmatch(macros.hare_arches, ...)) Thanks for the tip. I literally have no preference, this is my very first lua scripting in a spec file. I'm a total noob in this area. > https://git.sr.ht/~sircmpwn/hare/archive/0.26.0.tar.gz#/hare-0.26.0.tar.gz : > CHECKSUM(SHA256) this package : 72a0f05e172523df333b2cce4c3bf8181a05d71a62531b89565e9913b2430cae > CHECKSUM(SHA256) upstream package : 525ee699bdbade390eb1e35525ab9b5b3032c5f42cddce49d9176bbdc9172d04 > However, diff -r shows no differences I didn't repack the source archive, so something must have changed on sourcehut (like gzip compression level in zlib or other). This will become a moot point since my next submission will target the 0.26.0.1 release. > hare.spec: W: patch-not-applied Patch0: 0001-hare-parse-fix-crash-on-invalid-input.patch > (snip) > Provides > -------- > (snip) > hare-stdlib: > hare-stdlib This is very wrong, hare-stdlib should provide hare_mod(...) for each module, and the patch is here to prevent a crash happening during dependency generation. I probably have local changes I made since the last submission.
Thanks for working on this and responding to the feedback. Let me know when you're ready for another review :). > Regarding the RPM macros and my choice of MIT, I actually went with Fedora's licensing for spec files and packaging-related deliverables. Yeah, that makes sense to me, you just have to include the MIT license text with %license in the actual package to stay in line with the Licensing Guidelines. > This patch comes from the master branch, so I didn't feel the need for a comment. It's still good to have *something*, even a one sentence "This patch was backported from upstream." comment would suffice. > This looks like a side effect of patching fedora-review to feed it the SRPM's spec instead of a separate one. I'm not sure my own patch had this problem, I don't remember. I assumed it was because I used the -r/--rpm-spec and/or -p/--prebuilt fedora-review flags. I don't think it had to do with your patch. >> - I see there's a `# XXX: HARETEST_INCLUDE=slow` comment. What's the story there? > > I didn't want to waste time waiting for tests feeding GBs of zeros to hash functions while I was iterating, so I kept a reminder. I would suggest a bcond here. At the top of the specfile, you could include ``` # Enable this to run the slow tests %bcond slow_tests 0 ``` and then use ``` %make_build check %{?with_slow_tests:HARETEST_INCLUDE=slow} ``` to only run the slow tests when the slow_tests bcond is enabled. > Thanks for the tip. I literally have no preference, this is my very first lua scripting in a spec file. I'm a total noob in this area. You're also welcome to use normal shell scripting here if you prefer that approach.