Copr build:
https://copr.fedorainfracloud.org/coprs/build/5580466
(succeeded)

Review template:
https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2174227-rust-imagequant-sys/fedora-rawhide-x86_64/05580466-rust-imagequant-sys/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.

Thanks for submitting this for review! I'll take a look tomorrow :)

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-sequoia.spec

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).

Updated spec file and SRPM under:

Spec URL: https://blinxen.fedorapeople.org/rust-imagequant-sys/rust-imagequant-sys.spec
SRPM URL: https://blinxen.fedorapeople.org/rust-imagequant-sys/rust-imagequant-sys-4.0.1-1.fc37.src.rpm


> 1. 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?

> 2. 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 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.

> 3. 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

Created attachment 1947239 [details]
The .spec file difference from Copr build 5580466 to 5582780

Copr build:
https://copr.fedorainfracloud.org/coprs/build/5582780
(succeeded)

Review template:
https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2174227-rust-imagequant-sys/fedora-rawhide-x86_64/05582780-rust-imagequant-sys/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.

(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.spec
> 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.

> > 1. 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_binary_packages

> > 2. 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 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.

> > 3. 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).

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_library_files)
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

The Pagure repository was created at https://src.fedoraproject.org/rpms/rust-imagequant-sys