[HEADS-UP] Planning to upgrade rust-loopdev to 0.4.0
by the Mulhern
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 year, 8 months
[HEADS-UP] Upcoming retirement of gstreamer-rs and wasm-bindgen stacks
by Fabio Valentini
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 year, 8 months
How to update packages?
by Orion Poplawski
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/
1 year, 8 months
Convention for releasing Rust packages after rawhide has branched
by the Mulhern
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
1 year, 8 months
packaging external-editor-revived
by Dusty Mabe
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
1 year, 8 months
Abandoning effort to package wasmtime
by Fabio Valentini
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 year, 8 months
How to build locally?
by Orion Poplawski
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/
1 year, 8 months
checksum changed error
by Orion Poplawski
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/
1 year, 8 months
Help updating rand usage in rust_dct
by Orion Poplawski
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.
1 year, 8 months