This bug and its sister bug are driving me crazy:
https://bugs.launchpad.net/mir/+bug/1388490
https://bugs.launchpad.net/mir/+bug/1377872
I can see in both cases that the frame rate ceiling is arbitrary and
temporary. It has nothing at all to do with the power of the host. And
the workaround th
Some good news: Anpok's fix for the Intel i915 driver finally landed on
the weekend in vivid:
https://launchpad.net/ubuntu/+source/mesa
What this means is that Mir now works fully on netbooks and other older
Intel GPUs that use the i915 driver.
Beware of this bug though: https://bugs.launchpa
Definitely controversial; factually false or easily arguable.
Sounds like a response to one of my merge proposals. So please put
arguments in the code reviews...
On 10/11/14 10:48, Christopher James Halse Rogers wrote:
Hey all.
We're getting into the meaty bit of client API support I though
BTW, I do actually agree with half of your points. Just feel that
over-generalising in a discussion like this one is counter-productive.
Because it always is (<- over-generalisation).
On 10/11/14 11:31, Daniel van Vugt wrote:
Definitely controversial; factually false or easily argua
van Vugt
wrote:
Definitely controversial; factually false or easily arguable.
Sounds like a response to one of my merge proposals. So please put
arguments in the code reviews...
It indirectly is, but also in response to some discussion on IRC of one
of your merge proposals.
I thought it would
uot; are explicitly not a window type right now (as copied from
the WM design docs). So it's possibly assuming too much to mention the
the word "menu" in the client API. Although we possibly could - rename
popover?
On 10/11/14 17:58, Alan Griffiths wrote:
On 10/11/14 03:31, Daniel
gnore the
(x,y) for menus (see #1 above).
On 11/11/14 09:33, Daniel van Vugt wrote:
We are actually in violent agreement on "policy" and conflating two
different issues. So please, let's separate them :)
It is indeed up to the server/shell to dictate policy, particularly
e agreeing, and more solid reasoning.
On 11/11/14 09:48, Daniel van Vugt wrote:
On the second issue of client API design, it's useful to point out why
the menu example is not a good argument:
1. Depending on your shell, and its current mode, a "menu" might not
have a relative posit
I've already explained why that is untrue. Twice.
On 11/11/14 10:03, Christopher James Halse Rogers wrote:
On Tue, Nov 11, 2014 at 12:33 PM, Daniel van Vugt
wrote:
We are actually in violent agreement on "policy" and conflating two
different issues. So please, let's sep
t
return errors immediately. Rather you can optionally wait for their
completion and then query what actually happened.
On 11/11/14 10:12, Christopher James Halse Rogers wrote:
On Tue, Nov 11, 2014 at 12:48 PM, Daniel van Vugt
wrote:
On the second issue of client API design, it's
see today.
People often get confused about why I mention database normalization in
API design, but the principles and objectives are the same:
http://en.wikipedia.org/wiki/Database_normalization
On 11/11/14 10:22, Daniel van Vugt wrote:
There is no invalid state possible, providing all
ameters to each function.
On 11/11/14 10:59, Christopher James Halse Rogers wrote:
On Tue, Nov 11, 2014 at 1:40 PM, Daniel van Vugt
wrote:
So given invalid states are easily rejected by the shell and what mode
it's in, and given it's unrealistic (predicting the future) and
undes
void
writing 7 different parenting functions.
On 11/11/14 11:12, Daniel van Vugt wrote:
You've forgotten the first point we all agreed on. That is it's up to
the shell to enforce semantics. The rules will change between shells and
between modes of a single shell. So you can
think any task running in AsioMainLoop that blocks at all (>1ms) is a
bug... So any experts on AsioMainLoop know where we're submitting
blocking tasks to the poor overworked AsioMainLoop?
- Daniel
On 03/11/14 08:36, Daniel van Vugt wrote:
This bug and its sister bug are driving me craz
ec
I think any task running in AsioMainLoop that blocks at all (>1ms) is a
bug... So any experts on AsioMainLoop know where we're submitting
blocking tasks to the poor overworked AsioMainLoop?
- Daniel
On 03/11/14 08:36, Daniel van Vugt wrote:
This bug and its sister bug are driving me
dreas Pokorny
Apologies:
Daniel van Vugt
1. We started with a recap over some design goals:
1.1 The server should be in control of "policy"
1.2 It should be easy to validate use of the client API
Thomas noted that he saw no need to support re-parenting - there was no
disagreement.
W
way or another, because blocking the
compositor thread is a very visible problem.
On 03/11/14 08:36, Daniel van Vugt wrote:
This bug and its sister bug are driving me crazy:
https://bugs.launchpad.net/mir/+bug/1388490
https://bugs.launchpad.net/mir/+bug/1377872
I can see in both cases that the
e
used to have with it being fixed in size. Some intelligent scaling is
required.
Although longer term, a thread pool might not be required at all if we
can come up with a reliably fast asynchronous select() implementation to
replace the asio sockets/io_service.
On 13/11/14 11:58, Daniel
access in SessionMediator::exchange_buffer(), but not much - its all
frontend.
On 13/11/14 04:19, Daniel van Vugt wrote:
I think the cleanest solution would be a return to using the "IPC
thread pool" (like in the old days). Presently we use it for receiving
requests, but not for sending respon
sktop performance now for sure. As for the
netbook, I think that requires both fixes at least. Maybe more...
On 14/11/14 09:51, Daniel van Vugt wrote:
Yes agreed; that's actually what I was saying in the previous email and
I prototyped it yesterday.
No visible benefit yet so I'm trying
Hey all,
In the interests of increasing face-to-face time with Europe, is there
an existing scheduled meeting I can be part of that's not too late (say
before 10am UTC)? Do we need a new slot?
I'm sending this to the public list because it would be awesome if other
people wanted to join in M
I'd be happy with weekly (which I do already with the USA), but spanning
all timezones with one meeting isn't feasible...
On 18/11/14 17:27, Alan Griffiths wrote:
On 18/11/14 05:24, Daniel van Vugt wrote:
Hey all,
In the interests of increasing face-to-face time with Europe, i
Done. Invitations for mir-team people have been sent.
If there are any other _developers_ who want to join in on a Tuesday
then please do:
https://www.google.com/calendar/event?action=TEMPLATE&tmeid=N3N2M2txMHFlZnVtc201dDAxOGk2MGRuMzBfMjAxNDExMjVUMDkzMDAwWiBkYW5pZWwudmFuLnZ1Z3RAY2Fub25pY2FsLmN
I'm not convinced *DisplayChanger are good abstractions. If you're
touching them then maybe we can think of a cleaner way to approach the
task of changing displays :)
http://objology.blogspot.com.au/2011/09/one-of-best-bits-of-programming-advice.html
http://www.benhallbenhall.com/2013/01/naming
Indeed, there's a reason why we still have fatal signals in modern
Unix/Linux. Some mistakes you can't back out of gracefully within the
scope of your already buggy program.
What we do have is a kernel that will clean up by killing just the
offending process in its entirety, and leaving a core
I notice the online docs haven't refreshed since 10 October:
http://unity.ubuntu.com/mir/
which seems to coincide with release 0.8.0 for utopic/rtm.
Anyone know if we are able to get the web site refreshed with the newer
docs from vivid, or even newer from the source?
- Daniel
--
Mir-deve
Regarding Display Posting [2] ...
MultiThreadedCompositor can be easily tricked into creating only one
thread, one DisplayBufferCompositor and sharing it between an arbitrary
number of outputs using a single render loop. Alexandros made sure of
this, but I feel we have not utilised its full po
Even displays of the same refresh rate are a problem (see in X/Compiz
where all but one of your displays will tear).
In Mir (the DRM platform) we've solved this with parallel rendering
while waiting for the previous page flips. Because if you have multiple
monitors at the same refresh rate, th
ne sticks for
that display. IMO Mesa has thought about multimonitor better in its api,
and 'don't break mesa's goodness" is a goal in accommodating HWC.
On Wed, Dec 10, 2014 at 9:50 PM, Daniel van Vugt
mailto:daniel.van.v...@canonical.com>>
wrote:
Even displays of the same
Oh, a SingleThreadedCompositor might be infeasible due to:
https://bugs.launchpad.net/mir/+bug/1395421
And I have a couple of performance fixes that are blocked by that bug
too. Any takers?
On 12/12/14 09:16, Daniel van Vugt wrote:
So if you need separate display buffers but a single
Does anyone have a plan for how to represent Renderables (or
SceneElement) that don't have a buffer()? I'm thinking about dynamically
generated elements that don't have buffer streams and are not fixed
resolution. Such elements are either pre-generated (once) or even
produced entirely on the GP
On 15/12/14 17:35, Daniel van Vugt wrote:
Does anyone have a plan for how to represent Renderables (or
SceneElement) that don't have a buffer()? I'm thinking about dynamically
generated elements that don't have buffer streams and are not fixed
resolution. Such elements are eithe
on, Dec 15, 2014 at 3:45 AM, Daniel van Vugt
mailto:daniel.van.v...@canonical.com>>
wrote:
On 15/12/14 17:35, Daniel van Vugt wrote:
Does anyone have a plan for how to represent Renderables (or
SceneElement) that don't have a buffer()? I'm thinking
Thanks for Alberto and Francis for getting Jenkins back in full...
If anyone knows how to do a quick test run of a demo server/shell or two
as part of CI, please get it in there... On several occasions recently
we've had merge proposals pass all tests but cause demo servers to crash
or hang. S
All,
Be aware that since binary wrapping was introduced in r2179, valgrind
will silently run but not instrument your binaries.
To make valgrind actually work now you need to tell it to follow exec:
valgrind --trace-children=yes ...
- Daniel
--
Mir-devel mailing list
Mir-devel@lists.ubuntu
Hi all,
I've been dabbling in reducing Mir's lag for about a year now. It's
something that only gets limited attention in my spare time so might
benefit from other people getting involved...
End-to-end, Mir's (Unity8's) lag is about 6 frames. This is the sum of:
Client: 2 frames lag (triple
Mir 0.10.0 was released last week. Users of vivid (touch and desktop)
already have it :)
https://launchpad.net/mir/+milestone/0.10.0
--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/mir-devel
It appears Mir is nowhere to be found in upstream Mesa still:
http://cgit.freedesktop.org/mesa/mesa/tree/
Is there something holding this up?
I'm pretty sure the Mir patch for Mesa has been mostly unchanged for a
few years now...
--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify set
Replied in the bug :)
On 20/01/15 22:19, Kevin Gunn wrote:
hi all -
Just catching up on some bug house cleaning & found an open question on
this bug
https://bugs.launchpad.net/mir/+bug/1401916
Is there an architectural preference for where to save off display
configs ? and reasons for the pr
Hi all,
Any chance people could stop putting their personal branches in
lp:~mir-team/ ? That makes it hard to find other branches when there are
so many.
There are good reasons for using lp:~mir-team/ but I think they all
involve cases when you require or expect other people to fix your code
Looking at an example of changing from the old input event API to the
new one in Mir 0.10:
http://bazaar.launchpad.net/~mir-team/mir/development-branch/revision/2246?compare_revid=2128#examples/fingerpaint.c
You can see it requires a lot more code now.
I'm wondering if anyone has any thoughts
r. So it
could be simpler again:
MirTouch* touch = mir_event_get_touch(event);
x = mir_touch_get_axis(touch, 0, mir_touch_axis_x);
- Daniel
On 22/01/15 16:23, Daniel van Vugt wrote:
Looking at an example of changing from the old input event API to the
new one in Mir 0.10:
http://bazaa
NamespaceClassFoo namespace_class_get_foo(NamespaceClass instance,
size_t foo_index)
etc
You have a fair amount of repeating yourself but each type name is easy
to guess...I guess to me this is a pretty significant advantage and im
inclined to keep it. Interested in more feedback I guess.
On T
We seem to have some client functions residing in libmircommon now...
That sounds reasonable at first but doesn't this prevent us from being
able to bump the common ABI without breaking clients?
- Daniel
--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
p the common ABI.
On 28/01/15 08:57, Christopher James Halse Rogers wrote:
On Tue, Jan 27, 2015 at 2:50 PM, Daniel van Vugt
wrote:
We seem to have some client functions residing in libmircommon now...
That sounds reasonable at first but doesn't this prevent us from being
able to bump the
That's the point. Yes, we do now have a handful of client functions
exported from libmircommon directly to (future) clients. So that's why I
raised it...
On 28/01/15 09:55, Christopher James Halse Rogers wrote:
On Wed, Jan 28, 2015 at 12:49 PM, Daniel van Vugt
wrote:
I forgot (
All,
Just a heads up... we're still seeing more regressions occurring than we
really should.
Although we can't expect authors to predict how other authors might
modify their code into the future [1], I think the common factors we can
improve on are:
* More manual testing of merge proposal
Hi all (and this is directed mostly at the wider world outside of
mir-team), a quick poll:
Which of these names makes more sense to you?
MirTouchInput = read_all_fingers();
MirTouchEvent = read_all_fingers();
MirTouchInputEvent = read_all_fingers();
--
Mir-devel mailing list
Mir-devel@lists.ub
Mir 0.11.0 just released, and it's in vivid already...
https://launchpad.net/ubuntu/+source/mir
https://launchpad.net/mir/+milestone/0.11.0
--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/mir-devel
I think this is a bad idea.
Supporting trusty with the latest Mir is presently easy, as demonstrated:
https://code.launchpad.net/~vanvugt/mir/revive-trusty/+merge/249789
Using newer language specs I think is contrary to engineering maturity.
Because it means we knowingly and needlessly reduce t
Also worth noting, it takes less effort to support trusty:
https://code.launchpad.net/~vanvugt/mir/revive-trusty/+merge/249789
than it does to start using C++14 features:
https://code.launchpad.net/~afrantzis/mir/introduce-c++14/+merge/249988
On 18/02/15 09:39, Daniel van Vugt wrote:
I
As a compromise why don't we say Mir supports the latest LTS only?
So 14 months from now, we'll be free to jump to C++14 (and it will be
more mature in implementation by then). But until then, we would stick
to C++11 for trusty.
On 18/02/15 09:39, Daniel van Vugt wrote:
I think
We do seem to be guilty of having the same conversations in multiple
different places a lot :)
Just FYI, the nail is in the coffin. C++14 support landed last night. So
trusty is dropped I guess.
On 18/02/15 12:43, Daniel van Vugt wrote:
As a compromise why don't we say Mir support
On Wed, Feb 18, 2015 at 8:12 PM, Daniel van Vugt
mailto:daniel.van.v...@canonical.com>>
wrote:
We do seem to be guilty of having the same conversations in multiple
different places a lot :)
Just FYI, the nail is in the coffin. C++14 support landed last
night. So trusty is d
Gauravdeep,
Also keep in mind that online copy of our docs is a bit out of date.
What it doesn't say (and it should) is that you need to be running vivid
(Ubuntu 15.04 pre-release) to build the latest Mir source:
http://cdimage.ubuntu.com/daily-live/current/
Then follow the docs and buildin
Hi all,
The following branches are failing to build right now. Could the owners
of the respective changes please look into the issues?
lp:qtmir/devel-mir-next
kdub: Display class changes (still calling flip())
racarr: keymap_changed()
lp:unity-system-compositor/devel-mir-next
racarr: sp
"failing to build against lp:mir" I mean.
On 06/03/15 17:55, Daniel van Vugt wrote:
Hi all,
The following branches are failing to build right now. Could the owners
of the respective changes please look into the issues?
lp:qtmir/devel-mir-next
kdub: Display class changes (sti
scene::Surface::visible() does the first-frame check for you. Although
you probably know that already.
Be aware however; surfaces go into the Scene (SurfaceStack) immediately.
Long before they are visible().
On 09/03/15 18:10, Gerry Boland wrote:
On 09/03/15 09:58, Alan Griffiths wrote:
Ba
Hi all,
The evidence of Intel driver bugs causing frame skipping is slowly
mounting. If you experience this, please join in:
Modern systems: https://bugs.freedesktop.org/show_bug.cgi?id=86366
Atom or similar: https://bugs.launchpad.net/mir/+bug/1388490
- Daniel
--
Mir-devel mailing list
Mi
release time, as
well as anyone trying to tinker with the whole stack against lp:mir.
On Fri, Mar 6, 2015 at 5:04 AM, Alan Griffiths
mailto:alan.griffi...@canonical.com>> wrote:
On 06/03/15 09:57, Daniel van Vugt wrote:
> "failing to build against lp:mir" I mean.
P
This is interesting. Since r2408 we do indeed have legacy clients still
working with newer library builds. So no obvious ABI break. But they
work because they can load libmircommon.so.3&4 simultaneously.
So everything apparently still works, but I'm a little afraid there
might be unseen risks
0/03/15 15:32, Daniel van Vugt wrote:
This is interesting. Since r2408 we do indeed have legacy clients still
working with newer library builds. So no obvious ABI break. But they
work because they can load libmircommon.so.3&4 simultaneously.
So everything apparently still works, but I'm a
For the benefit of all future shell developers;
I'd like to inherit from "SomethingShell" and get
something that works in a few lines without writing additional code.
Then I would like to be able to override functions to customise the
shell behaviour.
I feel that's the driving requirement bec
Sorry RDP/VNC support for Mir does not exist yet, either way you
interpret it.
Which way are you aiming for? Do you want to connect to a Mir server by
those protocols, or do you want to render a client of RDP/VNC in Mir?
- Daniel
On 19/03/15 15:31, Martin Reisenhofer wrote:
How Remote Desk
MIR.
(headless rendering with gpu support)
Exist something in this Direction? Provide the Mir Specification something in
this direction?
Best Regards
Martin
Am 23.03.2015 um 03:46 schrieb Daniel van Vugt :
Forwarded Message
Subject: Re: MiR and Remote Desktop
Date: Mon,
gs seem to work. We should fix this ASAP,
preferably with a test case that screams when two versions are loaded
simultaneously. Bumping the priority of the bug so it gets proper
attention.
-C
On Fri, Mar 20, 2015 at 2:40 AM, Daniel van Vugt
mailto:daniel.van.v...@canonical.com>>
wrote:
Changing focus is a WM concept. But strictly speaking "focus" is an
input concept [1]. It exists lower level in the display server to ensure
key events land on the correct surface. You might also have "active"
window for visual focus (greater highlighting, shadow), which is usually
and hopefull
Guaranteed to work... unless we change a structure definition and it
gets say created by libmircommon.so.4 and then used by a function in
libmircommon.so.3.
But that hasn't happened yet, and probably won't.
On 26/03/15 15:19, Christopher James Halse Rogers wrote:
On Mon, Mar 23, 2015 at 3:33
Ronald,
Please run command "ubuntu-bug" on the affected machine and follow the
prompts.
If that fails, you can log a bug here:
https://bugs.launchpad.net/ubuntu/+filebug
- Daniel
On 31/03/15 10:17, ronald plopper wrote:
New Broad well graphic on Dell laptop horizontal flashing lines on
de
Last I checked mir_proving_server was more functional and less buggy
than our other example servers. That and our colleagues tend to use it
as their primary development platform when testing toolkit/app ports. So
mir_proving_server is important and should be reworked to use any newer
APIs you w
tures that are missing?
On Tue, Mar 31, 2015 at 8:40 PM, Daniel van Vugt
mailto:daniel.van.v...@canonical.com>>
wrote:
Last I checked mir_proving_server was more functional and less buggy
than our other example servers. That and our colleagues tend to use
it as their primary dev
Hey all,
The Mir team has a few separate efforts under way that will reduce
latency/lag in the future. This is great and you'll see them announced
when eventually released but in the mean time you should remember a
well-written app/toolkit doesn't need all of the coming enhancements. So
here
Sounds like it's this issue (introduced in 0.10, fixed in 0.13):
https://bugs.launchpad.net/mir/+bug/1415321
It has a regression test now so once everything is on 0.13 it won't
happen again.
On 27/05/15 16:49, Alan Griffiths wrote:
Hi Robert,
Is "release breakage" the same problem with la
I've experienced this for a long time when running mir_proving_server
nested inside mir_demo_server_minimal. The screen doesn't go grey
(nested server is drawn) until a client is started in the nested server.
I feel it's a reasonable side-effect of us not drawing any "shell" in
demo servers. B
Sorry for the confusion. Yes it's just a bug that needs fixing...
If one frame has been posted then you need to take it because you can
never predict how long before a second one arrives, if at all.
On 29/05/15 11:12, Christopher James Halse Rogers wrote:
On Fri, May 29, 2015 at 2:35 AM, A
In case you hadn't noticed yet, Mir 0.13.1 is now released in wily
(Ubuntu 15.10).
This is the largest Mir release in some time and is the culmination of:
https://launchpad.net/mir/+milestone/0.13.0
https://launchpad.net/mir/+milestone/0.13.1
Have fun...
--
Mir-devel mailing list
Mir-deve
If you find mir-demos are not working, just remember to:
apt-get install mir-platform-graphics-mesa2
On 02/06/15 09:53, Daniel van Vugt wrote:
In case you hadn't noticed yet, Mir 0.13.1 is now released in wily
(Ubuntu 15.10).
This is the largest Mir release in some time and i
+1
Go nuts.
In the past the only point of contention was that people (myself
included) made mistakes in measurement. So we need to be aware that
non-trivial tests can have just as many bugs as the system being tested,
and keep an eye out for them. It would be nice to build some automation
tha
+1 on having a discussion. I wondered the same when I touched those APIs
a few months ago.
I don't think the intermediate InputEvent is useful enough to keep.
Conceivably any app/toolkit developer could want to correlate other
types of events with input just as much as correlating input with i
I'm curious (but not yet concerned) about how the new plan will deal
with the transitions we have between 2-3-4 buffers which is neatly
self-contained in the single BufferQueue class right now. Although as
some responsibilities clearly live on one side and not the other, maybe
things could beco
se you don't want a compositor that tries to
keep up with a 1000 FPS client by scheduling all of those frames on a
60Hz display. It has to drop some.
On 26/06/15 11:39, Christopher James Halse Rogers wrote:
On Fri, Jun 26, 2015 at 12:39 PM, Daniel van Vugt
wrote:
I'm curious (but n
Hmm, maybe not. If we assume the server is only communicating with the
client at 60Hz then the client could just do all the dropping itself and
send one frame (the newest completed one) every 16.6ms when the server asks.
On 26/06/15 12:01, Daniel van Vugt wrote:
bypass/overlays: If you look
se Rogers wrote:
On Fri, Jun 26, 2015 at 2:04 PM, Daniel van Vugt
wrote:
Hmm, maybe not. If we assume the server is only communicating with the
client at 60Hz then the client could just do all the dropping itself and
send one frame (the newest completed one) every 16.6ms when the server
asks.
I
TL;DR email is messy
See this instead:
https://docs.google.com/spreadsheets/d/1qf3IssN_sujygMPK2sTX2AUhGiDUBF3TMYYcSRSaSy0/pubhtml
On 26/06/15 12:24, Daniel van Vugt wrote:
That's why it's a hard problem to replace BufferQueue -- you have to
figure out whether 2, 3 or 4 buffe
Rather than querying types and aborting you can simplify things for
clients by just returning NULL instead:
if (MirTouchEvent* touch = mir_event_as_touch_event(event))
{
...
}
Segfaulting in dereferencing NULL is just as reliable as aborting, but
this way requires less effort to use the cl
I agree with Alberto et al here.
Anything other than range and syntax checking in libmirclient is too
much. Semantic checks must be done on the server because the definition
of what is semantically correct varies between shells. An app should be
written once, try to set everything it wants, se
+1
On 21/07/15 18:00, Alexandros Frantzis wrote:
Hi all,
in the Mir project we are following the standard practice of forking off
a new branch from trunk for each (minor) release. The benefits of this
approach are well known, but to summarize, the main points are:
* Decouples trunk from the
ABI compliance checker just moved to main
(https://bugs.launchpad.net/ubuntu/+source/abi-compliance-checker/+bug/1464447)
Does this mean we can turn it on now?
--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/mir-d
Indeed multi-series development is an overlapping activity.
If you consider the Mir 0.14.0 release we're trying to get out the door
right now, most of what's gone into that is dated 1 May to 23 June (tags
br0.13..br0.14). That does not mean the team has been sitting on their
hands since 23 Jun
Mir 0.14.0 is now released and is in wily too.
https://launchpad.net/ubuntu/+source/mir
https://launchpad.net/mir/+milestone/0.14.0
P.S. Everyone on ~mir-team owes anpok a drink for this effort.
--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lis
structions are below...
- Daniel
On 12/02/13 10:01, Tim Penhey wrote:
On 12/02/13 14:24, Daniel van Vugt wrote:
Yes this happened last year (on 9th Feb too). And we immediately locked
down the branch to prevent direct pushes from being able to overwrite
previous revisions.
However, that was lp:comp
All,
In the past we've made decisions to adopt new language variants and
dependencies for Mir that meant only users on the latest Ubuntu release
could build the latest Mir code. And if the latest Ubuntu release means
the pre-release then we're probably excluding most Ubuntu users from
being a
Sounds good. In fact I made the mistake of thinking it was lp:qtmir already.
Also, if by 'release branches' you mean Ubuntu distro branches, then
they already exist under the Ubuntu project:
https://code.launchpad.net/ubuntu/+source/qtmir
You theoretically should not need one in lp:qtmir/* e
Nice work.
On the Mir side we should also upstream the Mesa work. Although there
are some bugs open there that we should fix first.
On 10/08/15 21:58, Gerry Boland wrote:
Hey folks,
a quick announcement, we have initial support for Qt clients on Mir
(i.e. qtubuntu) upstream in Qt! It'll land
I feel that is just making excuses to not aim higher. The whole platform
changes every six months and yes Linux developers are used to the pain
that comes with that. But would it hurt us to try and make Mir one of
the more stable parts of that platform?
On 12/08/15 08:17, Christopher James Ha
using trusty never get involved in Mir then I think it's too high.
On 12/08/15 10:09, Christopher James Halse Rogers wrote:
On Wed, Aug 12, 2015 at 12:03 PM, Daniel van Vugt
wrote:
I feel that is just making excuses to not aim higher. The whole
platform changes every six months and yes Linux
latest and greatest tools/OS.
Cemil
On Tue, Aug 11, 2015 at 9:52 PM, Christopher James Halse Rogers
mailto:ch...@cooperteam.net>> wrote:
On Wed, Aug 12, 2015 at 12:17 PM, Daniel van Vugt
mailto:daniel.van.v...@canonical.com>> wrote:
We did. C++14 was completely un
Mir does not build on a fully updated wily system today. This is
expected as the whole archive is "transitioning" (rebuilding) to GCC 5
and a new C++ ABI.
A workaround for the time being is:
cmake .. -DCMAKE_CXX_COMPILER=g++-4.9 -DCMAKE_C_COMPILER=gcc-4.9
or clang of course.
You can monitor
This also means autolandings won't work. So best to hold off any top
approvals till wily is updated and working again.
On 12/08/15 12:16, Daniel van Vugt wrote:
Mir does not build on a fully updated wily system today. This is
expected as the whole archive is "transitioning"
COMPILER=g++-4.9 -DCMAKE_C_COMPILER=gcc-4.9
- Daniel
On 12/08/15 12:16, Daniel van Vugt wrote:
Mir does not build on a fully updated wily system today. This is
expected as the whole archive is "transitioning" (rebuilding) to GCC 5
and a new C++ ABI.
A workaround for the time being
201 - 300 of 384 matches
Mail list logo
