Fedora Account System
Red Hat Associate
Red Hat Customer
Spec URL: https://raw.githubusercontent.com/blacknon/hwatch/0.4.2/package/fedora/hwatch.spec SRPM URL: https://github.com/blacknon/hwatch/releases/download/0.4.2/hwatch-0.4.2-1.fc44.src.rpm Description: hwatch is an interactive terminal application similar to watch. It records command output over time, lets users inspect history, view differences between runs, export logs, and optionally trigger follow-up commands when output changes. Fedora Account System Username: blacknon Notes: - The package uses Fedora Rust packaging macros. - Shell completions and the man page are installed by the package. - The previous termwiz dependency was removed from the upstream ANSI parsing layer to simplify Fedora dependency resolution. - I am a new Fedora package contributor and will need sponsorship. Reproducible: Always
Copr build: https://copr.fedorainfracloud.org/coprs/build/10406783 (succeeded) Review template: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2463848-hwatch/fedora-rawhide-x86_64/10406783-hwatch/fedora-review/review.txt Found issues: - Upstream MD5sum check error, diff is in /var/lib/copr-rpmbuild/results/hwatch/diff.txt Read more: https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/ Please know that there can be false-positives. --- 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.
Updated spec and SRPM URLs after fixing the source tarball mismatch reported by fedora-review-service. Spec URL: https://raw.githubusercontent.com/blacknon/hwatch/0.4.2/package/fedora/hwatch.spec SRPM URL: https://github.com/blacknon/hwatch/releases/download/0.4.2/hwatch-0.4.2-2.src.rpm For reference: - source tarball URL: https://github.com/blacknon/hwatch/releases/download/0.4.2/hwatch-0.4.2.tar.gz - source tarball SHA256: a556fcd7bb95ff1ba9977db77e477cd844d074f417b246070ab7f883d5a05f70 - SRPM SHA256: b6e1ad3ba360b7379caf80e8c093e9d678b0edb08d991f1ac98b8c9461418099
Created attachment 2138651 [details] The .spec file difference from Copr build 10406783 to 10406970
Copr build: https://copr.fedorainfracloud.org/coprs/build/10406970 (succeeded) Review template: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2463848-hwatch/fedora-rawhide-x86_64/10406970-hwatch/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, I will pick this one up for the review stage. Regards Phil
Hi, Looks good here. One personal thing. I prefer an empty line between changelog entries. Marking as '+'. If you are in the 'packager' group, you can now request the repo for the package and then import the initial rpm. If not in the 'packager' group, please file a sponsorship request at https://pagure.io/packager-sponsors/issues Regards Phil
Hi Phil, Thank you very much for the review and for marking it as approved. I also appreciate the changelog formatting suggestion. I am not in the packager group yet, so I will file a sponsorship request. Regards blacknon
(In reply to Phil Wyett from comment #6) > Hi, > > Looks good here. > > One personal thing. I prefer an empty line between changelog entries. > > Marking as '+'. > > If you are in the 'packager' group, you can now request the repo for the > package and then import the initial rpm. > > If not in the 'packager' group, please file a sponsorship request at > https://pagure.io/packager-sponsors/issues > > Regards > > Phil This is a very very bare-bones review. I don't think this is great, especially given that this is the submitters's first package submission. Additionally, I don't agree with the fedora-review+ flag here. The spec file is very much not in line with the latest Rust packaging guidelines. The guidelines have a template that is suitable for packages like this: https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/#_non_crate_rust_project Additionally, the monkey-patching for "broken" Fedora crates looks entirely unnecessary. I don't even understand how that *works* since /usr/share should be read-only during the build ... Also, patching out test dependencies looks unnecessary too - they are all packaged, looks like the %cargo_generate_buildrequires macro is just called incorrectly.
Hi Fabio Thank you feedback. I will update the package based on your comments and upload the revised Spec and SRPM.
Hi Fabio, Thank you for the review. I updated the spec to follow the current Rust packaging guidelines more closely: - removed the monkey-patching - stopped removing test-only dependencies - switched to %cargo_generate_buildrequires -a -t - switched %check to %cargo_test Updated files: SRPM: https://github.com/blacknon/hwatch/releases/download/0.4.2/hwatch-0.4.2-3.src.rpm Spec: https://github.com/blacknon/hwatch/releases/download/0.4.2/hwatch-0.4.2-3.spec The SRPM build succeeds locally. The remaining full build failure seems to come from Fedora’s packaged compact_str 0.9.0 crate, which references ../README.md but does not ship that file. Would you prefer a temporary downstream workaround, or should this be treated as a dependency-side issue first? Thanks.
> The remaining full build failure seems to come from Fedora’s packaged compact_str 0.9.0 crate, which references ../README.md but does not ship that file. > Would you prefer a temporary downstream workaround, or should this be treated as a dependency-side issue first? Sorry, I don't understand. The package builds successfully. What do you mean to say here? > I updated the spec to follow the current Rust packaging guidelines more closely: This improves some things, but you're still doing some things that are either out of date or not following "SHOULD" rules, and some of your changes made things *worse*. 1. BuildRequires: gcc What is this for? This is a Rust package built with cargo. 2. BuildRequires: rust-packaging This MUST be "cargo-rpm-macros". rust-packaging is an old alias that is only present for backwards compatibility. https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/#_mandatory_buildrequires 3. You're not handling licenses of statically linked dependencies at all. I would recommend to look at the template again, and / or at existing similar packages (for example, nushell). 4. You're using "%cargo_install". The template for packages like this uses plain "install" command, that is simpler in this case. 5. The way you're skipping specific tests is broken. The newline escaping interferes with RPM macro argument handling. It causes a ' ' argument to get passed, filtering out all tests that don't contain a " " character (which is all of them). test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 100 filtered out; finished in 0.00s
> > The remaining full build failure seems to come from Fedora’s packaged compact_str 0.9.0 crate, which references ../README.md but does not ship that file. > > Would you prefer a temporary downstream workaround, or should this be treated as a dependency-side issue first? > > Sorry, I don't understand. The package builds successfully. What do you mean to say here? Sorry, that wording was misleading. I was referring to Fedora's packaged `compact_str` crate, not to `hwatch` itself. For context, this came from a local Fedora package build test during the `%build` phase of `rpmbuild -bb`, where Fedora's packaged `compact_str` 0.9.0 failed to compile because `../README.md` was missing from `/usr/share/cargo/registry/compact_str-0.9.0/`. ``` error: couldn't read `/usr/share/cargo/registry/compact_str-0.9.0/src/../README.md`: No such file or directory (os error 2) --> /usr/share/cargo/registry/compact_str-0.9.0/src/lib.rs:1:10 | 1 | #![doc = include_str!("../README.md")] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: attribute value must be a literal --> /usr/share/cargo/registry/compact_str-0.9.0/src/lib.rs:1:10 | 1 | #![doc = include_str!("../README.md")] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: could not compile `compact_str` (lib) due to 2 previous errors ``` I've been making various modifications to the specs to circumvent this issue, but what should I do this time? > > I updated the spec to follow the current Rust packaging guidelines more closely: > > This improves some things, but you're still doing some things that are either out of date or not following "SHOULD" rules, and some of your changes made things *worse*. > > 1. BuildRequires: gcc > > What is this for? This is a Rust package built with cargo. > > 2. BuildRequires: rust-packaging > > This MUST be "cargo-rpm-macros". rust-packaging is an old alias that is only present for backwards compatibility. > https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/#_mandatory_buildrequires > 4. You're using "%cargo_install". > > The template for packages like this uses plain "install" command, that is simpler in this case. > > 5. The way you're skipping specific tests is broken. > > The newline escaping interferes with RPM macro argument handling. It causes a ' ' argument to get passed, filtering out all tests that don't contain a " " character (which is all of them). > > test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 100 filtered out; finished in 0.00s Thank you, you were right on all of these points. I changed them. The main causes were forgetting to delete something or a lack of understanding. I have corrected it. - removed `BuildRequires: gcc` - replaced `BuildRequires: rust-packaging` with `BuildRequires: cargo-rpm-macros` - replaced `%cargo_install` with plain `install` - fixed the `%cargo_test` invocation so the skipped test names are passed correctly on a single line > 3. You're not handling licenses of statically linked dependencies at all. > > I would recommend to look at the template again, and / or at existing similar packages (for example, nushell). Thank you. I changed now updated the `License:` field to reflect the statically linked Rust dependencies and kept the bundled dependency license output in `LICENSE.dependencies`. The above corrections have been applied to the following files. - https://github.com/blacknon/hwatch/releases/download/0.4.2/hwatch-0.4.2-4.spec - https://github.com/blacknon/hwatch/releases/download/0.4.2/hwatch-0.4.2-4.src.rpm
Created attachment 2143508 [details] The .spec file difference from Copr build 10522178 to 10527356
Copr build: https://copr.fedorainfracloud.org/coprs/build/10527356 (failed) Build log: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2463848-hwatch/fedora-rawhide-x86_64/10527356-hwatch/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.
(In reply to blacknon from comment #12) > > > The remaining full build failure seems to come from Fedora’s packaged compact_str 0.9.0 crate, which references ../README.md but does not ship that file. > > > Would you prefer a temporary downstream workaround, or should this be treated as a dependency-side issue first? > > > > Sorry, I don't understand. The package builds successfully. What do you mean to say here? > > Sorry, that wording was misleading. > > I was referring to Fedora's packaged `compact_str` crate, not to `hwatch` > itself. > For context, this came from a local Fedora package build test during the > `%build` phase of `rpmbuild -bb`, where Fedora's packaged `compact_str` > 0.9.0 failed to compile because `../README.md` was missing from > `/usr/share/cargo/registry/compact_str-0.9.0/`. Ok - this tells me that you used a non-standard build environment (i.e. not "mock"), probably some kind of container, where the RPM configuration prevents installation of files marked as "%doc". This does not affect package builds in Fedora (or COPR). We do consider this kind of issue to be a "packaging bug", but also treat it as very low priority since having the file marked as %doc only breaks things in non-standard build environments. > I've been making various modifications to the specs to circumvent this > issue, but what should I do this time? Don't. It's a non-issue for normal package builds. We only ever find out about this issue when users have non-standard build environments locally. :) > > 3. You're not handling licenses of statically linked dependencies at all. > > > > I would recommend to look at the template again, and / or at existing similar packages (for example, nushell). > > Thank you. > I changed now updated the `License:` field to reflect the statically linked > Rust dependencies and kept the bundled dependency license output in > `LICENSE.dependencies`. > > The above corrections have been applied to the following files. This is not really correct. In particular, clauses like "Apache-2.0 OR MIT" cannot just be collapsed into other "Apache-2.0"s and "MIT"s - the "OR" needs to be preserved.
(In reply to Fabio Valentini from comment #15) > Ok - this tells me that you used a non-standard build environment (i.e. not > "mock"), probably some kind of container, where the RPM configuration > prevents installation of files marked as "%doc". This does not affect > package builds in Fedora (or COPR). > > We do consider this kind of issue to be a "packaging bug", but also treat it > as very low priority since having the file marked as %doc only breaks things > in non-standard build environments. > > Don't. It's a non-issue for normal package builds. > We only ever find out about this issue when users have non-standard build > environments locally. :) Thank you. I understand. I thought this was something that needed to be addressed. In that case, I'll ignore this error. > This is not really correct. In particular, clauses like "Apache-2.0 OR MIT" > cannot just be collapsed into other "Apache-2.0"s and "MIT"s - the "OR" > needs to be preserved. Thank you, I probably understand. I thought the way helix was written might be helpful, so I rewrote it based on that. I update also about comment #14 and uploaded the file below. - https://github.com/blacknon/hwatch/releases/download/0.4.2/hwatch-0.4.2-5.spec - https://github.com/blacknon/hwatch/releases/download/0.4.2/hwatch-0.4.2-5.src.rpm
Created attachment 2143693 [details] The .spec file difference from Copr build 10527356 to 10530695
Copr build: https://copr.fedorainfracloud.org/coprs/build/10530695 (failed) Build log: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2463848-hwatch/fedora-rawhide-x86_64/10530695-hwatch/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.
I readed Comment 18. Spec URL: https://github.com/blacknon/hwatch/releases/download/0.4.2/hwatch-0.4.2-6.spec SRPM URL: https://github.com/blacknon/hwatch/releases/download/0.4.2/hwatch-0.4.2-6.src.rpm This updates the package to 0.4.2-6. The main change is to generate LICENSE.dependencies explicitly so that it is shipped correctly in %license.
Created attachment 2143715 [details] The .spec file difference from Copr build 10530695 to 10531052
Copr build: https://copr.fedorainfracloud.org/coprs/build/10531052 (succeeded) Review template: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2463848-hwatch/fedora-rawhide-x86_64/10531052-hwatch/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.
Those manual changelogs are nowadays unnecessary… You might want to switch to https://fedora-infra.github.io/rpmautospec-docs/opting-in.html. /usr/bin/cargo2rpm, /usr/bin/env, /usr/bin/cargo can be written without the paths. (Actually, the call to env is unnecessary. Plain CARGO_HOME=.cargo RUSTC_BOOTSTRAP=1 cargo test ... works too.) Don't use %bcond_without, use '%bcond check 1' instead. install -D -m 644 man/hwatch.1 %{buildroot}%{_mandir}/man1/%{name}.1 → install -D -m 644 man/hwatch.1 -t %{buildroot}%{_mandir}/man1/ to avoid repeating stuff. The same for all the other install commands.
Thank you for the review. I updated packages. Spec URL: https://github.com/blacknon/hwatch/releases/download/0.4.2/hwatch-0.4.2-7.spec SRPM URL: https://github.com/blacknon/hwatch/releases/download/0.4.2/hwatch-0.4.2-7.src.rpm I updated the package to 0.4.2-7 and made the requested cleanups: - switched to `%bcond check 1` - removed unnecessary full command paths - simplified the `%check` command - cleaned up the install commands to use `install ... -t ...` For `rpmautospec`, I understand the recommendation, but I would prefer to keep the manual `Release` and `%changelog` handling for now. At this stage, I am making incremental updates in response to review feedback, and keeping explicit release numbers such as `0.4.2-6`, `0.4.2-7`, etc. makes those updates easier to track during the review. With `rpmautospec`, the release value follows the commit history, so multiple intermediate commits may advance the release number in a way that is less predictable for this review process. I may switch to `rpmautospec` later, but for now I would like to keep the current manual scheme until the review is finished.
Created attachment 2144285 [details] The .spec file difference from Copr build 10531052 to 10569907
Copr build: https://copr.fedorainfracloud.org/coprs/build/10569907 (failed) Build log: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2463848-hwatch/fedora-rawhide-x86_64/10569907-hwatch/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.
I readed Comment 25. Spec URL: https://github.com/blacknon/hwatch/releases/download/0.4.2/hwatch-0.4.2-8.spec SRPM URL: https://github.com/blacknon/hwatch/releases/download/0.4.2/hwatch-0.4.2-8.src.rpm This updates the package to 0.4.2-8.
Created attachment 2144296 [details] The .spec file difference from Copr build 10569907 to 10570356
Copr build: https://copr.fedorainfracloud.org/coprs/build/10570356 (succeeded) Review template: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2463848-hwatch/fedora-rawhide-x86_64/10570356-hwatch/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.
On second thought, why not use the rpm macro to invoke the test: %cargo_test --all-features -- --skip test_exec_command_with_force_color_stdout_is_tty --skip test_exec_command_with_force_color_stdin_is_tty LGTM otherwise. -- @philip.wyett Any other thoughts? Can we wrap this up?
(In reply to Zbigniew Jędrzejewski-Szmek from comment #29) > On second thought, why not use the rpm macro to invoke the test: > %cargo_test --all-features -- --skip > test_exec_command_with_force_color_stdout_is_tty --skip > test_exec_command_with_force_color_stdin_is_tty > > LGTM otherwise. > > -- > > @philip.wyett Any other thoughts? Can we wrap this up? Thankyou, I updated packages. Spec URL: https://github.com/blacknon/hwatch/releases/download/0.4.2/hwatch-0.4.2-9.spec SRPM URL: https://github.com/blacknon/hwatch/releases/download/0.4.2/hwatch-0.4.2-9.src.rpm
[fedora-review-service-build] Spec URL: https://github.com/blacknon/hwatch/releases/download/0.4.2/hwatch-0.4.2-9.spec SRPM URL: https://github.com/blacknon/hwatch/releases/download/0.4.2/hwatch-0.4.2-9.src.rpm The Fedora Review Service wasn't working, so I try submitting again.
Hi Fabio, Phil, Is there anything for me to do here?
The latest versions are better in some regards, but they also introduce quite a few *new* issues, and it currently doesn't even build. 1. You define "%bcond check 1" - this is superfluous with the "-t" flag for "%cargo_generate_buildrequires". You can replace this entire block: ``` %if %{with check} %cargo_generate_buildrequires -a -t %else %cargo_generate_buildrequires -a %endif ``` With just the standard "%cargo_generate_buildrequires -a". The macro reads the value of the "check" bcond, no need to pass the "-t" flag externally too. 2. The manual "cargo2rpm license-breakdown" calls are wrong. Not sure where you got this from: ``` # Keep a concrete dependency license manifest in the package, similar to helix. cargo2rpm --path Cargo.toml license-breakdown --all-features > LICENSE.dependencies test -s LICENSE.dependencies ``` helix does no such thing, it has "%{cargo_license} > LICENSE.dependencies". So in this case, this should probably just be: ``` %{cargo_license -a} > LICENSE.dependencies ``` 3. The arguments passed to "%cargo_test" are wrong - which makes the package currently fail to build. There's a missing second "--" before the "--skip" argument (yes, it needs two "--"). 4. The links used for Spec URL / SRPM URL don't lead to correctly named .spec and .src.rpm files, that's probably why they are not recognized by fedora-review-service. The file names should be "hwatch.spec" and "hwatch-9.4.2-9.fc45.src.rpm". 5. Not sure what these BuildRequires are for: "BuildRequires: bash-completion" - they should not be needed. 6. Use macros for the installation locations of shell completions: - %{bash_completions_dir} - %{fish_completions_dir} - %{zsh_completions_dir}
Hi, I addressed the issues raised in comment #33 and rebuilt the SRPM for Fedora Rawhide. Changes include: - simplified %cargo_generate_buildrequires - switched dependency license generation to %{cargo_license -a} - fixed the %cargo_test argument separator - removed the unnecessary bash-completion BuildRequires - used the shell completion directory macros - rebuilt the SRPM with the .fc45 dist tag - restored the fixed upstream release tarball Spec URL: https://github.com/blacknon/hwatch/releases/download/0.4.2/hwatch-0.4.2-10.fc45.spec SRPM URL: https://github.com/blacknon/hwatch/releases/download/0.4.2/hwatch-0.4.2-10.fc45.src.rpm [fedora-review-service-build]
Copr build: https://copr.fedorainfracloud.org/coprs/build/10622202 (succeeded) Review template: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2463848-hwatch/fedora-rawhide-x86_64/10622202-hwatch/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 Fabio, I addressed all six issues raised in comment #33. The latest Fedora Review Service build succeeded on Fedora Rawhide x86_64, with 0 rpmlint errors and 0 warnings, and the Source0 checksum matches upstream. Could you please confirm whether the issues you raised are now resolved? Review report: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2463848-hwatch/fedora-rawhide-x86_64/10622202-hwatch/fedora-review/review.txt Thanks.
Thanks, this looks pretty good now. I would leave making the positive review official to the original assignee. I am only curious why you are using a custom uploaded .tar.gz file / release asset, and not the autogenerated .tar.gz tarball? Usually the auto-generated tar.gz is preferable since it should correspond exactly to the contents of the repository, and is not handled through a separate (and often opaque / undocumented) release process. The relevant documentation for the "standard" way to reference tarballs for tags in a git repo hosted on GitHub is here: https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/#_git_tags In this case, that would be: Source: %{url}/archive/0.4.3/hwatch-%{version}.tar.gz
Hi Fabio, Phil, Thank you for the feedback. I switched Source0 from the custom uploaded release asset to the GitHub-generated source archive for the upstream tag. I also renamed the branch that previously had the same name as the tag, so the archive URL is no longer ambiguous. The updated Spec and SRPM are available here: Spec URL: https://github.com/blacknon/hwatch/releases/download/0.4.2/hwatch-0.4.2-11.fc45.spec SRPM URL: https://github.com/blacknon/hwatch/releases/download/0.4.2/hwatch-0.4.2-11.fc45.src.rpm The relevant Source0 entry is now: Source0: %{url}/archive/%{version}/%{name}-%{version}.tar.gz Phil, could you please complete the remaining review when convenient? Thanks. [fedora-review-service-build]
Created attachment 2146544 [details] The .spec file difference from Copr build 10622202 to 10647149
Copr build: https://copr.fedorainfracloud.org/coprs/build/10647149 (succeeded) Review template: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2463848-hwatch/fedora-rawhide-x86_64/10647149-hwatch/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.
This is an automatic action taken by review-stats script. The ticket reviewer failed to clear the NEEDINFO flag in a month. As per https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews we reset the status and the assignee of this ticket.
Hi Fabio, The stalled-review automation reset the previous assignee on July 9, so this review is currently unassigned. The latest Fedora Review Service build succeeds, and I believe that all issues raised during the review, including the Source0 issue, have now been addressed. Since you mentioned in comment #37 that the package looked pretty good, would you be willing to take over the formal review and complete it if everything is satisfactory? If you are not available, no problem at all. I will look for another reviewer. Thanks, blacknon