Re: How to deal with packages cointaining rust parts?
by Fabio Valentini
On Sun, Apr 30, 2023 at 1:31 PM Julian Sikorski <belegdol(a)gmail.com> wrote:
>
> thanks for the detailed feedback! The reason I wanted to give it a shot
> was the issue reported with raw_thumbnailer [1]. I am already
> co-maintaining libopenraw, so I thought I could at least try.
> So far I managed to get packages for mp4parse, mp4parse_capi, criterion
> and bitreader building, see attached. I also managed libopenraw not to
> fail at attempting to go online, but I am not sure how to solve the
> error I am getting now:
>
> error: Dependency tokens must begin with alpha-numeric, '_' or '/':
> ~/build/BUILD/libopenraw-0 .3.5/lib/mp4 ~/build/BUILD/libopenraw-0.3.5
This is caused by using pushd / popd instead of "cd", because pushd
and popd print things to stdout that %generate_buildrequires
interprets as names of dependencies ... you can use plain "cd"
instead.
> I am also not sure I will be able to get rid of the patching. At the
> first glance it requires understanding what the patches are doing and
> knowing how to replace the functionality.
It doesn't look like a problem, the patch here looks harmless:
https://gitlab.freedesktop.org/libopenraw/libopenraw/-/blob/master/lib/mp...
> If you would be willing to pick up where I left, I can definitely offer
> to do the package reviews. I am just worried I would not be able to help
> much beyond that, saving for keeping the packages up-to-date and liasing
> with their upstreams. But it definitely looks like you are right and I
> have bitten off more than I can chew.
I took a look at the libopenraw spec file, and after fixing the
pushd/cd thing, the biggest problem I see is more of an upstream
problem ...
It bundles copies of the mp4parse and mp4parse_capi crates (no idea
whether the sources are just included or if they are forks with
downstream changes), in addition to 15 MB of vendored Rust
dependencies, which we cannot use for Fedora builds.
If the mp4parse{,_capi} sources are indeed forks with downstream
patches, it would be ok to leave them as they are, but the vendored
Rust dependencies need to be removed and can't be used. Honestly, the
entire Rust part of libopenraw [0] looks very "hackish" and ad-hoc
(it's not even a proper cargo workspace - which our Rust packaging
tools support - but disconnected crates that are held together by
path-based dependencies - which our tools *don't' support).
I'll try to make the package build ~somehow~, but I can't make any
promises right now :)
Fabio
[0]: https://gitlab.freedesktop.org/libopenraw/libopenraw/-/tree/master/lib/mp4
4 months, 3 weeks
How to deal with packages cointaining rust parts?
by Julian Sikorski
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_189...
[3] https://src.fedoraproject.org/rpms/rust-mp4parse
4 months, 4 weeks
Can the native rust-* packages be used for cross-compilation? (Use of undeclared crate or module `winapi`)
by Sandro Mani
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/
5 months, 3 weeks
