Bug 2230729
| Summary: | Review Request: rust-gvdb - Read and write GLib GVariant database files | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Kalev Lember <klember> |
| Component: | Package Review | Assignee: | Fabio Valentini <decathorpe> |
| Status: | ASSIGNED --- | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | rawhide | CC: | decathorpe, package-review |
| Target Milestone: | --- | Flags: | decathorpe:
fedora-review?
|
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | https://crates.io/crates/gvdb | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | Type: | --- | |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 2230010, 2230724 | ||
| Bug Blocks: | 2230732 | ||
|
Description
Kalev Lember
2023-08-09 22:11:04 UTC
Note that this depends on rust-safe-transmute and rust-litrs reviews, and updating rust-quick-xml (I've put it in a PR for now, https://src.fedoraproject.org/rpms/rust-quick-xml/pull-request/2) Copr build: https://copr.fedorainfracloud.org/coprs/build/6261773 (failed) Build log: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2230729-rust-gvdb/fedora-rawhide-x86_64/06261773-rust-gvdb/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. Two issues I can note immediately while I'm running a scratch build for all architectures: 1. Please file an upstream issue for the missing license file. The MIT license is one of the licenses that requires redistributed sources to contain a copy of the license text. This applies to crates distributed via crates.io and to distro packages (it can be solved by including the file manually from upstream git for now, but that should be a temporary solution until upstream publishes tarballs / crates with the license text included). 2. You might want to prevent test data from being installed / packaged. They include some icons where I'm not sure where they're from (looks like either the hicolor icon theme or Adwaita icon theme), so it's not clear which license applies to them (if any). It would be good to clarify the origin / license of these files with upstream. Until then, the least that you'd need to do is prevent them from being included in built RPMs, simplest solution would be a patch for Cargo.toml that does this: -exclude = ["test/c"] +exclude = ["test/c", "test-data"] It doesn't look like anything from the test-data directory is non-free / non-redistributable, but I can't be sure about that since it's not documented where the files come from, so it would be great if upstream could clarify this. In the unlikely event that the files indeed are non-redistributable, you would need to re-package a "clean" tarball without the test data. You can look at the rust-statrs package for an example of how to do that. Another solution would be to ask upstream to exclude the test-data directory from published crate tarballs (i.e. push the 1-line-patch included above to be upstream instead of downstream). Ran a scratch build now that all dependencies are available in rawhide, and it failed: https://koji.fedoraproject.org/koji/taskinfo?taskID=104697659 As I suspected (I'm getting old), the tests are failing on s390x. There's two possibilities for the root cause(s): 1. Tests hard-code bytes that are not byte-swapped for big-endian architectures (i.e. s390x) so the code works correctly, but the tests are broken because they compare correct results with a broken expected value. 2. Tests are correct, but the underlying code doesn't handle big-endian architectures correctly. Case 1 is usually much easier to handle (either by fixing test fixtures or by ignoring failing tests). Case 2 can be annoying, since it requires working with upstream to find the places in the code base where little-endianness is (wrongly) assumed, and fixing them properly. |