Merge lp://qastaging/~vanvugt/mir/common7 into lp://qastaging/mir
- common7
- Merge into development-branch
Status: | Merged |
---|---|
Approved by: | Daniel van Vugt |
Approved revision: | no longer in the source branch. |
Merged at revision: | 3758 |
Proposed branch: | lp://qastaging/~vanvugt/mir/common7 |
Merge into: | lp://qastaging/mir |
Diff against target: |
212 lines (+18/-92) 6 files modified
debian/control (+2/-2) debian/libmircommon7.install (+1/-1) src/common/CMakeLists.txt (+1/-1) src/common/dispatch/CMakeLists.txt (+0/-1) src/common/dispatch/legacy_readable_fd.cpp (+0/-34) src/common/symbols.map (+14/-53) |
To merge this branch: | bzr merge lp://qastaging/~vanvugt/mir/common7 |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Daniel van Vugt | Abstain | ||
Mir CI Bot | continuous-integration | Approve | |
Alan Griffiths | Disapprove | ||
Kevin DuBois (community) | Approve | ||
Review via email:
|
Commit message
Bump ABI to MIR_COMMON_0.25 (libmircommon.so.7)
Because a public symbol got removed yesterday in r3756 and we failed to notice before it landed: MirInputDeviceS
Description of the change
.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Mir CI Bot (mir-ci-bot) wrote : | # |
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Daniel van Vugt (vanvugt) wrote : | # |
^^^
Bug 1560909
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Mir CI Bot (mir-ci-bot) wrote : | # |
FAILED: Continuous integration, rev:3678
https:/
Executed test runs:
FAILURE: https:/
SUCCESS: https:/
SUCCESS: https:/
SUCCESS: https:/
SUCCESS: https:/
SUCCESS: https:/
deb: https:/
SUCCESS: https:/
deb: https:/
SUCCESS: https:/
deb: https:/
SUCCESS: https:/
deb: https:/
FAILURE: https:/
SUCCESS: https:/
deb: https:/
Click here to trigger a rebuild:
https:/
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Alan Griffiths (alan-griffiths) wrote : | # |
> Admittedly this is not a retrospective fix but it is a new more clean break
> that removes the offending duplication. I don't think a proper retrospective
> fix (duplicating the class in two different versions) is worth the effort.
I would a retrospective fix.
> Our consumers won't notice the difference because this is all C++. So if any
> downstreams are using it then they're doing so via libmirserver which still
> breaks ABIs most releases anyway. Users of libmirclient don't have /direct/
> linkage to the affected C++ symbols in libmircommon (as verified by the test
> 'Clients-
While they may currently be hypothetical, the plan is for downstreams to use lp:miral to avoid the libmirserver ABI breaks. Such downstreams will be dependent on libmircommon without being dependent on libmirserver. That means we should make the effort to maintain the libmircommon ABI.
Sadly, this horse is out of the barn: the LTS has Mir-0.21 with libmircommon5 (libmircommon6 was introduced in Mir-0.23).
If Yakkety ships with Mir-0.24/
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Daniel van Vugt (vanvugt) wrote : | # |
^^^
Jenkins failure is bug 1394369. Haven't seen that in a long time.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Daniel van Vugt (vanvugt) wrote : | # |
I was happy to say 'Won't Fix' for the 0.24 series. We could say 'Won't Fix' everywhere. Depends if a second and third user reports the same bug...
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Mir CI Bot (mir-ci-bot) wrote : | # |
PASSED: Continuous integration, rev:3679
https:/
Executed test runs:
SUCCESS: https:/
SUCCESS: https:/
SUCCESS: https:/
SUCCESS: https:/
SUCCESS: https:/
SUCCESS: https:/
deb: https:/
SUCCESS: https:/
deb: https:/
SUCCESS: https:/
deb: https:/
SUCCESS: https:/
deb: https:/
SUCCESS: https:/
deb: https:/
SUCCESS: https:/
deb: https:/
Click here to trigger a rebuild:
https:/
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Kevin DuBois (kdub) wrote : | # |
> While they may currently be hypothetical, the plan is for downstreams to use
> lp:miral to avoid the libmirserver ABI breaks. Such downstreams will be
> dependent on libmircommon without being dependent on libmirserver. That means
> we should make the effort to maintain the libmircommon ABI.
Hmm, my understanding is a bit different. I thought that mircommon was merely split out as 'common' to share code between mirserver and mirclient, so its only as stable as the mirserver stuff.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Alan Griffiths (alan-griffiths) wrote : | # |
> > While they may currently be hypothetical, the plan is for downstreams to use
> > lp:miral to avoid the libmirserver ABI breaks. Such downstreams will be
> > dependent on libmircommon without being dependent on libmirserver. That
> means
> > we should make the effort to maintain the libmircommon ABI.
>
> Hmm, my understanding is a bit different. I thought that mircommon was merely
> split out as 'common' to share code between mirserver and mirclient, so its
> only as stable as the mirserver stuff.
We *want* a stable "server" ABI but libmirserver is a long way from that. libmircommon is less of a problem, and we could make the effort there.
libmiral is an approach to wrapping libmirserver, but there are things available from libmircommon (like Rectangle) that there seems little point in re-inventing if we try to keep it ABI stable. That is the plan.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Daniel van Vugt (vanvugt) wrote : | # |
It's worth remembering changing the mircommon ABI is only a problem if it happens more frequently than mirserver.
We see a server ABI break coming in Mir 0.25 here:
https:/
So it's harmless to bump the mircommon ABI at the same or less frequency.
This change here in particular provides absolute resolution of the symbol problem of bug 1617865. It won't happen any more if binaries are looking for libmircommon.so.7 instead of the broken libmircommon.so.6.
So yes I agree we don't want to bump ABIs, but if we do bump mirserver in a release then we can bump mircommon for free. And we should because of bug 1617865.
I also choose to maintain a simple view of the world and ignore mirAL until its bits get merged into lp:mir. Then it becomes relevant to us here.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Alan Griffiths (alan-griffiths) wrote : | # |
> I also choose to maintain a simple view of the world and ignore mirAL until
> its bits get merged into lp:mir. Then it becomes relevant to us here.
Has there been a failure of communication?
As soon as MirAL is in archive it becomes relevant here. Merging bits back is a long term goal.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Daniel van Vugt (vanvugt) wrote : | # |
Yes, MirAL entering archive is news to me so there was a failure of communication (or failure of my listening). Although I don't like the idea of us publishing temporary projects I can see how publishing that one will speed us up.
However...
(1) Is there an opportunity right now for us to land this ABI cleanup/break before our downstreams get fixated on one indefinite MirAL ABI?
(2) Are you sure that consumers of MirAL are also bound to the libmircommon ABI? Or do we have an opportunity still to strengthen APIs to ensure that dependency doesn't leak into consumers of MirAL headers?
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Alan Griffiths (alan-griffiths) wrote : | # |
> Yes, MirAL entering archive is news to me so there was a failure of
> communication (or failure of my listening). Although I don't like the idea of
> us publishing temporary projects I can see how publishing that one will speed
> us up.
>
> However...
> (1) Is there an opportunity right now for us to land this ABI cleanup/break
> before our downstreams get fixated on one indefinite MirAL ABI?
It depends.
I don't think the qtmir integration work will complete in time for MirAL to land in yakkety.
And I have doubts that Mir-0.25 will land there.
But it could happen.
> (2) Are you sure that consumers of MirAL are also bound to the libmircommon
> ABI? Or do we have an opportunity still to strengthen APIs to ensure that
> dependency doesn't leak into consumers of MirAL headers?
It is possible to hide libmircommon too. But it is an API we really ought to be able to stabilize and I think that is a better use of effort.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Daniel van Vugt (vanvugt) wrote : | # |
MirAL will never be "stable" unless its headers are independent of mircommon headers and so won't be broken by mircommon ABI changes.
If MirAL is sensitive to that then I'd say it should be a high priority to work to eliminate that sensitivity or else we're already making the same mistakes as are in the mirserver headers.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Mir CI Bot (mir-ci-bot) wrote : | # |
FAILED: Continuous integration, rev:3684
https:/
Executed test runs:
FAILURE: https:/
FAILURE: https:/
FAILURE: https:/
FAILURE: https:/
FAILURE: https:/
FAILURE: https:/
FAILURE: https:/
FAILURE: https:/
FAILURE: https:/
FAILURE: https:/
FAILURE: https:/
Click here to trigger a rebuild:
https:/
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Mir CI Bot (mir-ci-bot) wrote : | # |
PASSED: Continuous integration, rev:3684
https:/
Executed test runs:
SUCCESS: https:/
SUCCESS: https:/
SUCCESS: https:/
SUCCESS: https:/
SUCCESS: https:/
SUCCESS: https:/
deb: https:/
SUCCESS: https:/
deb: https:/
SUCCESS: https:/
deb: https:/
SUCCESS: https:/
deb: https:/
SUCCESS: https:/
deb: https:/
Click here to trigger a rebuild:
https:/
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Kevin DuBois (kdub) wrote : | # |
Apart from the abi discussions above (which are important that we get on the same page; I'm probably lagging a bit behing the current intentions in some regards...), this now just looks like a cleanup of the ABI for the 0.25 series, so looks alright by me.
+ __android_
+ __android_
+ systemTime;
+ toMillisecondTi
seems strange that we still need these symbols, assuming these are something for the input stack (which I thought we were trynig to make into a platform)
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Daniel van Vugt (vanvugt) wrote : | # |
If those can be removed then this is the time to try...
The remaining concern is how a mircommon ABI break could break consumers of MirAL (if it uses mircommon classes/structs in public headers). In short I argue if that's a problem at all then it's a problem MirAL should own rather than blocking mircommon ABI bumps.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Mir CI Bot (mir-ci-bot) wrote : | # |
PASSED: Continuous integration, rev:3690
https:/
Executed test runs:
SUCCESS: https:/
SUCCESS: https:/
SUCCESS: https:/
SUCCESS: https:/
SUCCESS: https:/
SUCCESS: https:/
deb: https:/
SUCCESS: https:/
deb: https:/
SUCCESS: https:/
deb: https:/
SUCCESS: https:/
deb: https:/
SUCCESS: https:/
deb: https:/
Click here to trigger a rebuild:
https:/
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Mir CI Bot (mir-ci-bot) wrote : | # |
FAILED: Continuous integration, rev:3692
https:/
Executed test runs:
FAILURE: https:/
SUCCESS: https:/
SUCCESS: https:/
SUCCESS: https:/
SUCCESS: https:/
SUCCESS: https:/
deb: https:/
SUCCESS: https:/
deb: https:/
SUCCESS: https:/
deb: https:/
FAILURE: https:/
FAILURE: https:/
Click here to trigger a rebuild:
https:/
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Daniel van Vugt (vanvugt) wrote : | # |
^^^
Failures were a network/
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Mir CI Bot (mir-ci-bot) wrote : | # |
PASSED: Continuous integration, rev:3693
https:/
Executed test runs:
SUCCESS: https:/
SUCCESS: https:/
SUCCESS: https:/
SUCCESS: https:/
SUCCESS: https:/
SUCCESS: https:/
deb: https:/
SUCCESS: https:/
deb: https:/
SUCCESS: https:/
deb: https:/
SUCCESS: https:/
deb: https:/
SUCCESS: https:/
deb: https:/
Click here to trigger a rebuild:
https:/
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Mir CI Bot (mir-ci-bot) wrote : | # |
PASSED: Continuous integration, rev:3694
https:/
Executed test runs:
SUCCESS: https:/
SUCCESS: https:/
SUCCESS: https:/
SUCCESS: https:/
SUCCESS: https:/
SUCCESS: https:/
deb: https:/
SUCCESS: https:/
deb: https:/
SUCCESS: https:/
deb: https:/
SUCCESS: https:/
deb: https:/
SUCCESS: https:/
deb: https:/
Click here to trigger a rebuild:
https:/
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Alan Griffiths (alan-griffiths) wrote : | # |
Providing two versions of the symbols seems simpler. C.f. lp:~alan-griffiths/mir/fix-1617865
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Daniel van Vugt (vanvugt) wrote : | # |
I agree, if you can make that branch pass CI....
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Alan Griffiths (alan-griffiths) wrote : | # |
> I agree, if you can make that branch pass CI....
Unfortunately, not without losing the point.
Given that all code affected by the bug is internal and, by now, rebuilt. I'm not sure we should solve it at all if it requires a solution this drastic.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Daniel van Vugt (vanvugt) wrote : | # |
Needs information (from me). This is a simple problem in theory and I don't think we should yet give up trying to wrangle our tooling into submission. It's theoretically possible to fix properly per Alan's above attempt.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Daniel van Vugt (vanvugt) wrote : | # |
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Alan Griffiths (alan-griffiths) wrote : | # |
> Try this instead:
> https:/
> breaks/
This is worse than that
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Alan Griffiths (alan-griffiths) wrote : | # |
> > Try this instead:
> > https:/
> > breaks/
>
> This is worse than that
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Daniel van Vugt (vanvugt) wrote : | # |
I just realised we can do both. Land the other one now and continue to debate this one (which came up again in the meeting this morning as other people want to break mircommon ABI too).
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Daniel van Vugt (vanvugt) : | # |
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Mir CI Bot (mir-ci-bot) wrote : | # |
PASSED: Continuous integration, rev:3700
https:/
Executed test runs:
SUCCESS: https:/
SUCCESS: https:/
SUCCESS: https:/
SUCCESS: https:/
SUCCESS: https:/
SUCCESS: https:/
deb: https:/
SUCCESS: https:/
deb: https:/
SUCCESS: https:/
deb: https:/
SUCCESS: https:/
deb: https:/
SUCCESS: https:/
deb: https:/
Click here to trigger a rebuild:
https:/
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Mir CI Bot (mir-ci-bot) wrote : | # |
PASSED: Continuous integration, rev:3701
https:/
Executed test runs:
SUCCESS: https:/
SUCCESS: https:/
SUCCESS: https:/
SUCCESS: https:/
SUCCESS: https:/
SUCCESS: https:/
deb: https:/
SUCCESS: https:/
deb: https:/
SUCCESS: https:/
deb: https:/
SUCCESS: https:/
deb: https:/
SUCCESS: https:/
deb: https:/
Click here to trigger a rebuild:
https:/
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Daniel van Vugt (vanvugt) wrote : | # |
I don't feel we need this branch any more, but bschaefer and anpok (and raof?) have expressed the opinion that they need the break for other reasons anyway.
So you guys can argue with alan_g here.
I abstain but will maintain the branch just in case it gets approved.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Daniel van Vugt (vanvugt) wrote : | # |
Unfortunately we broke the mircommon ABI last night (r3756). So this branch now needs to land.
FAILED: Continuous integration, rev:3677 /mir-jenkins. ubuntu. com/job/ mir-ci/ 1558/ /mir-jenkins. ubuntu. com/job/ build-mir/ 1947/console /mir-jenkins. ubuntu. com/job/ build-0- fetch/2007 /mir-jenkins. ubuntu. com/job/ build-1- sourcepkg/ release= vivid+overlay/ 1998 /mir-jenkins. ubuntu. com/job/ build-1- sourcepkg/ release= xenial+ overlay/ 1998 /mir-jenkins. ubuntu. com/job/ build-1- sourcepkg/ release= yakkety/ 1998 /mir-jenkins. ubuntu. com/job/ build-2- binpkg- mir/arch= amd64,compiler= clang,platform= mesa,release= yakkety/ 1973 /mir-jenkins. ubuntu. com/job/ build-2- binpkg- mir/arch= amd64,compiler= clang,platform= mesa,release= yakkety/ 1973/artifact/ output/ *zip*/output. zip /mir-jenkins. ubuntu. com/job/ build-2- binpkg- mir/arch= amd64,compiler= gcc,platform= mesa,release= xenial+ overlay/ 1973 /mir-jenkins. ubuntu. com/job/ build-2- binpkg- mir/arch= amd64,compiler= gcc,platform= mesa,release= xenial+ overlay/ 1973/artifact/ output/ *zip*/output. zip /mir-jenkins. ubuntu. com/job/ build-2- binpkg- mir/arch= amd64,compiler= gcc,platform= mesa,release= yakkety/ 1973 /mir-jenkins. ubuntu. com/job/ build-2- binpkg- mir/arch= amd64,compiler= gcc,platform= mesa,release= yakkety/ 1973/artifact/ output/ *zip*/output. zip /mir-jenkins. ubuntu. com/job/ build-2- binpkg- mir/arch= cross-armhf, compiler= gcc,platform= android, release= vivid+overlay/ 1973/console /mir-jenkins. ubuntu. com/job/ build-2- binpkg- mir/arch= cross-armhf, compiler= gcc,platform= android, release= vivid+overlay/ 1973/artifact/ output/ *zip*/output. zip /mir-jenkins. ubuntu. com/job/ build-2- binpkg- mir/arch= i386,compiler= gcc,platform= android, release= vivid+overlay/ 1973 /mir-jenkins. ubuntu. com/job/ build-2- binpkg- mir/arch= i386,compiler= gcc,platform= android, release= vivid+overlay/ 1973/artifact/ output/ *zip*/output. zip /mir-jenkins. ubuntu. com/job/ build-2- binpkg- mir/arch= i386,compiler= gcc,platform= mesa,release= xenial+ overlay/ 1973 /mir-jenkins. ubuntu. com/job/ build-2- binpkg- mir/arch= i386,compiler= gcc,platform= mesa,release= xenial+ overlay/ 1973/artifact/ output/ *zip*/output. zip
https:/
Executed test runs:
FAILURE: https:/
SUCCESS: https:/
SUCCESS: https:/
SUCCESS: https:/
SUCCESS: https:/
SUCCESS: https:/
deb: https:/
SUCCESS: https:/
deb: https:/
SUCCESS: https:/
deb: https:/
FAILURE: https:/
deb: https:/
SUCCESS: https:/
deb: https:/
SUCCESS: https:/
deb: https:/
Click here to trigger a rebuild: /mir-jenkins. ubuntu. com/job/ mir-ci/ 1558/rebuild
https:/