Mir made a new release during the F44 Freeze
libmircommon and libmirserver both had ABI bumps to 67 and 12, respectively.
The only direct consumer of these libraries is Miracle-WM and Mir itself
mustang ~ % dnf rq --whatrequires 'libmirserver.so.66()(64bit)' mir-demos-0:2.25.1-5.fc44.x86_64 mir-devel-0:2.25.1-5.fc44.x86_64 mir-lomiri-libs-0:2.25.1-5.fc44.x86_64 mir-test-tools-0:2.25.1-5.fc44.x86_64 miracle-wm-0:0.8.3-3.fc44.x86_64
mustang ~ % dnf rq --whatrequires 'libmircommon.so.11()(64bit)' mir-demos-0:2.25.1-5.fc44.x86_64 mir-devel-0:2.25.1-5.fc44.x86_64 mir-lomiri-libs-0:2.25.1-5.fc44.x86_64 mir-server-libs-0:2.25.1-5.fc44.x86_64 mir-test-tools-0:2.25.1-5.fc44.x86_64 miracle-wm-0:0.8.3-3.fc44.x86_64
Miracle-WM also had a version update in the same window, from 0.8.3 to 0.9.0
I have built everything in: https://copr.fedorainfracloud.org/coprs/sfaulken/mir-2.26/
In addition to Miriway as the other major consumer of Mir.
Metadata Update from @ngompa: - Issue tagged with: updates policy exception
+1
The thing that's missing here for me would be an explanation of why is it important that these updates land in Fedora 44 too. Without that rationale, these updates not landing in F44 would be the expected outcome.
Right now, I'm a -1 on this. It's a major update with no obvious rationale for why it can't just wait until F45.
Metadata Update from @sgallagh: - Issue tagged with: meeting
If the release hadn't happened during the F44 freeze, I wouldn't even be trying to get it in, but it did. Mir isn't on a fixed release schedule.
It's not the end of the world if this exception gets declined, but it will cause some bugs to potentially be unaddressed for the better part of six months, and being as Miriway also isn't on a fixed schedule, I likely won't be able to update it, when it inevitably has a new release in the next few months, because Mir potentially will be too old.
Miracle-WM is only included here, because it's release was the most expedient way to build against the updated Mir-2.26
We don't presently have a huge userbase using Mir/Miriway/Miracle-WM (I don't think) but we are shipping Miriway as the default wayland compositor for the Fedora LXQt Spin, and we have a Fedora Miracle spin as well, that will benefit from the newer version of Miracle-WM
Some of the bugs addressed in this release of Mir are:
SIGQUIT
SIGABRT
Some of the new features, that benefit both Miriway and Miracle-WM are: - Adding image_set_to to input::CursorObserver that monitors when the cursor image changes - Adds ext-input-trigger-registration-v1 and ext-input-trigger-action-v1 wayland protocols, which provide improved handling of input trigger types (keyboard shortcuts, modifier taps/holds, pointer/touch gestures) and associating them with named actions - Adds a partial implementation of ext_image_copy_capture_v1 which greatly improves the cursor tracking, especially in remote desktop situations, and when running as a virtualized guest - Replaces strerror() with thread safe version strerror_r() - CursorObserverMultiplexer sends the initial state to newly registered CursorObservers
image_set_to
input::CursorObserver
ext-input-trigger-registration-v1
ext-input-trigger-action-v1
ext_image_copy_capture_v1
strerror()
strerror_r()
This was discussed during the FESCo meeting on Tuesday: the exception is APPROVED (+5, ±1, -1)
Metadata Update from @zbyszek: - Issue close_status updated to: Accepted - Issue status updated to: Closed (was: Open)
Metadata Update from @zbyszek: - Issue untagged with: meeting