August 2022 - Rust - Fedora mailing-lists

[HEADS-UP] Planning to upgrade rust-loopdev to 0.4.0
by the Mulhern 22 Aug '22

22 Aug '22

Hi all, I'm planning to upgrade rust-loopdev to 0.4.0 to evade some cruft that is in the previously released 0.2.0. As far as I can tell, only Stratis projects stratisd, rust-devicemapper, and rust-libcryptsetup depend on this crate. - mulhern -- The Moving Finger writes; and, having writ, Moves on: nor all thy Piety nor Wit Shall lure it back to cancel half a Line, Nor all thy Tears wash out a Word of it. - "The Rubaiyat of Omar Khayyam", Robert Fitzgerald, translator

1 0

[HEADS-UP] Upcoming retirement of gstreamer-rs and wasm-bindgen stacks
by Fabio Valentini 20 Aug '22

20 Aug '22

Hello fellow Rust packagers, I am progressing with my "spring cleaning" efforts for the Rust stack, and it became apparent that there's a few clusters of packages that are actually unused, but which regularly take up a non-insignificant amount of my package maintenance time. The gstreamer-rs stack seems to have been imported in preparation for packaging an application (maybe shortwave?) over three years ago (!), but that effort seems to have been abandoned, and as a result, the following packages have been unused since (but were actively maintained and updated to new versions): - rust-gstreamer - rust-gstreamer-sys - rust-gstreamer-audio - rust-gstreamer-audio-sys - rust-gstreamer-base - rust-gstreamer-base-sys - rust-gstreamer-editing-services - rust-gstreamer-editing-services-sys - rust-gstreamer-pbutils - rust-gstreamer-pbutils-sys - rust-gstreamer-player - rust-gstreamer-player-sys - rust-gstreamer-video - rust-gstreamer-video-sys Another set of packages that has been unused for over two years are the packages for wasm-bindgen and the JavaScript (js-sys) / Web API (web-sys) bindings. They appear to have been packaged "by mistake", and all dependencies on these crates turned out to be either unnecessary or no-ops, since we do not compile any WebAssembly (targeted at JavaScript / web browsers) from Fedora Rust packages: - rust-wasm-bindgen - rust-wasm-bindgen-backend - rust-wasm-bindgen-macro - rust-wasm-bindgen-macro-support - rust-wasm-bindgen-shared - rust-js-sys - rust-web-sys I would like to retire all listed packages (and possibly some resulting new leaf packages) in time for the Fedora 37 freezes, given that they have been unused for years and only cause additional maintenance burden for the Rust SIG (i.e. me). Please make yourself heard if you are packaging something that will depend on any of these packages, or have another legitimate use-case for these packages. Fabio

1 0

How to update packages?
by Orion Poplawski 17 Aug '22

17 Aug '22

So, how does one actually go about updating a rust package? How do you find out what breaks with the update? Do we always provide a compat package, or do we try to update the deps? Go for it in a side tag and make a compat package if we can't update the deps? For example, looking at updating miniz_oxide to 0.5.3, if I try to install on my devel machine that is loading with rust packages I get: Error: Problem 1: problem with installed package rust-tiff-devel-0.6.1-5.fc37.noarch - package rust-tiff-devel-0.6.1-5.fc37.noarch requires (crate(miniz_oxide/default) >= 0.4.1 with crate(miniz_oxide/default) < 0.5.0~), but none of the providers can be installed - cannot install both rust-miniz_oxide+default-devel-0.5.3-1.fc37.noarch and rust-miniz_oxide+default-devel-0.4.4-4.fc37.noarch - conflicting requests Problem 2: problem with installed package rust-flate2+miniz_oxide-devel-1.0.22-3.fc37.noarch - package rust-flate2+miniz_oxide-devel-1.0.22-3.fc37.noarch requires (crate(miniz_oxide) >= 0.4.0 with crate(miniz_oxide) < 0.5.0~), but none of the providers can be installed - cannot install both rust-miniz_oxide-devel-0.5.3-1.fc37.noarch and rust-miniz_oxide-devel-0.4.4-4.fc37.noarch - conflicting requests Problem 3: problem with installed package rust-png-devel-0.17.2-2.fc37.noarch - package rust-png-devel-0.17.2-2.fc37.noarch requires (crate(miniz_oxide/no_extern_crate_alloc) >= 0.4.1 with crate(miniz_oxide/no_extern_crate_alloc) < 0.5.0~), but none of the providers can be installed - cannot install both rust-miniz_oxide+no_extern_crate_alloc-devel-0.5.3-1.fc37.noarch and rust-miniz_oxide+no_extern_crate_alloc-devel-0.4.4-4.fc37.noarch - conflicting requests But I don't know how to construct a repoquery that would test for that. -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion(a)nwra.com Boulder, CO 80301 https://www.nwra.com/

2 4

Convention for releasing Rust packages after rawhide has branched
by the Mulhern 16 Aug '22

16 Aug '22

