ilar, but will be the default behaviour for the
foreseeable future.
--
Michał Sawicz
Canonical Ltd.
signature.asc
Description: OpenPGP digital signature
--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/mir-devel
ving added some meaningful command
line options.
Another way to identify we were considering is via the apparmor profile
an app is launched under, so that upstart/ubuntu-app-launch could be
taken out of the equation, but we've not confirmed that's our way forward.
--
Michał Sawicz
Can
me, it will be a different commit.
If you really don't want to maintain a Ubuntu packaging branch (which
lp:mir/ubuntu really is), you'll just need to build the source packages
by hand and ask the train staff to upload them to your silos.
--
Michał Sawicz
Canonical Ltd.
signa
outside of LP.
--
Michał Sawicz
Canonical Ltd.
signature.asc
Description: OpenPGP digital signature
--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/mir-devel
W dniu 15.08.2014 o 09:32, Gerry Boland pisze:
Only reason I suggested the idea is that restarting unity8 would be a new thing
for all app tests, and maybe sending a dbus signal would be less disruptive?
But if Thomi things restarting is ok, then I'm happy.
We're already restarting unity with
W dniu 07.08.2014 o 01:02, Christopher James Halse Rogers pisze:
Hey all!
As seen on IRC last night:
18:22 Seems like we need a way to replicate what the silos are
doing - building mir, creating packages from it, installing them, and
then building downstreams... I.e. not just building downstre
On 18.07.2014 10:06, Alan Griffiths wrote:
> Anyone know which project to report the bug against?
https://bugs.launchpad.net/ubuntu-ci-services-itself/
Should be a good place.
--
Sq
signature.asc
Description: OpenPGP digital signature
--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Mod
On 09.05.2014 14:53, Cemil Azizoglu wrote:
> This is a good one Who wants to take it up? :-)
Reported to #launchpad on Freenode, please do so whenever you see such a
thing.
--
Michał (Saviq) Sawicz
Canonical Services Ltd.
signature.asc
Description: OpenPGP digital signature
--
Mir-devel
On 02.05.2014 08:52, Daniel van Vugt wrote:
> Sure, not disastrous. Just that fixes documented (in the proposal) as
> being fixed in "0.1.9" may not actually have made it into the package.
> So inaccurate. It's nice to have accurate info about where things are
> fixed :)
Of course, if there were t
On 02.05.2014 03:20, Daniel van Vugt wrote:
> No problem. Next time we should be sure the proposal is top-approved
> first. It wasn't top approved in this case so there was a real risk that
> people like me could make further changes without knowing those changes
> were too late to reach archive.
On 01.05.2014 08:03, Daniel van Vugt wrote:
> Although the landing process must have changed because the 0.1.9
> packages were released without anything landing in lp:mir yet(!?).
Kicked the merge & clean job and everything's in trunks now.
--
Michał (Saviq) Sawicz
Canonical Services Ltd.
si
On 29.01.2014 12:22, Marco Trevisan wrote:
Where all my work is done only in work dir, and I can use bzr switch to
move to a different branch that I might create or fetch in BRANCHES.
See [1] for more hints, but that definitely made my workflow with bzr
much more productive (so, that switching b
On 12.12.2013 09:24, Daniel van Vugt wrote:
Oh, I see where the confusion is.
No, Mir is not on daily releases because it affects too many other
projects and we need to manually coordinate ABI/API changes for each
release. Mir is on weekly-ish releases, all of which have proper version
numbers.
On 12.12.2013 02:19, Daniel van Vugt wrote:
"0.1.2" is the upstream version number, and there is only one tarball;
https://launchpad.net/mir/+milestone/0.1.2
I'm not sure where the suggestion of multiple upstream tarballs comes from.
Do you bump the upstream version number between packages int
On 11.12.2013 19:46, Kevin Gunn wrote:
I can't remember exactly why, but I believe its the release teams
process to add the date in when they insert it into archive.
0.1.2+14.04.20131128.1-0ubuntu2
Upstream_Version+Target_Release.Date[.Iteration]
AFAICT the purpose was to be able to easily de
On 05.12.2013 18:48, Thomi Richards wrote:
That should be easy to write, I think?
Oh yeah, there would definitely be a simple implementation of the client.
BUT! Screenshotting very much != screencasting, which was identified as
the requirement for AP test failures to get more data.
Whatever
On 27.11.2013 16:30, Ricardo Mendoza wrote:
Back to this, providing a screenshotting interface with a default file
sink is a matter of... 30 minutes? I believe extending the
com.canonical.Unity.Screen interface; as long as you decide on a place
to put screenshot files and a default format.
I bel
On 15.10.2013 16:13, Daniel d'Andrada wrote:
That's because you're mapping a feature to a priority level, which is
wrong. A bug could have a "Wishlist" priority-level just as well as a
feature could be at a "High" priority level.
Not me - launchpad does...
--
Michał (Saviq) Sawicz
Canonical S
On 15.10.2013 16:04, Daniel d'Andrada wrote:
Bugs and new features are, on a slighly higher level, the same thing:
work that has to be done on some piece of software, according to some
specs, with a target milestone, an assignee, a given priority, a state
(in progress, new, commited, released),
On 15.10.2013 15:01, Kevin Gunn wrote:
What do you think of using blueprints for bugs-which-are-really-features ?
I believe the biggest issue here for us is ubuntu-ux's process of
design-related bugs.
On top of that, bugs allow you to link multiple related projects
together, which blueprint
W dniu 25.07.2013 01:28, Robert Carr pisze:
> I don't mean to raise FUD but it is unclear enough to me that I would
> not know the first step if assigned it as a task (My first question
> would be, does ms::Surface implement QQuickItem? If not, how do we avoid
> two copies of the SurfaceStack). I a
W dniu 19.07.2013 12:02, Daniel van Vugt pisze:
> Yes indeed the shell is meant to implement the scene graph. But that
> implementation is still inside libmirserver. It needs to be pulled out
> of the server library.
>
> Interface: mir::compositor::Scene
> Implementation: mir::surfaces::Sur
W dniu 19.07.2013 01:58, Gerry Boland pisze:
> What shell will need is, for every surface, the following properties:
> - x, y, z, width, height
> - opacity, visible
> - scale
> - ability to set more complex transformations/shaders, so can desaturate
> surface colours, do more advanced animations, b
23 matches
Mail list logo
