Spec URL: https://bmr.fedorapeople.org/snapm/snapm.spec SRPM URL: https://bmr.fedorapeople.org/snapm/snapm-0.4.1-1.fc41.src.rpm Description:Snapshot manager (snapm) is a tool for managing sets of snapshots on Linux systems. The snapm tool allows snapshots of multiple volumes to be captured at the same time, representing the system state at the time the set was created. Current plugins support lvm2 (copy-on-write and thin), and Stratis snapshots. Fedora Account System Username: bmr
Copr build: https://copr.fedorainfracloud.org/coprs/build/8859110 (succeeded) Review template: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2357266-snapm/fedora-rawhide-x86_64/08859110-snapm/fedora-review/review.txt Found issues: - Unversionned Python dependency found. Read more: https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_dependencies - Upstream MD5sum check error, diff is in /var/lib/copr-rpmbuild/results/snapm/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.
The original SRPM had a pre-release tarball. Fixed package and spec are here: Spec URL: https://bmr.fedorapeople.org/snapm/1/snapm.spec SRPM URL: https://bmr.fedorapeople.org/snapm/1/snapm-0.4.1-1.fc41.src.rpm
Note that fedora-review flags a false positive unversioned python dependency due to python3-dbus-python-client-gen: https://pagure.io/FedoraReview/issue/528 With a patched fedora-review I no longer see the unversioned dependency issue.
Copr build: https://copr.fedorainfracloud.org/coprs/build/8859127 (succeeded) Review template: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2357266-snapm/fedora-rawhide-x86_64/08859127-snapm/fedora-review/review.txt Found issues: - Unversionned Python dependency found. Read more: https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_dependencies 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.
> %if 0%{?centos} || 0%{?rhel} > %py3_build > %else > %pyproject_wheel > %endif > > %install > %if 0%{?centos} || 0%{?rhel} > %py3_install > %else > %pyproject_install > %endif What are we doing this for? The pyproject macros work in RHEL 9+. Also, CentOS defines %rhel, so I'm not sure why you are checking both.
> pytest-3 --log-level=debug -v Use "%pytest -- --log-level=debug" instead.
> License: GPL-2.0-only AND Apache-2.0 This is not a distributable combination. Is is possible to fix the GPL code to be "GPL-2.0-or-later" instead?
> What are we doing this for? The pyproject macros work in RHEL 9+. It's a relic from building from the same .spec on older distros. We no longer need to build for RHEL7 or 8 though so I will remove those. We initially started shipping in RHEL9 with the py3_build/install hence how that part of the spec was written. > Also, CentOS defines %rhel, so I'm not sure why you are checking both. Good to know, thanks.
> Use "%pytest -- --log-level=debug" instead. Ack, thanks.
(In reply to Bryn M. Reeves from comment #8) > > What are we doing this for? The pyproject macros work in RHEL 9+. > > It's a relic from building from the same .spec on older distros. We no > longer need to build for RHEL7 or 8 though so I will remove those. We > initially started shipping in RHEL9 with the py3_build/install hence how > that part of the spec was written. > You should also be able to switch to dynamic buildrequires as well.
> This is not a distributable combination. Is is possible to fix the GPL code to be "GPL-2.0-or-later" instead? That contradicts the advice we received during legal review. The Fedora license-validate tool also considers this a valid combination: $ license-validate -v 'GPL-2.0-only AND Apache-2.0' Approved license (this just seems to be checking that A OR B is valid) There are existing packages with this license combination, for e.g. golang-github-iovisor-gobpf-devel: Name : golang-github-iovisor-gobpf-devel Epoch : 0 Version : 0.2.0 Release : 5.fc41 Architecture : noarch Download size : 123.8 KiB Installed size : 400.8 KiB Source : golang-github-iovisor-gobpf-0.2.0-5.fc41.src.rpm Repository : fedora Summary : Go bindings for creating BPF programs URL : https://github.com/iovisor/gobpf License : GPL-2.0-only AND Apache-2.0 Description : Go bindings for creating BPF programs. I'm not in principal opposed to re-licensing as GPL-2.0-or-later, and I am in a position to do that for the covered code, but I don't think it is necessary based on the advice we've received about this so far.
(In reply to Bryn M. Reeves from comment #11) > > This is not a distributable combination. Is is possible to fix the GPL code to be "GPL-2.0-or-later" instead? > > That contradicts the advice we received during legal review. The Fedora > license-validate tool also considers this a valid combination: > > $ license-validate -v 'GPL-2.0-only AND Apache-2.0' > Approved license > > (this just seems to be checking that A OR B is valid) > > There are existing packages with this license combination, for e.g. > golang-github-iovisor-gobpf-devel: > > Name : golang-github-iovisor-gobpf-devel > Epoch : 0 > Version : 0.2.0 > Release : 5.fc41 > Architecture : noarch > Download size : 123.8 KiB > Installed size : 400.8 KiB > Source : golang-github-iovisor-gobpf-0.2.0-5.fc41.src.rpm > Repository : fedora > Summary : Go bindings for creating BPF programs > URL : https://github.com/iovisor/gobpf > License : GPL-2.0-only AND Apache-2.0 > Description : Go bindings for creating BPF programs. > > I'm not in principal opposed to re-licensing as GPL-2.0-or-later, and I am > in a position to do that for the covered code, but I don't think it is > necessary based on the advice we've received about this so far. It actually depends. In this case, from what I can see, the Apache-2.0 code is integrated as part of the GPL codebase, meaning they are not freestanding and the integration makes in not redistributable. Also, the gobpf license tag is not correct. It's "GPL-2.0-only WITH Linux-syscall-note" because it includes a syscall interface header, and the syscall note is what makes it compatible.
I've given this a lot of thought over the weekend, both around how these projects fit into the overall Python ecosystem, as well as reading resources from both Apache and the FSF on the topic of license compatibility. These projects (snapm and boom-boot) were historically licensed under the GPL because despite being original code bases they originated in GPL-licensed projects (a subpackage of lvm2 in the case of boom, and then smapm followed that pattern). On reflection, I no longer think that being licensed under the GPL is adding any value to these projects, and actually makes it harder to consume and re-use these components. A small part of snapm (the plugin loader) was originally derived from the sos project: https://github.com/sosreport/sos/ I filed a PR yesterday to rewrite this part of snapm: https://github.com/snapshotmanager/snapm/pull/195 - this deletes the last remnant of 3rd party code in the tree. I'm proposing to re-license both projects (boom-boot and snapm) under the Apache-2.0 license. Further explanation and discussion of the change can be found in the upstream issues: https://github.com/snapshotmanager/snapm/issues/205 https://github.com/snapshotmanager/boom-boot/issues/120 I think this is a positive change that simplifies life for users, developers, and maintainers - we will issue new releases soon with the re-licensing change included assuming that no objections are raised.
License change has been acked by the other contributors to both projects, and the new license is now merged: the README.md files have been updated to reflect the new licensing for the packages and the SPDX-License-Identifier strings have been changed to "Apache-2.0". I'm reviewing other open issues and aim to make new releases (boom-boot-1.6.7 and snapm-0.4.2) with the new license announcement this week.
A new draft SRPM and spec file based on the upstream snapm-0.4.2 release is now available - this release includes the licensing change to Apache-2.0: Spec URL: https://bmr.fedorapeople.org/snapm/2/snapm.spec SRPM URL: https://bmr.fedorapeople.org/snapm/2/snapm-0.4.2-1.fc42.src.rpm
Created attachment 2085092 [details] The .spec file difference from Copr build 8859127 to 8907872
Copr build: https://copr.fedorainfracloud.org/coprs/build/8907872 (succeeded) Review template: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2357266-snapm/fedora-rawhide-x86_64/08907872-snapm/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.
I believe the: - Package contains BR: python2-devel or python3-devel Issue flagged by fedora-review is a false positive - the package is using %autobuildrequires, so the check for the spec file dependencies fails to find it.
From the python packaging guidelines: Python modules MUST have a build-time dependency on python3-devel, even if Python is not actually invoked during build-time. Such a package MUST use one of the following in its .spec file: %pyproject_buildrequires in the %generate_buildrequires section BuildRequires: python3-devel We are using the first form (%generate_buildrequires section w/%pyproject_buildrequires), so I believe the explicity BuildRequires is unnecessary.
> I believe the: > > - Package contains BR: python2-devel or python3-devel > > Issue flagged by fedora-review is a false positive - the package is using %autobuildrequires, so the check for the spec file dependencies fails to find it. After reading https://src.fedoraproject.org/rpms/pyproject-rpm-macros/ I think this is incorrect. As I mentioned in comment #19 he Fedora Python Packaging Guidelines state that a package MUST use one of the following, but the pyproject-rpm-macros README makes it clear that an explicit BR for the appropriate python-devel is still required. I'll update the spec and SRPM based on this.
Package Review ============== Legend: [x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated [ ] = Manual review needed ===== MUST items ===== Generic: [x]: Package is licensed with an open-source compatible license and meets other legal requirements as defined in the legal section of Packaging Guidelines. [x]: 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* Apache License 2.0", "Apache License 2.0". 30 files have unknown license. Detailed output of licensecheck in /home/bgurney/pkgreviews/20250415_snapm_bz/2357266-snapm/licensecheck.txt [x]: License file installed when any subpackage combination is installed. [x]: Package must own all directories that it creates. Note: Directories without known owners: /usr/lib/python3.13, /usr/lib/python3.13/site-packages [x]: Package contains no bundled libraries without FPC exception. [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. [x]: Spec file is legible and written in American English. [-]: Package contains systemd file(s) if in need. [x]: Package is not known to require an ExcludeArch tag. [-]: Large documentation must go in a -doc subpackage. Large could be size (~1MB) or number of files. Note: Documentation size is 67784 bytes in 2 files. [x]: Package complies to the Packaging Guidelines [x]: Package successfully compiles and builds into binary rpms on at least one supported primary architecture. [x]: Package installs properly. [x]: Rpmlint is run on all rpms the build produces. Note: No rpmlint messages. [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]: Packages must not store files under /srv, /opt or /usr/local Python: [-]: Python eggs must not download any dependencies during the build process. [-]: A package which is used by another package via an egg interface should provide egg info. [x]: Package meets the Packaging Guidelines::Python [x]: Packages MUST NOT have dependencies (either build-time or runtime) on packages named with the unversioned python- prefix unless no properly versioned package exists. Dependencies on Python packages instead MUST use names beginning with python2- or python3- as appropriate. [x]: Python packages must not contain %{pythonX_site(lib|arch)}/* in %files [x]: Binary eggs must be removed in %prep ===== SHOULD items ===== Generic: [-]: If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it. [x]: Final provides and requires are sane (see attachments). [-]: Fully versioned dependency in subpackages if applicable. Note: No Requires: %{name}%{?_isa} = %{version}-%{release} in python3-snapm [x]: Package functions as described. [x]: Latest version is packaged. [x]: Package does not include license text files separate from upstream. [-]: 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. [x]: %check is present and all tests pass. [x]: Packages should try to preserve timestamps of original installed files. [x]: Reviewer should test that the package builds in mock. [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]: Uses parallel make %{?_smp_mflags} macro. [x]: Sources can be downloaded from URI in Source: tag [x]: SourceX is a working URL. [x]: Spec use %global instead of %define unless justified. ===== EXTRA items ===== Generic: [x]: Rpmlint is run on all installed packages. Note: No rpmlint messages. [x]: Spec file according to URL is the same as in SRPM. Rpmlint ------- Checking: snapm-0.4.2-1.fc43.noarch.rpm python3-snapm-0.4.2-1.fc43.noarch.rpm python3-snapm-doc-0.4.2-1.fc43.noarch.rpm snapm-0.4.2-1.fc43.src.rpm ============================ rpmlint session starts ============================ rpmlint: 2.6.1 configuration: /usr/lib/python3.13/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/tmpq5o5vzaf')] checks: 32, packages: 4 4 packages and 0 specfiles checked; 0 errors, 0 warnings, 15 filtered, 0 badness; has taken 0.4 s Rpmlint (installed packages) ---------------------------- ============================ rpmlint session starts ============================ rpmlint: 2.7.0 configuration: /usr/lib/python3.13/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: 3 3 packages and 0 specfiles checked; 0 errors, 0 warnings, 11 filtered, 0 badness; has taken 0.1 s Source checksums ---------------- https://github.com/snapshotmanager/snapm/archive/v0.4.2/snapm-0.4.2.tar.gz : CHECKSUM(SHA256) this package : 7ad1df0fcc04fdf91c6885eca9e313e023e15aa1669bf000f9f159bac2901608 CHECKSUM(SHA256) upstream package : 7ad1df0fcc04fdf91c6885eca9e313e023e15aa1669bf000f9f159bac2901608 Requires -------- snapm (rpmlib, GLIBC filtered): /usr/bin/python3 python3-snapm python3-snapm (rpmlib, GLIBC filtered): /usr/bin/python3 python(abi) python3-snapm-doc (rpmlib, GLIBC filtered): Provides -------- snapm: snapm python3-snapm: python-snapm python3-snapm python3.13-snapm python3.13dist(snapm) python3dist(snapm) python3-snapm-doc: python-snapm-doc python3-snapm-doc python3.13-snapm-doc Generated by fedora-review 0.10.0 (e79b66b) last change: 2023-07-24 Command line :/usr/bin/fedora-review -b 2357266 Buildroot used: fedora-rawhide-x86_64 Active plugins: Python, Generic, Shell-api Disabled plugins: R, Ocaml, Haskell, PHP, Perl, SugarActivity, C/C++, Java, fonts Disabled flags: EXARCH, EPEL6, EPEL7, DISTTAG, BATCH
Thanks everyone for the helpful review comments. I have made some further updates to the spec file based on feedback and a closer reading of the Fedora Packaging Guidelines. A new upstream release, snapm-0.4.3 has been made incorporating these changes: https://github.com/snapshotmanager/snapm/releases/tag/v0.4.3 And I have updated the draft spec/SRPM: Spec URL: https://bmr.fedorapeople.org/snapm/3/snapm.spec SRPM URL: https://bmr.fedorapeople.org/snapm/3/snapm-0.4.3-1.fc43.src.rpm Changes since v2: * Dropped global sphinx_docs and made docs build unconditional * Switched to dynamic buildrequires * Dropped obsolete python_provide macro use * Deleted obsolete Requires: %{__python3} * Replaced direct install invocation with %{__install} * Replaced direct make invocation with %{make_build} * Simplified doc build and cleanup Unless anyone has any further suggestions I intend to go ahead with packaging the release this week.
Please use %{buildroot} over ${RPM_BUILD_ROOT} so that paths are consistently evaluated through the macro engine.
> %generate_buildrequires > %pyproject_buildrequires This is a spec build section that runs after %prep and before %build, so please consider placing it there in the spec file too.
> Please use %{buildroot} over ${RPM_BUILD_ROOT} so that paths are consistently evaluated through the macro engine. For consistency it would be nice if the Fedora Packaging Guidelines picked a side on this. The current text reads: "There is very little value in choosing one style over the other, since they will resolve to the same values in all scenarios. You should pick a style and use it consistently throughout your packaging." https://docs.fedoraproject.org/en-US/packaging-guidelines/#_using_buildroot_and_optflags_vs_rpm_build_root_and_rpm_opt_flags The RPM Packaging Guide does express a preference (for the same reason you give), but hasn't been updated in over two years and lacks any discussion of %generate_buildrequires and other newer features: https://rpm-packaging-guide.github.io/ > This is a spec build section that runs after %prep and before %build, so please consider placing it there in the spec file too. Thanks. I was lead astray by the Python example at: https://fedoraproject.org/wiki/Changes/DynamicBuildRequires#Python Which places the %generate_buildrequires after the BuildRequires. Even reading: https://src.fedoraproject.org/rpms/pyproject-rpm-macros It's not clearly stated where these should go (other than an example under the provisional Declarative Buildsystem section) - I should have referred to the examples in: https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/
Updated with the most recent suggestions: Spec URL: https://bmr.fedorapeople.org/snapm/4/snapm.spec SRPM URL: https://bmr.fedorapeople.org/snapm/4/snapm-0.4.3-1.fc43.src.rpm Changes since v3: * Replace ${RPM_BUILD_ROOT} with %{buildroot} * Move %generate_buildrequires after %prep
The Pagure repository was created at https://src.fedoraproject.org/rpms/snapm
Package Review ============== Legend: [x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated [ ] = Manual review needed ===== MUST items ===== Generic: [x]: Package is licensed with an open-source compatible license and meets other legal requirements as defined in the legal section of Packaging Guidelines. [x]: 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* Apache License 2.0", "Apache License 2.0". 29 files have unknown license. Detailed output of licensecheck in /home/bgurney/pkgreviews/20250422_snapm_bz/2357266-snapm/licensecheck.txt [x]: License file installed when any subpackage combination is installed. [x]: Package must own all directories that it creates. Note: Directories without known owners: /usr/lib/python3.13/site- packages, /usr/lib/python3.13 [x]: Package contains no bundled libraries without FPC exception. [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. [x]: Spec file is legible and written in American English. [-]: Package contains systemd file(s) if in need. [x]: Package is not known to require an ExcludeArch tag. [-]: Large documentation must go in a -doc subpackage. Large could be size (~1MB) or number of files. Note: Documentation size is 67784 bytes in 2 files. [x]: Package complies to the Packaging Guidelines [x]: Package successfully compiles and builds into binary rpms on at least one supported primary architecture. [x]: Package installs properly. [x]: Rpmlint is run on all rpms the build produces. Note: No rpmlint messages. [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]: Packages must not store files under /srv, /opt or /usr/local Python: [-]: Python eggs must not download any dependencies during the build process. [-]: A package which is used by another package via an egg interface should provide egg info. [x]: Package meets the Packaging Guidelines::Python [x]: Package contains BR: python2-devel or python3-devel [x]: Packages MUST NOT have dependencies (either build-time or runtime) on packages named with the unversioned python- prefix unless no properly versioned package exists. Dependencies on Python packages instead MUST use names beginning with python2- or python3- as appropriate. [x]: Python packages must not contain %{pythonX_site(lib|arch)}/* in %files [x]: Binary eggs must be removed in %prep ===== SHOULD items ===== Generic: [-]: If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it. [x]: Final provides and requires are sane (see attachments). [-]: Fully versioned dependency in subpackages if applicable. Note: No Requires: %{name}%{?_isa} = %{version}-%{release} in python3-snapm [x]: Package functions as described. [x]: Latest version is packaged. [x]: Package does not include license text files separate from upstream. [-]: 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. [x]: %check is present and all tests pass. [x]: Packages should try to preserve timestamps of original installed files. [x]: Reviewer should test that the package builds in mock. [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. [x]: Spec use %global instead of %define unless justified. ===== EXTRA items ===== Generic: [x]: Rpmlint is run on all installed packages. Note: No rpmlint messages. [x]: Spec file according to URL is the same as in SRPM. Rpmlint ------- Checking: snapm-0.4.3-1.fc43.noarch.rpm python3-snapm-0.4.3-1.fc43.noarch.rpm python3-snapm-doc-0.4.3-1.fc43.noarch.rpm snapm-0.4.3-1.fc43.src.rpm ============================ rpmlint session starts ============================ rpmlint: 2.6.1 configuration: /usr/lib/python3.13/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/tmpz2nyoda1')] checks: 32, packages: 4 4 packages and 0 specfiles checked; 0 errors, 0 warnings, 15 filtered, 0 badness; has taken 0.4 s Rpmlint (installed packages) ---------------------------- ============================ rpmlint session starts ============================ rpmlint: 2.7.0 configuration: /usr/lib/python3.13/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: 3 3 packages and 0 specfiles checked; 0 errors, 0 warnings, 11 filtered, 0 badness; has taken 0.1 s Source checksums ---------------- https://github.com/snapshotmanager/snapm/archive/v0.4.3/snapm-0.4.3.tar.gz : CHECKSUM(SHA256) this package : fdb331b98ca69e4baff483096b50ee0736077ffdff10959211b0947efd3af43f CHECKSUM(SHA256) upstream package : fdb331b98ca69e4baff483096b50ee0736077ffdff10959211b0947efd3af43f Requires -------- snapm (rpmlib, GLIBC filtered): /usr/bin/python3 python3-snapm python3-snapm (rpmlib, GLIBC filtered): python(abi) python3.13dist(boom-boot) python3.13dist(dbus-client-gen) python3.13dist(dbus-python-client-gen) python3.13dist(justbytes) python3.13dist(packaging) python3.13dist(python-dateutil) python3.13dist(wcwidth) python3-snapm-doc (rpmlib, GLIBC filtered): Provides -------- snapm: snapm python3-snapm: python-snapm python3-snapm python3.13-snapm python3.13dist(snapm) python3dist(snapm) python3-snapm-doc: python-snapm-doc python3-snapm-doc python3.13-snapm-doc Generated by fedora-review 0.10.0 (e79b66b) last change: 2023-07-24 Command line :/usr/bin/fedora-review -b 2357266 Buildroot used: fedora-rawhide-x86_64 Active plugins: Generic, Shell-api, Python Disabled plugins: SugarActivity, PHP, Haskell, C/C++, Perl, fonts, R, Ocaml, Java Disabled flags: EXARCH, EPEL6, EPEL7, DISTTAG, BATCH
FEDORA-2025-160f873f2e (snapm-0.4.3-1.fc43) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2025-160f873f2e
FEDORA-2025-160f873f2e (snapm-0.4.3-1.fc43) has been pushed to the Fedora 43 stable repository. If problem still persists, please make note of it in this bug report.