rust building is a pain. this is a heads-up that I won't be spending any time on that.

Hi there,

I'm not sure why I was CCed here. While I'm happy to help advise on issues that you may have while using Rust in SUSE/OpenSUSE, as the Rust maintainer it's not my responsibility to update this package spec file to work with Rust.

If you do have genuine concerns about what makes "rust building a pain" as you say, then I would like to know what they are so that I can potentially improve things. 

Thanks

The bcachefs-tools release script https://evilpiepirate.org/git/bcachefs-tools.git/tree/make-release-tarball.sh?h=v1.4.1#n31 publishes a signed source tarball with all cargo crate dependencies vendored to https://evilpiepirate.org/bcachefs-tools/ .
I think the "easiest" way forward here would be to use that bcachefs-tools-vendored tarball (with signature) in the Factory package.

The elephant in the room here is that the extra rust dependencies 
introduce over 200M of source code, which should ideally be audited for any obvious malice.

(In reply to David Disseldorp from comment #3)
> The bcachefs-tools release script
> https://evilpiepirate.org/git/bcachefs-tools.git/tree/make-release-tarball.
> sh?h=v1.4.1#n31 publishes a signed source tarball with all cargo crate
> dependencies vendored to https://evilpiepirate.org/bcachefs-tools/ .
> I think the "easiest" way forward here would be to use that
> bcachefs-tools-vendored tarball (with signature) in the Factory package.

Following discussions with some Rust packagers, it seems that we might be better off using https://github.com/openSUSE/obs-service-cargo_vendor locally to do the vendoring, to ensure that its integrated crate-audit functionality is used.

David, thanks for investigation. Do you plan to do the packaging? Because Jan stated that he won't be doing it.

> Following discussions with some Rust packagers, it seems that we might be
> better off using https://github.com/openSUSE/obs-service-cargo_vendor
> locally to do the vendoring, to ensure that its integrated crate-audit
> functionality is used.

Yes, this would be the best approach, and suse product security will appreciate that greatly. :)

(In reply to Petr Vorel from comment #5)
> David, thanks for investigation. Do you plan to do the packaging? Because
> Jan stated that he won't be doing it.

I can do that, but I don't expect to have much time for review of the huge amount of new source being added here.


(In reply to William Brown from comment #6)
> > Following discussions with some Rust packagers, it seems that we might be
> > better off using https://github.com/openSUSE/obs-service-cargo_vendor
> > locally to do the vendoring, to ensure that its integrated crate-audit
> > functionality is used.
> 
> Yes, this would be the best approach, and suse product security will
> appreciate that greatly. :)

Thanks for the pointers :)

I've submitted a rust-enabled build via https://build.opensuse.org/request/show/1142783
I ended up going with the published upstream vendored-source tarball for a couple of reasons:
- Kent generates and signs it in a relatively transparent way
  + I've requested that a "cargo audit" step become part of the release process
    see https://lore.kernel.org/linux-bcachefs/20240130070356.8174-1-ddiss@suse.de/T/#u
- the osc cargo / cargo_audit / cargo_vendor services appear to be in a lot of flux, changing significantly between versions

@Jan: feel free to add me as co-maintainer if you'd prefer to avoid dealing with this stuff in future.

This is an autogenerated message for OBS integration:
This bug (1219158) was mentioned in
https://build.opensuse.org/request/show/1142786 Factory / bcachefs-tools

Merged to Factory. Closing...

> - the osc cargo / cargo_audit / cargo_vendor services appear to be in a lot
> of flux, changing significantly between versions

It's settled down now, and I don't expect major changes anytime soon.

David, thanks a lot for fixing the tool! Yes, build 20240130 got the fixed package and all tests work as expected.