[regression] OTA7 broke previously working app
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Canonical System Image |
Won't Fix
|
Undecided
|
kevin gunn | ||
Mir |
Won't Fix
|
High
|
Unassigned | ||
0.16 |
Won't Fix
|
High
|
Unassigned | ||
0.17 |
Won't Fix
|
High
|
Unassigned | ||
mir (Ubuntu) |
Won't Fix
|
High
|
Unassigned |
Bug Description
OTA7 broke previously working app
after OTA7 update on Meizu MX4, glmark2 stopped working https:/
system updates should not break apps
~/.cache/upstart$ cat application-
libust[
libust[
libust[
libust[
Error: Couldn't connect to the Mir display server
Error: main: Could not initialize canvas
[1445336019.182277] <ERROR> MirConnectionAPI: Caught exception at client library boundary (in release): /build/
Dynamic exception type: N5boost16except
std::exception:
32, "Broken pipe"
libust[
libust[
libust[
libust[
Error: Couldn't connect to the Mir display server
Error: main: Could not initialize canvas
[1445336029.784398] <ERROR> MirConnectionAPI: Caught exception at client library boundary (in release): /build/
Dynamic exception type: N5boost16except
std::exception:
32, "Broken pipe"
Related branches
- PS Jenkins bot (community): Approve (continuous-integration)
- Mir CI Bot: Approve (continuous-integration)
- Alan Griffiths: Abstain
- Kevin DuBois (community): Approve
- Mir development team: Pending requested
-
Diff: 134 lines (+21/-26)3 files modifiedsrc/include/common/mir/protobuf/protocol_version.h (+10/-12)
src/server/frontend/socket_connection.cpp (+5/-7)
tests/acceptance-tests/test_client_library.cpp (+6/-7)
Changed in canonical-devices-system-image: | |
assignee: | nobody → kevin gunn (kgunn72) |
status: | New → Confirmed |
Changed in mir: | |
milestone: | 0.18.0 → none |
tags: |
added: regression-release removed: regression |
Changed in canonical-devices-system-image: | |
status: | Confirmed → Won't Fix |
Hi dinamic, good to hear from you again.
We do know of a protocol compatibility break that occurred in Mir 0.15.0, which was first reported as bug 1486496 (which due to disagreements got reworded and watered down such that mir-team was not required to fix the regression). I also mentioned back in August that it could become a problem for Snappy: https:/ /bugs.launchpad .net/mir/ +bug/1486496/ comments/ 15
Although I was trying for protocol backward- compatibility at the time, that's not something we can realistically maintain forever. And it was rightly pointed out that in a traditional packaging system the problem mostly would not exist as even old clients would start using the new (shared!) libmirclient/ libmirprotobuf automatically.
So this really is mostly just an issue we'll see in Snappy where apps carry their own libmir* client libraries. Here are some possible ways forward for us:
(a) App developers: Maybe ensure apps don't package libmir* and instead rely on that of the system/mir framework already installed; or
(b) ~mir-team: make a conscious decision to maintain socket protocol level compatibility for the lifetime of the given Ubuntu Touch series (which unfortunately also means supporting old buffer semantics too). Kind of analogous to what people usually do with ABIs; or
(c) ~mir-team: As we know the precise point of regression (r2730), make an effort to reinstate protocol backward compatibility (although this suggestion was met with strong opposition previously, and admittedly would be difficult to maintain forever).
Options (a) and (b) are most likely and unfortunately both require your app packages to get rebuilt/ re-released. Maybe there are more options?