https://bugzilla.redhat.com/show_bug.cgi?id=2174227
Bug ID: 2174227 Summary: Review Request: rust-imagequant-sys - Convert 24/32-bit images to 8-bit palette with alpha channel Product: Fedora Version: rawhide Hardware: All OS: Linux Status: NEW Component: Package Review Severity: medium Priority: medium Assignee: nobody@fedoraproject.org Reporter: h-k-81@hotmail.com QA Contact: extras-qa@fedoraproject.org CC: package-review@lists.fedoraproject.org Target Milestone: --- Classification: Fedora
Spec URL: https://blinxen.fedorapeople.org/rust-imagequant-sys/rust-imagequant-sys.spe... SRPM URL: https://blinxen.fedorapeople.org/rust-imagequant-sys/rust-imagequant-sys-4.0... Description: Convert 24/32-bit images to 8-bit palette with alpha channel. C API/FFI libimagequant that powers pngquant lossy PNG compressor. Dual-licensed like pngquant. See https://pngquant.org for details.
Fedora Account System Username: blinxen
This is a re-review request for a package rename. This package will replace `libimagequant` [1]. `libimagequant` will still live as a subpackage of `rust-imagequant-sys` (See spec file). I consciously did not set `Provides` or `Obsoletes` [2] because the "oldpackagename" still exists but as a subpackage. Please correct me if my reasoning is wrong here.
Reason for renaming the package: The upstream project rewrote the library in rust and this crate contains the C bindings of the rust code. According to the packaging guidelines [3], "Source packages for Rust crates which contain a library with a public API MUST be named rust-$crate".
The spec file has already had a first review (thanks! @decathorpe) in this PR: https://src.fedoraproject.org/rpms/libimagequant/pull-request/2
[1] https://src.fedoraproject.org/rpms/libimagequant [2] https://docs.fedoraproject.org/en-US/packaging-guidelines/#renaming-or-repla... [3] https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/#_library_cra...
https://bugzilla.redhat.com/show_bug.cgi?id=2174227
Jakub Kadlčík jkadlcik@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- URL| |https://crates.io/crates/im | |agequant-sys
--- Comment #1 from Jakub Kadlčík jkadlcik@redhat.com --- Copr build: https://copr.fedorainfracloud.org/coprs/build/5580466 (succeeded)
Review template: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-rev...
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.
https://bugzilla.redhat.com/show_bug.cgi?id=2174227
Fabio Valentini decathorpe@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Assignee|nobody@fedoraproject.org |decathorpe@gmail.com Doc Type|--- |If docs needed, set a value Status|NEW |ASSIGNED Flags| |fedora-review? CC| |decathorpe@gmail.com
--- Comment #2 from Fabio Valentini decathorpe@gmail.com --- Thanks for submitting this for review! I'll take a look tomorrow :)
https://bugzilla.redhat.com/show_bug.cgi?id=2174227
--- Comment #3 from Fabio Valentini decathorpe@gmail.com --- Looks pretty good already, with only some small small issues:
1. Superfluous License tag in the libimagequant-devel subpackage:
This built package contains only a symlink, a header, and a pkgconfig file. Since there are no binaries in this subpackage, the license tag can just be inherited from the source package and does not need to be specified in the -devel subpackage. This means you also don't need a separate macro for the library_license.
I suggest that you look at rust-rpm-sequoia for how modern Rust packaging handles the package license: https://src.fedoraproject.org/rpms/rust-rpm-sequoia/blob/rawhide/f/rust-rpm-...
If you use the %cargo_license or %cargo_license_summary macros for generating the license information for the statically linked binary, you will need to bump the rust-packaging dependency from >= 21 to >= 23, since the macros were only added with that version.
2. The description says "dual-licensed like pngquant", but the license metadata is just "GPL-3.0-or-later".
To me those two pieces of information are contradictory, please check which one is correct. If it turns out that the metadata in Cargo.toml is indeed incomplete, please patch Cargo.toml to fix it (%cargo_license* macros read this metadata to generate the license summaries, so it's important to not only fix the License tag in the spec file, but also to fix it in the crate metadata itself).
3. Is the ABI of "old" libimagequant (v2) the same as the one provided by the "new" one built in this package?
If the ABI has changed, you will need to rebuild any dependent packages once you submit this package to Fedora (assuming the APIs are the same ...). (This is not a blocker for the review, just a note that you will need to take this into account when building the package).
https://bugzilla.redhat.com/show_bug.cgi?id=2174227
--- Comment #4 from blinxen h-k-81@hotmail.com --- Updated spec file and SRPM under:
Spec URL: https://blinxen.fedorapeople.org/rust-imagequant-sys/rust-imagequant-sys.spe... SRPM URL: https://blinxen.fedorapeople.org/rust-imagequant-sys/rust-imagequant-sys-4.0...
- Superfluous License tag in the libimagequant-devel subpackage:
Thanks for the example! Are the marcos documented somewhere? If not, where would be the best place to document it?
- The description says "dual-licensed like pngquant", but the license metadata is just "GPL-3.0-or-later".
I think with dual-licensed the following is meant [1]:
``` Libimagequant is dual-licensed:
For Free/Libre Open Source Software it's available under GPL v3 or later with additional copyright notices for older parts of the code. For use in closed-source software, AppStore distribution, and other non-GPL uses, you can obtain a commercial license. Feel free to ask kornel@pngquant.org for details and custom licensing terms if you need them. ```
That means that if someone wants to use this code in a non GPL-3.0-or-later compliant code then he could acquire a commercial license. At least that's why I understand the from the statement above.
- Is the ABI of "old" libimagequant (v2) the same as the one provided by the "new" one built in this package?
I would assume that because rust (still?) has no stable ABI, the dependent packages will need to be rebuilt.
assuming the APIs are the same
This is the diff between the main and 2.x branch:
```
diff libimagequant_main.h libimagequant_2.h
16,17c16,17 < #define LIQ_VERSION 40000 < #define LIQ_VERSION_STRING "4.0.0" ---
#define LIQ_VERSION 21800 #define LIQ_VERSION_STRING "2.18.0"
75c75 < LIQ_EXPORT LIQ_USERESULT liq_attr* liq_attr_create_with_allocator(void* removed, void *unsupported); ---
LIQ_EXPORT LIQ_USERESULT liq_attr* liq_attr_create_with_allocator(void* (*malloc)(size_t), void (*free)(void*));
```
From my limited C knowledge I would assume that this is ok?
[1] https://github.com/ImageOptim/libimagequant#license
https://bugzilla.redhat.com/show_bug.cgi?id=2174227
--- Comment #5 from Jakub Kadlčík jkadlcik@redhat.com --- Created attachment 1947239 --> https://bugzilla.redhat.com/attachment.cgi?id=1947239&action=edit The .spec file difference from Copr build 5580466 to 5582780
https://bugzilla.redhat.com/show_bug.cgi?id=2174227
--- Comment #6 from Jakub Kadlčík jkadlcik@redhat.com --- Copr build: https://copr.fedorainfracloud.org/coprs/build/5582780 (succeeded)
Review template: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-rev...
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.
https://bugzilla.redhat.com/show_bug.cgi?id=2174227
--- Comment #7 from Fabio Valentini decathorpe@gmail.com --- (In reply to blinxen from comment #4)
Updated spec file and SRPM under:
Spec URL: https://blinxen.fedorapeople.org/rust-imagequant-sys/rust-imagequant-sys.spe... SRPM URL: https://blinxen.fedorapeople.org/rust-imagequant-sys/rust-imagequant-sys-4.0. 1-1.fc37.src.rpm
Thanks for the update, I'll run final checks and finalize the review later today.
- Superfluous License tag in the libimagequant-devel subpackage:
Thanks for the example! Are the marcos documented somewhere? If not, where would be the best place to document it?
They are not documented yet (other than in /usr/lib/rpm/macros.d/macros.cargo itself). I wanted to give them a bit of time to "bake" before doing that, but it's been a while and they work fine, as far as I can tell.
I have a few updates for the Rust packaging guidelines anyway, so I will probably add a mention of them here: https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/#_license_for...
- The description says "dual-licensed like pngquant", but the license metadata is just "GPL-3.0-or-later".
I think with dual-licensed the following is meant [1]:
Libimagequant is dual-licensed: For Free/Libre Open Source Software it's available under GPL v3 or later with additional copyright notices for older parts of the code. For use in closed-source software, AppStore distribution, and other non-GPL uses, you can obtain a commercial license. Feel free to ask kornel@pngquant.org for details and custom licensing terms if you need them.
That means that if someone wants to use this code in a non GPL-3.0-or-later compliant code then he could acquire a commercial license. At least that's why I understand the from the statement above.
Ok, makes sense. In this case, listing only GPL-3.0-or-later is correct.
- Is the ABI of "old" libimagequant (v2) the same as the one provided by the "new" one built in this package?
I would assume that because rust (still?) has no stable ABI, the dependent packages will need to be rebuilt.
True, but this doesn't apply here: The library is built with C ABI, not Rust ABI.
assuming the APIs are the same
This is the diff between the main and 2.x branch:
> diff libimagequant_main.h libimagequant_2.h 16,17c16,17 < #define LIQ_VERSION 40000 < #define LIQ_VERSION_STRING "4.0.0" --- > #define LIQ_VERSION 21800 > #define LIQ_VERSION_STRING "2.18.0" 75c75 < LIQ_EXPORT LIQ_USERESULT liq_attr* liq_attr_create_with_allocator(void* removed, void *unsupported); --- > LIQ_EXPORT LIQ_USERESULT liq_attr* liq_attr_create_with_allocator(void* (*malloc)(size_t), void (*free)(void*));
From my limited C knowledge I would assume that this is ok?
The answer is probably "it depends" ... If dependent packages expect these header definitions to be numbers instead of strings, things will break. I'm not sure about the liq_attr_create_with_allocator function (or whether casting function pointers to void* is valid).
However, it appears that the library soname is unchanged (libimagequant.so.0()(64bit)) even though there are API changes :( So you will need to rebuild applications (and fix them, if they are affected by these API changes).
https://bugzilla.redhat.com/show_bug.cgi?id=2174227
Fabio Valentini decathorpe@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags|fedora-review? |fedora-review+ Status|ASSIGNED |POST
--- Comment #8 from Fabio Valentini decathorpe@gmail.com --- Ok, package looks good to me.
You might want to consider replacing "%{_libdir}/%{lib}.so.0*" with "%{_libdir}/%{lib}.so.0{,.*}". (see https://docs.fedoraproject.org/en-US/packaging-guidelines/#_listing_shared_l...) but that's a minor thing.
The ABI / API compatibility with libimagequant v2 is not part of the package review, but please make sure that maintainers of dependent packages (and the "devel" list) are notified of the change.
===
Package was generated with rust2rpm, simplifying the review.
- package builds and installs without errors on rawhide - test suite is run and all unit tests pass - latest version of the crate is packaged - license matches upstream specification and is acceptable for Fedora - license file is included with %license in %files - license of statically linked components is reflected in License tag - shared C-ABI library built and installed correctly - package complies with Rust Packaging Guidelines
Package APPROVED.
===
Recommended post-import rust-sig tasks:
- add @rust-sig with "commit" access as package co-maintainer
- set bugzilla assignee overrides to @rust-sig (optional)
- set up package on release-monitoring.org: project: $crate homepage: https://crates.io/crates/$crate backend: crates.io version scheme: semantic version filter: alpha;beta;rc;pre distro: Fedora Package: rust-$crate
- track package in koschei for all built branches
https://bugzilla.redhat.com/show_bug.cgi?id=2174227
--- Comment #9 from Fedora Admin user for bugzilla script actions fedora-admin-xmlrpc@fedoraproject.org --- The Pagure repository was created at https://src.fedoraproject.org/rpms/rust-imagequant-sys
https://bugzilla.redhat.com/show_bug.cgi?id=2174227
blinxen h-k-81@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|POST |CLOSED Resolution|--- |NEXTRELEASE Last Closed| |2023-03-03 21:16:33
package-review@lists.fedoraproject.org