I just got a bug report that the Fedora Linux package for helvum is out of date - we didn't notice that there were new releases of Helvum because Fedora Linux is set up to track releases via crates.io (https://release-monitoring.org/project/242208/). It would be great if the missing releases could be published to crates.io.
If you instead no longer plan to publish helvum on crates.io, please let us know, and we can switch to tracking GitLab tags directly. In that case, it would be good to publish a "sentinel" version on crates.io to let users know that it will not be getting the latest releases any longer.
Yes, the commit from your branch fixes the test failure
I get a strange test failure building gstreamer-rs v0.21.1 for Fedora - tests pass on all architectures, except for s390x (our only supported big-endian architecture). From the build log:
failures:
---- video_format::tests::sort stdout ----
thread 'video_format::tests::sort' panicked at src/video_format.rs:544:9:
assertion `left == right` failed
left: [Ayuv64, Argb64, Gbra12be, Gbra12le, A44410be, Gbra10be, A44410le, Gbra10le, A42210be, A42210le, A42010be, A42010le, Gbra, Ayuv, Rgba, Argb, Bgra, Abgr, A420, V216, Y44412be, Gbr12be, Y44412le, Gbr12le, I42212be, I42212le, I42012be, I42012le, Y44410be, Gbr10be, Y44410le, Gbr10le, R210, I42210be, I42210le, Nv1610le32, Uyvp, V210, I42010be, I42010le, P01010be, P01010le, Nv1210le32, Y444, Gbr, Nv24, V308, Iyu2, Rgbx, Xrgb, Bgrx, Xbgr, Rgb, Bgr, Y42b, Nv16, Nv61, Yuy2, Yvyu, Uyvy, Vyuy, I420, Yv12, Nv12, Nv21, Nv1264z32, Y41b, Iyu1, Yuv9, Yvu9, Bgr16, Rgb16, Bgr15, Rgb15, Rgb8p, Gray16Be, Gray16Le, Gray10Le32, Gray8]
right: [Ayuv64, Argb64, Gbra12be, Gbra12le, A44410be, Gbra10be, A44410le, Gbra10le, A42210be, A42210le, A42010be, A42010le, Gbra, Ayuv, Rgba, Argb, Bgra, Abgr, A420, V216, Y44412be, Gbr12be, Y44412le, Gbr12le, I42212be, I42212le, I42012be, I42012le, Y44410be, Gbr10be, Y44410le, Gbr10le, R210, I42210be, I42210le, Nv1610le32, Uyvp, V210, I42010be, I42010le, P01010be, Nv1210le32, P01010le, Y444, Gbr, Nv24, V308, Iyu2, Rgbx, Xrgb, Bgrx, Xbgr, Rgb, Bgr, Y42b, Nv16, Nv61, Yuy2, Yvyu, Uyvy, Vyuy, I420, Yv12, Nv12, Nv21, Nv1264z32, Y41b, Iyu1, Yuv9, Yvu9, Bgr16, Rgb16, Bgr15, Rgb15, Rgb8p, Gray16Be, Gray16Le, Gray10Le32, Gray8]
failures:
video_format::tests::sort
test result: FAILED. 25 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.03s
error: test failed, to rerun pass `--lib`
The lists are identical except two adjacent elements that are swapped: P01010le, Nv1210le32
vs. Nv1210le32, P01010le
It appears that this code has recently changed? 635b3161
If I read the changelog correctly, pipewire 0.3.65 should have reintroduced this symbol (with a warning) - but Fedora builds of the pipewire Rust binings and helvum still fail with this same error.
I'm co-maintaining the PipeWire Rust bindings on Fedora, and they started to fail to build since the update to PipeWire 0.3.64 with this error:
error[E0425]: cannot find value `PW_KEY_NODE_TARGET` in crate `pw_sys`
--> src/auto/keys.rs:164:28
|
164 | key_constant!(NODE_TARGET, PW_KEY_NODE_TARGET,
| ^^^^^^^^^^^^^^^^^^ help: a constant with a similar name exists: `PW_KEY_NODE_NAME`
|
::: /builddir/build/BUILD/pipewire-0.5.0/target/release/build/pipewire-sys-7764d7a430245b6f/out/bindings.rs:5:8276
|
5 | ... b"node.id\0" ; pub const PW_KEY_NODE_NAME : & [u8 ; 10usize] = b"node.name\0" ; pub const PW_KEY_NODE_NICK : & [u8 ; 10usize] = b"nod...
| --------------------------------------------- similarly named constant `PW_KEY_NODE_NAME` defined here
For more information about this error, try `rustc --explain E0425`.
error: could not compile `pipewire` due to previous error
It might not break the ABI if this constant is still there but just not exported in header files, but it's still a breaking change. The release highlights for 0.3.64 mention that the NODE_TARGET
has been deprecated (but not that it has been removed).
Digging into it more, it looks like none of the applications building against PipeWire in Fedora use this API, so it's not a problem in that regard - but the Rust bindings are now broken because PW_KEY_NODE_TARGET
is no longer defined.
Should I report an issue with pipewire-rs about this? Removing this constant from the API there might or might not break API as well (which would require a major version bump), so maybe the bindings should build with PW_ENABLE_DEPRECATED
defined by default?
So 0.3.64 is not API compatible after all? The Rust bindings don't export this environment variable, so they are currently broken with 0.3.64.
I'm co-maintaining the PipeWire Rust bindings on Fedora, and they started to fail to build since the update to PipeWire 0.3.64 with this error:
error[E0425]: cannot find value `PW_KEY_NODE_TARGET` in crate `pw_sys`
--> src/auto/keys.rs:164:28
|
164 | key_constant!(NODE_TARGET, PW_KEY_NODE_TARGET,
| ^^^^^^^^^^^^^^^^^^ help: a constant with a similar name exists: `PW_KEY_NODE_NAME`
|
::: /builddir/build/BUILD/pipewire-0.5.0/target/release/build/pipewire-sys-7764d7a430245b6f/out/bindings.rs:5:8276
|
5 | ... b"node.id\0" ; pub const PW_KEY_NODE_NAME : & [u8 ; 10usize] = b"node.name\0" ; pub const PW_KEY_NODE_NICK : & [u8 ; 10usize] = b"nod...
| --------------------------------------------- similarly named constant `PW_KEY_NODE_NAME` defined here
For more information about this error, try `rustc --explain E0425`.
error: could not compile `pipewire` due to previous error
It might not break the ABI if this constant is still there but just not exported in header files, but it's still a breaking change. The release highlights for 0.3.64 mention that the NODE_TARGET
has been deprecated (but not that it has been removed).
Thanks for merging!
Fixes #273
Fabio Valentini (fd89c1cd) at 24 Jul 16:02
zbus_names: include symlink to the LICENSE file
It appears that all crates that are managed and published from this cargo workspace contain the LICENSE -> ../LICENSE
symlink that's required for published crates to contain a license file, except for zbus_names
, which seems to have been created last. So I assume this is an oversight.
Thanks!
The libspa-sys, libspa, pipewire-sys, and pipewire crates as published to crates.io all do not contain a license file. To comply with the terms of the MIT license, including a LICENSE file with redistributed sources is a requirement. This is also a problem for packaging these crates for Fedora, for example.
Adding LICENSE -> ../LICENSE
symlinks inside the four folders should fix the problem, at least for the next versions that are published.
Uhm, I know this issue is kinda old, and the repository hasn't been touched in years, but this issue has popped up again during a Fedora package review, and it would really be great to have it fixed.
I'm currently only going through our backlog of crate version updates etc., so I'm not planning to package anything new for now. And since today, gtk-rs is now updated to 0.14.0 and gstreamer-rs is at 0.17.0 in Fedora Rawhide, so that's done, for now at least ...
We did until a few years ago ... but big-dndian POWER is no longer supported, since Fedora 28 or so, now we only have powerpc64le, and s390x is the only big-endian architecture left.
In any case, let me know if there's anything that can make things easier to package for you :)
Thanks! gstreamer-rs is pretty simple to package, we have good tooling for Rust stuff, but I'll keep that in mind
Good to know!
I encountered this while working on the Fedora packages for gstreamer-rs. The only big-endian architecture we support is s390x / IBM System Z (the mainframe stuff), target triple s390x-unknown-linux-gnu
in Rust :)
Fixes #351
This MR changes the code for big-endian targets to match that for little-endian targets.
Previously, the crate::
path prefix was missing, causing compilation to fail due to syntax / path resolution errors.