Rust May 2024

rust@lists.fedoraproject.org

6 participants
4 discussions

Advise on packaging a Rust app
by Antoine Tenart 24 Jan '25

24 Jan '25

Hello, [Resending as first email was rejected; wasn't a member of the list] We'd like to package a Rust application for Fedora, Retis[1]. We currently distribute it in COPR[2] because we can't easily follow the Fedora Rust packing rules at the moment but that is far from being perfect (on all levels). Don't get me wrong, I think the packaging rules make sense; but those are a high entry barrier for projects with multiple unpackaged complex dependencies (recursively). We wrote a plan with detailed steps to get there, https://github.com/retis-org/retis/milestone/13. It's basically divided into the following directions: - Take over / upgrade some outdated dependencies. - Package the missing dependencies in Fedora. Some are easier than others to package / maintain. - Remove the use of other dependencies. There are a few issues to overcome (packaging complex dependencies takes time, I think we have a dep of a dep w/o a license, etc) but most importantly I think the concern is with maintenance; especially when it's not trivial. All that of course will be quite an effort so we thought we should ask for your input and advises on if this is the right direction or if you have some comments? Also we're wondering if there's anything that could ease the process or make the delay shorter (eg. vendoring *some* deps temporarily)? The above also raises an additional question: any additional dependency added upstream, if not already packaged and non trivial, could gate upcoming releases from being packaged. Gating upstream development on downstream packaging doesn't look right and I guess those kind of issues are just expected (we already have one coming); but wanted to ask just in case :) Thanks! Antoine [1] https://retis.readthedocs.io/en/stable/ [2] https://copr.fedorainfracloud.org/coprs/g/retis/retis/

2 11

Firecracker 1.8 crate updates
by David Michael 19 Jul '24

19 Jul '24

Hi, It's been ~2 months since I last pestered about dependency updates, so it's that time again. The 1.8 release branch was only created recently, and if it goes like the last release, there could be a few weeks of stabilization before it's actually tagged. There's no rush, I'm just sending this list to get ahead of it. These are the minimum versions in the 1.8 branch needing updates: decathorpe: - itertools 0.13.0 (API change from 0.12.1) - libc 0.2.155 (from 0.2.154) - proc-macro2 1.0.83 (from 1.0.82, 1.0.84 available) - serde 1.0.202 (from 1.0.200, 1.0.203 available) - syn 2.0.65 (from 2.0.64, 2.0.66 available) - thiserror 1.0.61 (from 1.0.60) The first one will probably require a compat package, and there is another app needing it in the itertools upgrade Bugzilla ticket. I could downgrade this with a patch if that's preferred, though. slp: - kvm-bindings 0.8.0 (API change from 0.7.0, 0.8.1 available) - kvm-ioctls 0.17.0 (API change from 0.16.0) - vhost 0.11.0 (API change from 0.10.0) - vm-memory 0.14.1 (from 0.14.0) These are mostly API bumps. It looks like users libkrun and sev have open-ended dependencies and won't be affected, and virtiofsd and vhost-device-* crates have bumped deps upstream but need new releases. There is also a vm-fdt API bump which I can push along with firecracker-1.8 since that's the only user (aside from libkrun's unbound dependency). Let me know if you want me to handle any of these other updates, although I'd need to be added as a comaintainer. Thanks. David

4 16

[HEADS-UP] Upcoming Rust SIG mini-mass-rebuild
by Fabio Valentini 26 May '24

26 May '24

Hi all, As discussed in the Fedora Rust channel on Matrix, I am planning to do a mini-mass-rebuild of all Rust applications (that are co-maintained by the Rust SIG), likely by the end of this week. I estimate that it will involve just shy of 200 packages per branch. The motivation for a mini-mass-rebuild is two-fold: 1. Until very recently, the Rust standard library (shipped as a static archive by the "rust" package) was accidentally shipped with stripped debuginfo, which resulted in Rust applications that linked the standard library to have incomplete debuginfo - and as a result, they produced incomplete backtraces for any stack traces that involved the Rust standard library. This has been fixed since rust 1.78, but applications need to be rebuilt to pick up this improvement. 2. I regularly rebuild applications for "major" / "high priority" security issues in Rust crates, but there are a few accumulated "minor" / "low priority" security issues where I didn't yet have the time to rebuild the affected applications against the library versions that contain the necessary fixes. A mini-mass-rebuild would take care of all of these at the same time. I plan to only rebuild Rust applications that are associated with the Rust SIG (i.e. packages "rust-*"), but no other packages (for example, firefox, thunderbird, or librsvg2). If any maintainers of packages that contain Rust code but that are not co-maintained by the Rust SIG would like their packages to be included in the mini-mass-rebuild as well, just let me know and I'll add them to my list. Fabio PS: Packages that build with vendored Rust dependencies (there are a handful of them, and most are not co-maintained by the Rust SIG) would only benefit from better debuginfo / backtraces, but not from security updates (that would require manually updating the vendor tarball), which is why I will not include them in the mini-mass-rebuild.

2 2

Implementing opt-in support for SPECPARTS in rust2rpm
by Fabio Valentini 15 May '24

15 May '24

Hello Rust packagers, I have realized today that with the upcoming EOL of Fedora 38, all branches of Fedora will ship with a version of RPM (i.e. >= 4.19) that supports dynamic generation of spec file snippets at build-time (SPECPARTS). In particular, if I understand correctly how it works, I think this functionality would be great for generating the "+feature-devel" subpackages in Rust crate packages. It would reduce spec file churn when updating Rust crates to new versions, and would make it easier to integrate tooling like packit: There would no longer need to be a MUST requirement to regenerate spec files for Rust crates for every new upstream version, since that requirement is almost entirely caused by the requirement of keeping feature subpackages in sync with crate features. Since this functionality would not be available in EPEL 9 probably ever, if this is implemented, it would probably be best kept as an opt-in feature for now (likely via rust2rpm config) for Fedora-only Rust packages. What do you think? Fabio

3 4

2025

2024

2023

2022

2021

2020

2019

2018

2017

Rust May 2024