[GH-ISSUE #294] trait bound `key_row::KeyRow: IsA<ActionRow>` is not satisfied #148

New issue

Closed

opened 2026-05-05 22:11:39 -06:00 by gitea-mirror · 4 comments

gitea-mirror commented

2026-05-05 22:11:39 -06:00

Owner

Originally created by @DrYak on GitHub (May 16, 2025).
Original GitHub issue: https://github.com/feschber/lan-mouse/issues/294

Hello, while rebuilding my RPM of lan-mouse I am getting these errors:

[  213s] error[E0277]: the trait bound `key_row::KeyRow: IsA<ActionRow>` is not satisfied
[  213s]   --> lan-mouse-gtk/src/key_row/imp.rs:68:6
[  213s]    |
[  213s] 68 | impl ActionRowImpl for KeyRow {}
[  213s]    |      ^^^^^^^^^^^^^ the trait `IsA<ActionRow>` is not implemented for `key_row::KeyRow`
[  213s]    |
[  213s]    = help: the following other types implement trait `IsA<T>`:
[  213s]              `key_row::KeyRow` implements `IsA<Accessible>`
[  213s]              `key_row::KeyRow` implements `IsA<Actionable>`
[  213s]              `key_row::KeyRow` implements `IsA<Buildable>`
[  213s]              `key_row::KeyRow` implements `IsA<ConstraintTarget>`
[  213s]              `key_row::KeyRow` implements `IsA<ExpanderRow>`
[  213s]              `key_row::KeyRow` implements `IsA<ListBoxRow>`
[  213s]              `key_row::KeyRow` implements `IsA<PreferencesRow>`
[  213s]              `key_row::KeyRow` implements `IsA<gtk4::Widget>`
[  213s]            and 2 others
[  213s] note: required by a bound in `libadwaita::subclass::action_row::ActionRowImpl`
[  213s]   --> /home/abuild/rpmbuild/BUILD/lan-mouse-0.10.0_40-build/lan-mouse-0.10.0~40/vendor/libadwaita-0.7.2/src/subclass/action_row.rs:7:68
[  213s]    |
[  213s] 7  | pub trait ActionRowImpl: PreferencesRowImpl + ObjectSubclass<Type: IsA<ActionRow>> {
[  213s]    |                                                                    ^^^^^^^^^^^^^^ required by this bound in `ActionRowImpl`

The difference I notice is that the last successful local build was using libadwaita 0.7.1, whereas the version that got automatically vendorized into the RPM is 0.7.2

Originally created by @DrYak on GitHub (May 16, 2025). Original GitHub issue: https://github.com/feschber/lan-mouse/issues/294 Hello, while rebuilding my RPM of lan-mouse I am getting these errors: ```console [ 213s] error[E0277]: the trait bound `key_row::KeyRow: IsA<ActionRow>` is not satisfied [ 213s] --> lan-mouse-gtk/src/key_row/imp.rs:68:6 [ 213s] | [ 213s] 68 | impl ActionRowImpl for KeyRow {} [ 213s] | ^^^^^^^^^^^^^ the trait `IsA<ActionRow>` is not implemented for `key_row::KeyRow` [ 213s] | [ 213s] = help: the following other types implement trait `IsA<T>`: [ 213s] `key_row::KeyRow` implements `IsA<Accessible>` [ 213s] `key_row::KeyRow` implements `IsA<Actionable>` [ 213s] `key_row::KeyRow` implements `IsA<Buildable>` [ 213s] `key_row::KeyRow` implements `IsA<ConstraintTarget>` [ 213s] `key_row::KeyRow` implements `IsA<ExpanderRow>` [ 213s] `key_row::KeyRow` implements `IsA<ListBoxRow>` [ 213s] `key_row::KeyRow` implements `IsA<PreferencesRow>` [ 213s] `key_row::KeyRow` implements `IsA<gtk4::Widget>` [ 213s] and 2 others [ 213s] note: required by a bound in `libadwaita::subclass::action_row::ActionRowImpl` [ 213s] --> /home/abuild/rpmbuild/BUILD/lan-mouse-0.10.0_40-build/lan-mouse-0.10.0~40/vendor/libadwaita-0.7.2/src/subclass/action_row.rs:7:68 [ 213s] | [ 213s] 7 | pub trait ActionRowImpl: PreferencesRowImpl + ObjectSubclass<Type: IsA<ActionRow>> { [ 213s] | ^^^^^^^^^^^^^^ required by this bound in `ActionRowImpl` ``` The difference I notice is that the last successful local build was using libadwaita 0.7.1, whereas the version that got automatically vendorized into the RPM is 0.7.2

gitea-mirror closed this issue

2026-05-05 22:11:40 -06:00

gitea-mirror commented

2026-05-05 22:11:43 -06:00

Author

Owner

@DrYak commented on GitHub (May 22, 2025):

I've dug a bit into it on my side: the official rust plug-ins of OBS (OpenBuild Service) run cargo vendor with --versioned-dirs but without --locked.
This will predictably bump up the versions of everything and thus the most recent versions of everything will get vendorized.
Manually vendorizing with --locked keeps at the Cargo.lock's version 0.7.1 of libadwaita and doesn't trigger the above incompatibility.

For now I've changed the vendor package in my RPM and it temporarily solves the problem, until lan-mouse eventually get libadwaita-0.7.2 compatibility

@DrYak commented on GitHub (May 22, 2025): I've dug a bit into it on my side: the [official rust plug-ins](https://en.opensuse.org/openSUSE:Packaging_Rust_Software) of OBS (OpenBuild Service) run `cargo vendor` with `--versioned-dirs` but without `--locked`. This will predictably bump up the versions of everything and thus the most recent versions of everything will get vendorized. Manually vendorizing with `--locked` keeps at the `Cargo.lock`'s version 0.7.1 of libadwaita and doesn't trigger the above incompatibility. For now I've changed the vendor package in my RPM and it temporarily solves the problem, until lan-mouse eventually get libadwaita-0.7.2 compatibility

gitea-mirror commented

2026-05-05 22:11:43 -06:00

Author

Owner

@feschber commented on GitHub (Jun 12, 2025):

looks like a small oversight on my part. #300 should fix it

@feschber commented on GitHub (Jun 12, 2025): looks like a small oversight on my part. #300 should fix it

gitea-mirror commented

2026-05-05 22:11:45 -06:00

Author

Owner

@DrYak commented on GitHub (Jun 12, 2025):

Thanks for the fix, the latest master commit of lan-mouse now successfully builds the RPM with the automatically vendorized libadwaita 0.7.2.

(BTW: Any vague idea when you would be tagging 0.11 ?)

@DrYak commented on GitHub (Jun 12, 2025): Thanks for the fix, the latest master commit of lan-mouse [now successfully builds](https://build.opensuse.org/package/live_build_log/home:dr-yak/lan-mouse/openSUSE_Tumbleweed/x86_64) the RPM with the automatically vendorized libadwaita 0.7.2. (BTW: Any vague idea when you would be tagging 0.11 ?)

gitea-mirror commented

2026-05-05 22:11:46 -06:00

Author

Owner

@DrYak commented on GitHub (Jun 13, 2025):

Damn, the autobumping vendorizing broke it again: #303

@DrYak commented on GitHub (Jun 13, 2025): Damn, the autobumping vendorizing broke it again: #303