Re: [Ubuntu-phone] Landing team 18.12.13

image green': > > * calendar-app (Nicholas): > Still no comment on those - is there any progress? I guess filling in a > bug is a good idea here. Last smoketesting reports 4 failures on maguro. > http://ci.ubuntu.com/smokeng/trusty/touch/maguro/73:20131218:20131211.2/5531/ca

[Ubuntu-phone] Compile problem with no errors

When I compile UT with all namespace and cgroup configs , lxc-checkconfig says missing on some of the items. Running lxc-checkconfig config-file shows that its all enabled . -- Sent from my Android device with K-9 Mail. Please excuse my brevity.-- Mailing list: https://launchpad.net/~ubuntu-p

Re: [Ubuntu-phone] WARNING: Use application:/// URLs, not application://

On Wed, 2013-12-18 at 20:48 -0200, Carlos J Mazieri wrote: > Am I doing something wrong? Not wrong, but it moved to being a click package, which means it needs a slightly more complex URL. appid://com.ubuntu.terminal/terminal/current-user-version That should open the lastest version installed

Re: [Ubuntu-phone] WARNING: Use application:/// URLs, not application://

Hi there, I am trying to call the Ubuntu Terminal Application using QDesktopServices::openUrl() in C++. I tried URL as "application:///ubuntu-terminal-app.desktop". I did not get any error message, but I did not get the terminal application. Also tried from QML: Qt.openUrlExternally("appli

Re: [Ubuntu-phone] New Landing Plan format!

On Tue, Dec 17, 2013 at 10:30 PM, Martin Pitt wrote: > What a nice christmas present! I already had feared we'd be stuck with > this spreadsheet for much longer, so thanks for getting rid of > it! No more IRC hunting "can someone pretty please add this". I'm glad somebody liked it ;-) >> When y

[Ubuntu-phone] Landing team 18.12.13

illing in a bug is a good idea here. Last smoketesting reports 4 failures on maguro. http://ci.ubuntu.com/smokeng/trusty/touch/maguro/73:20131218:20131211.2/5531/calendar-app-autopilot/ * music-app (Nicholas): We just noticed that there's a flaky test in music-app as well (most probably).

Re: [Ubuntu-phone] LP: #1260712 post-mortem and improving our processes

Thanks for the followup Leo! I don't have much more to add, but let me comment quickly on a few things. On Dec 16, 2013, at 06:26 PM, Leo Arias wrote: >If we have to change the test client for the tests to pass, we will need to >communicate it to all our known clients. Ideally, getting a +1 on t

Re: [Ubuntu-phone] LP: #1260712 post-mortem and improving our processes

On Dec 17, 2013, at 10:50 PM, Alberto Mardegan wrote: >But if I got it right, Barry needed an asynchronous method *implementation*, >on the server side. Correct. >Actually the tutorial you linked if mentions that it's possible, however it >doesn't document it: > >http://dbus.freedesktop.org/doc/

Re: [Ubuntu-phone] LP: #1260712 post-mortem and improving our processes

On 18 December 2013 16:34, Barry Warsaw wrote: > On Dec 14, 2013, at 08:24 AM, Thomas Voß wrote: > >>Seconded. Treating DBus as an implementation detail and not leaking it >>to customers of your service helps a lot in versioning access to your >>API/service. In addition, our tooling and packaging

Re: [Ubuntu-phone] LP: #1260712 post-mortem and improving our processes

On Wed, Dec 18, 2013 at 5:34 PM, Barry Warsaw wrote: > On Dec 14, 2013, at 08:24 AM, Thomas Voß wrote: > >>Seconded. Treating DBus as an implementation detail and not leaking it >>to customers of your service helps a lot in versioning access to your >>API/service. In addition, our tooling and pack

Re: [Ubuntu-phone] LP: #1260712 post-mortem and improving our processes

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Dec 17, 2013, at 02:25 PM, Alberto Mardegan wrote: >In fact, it was not necessary: the ApplyUpdate() could have stayed as it was, >and yet be processed asynchronously, allowing the main loop to continue >running. I'm not sure if that's possible

Re: [Ubuntu-phone] LP: #1260712 post-mortem and improving our processes

On Dec 14, 2013, at 12:41 PM, Kevin Krammer wrote: >While it is of course nice to delegate version handling to the linker, it >also makes writing those interface libraries the difficult task. Thanks for enumerating some of the difficult design choices involved in writing D-Bus API wrappers. Anot

Re: [Ubuntu-phone] LP: #1260712 post-mortem and improving our processes

On Dec 14, 2013, at 08:24 AM, Thomas Voß wrote: >Seconded. Treating DBus as an implementation detail and not leaking it >to customers of your service helps a lot in versioning access to your >API/service. In addition, our tooling and packaging supports >versioning on a library/symbol level quite n

Re: [Ubuntu-phone] LP: #1260712 post-mortem and improving our processes

On Dec 13, 2013, at 11:05 PM, Dimitri John Ledkov wrote: >dbus apis are hard, hence a few dbus apis are provided as shared-libraries >(essentially generate client code and compile it into shared library). When >looking at dbus api, as if it's a compiled generated shared library the >ABI/API break

