Rust April 2023

rust@lists.fedoraproject.org

5 participants
3 discussions

How to deal with packages cointaining rust parts?
by Julian Sikorski 02 May '23

02 May '23

Hello, I looked into updating libopenraw to 0.3.5 yesterday, in order to possibly enable packaging miniaturo [1], a drop-in replacement for the unmaintained raw-thumbnailer [2]. During the build process, libopenraw tries do download mp4parse and mp4parse_capi, which works if --enable-network is passed to mock. For a proper update I assume these dependencies would need to be packaged first. mp4_parse even used to have a fedora package at some point in the past [3]. The question is: what would the proper way of packaging the updated libopenraw? How to tell it to use the system versions of the libs? The guidelines appear to be focused on pure rust packages. And, even more importantly: would miniaturo be even allowed to be packaged? There appears to be no package at crates.io. Thanks for the input. Best regards, Julian [1] https://github.com/dbrgn/miniaturo [2] https://gitlab.freedesktop.org/libopenraw/libopenraw/-/issues/14#note_18907… [3] https://src.fedoraproject.org/rpms/rust-mp4parse

2 10

Firecracker dependency crates
by David Michael 07 Apr '23

07 Apr '23

Hi, I submitted a bunch of PRs to Rust crates that are already packaged in Fedora to work towards adding Firecracker. (There is some more context on the devel list.[0]) Here is the list of links in a reviewable order: https://src.fedoraproject.org/rpms/rust-crypto-common/pull-request/1 https://src.fedoraproject.org/rpms/rust-universal-hash/pull-request/1 https://src.fedoraproject.org/rpms/rust-polyval/pull-request/1 https://src.fedoraproject.org/rpms/rust-ghash/pull-request/1 https://src.fedoraproject.org/rpms/rust-aead/pull-request/1 https://src.fedoraproject.org/rpms/rust-aes-gcm/pull-request/1 https://src.fedoraproject.org/rpms/rust-cookie/pull-request/1 https://src.fedoraproject.org/rpms/rust-criterion-plot/pull-request/1 https://src.fedoraproject.org/rpms/rust-criterion/pull-request/3 These updates are all to the latest release branch of the crates in Fedora. I tried to check repoquery to make sure everything is updated that depends on the crates' release branch, but I don't know if my queries caught everything. Updates were mostly done by running the current rust2rpm and backporting any adjustments. The only non-Firecracker dependency that was updated is the cookie crate to support newer aes-gcm. It was updated to a new patchlevel version in the same release branch, so its dependencies shouldn't be affected. This would also unretire criterion, which is an optional build dependency for around half a dozen new crates. This is only a first step to update the crates already in Fedora. I have the full set of crates together in a Git repo[1]. If the PRs look okay, I can start submitting review requests for the new crates. Thanks. David [0] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org… [1] https://github.com/dm0-/copr-firecracker

3 15

Can the native rust-* packages be used for cross-compilation? (Use of undeclared crate or module `winapi`)
by Sandro Mani 07 Apr '23

07 Apr '23

Hi I'm trying to update mingw-librsvg2 to version 2.56.0 [1], and am stuck at the following issue: error[E0433]: failed to resolve: use of undeclared crate or module `winapi` --> /usr/share/cargo/registry/gio-sys-0.17.4/src/manual.rs:13:63 | 13 | pub const G_SOCKET_FAMILY_INVALID: super::GSocketFamily = winapi::shared::ws2def::AF_UNSPEC; | ^^^^^^ use of undeclared crate or module `winapi` I've build rust-winapi and manually added the BR rust-winapi-devel to mingw-librsvg2.spec, but this did not help. I suspect that here gio-sys is a "native" build which cannot be used for cross-compiling to Windows? Do I have to build a "mingw-rust-gio-sys"? I'm not really familiar with rust so any pointers are appreciated. Thanks Sandro [1] https://copr.fedorainfracloud.org/coprs/smani/mingw-librsvg2/

3 7

2025

2024

2023

2022

2021

2020

2019

2018

2017

Rust April 2023