Fedora Account System
Red Hat Associate
Red Hat Customer
Spec URL: https://kalev.fedorapeople.org/rust-libadwaita-sys.spec SRPM URL: https://kalev.fedorapeople.org/rust-libadwaita-sys-0.1.0-2.fc38.src.rpm Description: This is a continuation of rust-libadwaita-sys packaging that got stalled in https://bugzilla.redhat.com/show_bug.cgi?id=2066040. I've only done a tiny change and regenerated the spec file with latest rust2rpm. Beyond that it's the same spec file that zhangyuannie put together. It's still on version 0.1.0 as we don't have new enough rust gtk4 bindings in rawhide yet to build 0.2.0. I intend to work on getting them updated once the libadwaita bindings are in. Fedora Account System Username: kalev
Koji scratch build: https://koji.fedoraproject.org/koji/taskinfo?taskID=94020270
*** Bug 2066040 has been marked as a duplicate of this bug. ***
Please don't waste your time on trying to update the gtk-rs stack to v0.16 / gtk4-rs v0.5 / gstreamer-rs v0.19, as that's probably above your pay grade (yes, it's not lost on me that I don't get paid for this stuff at all). The glib / gtk3 / gtk4 / gstreamer bindings are a tangled mess that can only be updated as a single unit. They're also one of the few groups of Rust packages that are only ever updated in rawhide, because they break so many things with each "major" update (gtk-rs 0.15 -> 0.16, in this case), and gtk-rs applications we ship often need some time to adapt to the new versions. I will handle the gtk-rs v0.16 + gtk4-rs v0.5 + gstreamer-rs v0.19 mega-update in F38 once things have settled down, but for now, we'll have to stick with gtk-rs v0.15 + gtk4-rs v0.4 + gstreamer-rs v0.18. === You can add this rust2rpm.conf file to automate adding Build/Requires: ``` [DEFAULT] buildrequires = pkgconfig(libadwaita-1) >= 1.0.0 lib.requires = pkgconfig(libadwaita-1) >= 1.0.0 ``` === Package was generated with rust2rpm, simplifying the review. - package builds and installs without errors on rawhide - test suite is run and all unit tests pass ! latest version of the crate is packaged (latest version that is compatible with versions of gtk-rs stack in Fedora is packaged) - license matches upstream specification and is acceptable for Fedora - license file is included with %license in %files (license manually included from upstream project until it will be included in crate sources with future versions) - package complies with Rust Packaging Guidelines Package APPROVED. === Recommended post-import rust-sig tasks: - add @rust-sig with "commit" access as package co-maintainer - set bugzilla assignee overrides to @rust-sig (optional) - set up package on release-monitoring.org: project: $crate homepage: https://crates.io/crates/$crate backend: crates.io version scheme: semantic version filter: alpha;beta;rc;pre distro: Fedora Package: rust-$crate - track package in koschei for all built branches
Thanks for the review, Fabio! I really appreciate all the help here. (In reply to Fabio Valentini from comment #3) > Please don't waste your time on trying to update the gtk-rs stack to v0.16 / > gtk4-rs v0.5 / gstreamer-rs v0.19, as that's probably above your pay grade > (yes, it's not lost on me that I don't get paid for this stuff at all). I don't understand at all what you mean with the pay grade comment. Can you clarify, please? > The glib / gtk3 / gtk4 / gstreamer bindings are a tangled mess that can only > be updated as a single unit. They're also one of the few groups of Rust > packages that are only ever updated in rawhide, because they break so many > things with each "major" update (gtk-rs 0.15 -> 0.16, in this case), and > gtk-rs applications we ship often need some time to adapt to the new > versions. > > I will handle the gtk-rs v0.16 + gtk4-rs v0.5 + gstreamer-rs v0.19 > mega-update in F38 once things have settled down, but for now, we'll have to > stick with gtk-rs v0.15 + gtk4-rs v0.4 + gstreamer-rs v0.18. I think it's worth trying to make sure there are more than one people who know enough to keep the stack updated. If you don't mind, I'd like to be involved in updating it this time around. What makes it especially complicated? Is there something in the stack that makes it hard to do compat packages to keep apps that haven't been updated for the new version working? If it's so hard to keep it up to date, maybe we should suggest vendoring it all instead... > > === > > You can add this rust2rpm.conf file to automate adding Build/Requires: > > ``` > [DEFAULT] > buildrequires = > pkgconfig(libadwaita-1) >= 1.0.0 > lib.requires = > pkgconfig(libadwaita-1) >= 1.0.0 > ``` Yes, thanks -- I already had that.
(In reply to Kalev Lember from comment #4) > I don't understand at all what you mean with the pay grade comment. Can you > clarify, please? Sorry, I might have used the wrong idiom here. I meant to say: The major gtk-rs updates are a bit painful. - it's a lot of packages that need to be built in the correct order - all builds need to be submitted to bodhi together as a single update - not all applications port to new major gtk-rs versions immediately Especially the last one is the reason why I have, in the past, submitted breaking gtk-rs stack updates only to rawhide (or rawhide and branched, depending on the timing of the release). > I think it's worth trying to make sure there are more than one people who > know enough to keep the stack updated. If you don't mind, I'd like to be > involved in updating it this time around. The problem is not the *how*. It's "just work", but it needs to be done carefully, and coordinated with maintainers of affected applications. > What makes it especially complicated? Is there something in the stack that > makes it hard to do compat packages to keep apps that haven't been updated > for the new version working? > > If it's so hard to keep it up to date, maybe we should suggest vendoring it > all instead... The problem is not that it's *hard* to keep it up-to-date and do compat packages, but it's the *scope*. With previous bumps, usually all but one application had already ported to the new version, so adding a few dozen (!) compat packages just to keep one application building was just not worth it - so I announced the gtk-rs update as a breaking change, and only pushed it to rawhide. Do you think we'll have more applications that use gtk-rs in Fedora in the Future? Then the effort of creating / building / maintaining a few dozen compat packages for older gtk-rs versions *might* be worth it.
I might add that this is, in fact, very similar to how other breaking changes (including in the GNOME stack) are handled - announce breaking change, push only to rawhide. If applications *need* the newer version, they're usually out of luck on older Fedora releases. So in that regard, the gtk-rs packages are only different when looked at from the Rust packaging POV (most other crates are updated across all Fedora branches), but very similar to how other breaking changes happen in Fedora :)
(fedscm-admin): The Pagure repository was created at https://src.fedoraproject.org/rpms/rust-libadwaita-sys
Thanks! I have a bit clearer picture now what's going on with the gtk-rs stack :) Let me know if you want to start doing the stack update and I'll try to help as much as I can. I'd like to try to add a few GNOME rust apps just to get a better feel for the ecosystem. I guess I'll find out when doing that if they need the latest gtk-rs and if we need compat packages. We can continue the discussion on irc to avoid spamming an unrelated ticket :) I'm on #fedora-rust as well these days. -- Package imported and built.