Re: Redundant distro branches
On Mon, Aug 24, 2015 at 4:17 AM, Daniel van Vugt wrote: > I'm kind of saying we should stop using: >lp:mir/ubuntu > and instead use: >lp:ubuntu/mir > > However that's not quite correct. You should target proposed first, so > actually we would target: >lp:ubuntu/wily-proposed/mir The problem is the dataflow. The ci-train assumes an "upstream" repo (here, it's lp:mir/ubuntu) into which it merges the target branches. It builds source debs, which then get uploaded to the -proposed pocket of the archive, which then migrates into the main (or -release) pocket of the archive and gets imported into the lp:ubuntu/mir repo. If you point the ci-train to merge target bracnhes directly into the Ubuntu archive, there's going to be trouble. -- Mir-devel mailing list Mir-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/mir-devel
Re: Detailed symbols.map
On Wed, Aug 26, 2015 at 5:40 AM, Daniel van Vugt
wrote:
> I guess the way we want to and should maintain ABIs is that the contents of
> a stanza MIR_SERVER_N { } never changes (although you can always add a new
> stanza MIR_SERVER_N+1 with changes). So store a historical copy of existing
> "ABIs" such as MIR_SERVER_N and compare to make sure its contents never
> change (if still present at all).
That's how libstdc++ does it, and they've done a pretty good job of
maintaining ABI copatibility for about 15 years (GCC-5
notwithstanding: sometimes you just have to break ABI). This has to
be done in conjunction with an additional check tool, though, which is
why a symbols version file is used in the sources *and*
dpkg-gensymbols is used in the packaging on Debian-based systems.
Libstdc++ actually uses its own tool during the build to look for
missing symbol changes at build time.
This is a false security, though, because most of the insidious ABI
changes do not show up as symbol name changes.
--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/mir-devel
Re: Running Mir apps on latest Snappy
On 15-10-12 09:46 PM, Christopher James Halse Rogers wrote: > > > On Tue, Oct 13, 2015 at 12:36 PM, Darren Landoll > wrote: >> >> … >> $ sudo qtdeclarative5-examples-amd64.clocks >> Bad system call >> Loading module: 'libubuntu_application_api_desktop_mirclient.so.2.9.0' >> [1444693723.318984] Loader: Loading modules from: >> /apps/mir/snap1.1/debs/usr/lib/x86_64-linux-gnu/mir/client-platform >> [1444693723.320623] Loader: Loading module: >> /apps/mir/snap1.1/debs/usr/lib/x86_64-linux-gnu/mir/client-platform/mesa.so.2 >> [1444693723.326652] Loader: Failed to load module: >> /apps/mir/snap1.1/debs/usr/lib/x86_64-linux-gnu/mir/client-platform/mesa.so.2 >> (error was:libmircommon.so.4: cannot >> open shared object file: No such file or directory) > ^^^ >> UbuntuClientIntegration: connection to Mir server failed. Check that a Mir >> server is >> running, and the correct socket is being used and is accessible. The shell >> may have >> rejected the incoming connection, so check its log file >> Aborted > > Looks like you're missing one of the dependencies of the client platform; > this will prevent any client from working. > > Once you work out why libmircommon.so.4 isn't available you should be able to > get things working again. Or, at least, > hit the next problem :) Is this the classic problem caused by removing the runtime dependencies from the Mir packaging and requiring them to be pre-seeded in the system images? Darren, if you add the mir-graphics-drivers-desktop package (eg. to your oem snap) does it work? -- Stephen M. Webb -- Mir-devel mailing list Mir-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/mir-devel
Re: Ideas for improving the release process
On 16-02-16 08:08 PM, Daniel van Vugt wrote: > If a critical bug isn't blocking a release I guess it should be demoted to > High. > > We need some simple threshold that doesn't require the reader to understand > the details of each bug. Just that "if > importance >= critical then don't release". And there's no other level we can > use for that other than critical (or > 'high' later as the project matures). I have to agree with this. If the bug is not critical enough to block a release, it shouldn't be classed as critical. -- Stephen M. Webb -- Mir-devel mailing list Mir-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/mir-devel
Re: Mir latency chart
On 2016-12-14 04:52 AM, Daniel van Vugt wrote: > > I spent a while today taking latency measurements of various Mir releases and > branches to check we're on the right > track. You might find the resulting chart interesting... > > https://docs.google.com/spreadsheets/d/1RbTVDbx04ohkF4-md3wAlgmxbSI1DttstnT6xdcXhZQ/pubchart?oid=1566479835&format=interactive Nice. -- Stephen M. Webb -- Mir-devel mailing list Mir-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/mir-devel
