Fedora Account System
Red Hat Associate
Red Hat Customer
sccache is *the* choice over ccache when one needs a different artifact storage than a local directory (for all cases that are just local directories, ccache works fine). Shipping an sccache with at least the S3-style storage feature explicitly disabled (it's enabled in the default cargo build) is hence making the packaging less-than-useful, I'm afraid Reproducible: Always Steps to Reproduce: 1. Install sccache package in your CI infrastructure on F43 (whereas on F42, you had to manually install) 2. expect caches to be populated, as with the upstream binaries 3. spend time digging 4. finally run `sccache --help` to see that storage backends are disabled Actual Results: no support for s3 or redis Expected Results: same s3 support as upstream binaries Additional Information: actually costs GNU Radio's CI quite some CPU hours because I expected the Fedora 43 packaging to be feature-comparable to default cargo builds.
> I expected the Fedora 43 packaging to be feature-comparable to default cargo builds. I agree that this is usually a reasonable expectation. In this case, enabling additional storage backends pulls in dozens and dozens of additional dependencies, and adding them to Fedora is work that just has not happened yet.
Option A: Package all of sccache requirements first before packaging sccache Option B: Don't package sccache at all Option C: Package sccache with the least requirements. I choose Option C and it took me already quite some time to package opendal and the dependencies for a local working sccache. If you support for S3-style storage in sccache, please help packaging. Looking opendal, rust-crc32c is missing. We seem to have the required reqwuest 0.12 packages. Then we could try to build opendal with s3-service support and then try it in sccache.
@asn oh absolutely; I frankly failed at making my own RPM for F42 when I wanted to use it, so your effort is super appreciated! I was just superficially walking through sccache's Cargo.toml and took away from it that with opendal packaging solved, the blocker for the S3 backend was gone. Let me give rust-crc32c a try. Thanks!
It was already submitted for review here: https://bugzilla.redhat.com/show_bug.cgi?id=2419806
I will try building once we have rust-crc32c in the distro.
@asn thanks; I've tried, but just removing "services-s3" from rust2rpm in opendal and running `rust2rpm -r` should fail without the crc32c dependency (and if that new package works, it should succeed with the review COPR repo included in mock), but in fact it seems to build; not sure how to proceed here, because I have no insight into how build features are specified if that doesn't make it fail; the rust2rpm man page has no indication and the spec is blissfully short. Anyways, as said, very much appreciated that you look into this; my skill level at rust packaging might simply not suffice here.
OpenDAL reports: Problem: conflicting requests - nothing provides (crate(reqsign/reqwest_request) > 0.16.5 with crate(reqsign/reqwest_request) < 0.20.0~) needed by rust-opendal+services-s3-devel-0.55.0-2.fc45.noarch from @commandline - nothing provides (crate(reqsign/services-aws) > 0.16.5 with crate(reqsign/services-aws) < 0.20.0~) needed by rust-opendal+services-s3-devel-0.55.0-2.fc45.noarch from @commandline rust-reqsign in Fedora doesn't provide those (yet).
Looks like reqsign dropped services-aws in version 0.17: https://lib.rs/crates/reqsign/versions
OpenDAL rewrote the code in the main branch to use: reqsign-aws-v4 = { version = "3.0.0", default-features = false } reqsign-core = { version = "3.0.0", default-features = false } reqsign-file-read-tokio = { version = "3.0.0", default-features = false } a) We need to wait till those are updated to version 3.0 in Fedora b) We need a new opendal release