Hi all, Since last week, rawhide is now headed into f38, and f37 (which was rawhide) is now its own branch. What I'm trying to understand is what the appropriate conventions are for releasing new versions of Rust libraries into Fedora. Take for example, rust-ouroborous[1], which was released in four places, rawhide (f38), f37, f36, and f35. In contrast, rust-pretty-hex[2] is released only into rawhide (f38), f37, and f36. I think that the reason for the difference is that the new version of rust-pretty-hex is is semantically incompatible with the previous version, and that it was due to that that it was not released into f35. So, the rule I have come up with is that, after rawhide branches to release n (currently f38), semantically incompatible updates of libraries shall be released only to Fedora releases n, n - 1, and n - 2, but no further. OTOH, semantically compatible updates of Rust libraries shall be released to n, n - 1, n - 2, and n - 3 Fedora releases until n - 3 goes out of support, i.e., for another 2 months, approx. Is that more or less the rule to follow? Thanks, - mulhern [1] https://src.fedoraproject.org/rpms/rust-ouroboros [2] https://src.fedoraproject.org/rpms/rust-pretty-hex -- The Moving Finger writes; and, having writ, Moves on: nor all thy Piety nor Wit Shall lure it back to cancel half a Line, Nor all thy Tears wash out a Word of it. - "The Rubaiyat of Omar Khayyam", Robert Fitzgerald, translator

2 1

packaging external-editor-revived
by Dusty Mabe 14 Aug '22

14 Aug '22

Hi, There is a thunderbird extension that allows you to pop open the email compose window into an external editor: https://github.com/Frederick888/external-editor-revived/ It's rust based and appears to have one build dep that isn't in Fedora right now: https://crates.io/crates/web-ext-native-messaging The external editor isn't on crates.io, but I can make the necessary modifications to the spec file (generated by rust2rpm) to deal with that. For web-ext-native-messaging I generated a spec using rust2rpm and built it pretty easy. Since it follows the normal pattern is there a way for the rust sig to import and maintain the web-ext-native-messaging dep? For external-editor-revived, since it's not a library (not a build dep of anything) I assume I should name the RPM `external-editor-revived` without the rust- prefix, correct? Thanks for any help here! Dusty

2 3

Abandoning effort to package wasmtime
by Fabio Valentini 09 Aug '22

09 Aug '22

Hello fellow Rust packagers, I decided to abandon my ongoing effort to package wasmtime. The version for which all review requests had been approved is pretty old now, and some packages which were already approved a long time ago have never been imported, because they have been blocked on FE-Legal for half a year. Today I tried updating all cranelift / wasmtime packages that are already in Fedora or pending review (in COPR), but at this point, this effort to update 30-40 inter-dependent Rust packages (and get new dependencies for every minor version through review) is just not worth it for me any longer, especially since those packages are unused, as /usr/bin/wasmtime was never actually imported to Fedora due to the unresolved FE-Legal block. I will retire the affected (unused) packages from rawhide later today. Fabio

1 0

How to build locally?
by Orion Poplawski 08 Aug '22

08 Aug '22

When I try to do a local build with fedpkg local I generally get something like: ++ /usr/bin/cargo-inspector --version Cargo.toml + CRATE_VERSION=0.2.6 + REG_DIR=/home/orion/BUILDROOT/rust-jpeg-decoder-0.2.6-1.fc37.x86_64/usr/share/cargo/registry/jpeg-decoder-0.2.6 + /usr/bin/mkdir -p /home/orion/BUILDROOT/rust-jpeg-decoder-0.2.6-1.fc37.x86_64/usr/share/cargo/registry/jpeg-decoder-0.2.6 + gawk -i inplace -v INPLACE_SUFFIX=.deps '/^\[((.+\.)?((dev|build)-)?dependencies|features)/{f=1;next} /^\[/{f=0}; !f' Cargo.toml + /usr/bin/env CARGO_HOME=.cargo RUSTC_BOOTSTRAP=1 'RUSTFLAGS=-Copt-level=3 -Cdebuginfo=2 -Ccodegen-units=1 -Clink-arg=-Wl,-z,relro -Clink-arg=-Wl,-z,now -Clink-arg=-Wl,-dT,/home/orion/fedora/rust-jpeg-decoder/jpeg-decoder-0.2.6/.package_note-rust-jpeg-decoder-0.2.6-1.fc37.x86_64.ld --cap-lints=warn' /usr/bin/cargo package -l + grep -w -E -v 'Cargo.(lock|toml.orig)' + xargs -d '\n' /usr/bin/cp --parents -a -t /home/orion/BUILDROOT/rust-jpeg-decoder-0.2.6-1.fc37.x86_64/usr/share/cargo/registry/jpeg-decoder-0.2.6 error: 36 files in the working directory contain changes that were not yet committed into git: tests/rayon.rs tests/lib.rs tests/rayon-0.rs tests/rayon-1.rs tests/rayon-2.rs Cargo.toml.deps LICENSE-MIT Cargo.toml src/marker.rs src/lib.rs src/decoder/lossless.rs src/idct.rs src/worker/mod.rs src/worker/rayon.rs src/worker/multithreaded.rs src/worker/immediate.rs src/arch/mod.rs src/arch/neon.rs src/arch/ssse3.rs src/parser.rs src/huffman.rs src/error.rs src/decoder.rs src/upsampler.rs LICENSE-APACHE benches/tower.jpg benches/large_image.rs benches/tower_progressive.jpg benches/tower_grayscale.jpg benches/decoding_benchmark.rs benches/large_image.jpg CHANGELOG.md rust-toolchain appveyor.yml README.md examples/decode.rs to proceed despite this and include the uncommitted changes, pass the `--allow-dirty` flag /usr/bin/cp: missing file operand Try '/usr/bin/cp --help' for more information. error: Bad exit status from /var/tmp/rpm-tmp.SxxYSB (%install) How does one get around this? -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion(a)nwra.com Boulder, CO 80301 https://www.nwra.com/