Re: [Ubuntu-phone] Cross-compile with CMake from SDK Apps to Unity8/Mir

Hey, On 17.12.2013 20:04, Zoltán Balogh wrote: > The cmake support with crossbuild feature is on its way. Most likely it > will be a two staged delivery. As a first step I will make the cmake > template of the QML plugins and add a hot-key (similar to the Ctrl-F12 > deployment) to build the pro

Re: [Ubuntu-phone] FALSE ALERT - Re: New Landing Plan format!

On Wed, 2013-12-18 at 10:44 +0100, Alexander Sack wrote: > this was not a not coordinated step by Rob. The format and process was > not agreed and algined with Landing Team. While I know that everyone > waits for something like this, but for now we will not use this > format. Besides "no one tol

Re: [Ubuntu-phone] New Landing Plan format!

On 18/12/13 10:46, Ricardo Salveti de Araujo wrote: On Wed, Dec 18, 2013 at 11:29 AM, Łukasz 'sil2100' Zemczak wrote: Hi guys, First of all: as per the other e-mail, we still don't have a better tool ;) As Alexander mentioned, this transition was not planned ahead and synced with anyone, so fo

Re: [Ubuntu-phone] New Landing Plan format!

On Wed, Dec 18, 2013 at 11:29 AM, Łukasz 'sil2100' Zemczak wrote: > Hi guys, > > First of all: as per the other e-mail, we still don't have a better tool > ;) As Alexander mentioned, this transition was not planned ahead and > synced with anyone, so for now we're still stuck with the spreadsheet.

Re: [Ubuntu-phone] New Landing Plan format!

Hi guys, First of all: as per the other e-mail, we still don't have a better tool ;) As Alexander mentioned, this transition was not planned ahead and synced with anyone, so for now we're still stuck with the spreadsheet. The topic of 'who can add requests' needs to be discussed through then. I u

Re: [Ubuntu-phone] New Landing Plan format!

On Wed, Dec 18, 2013 at 8:19 AM, Martin Pitt wrote: > Łukasz 'sil2100' Zemczak [2013-12-18 9:56 +0100]: >> Generally, access rights to submit bugs in this project should be >> restricted only to team managers and the landing team > > No, pretty please not. The major reason why this landing sheet

Re: [Ubuntu-phone] New Landing Plan format!

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robert Park wrote on 18/12/13 00:47: > > On Tue, Dec 17, 2013 at 4:03 PM, Chris Wayne > wrote: >> >> Not to be 'that guy', but wouldn't this work better as a Kanban >> board? > > No. The goal, as decided at the sprint, is to use launchpad bugs, >

Re: [Ubuntu-phone] FALSE ALERT - Re: New Landing Plan format!

Hi everyone, Just as discussed during the UTC morning landing meeting, let's do it like Alexander already proposed. Originally I thought that this was something planned to happen this week, but it seems not. Even though the idea is really nice (and it seems everyone else loves it as well), we shou

Re: [Ubuntu-phone] New Landing Plan format!

Łukasz 'sil2100' Zemczak [2013-12-18 9:56 +0100]: > Generally, access rights to submit bugs in this project should be > restricted only to team managers and the landing team No, pretty please not. The major reason why this landing sheet is annoying because right now e. g. I as core-dev (but not m

Re: [Ubuntu-phone] New Landing Plan format!

hi, Am Dienstag, den 17.12.2013, 19:03 -0500 schrieb Chris Wayne: > Not to be 'that guy', but wouldn't this work better as a Kanban board? > the idea was that the landing process kind of replicates a combination of two existing processes we already have and which developers (no matter if canonical

[Ubuntu-phone] FALSE ALERT - Re: New Landing Plan format!

Hi, this was not a not coordinated step by Rob. The format and process was not agreed and algined with Landing Team. While I know that everyone waits for something like this, but for now we will not use this format. Landing Team will revert the changes done and lets talk about this next year when

Re: [Ubuntu-phone] Cross-compile with CMake from SDK Apps to Unity8/Mir

On Tuesday 17 December 2013 21:04:34 Zoltán Balogh wrote: > On 12/17/2013 01:23 AM, Dimitri John Ledkov wrote: > > On 16 December 2013 18:14, Michael Zanetti > > > > wrote: > >> On Monday 16 December 2013 15:28:23 Thomas Voß wrote: > >>> I think the policy and guideline is pretty simple: For ever

Re: [Ubuntu-phone] New Landing Plan format!

Hi Robert! Now that's an unexpected Christmas present - you didn't mention anything about it on yesterdays meeting! Good work :) The task transition doesn't seem to be completely finished though, but I guess I'll pick this up and try making everything cleaned up. For instance, there are duplicate

Re: [Ubuntu-phone] A small patch on path matching in android_bootable_recovery

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 YC Cheng wrote on 13/12/13 07:45: > > Hi, the patch attached is a again path matching for file > system-image-upgrader. > > in git://phablet.ubuntu.com/CyanogenMod/android_bootable_recovery >