Spec URL: https://decathorpe.fedorapeople.org/rust-bindgen-cli.spec SRPM URL: https://decathorpe.fedorapeople.org/rust-bindgen-cli-0.62.0-1.fc37.src.rpm Description: Automatically generates Rust FFI bindings to C and C++ libraries Fedora Account System Username: decathorpe Note: Building this package is blocked on the v0.62.0 update for rust-bindgen, which is still being worked on in COPR: https://copr.fedorainfracloud.org/coprs/decathorpe/bindgen-0.62/ I'd like to submit all builds (rust-bindgen v0.62, rust-bindgen-cli, dependendent packages) as a single update, since the bindgen CLI, which was previously shipped with rust-bindgen, has been split off into rust-bindgen-cli with a recent version - and I'd like to avoid dropping and then re-introducing /usr/bin/bindgen with two separate updates, if possible. Successful COPR build on all architectures: https://copr.fedorainfracloud.org/coprs/decathorpe/bindgen-0.62/build/5045123/
Fedora review rust-bindgen-cli-0.62.0-1.fc37.src.rpm 2022-11-22 $ rpmlint rust-bindgen-cli-0.62.0-1.fc37.src.rpm \ rust-bindgen-cli-debugsource-0.62.0-1.fc37.x86_64.rpm \ bindgen-cli-0.62.0-1.fc37.x86_64.rpm \ bindgen-cli-debuginfo-0.62.0-1.fc37.x86_64.rpm =================================================================================== rpmlint session starts =================================================================================== rpmlint: 2.2.0 configuration: /usr/lib/python3.11/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/licenses.toml /etc/xdg/rpmlint/scoring.toml /etc/xdg/rpmlint/users-groups.toml /etc/xdg/rpmlint/warn-on-functions.toml checks: 32, packages: 4 bindgen-cli-debuginfo.x86_64: W: unstripped-binary-or-object /usr/lib/debug/usr/bin/bindgen-0.62.0-1.fc37.x86_64.debug bindgen-cli.x86_64: E: unknown-key d2e40d55 bindgen-cli-debuginfo.x86_64: E: unknown-key d2e40d55 rust-bindgen-cli-debugsource.x86_64: E: unknown-key d2e40d55 bindgen-cli-debuginfo.x86_64: E: shared-library-without-dependency-information /usr/lib/debug/usr/bin/bindgen-0.62.0-1.fc37.x86_64.debug bindgen-cli.x86_64: W: no-manual-page-for-binary bindgen bindgen-cli-debuginfo.x86_64: W: no-documentation rust-bindgen-cli-debugsource.x86_64: W: no-documentation bindgen-cli-debuginfo.x86_64: W: dangling-relative-symlink /usr/lib/debug/.build-id/7f/e2ce96fb16f314feb208d884af96ac5145559b ../../../.build-id/7f/e2ce96fb16f314feb208d884af96ac5145559b ==================================================== 4 packages and 0 specfiles checked; 4 errors, 5 warnings, 4 badness; has taken 0.8 s ==================================================== + OK ! needs attention + rpmlint output looks good - the unknown-key warnings are because the packages are downloaded from Fabio's copr - unstripped-binary-or-object seems like something gone wrong with rpmlint checks: it's complaining about the -debuginfo subpackage where all the unstripped binaries have to go - shared-library-without-dependency-information is expected as much as I understand for rust packages as they are statically linked + The package is named according to Fedora packaging guidelines + The spec file name matches the base package name. + The package meets the Packaging Guidelines + The package is licensed with a Fedora approved license and meets the Licensing Guidelines. - The license field in the spec file matches the actual license I think you may have forgotten "Unlicense" out of the license tag? "Unlicense OR MIT" is listed for 3 dependent crates in LICENSE.dependencies. + The license text (BSD-3-Clause) is included in %license + Spec file is written in American English + Spec file is legible + Upstream sources match the sources in the srpm SHA512 (bindgen-cli-0.62.0.crate) = c0e5404f6d46ad80ec18f2ee36fa9d70af859bf82e26dae1dddbe324d40feb826c4abc05b6a0b3a66878280115e316e54bed82af153c06e3c53b32842ce74523 SHA512 (Download/bindgen-cli-0.62.0.crate) = c0e5404f6d46ad80ec18f2ee36fa9d70af859bf82e26dae1dddbe324d40feb826c4abc05b6a0b3a66878280115e316e54bed82af153c06e3c53b32842ce74523 + Package builds in copr n/a ExcludeArch bugs filed + BuildRequires look sane n/a locale handling + Package does not bundle copies of system libraries n/a Package isn't relocatable + Package owns all the directories it creates + No duplicate files in %files + Permissions are properly set + Consistent use of macros + The package must contain code or permissible content n/a Large documentation files should go in -doc subpackage + Files marked %doc should not affect the runtime of application n/a Static libraries should be in -static n/a Development files should be in -devel n/a -devel must require the fully versioned base + Packages should not contain libtool .la files n/a Proper .desktop file handling + Doesn't own files or directories already owned by other packages + Filenames are valid UTF-8 + Package does not depend on deprecated packages APPROVED P.S. Please check if "Unlicense" is missing (as mentioned above) for the license tag before importing. P.P.S. I'll note that 0.63.0 was just released 38 minutes ago on https://crates.io/crates/bindgen-cli :)
(In reply to Kalev Lember from comment #1) > Fedora review rust-bindgen-cli-0.62.0-1.fc37.src.rpm 2022-11-22 Thanks for the review! > I think you may have forgotten "Unlicense" out of the license tag? > "Unlicense OR MIT" is listed for 3 dependent crates in LICENSE.dependencies. The terms of "Unlicense OR MIT" are already covered by "... AND MIT AND ...". > P.P.S. I'll note that 0.63.0 was just released 38 minutes ago on > https://crates.io/crates/bindgen-cli :) Ugh. I hate it when they release breaking changes so frequently. I'll continue with packaging 0.62.0 for now, it looks like 0.63.0 removed tons of deprecated functionality. At least at a glance the dependencies didn't change, so I should be able to update from 0.62.0 to 0.63.0 without problems after importing the packages.
(In reply to Fabio Valentini from comment #2) > (In reply to Kalev Lember from comment #1) > > I think you may have forgotten "Unlicense" out of the license tag? > > "Unlicense OR MIT" is listed for 3 dependent crates in LICENSE.dependencies. > > The terms of "Unlicense OR MIT" are already covered by "... AND MIT AND ...". Why do you want to leave "Unlicense" out? The licensing guidelines say to list both of the licenses in this case: https://docs.fedoraproject.org/en-US/legal/license-field/#_disjunctive_or_license_choice_also_known_as_dual_licenses "If your package (or part of your package) is licensed under a choice of two (or more) licenses, and each license is allowed for Fedora, the License: field must reflect this by using the OR operator." Furthermore, reading the new licensing guidelines a bit more, I would say that the way the licenses are simplified here is actually incorrect. See https://docs.fedoraproject.org/en-US/legal/license-field/#_combined_disjunctive_and_conjunctive_license_expressions : "The license expression must reflect the disjunctive license choice even if one or both of the license identifiers in the OR expression also appear separately in the composite license expression." So I'd actually say the correct license expression in this case should be: License: Apache-2.0 AND (Apache-2.0 OR MIT) AND BSD-3-Clause AND ISC AND MIT AND (MIT OR Apache-2.0) AND Unicode-DFS-2016 AND (Unlicense OR MIT) What do you think? How do you understand the new guidelines?
These new guidelines are stupid. It appears that the sections you linked above were added after my explicit objections that doing it this way is extremely pointless and makes the License tag - for which the intended audience is exclusively end users - *less useful* for end users.
Yes, I think I agree with you :(
I mean, a stupid " AND ".join(license_list) is way less work than manually condensing the list, so if lawyers be lawyering, I can do that :shrug:
(fedscm-admin): The Pagure repository was created at https://src.fedoraproject.org/rpms/rust-bindgen-cli
FEDORA-2022-fcda764b4f has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2022-fcda764b4f
FEDORA-2022-fcda764b4f has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report.