2 1

checksum changed error
by Orion Poplawski 08 Aug '22

08 Aug '22

I'm very new to rust and trying to build ClamAV 0.105.1 which adds usage of rust. I'm getting errors like the following when building (the package name seems to change): error: checksum for `heck v0.3.3` changed between lock files this could be indicative of a few possible errors: * the lock file is corrupt * a replacement source in use (e.g., a mirror) returned a different checksum * the source itself may be corrupt in one way or another unable to verify that `heck v0.3.3` is the same as when the lockfile was generated gmake[2]: Leaving directory '/builddir/build/BUILD/clamav-0.105.1/redhat-linux-build' gmake[2]: *** [libclamav_rust/CMakeFiles/clamav_rust_target.dir/build.make:83: libclamav_rust/x86_64-unknown-linux-gnu/debug/libclamav_rust.a] Error 101 gmake[1]: *** [CMakeFiles/Makefile2:1539: libclamav_rust/CMakeFiles/clamav_rust_target.dir/all] Error 2 I'm building from: https://src.fedoraproject.org/fork/orion/rpms/clamav/tree/0.105 though it needs a bunch of rust packages that I've just submitted for review. Any help would be greatly appreciated. -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion(a)nwra.com Boulder, CO 80301 https://www.nwra.com/

2 1

Help updating rand usage in rust_dct
by Orion Poplawski 08 Aug '22

08 Aug '22

I'm looking at packaging rust_dct for use by clamav. It fails to compile with the lastest rand due to a large amount of API changes between 0.4 and 0.8. I've filed a request upstream (https://github.com/ejmahler/rust_dct/issues/12) but figured I would ask here as well if anyone has experience with rand and porting packages to the latest version. Thanks.

2 2

Rustup packaging
by Andy Wang 04 Aug '22

04 Aug '22

Hi Rust SIG, I'm trying to package rustup so that users won't have to curl | bash. Here are the dependency issues, and my attempts to solve them: - (crate(effective-limits/default) >= 0.5.3 with crate(effective-limits/default) < 0.6.0~) On COPR: https://copr.fedorainfracloud.org/coprs/cbeuw/rustup-deps/package/rust-effe… - (crate(enum-map/default) >= 2.0.3 with crate(enum-map/default) < 3.0.0~) Package exists but on version 1.1.0: https://src.fedoraproject.org/rpms/rust-enum-map - (crate(git-testament/default) >= 0.2.0 with crate(git-testament/default) < 0.3.0~) Missing subdependencies: - (crate(no-std-compat/alloc) >= 0.4.0 with crate(no-std-compat/alloc) < 0.5.0~) On COPR https://copr.fedorainfracloud.org/coprs/cbeuw/rustup-deps/package/rust-no-s… - (crate(no-std-compat/default) >= 0.4.0 with crate(no-std-compat/default) < 0.5.0~) On COPR https://copr.fedorainfracloud.org/coprs/cbeuw/rustup-deps/package/rust-no-s… - (crate(rs_tracing/default) >= 1.0.1 with crate(rs_tracing/default) < 2.0.0~) On COPR https://copr.fedorainfracloud.org/coprs/cbeuw/rustup-deps/package/rust-rs_t… - (crate(rs_tracing/rs_tracing) >= 1.0.1 with crate(rs_tracing/rs_tracing) < 2.0.0~) On COPR https://copr.fedorainfracloud.org/coprs/cbeuw/rustup-deps/package/rust-rs_t… - (crate(sequoia-openpgp/crypto-rust) >= 1.5.0 with crate(sequoia-openpgp/crypto-rust) < 2.0.0~) Package exists but missing crypto-rust feature, PR filed https://src.fedoraproject.org/rpms/rust-sequoia-openpgp/pull-request/1 - (crate(zstd/default) >= 0.11.0 with crate(zstd/default) < 0.12.0~) Package exists but on version 0.10.0 https://src.fedoraproject.org/rpms/rust-zstd I have several questions: 1. How can I tell fedpkg to use my COPR project so that git-testament can be built? Or can it only be packaged after its dependency no-std-compat is in the official repo? 2. What should we do with enum-map, which requires a backwards-incompatible major version update. I can't find policy documents on this 3. I've never submitted a Fedora package before, so would anyone in Rust SIG be willing to sponsor me when I create my Review Request? Many Thanks! Andy

4 6

2024

2023

2022

2021

2020

2019

2018

2017

Rust August 2022