#3608 Updates Policy Exception for Mir and Miracle-WM
Closed: Accepted by zbyszek. Opened by sfaulken.

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

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:

  • Fixes BasicXCBConnection::destroy_window to call xcb_destroy_window instead of xcb_map_window
  • Fixes errors in XCB replies not being freed
  • Fixes an error where making a video fullscreen in Chromium browsers just makes the browser fullscreen, instead of the video
  • Fixes a number of potentially unsafe fatal_signal_handles such as SIGQUIT and SIGABRT which can hit arbitrary threads in arbitrary places

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

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

Metadata