Thank you for maintaining these binary packages. Could you point me to retained dependency metadata for the librsvg component of the following published artifacts?
@img/sharp-libvips-linux-x64@1.3.2@img/sharp-libvips-linuxmusl-x64@1.3.2- Build repository commit:
4da6d14c0d59866adfb9d8cf52bcaa53846dc4f6
- Associated release CI run
Existing information checked
I read the README licence section and THIRD-PARTY-NOTICES, including the distinction between the build scripts and bundled libraries. I also checked #120, #270 and #327; this request is not asking to relabel the binary packages as Apache-2.0.
The fixed build recipe changes librsvg features and runs cargo update --workspace, so its unmodified upstream Cargo.lock is not necessarily the final resolution. The npm provenance payload identifies the root source commit, but does not enumerate Rust transitive dependencies. The artifact API currently marks the associated run's build attachments as expired.
Requested information
Is the final, post-update Cargo.lock (or equivalent exact dependency/build SBOM), enabled feature set, and related third-party notice index available for these glibc/musl binaries? Any retained information distinguishing actually linked components from build-only dependencies would also help.
A persistent link to existing build metadata is sufficient. If it was not retained, please clarify that limitation rather than reconstructing a different resolution from current dependencies. I am seeking traceability for the existing published package bytes, not asking for a rebuild or a legal/commercial-use guarantee.
Thank you for maintaining these binary packages. Could you point me to retained dependency metadata for the librsvg component of the following published artifacts?
@img/sharp-libvips-linux-x64@1.3.2@img/sharp-libvips-linuxmusl-x64@1.3.24da6d14c0d59866adfb9d8cf52bcaa53846dc4f6Existing information checked
I read the README licence section and THIRD-PARTY-NOTICES, including the distinction between the build scripts and bundled libraries. I also checked #120, #270 and #327; this request is not asking to relabel the binary packages as Apache-2.0.
The fixed build recipe changes librsvg features and runs
cargo update --workspace, so its unmodified upstream Cargo.lock is not necessarily the final resolution. The npm provenance payload identifies the root source commit, but does not enumerate Rust transitive dependencies. The artifact API currently marks the associated run's build attachments as expired.Requested information
Is the final, post-update Cargo.lock (or equivalent exact dependency/build SBOM), enabled feature set, and related third-party notice index available for these glibc/musl binaries? Any retained information distinguishing actually linked components from build-only dependencies would also help.
A persistent link to existing build metadata is sufficient. If it was not retained, please clarify that limitation rather than reconstructing a different resolution from current dependencies. I am seeking traceability for the existing published package bytes, not asking for a rebuild or a legal/commercial-use guarantee.