On 15 December 2013 12:26, Alberto Mardegan
alberto.marde...@canonical.com wrote:
Hi Dimitri,
On 12/13/2013 07:58 PM, Dimitri John Ledkov wrote:
As of latest cmake upload into trusty, it is now trivial to
cross-compile CMake based projects:
One time setup:
$ mk-sbuild --target armhf trusty
On 15 December 2013 12:29, Michał Sawicz michal.saw...@canonical.com wrote:
On 15.12.2013 13:26, Alberto Mardegan wrote:
I'm interested in having the same support in qmake; is someone already
working on it?
What do your changes do, exactly? Do I understand correctly that the
goal is to have
On Mon, Dec 16, 2013 at 12:56 PM, Dimitri John Ledkov x...@ubuntu.comwrote:
On 15 December 2013 12:26, Alberto Mardegan
alberto.marde...@canonical.com wrote:
Hi Dimitri,
On 12/13/2013 07:58 PM, Dimitri John Ledkov wrote:
As of latest cmake upload into trusty, it is now trivial to
On 13-12-16 07:07 AM, Olivier Tilloy wrote:
Are you implying there are canonical projects not using CMake yet?
There are, yes. Off the top of my head:
- ubuntu-ui-toolkit
- oxide (not in the archive yet)
There might be more.
I've added a work item to switch oxide to CMake,
Dimitri,
Really cool stuff. If I want to use my laptop to cross-compile a C++ QML
extension I'd like to ship as a binary in a .click package (and not
necessarily build a .deb package), could I use this as well? And if so, how?
Thanks!
Cheers,
David.
On Mon, Dec 16, 2013 at 1:44 PM, Marc
Hi,
We have an upcoming (in the new year) Qt transition to 5.2 on the
platform. At that point we'll start building system and core apps
against Qt 5.2 which will mean they won't work on older images which
aren't 5.2 based.
We have core apps and 3rd party apps in the store. Currently each app
in
On 16 December 2013 12:56, David Planella david.plane...@ubuntu.com wrote:
Dimitri,
Really cool stuff. If I want to use my laptop to cross-compile a C++ QML
extension I'd like to ship as a binary in a .click package (and not
necessarily build a .deb package), could I use this as well? And if
On 16 December 2013 12:07, Olivier Tilloy olivier.til...@canonical.com wrote:
There are, yes. Off the top of my head:
- ubuntu-ui-toolkit
- oxide (not in the archive yet)
There might be more.
About ubuntu-ui-toolkit. Is it something that should be maintained at
qt upstream as a platform
On Mon, Dec 16, 2013 at 10:14 AM, Alan Pope alan.p...@canonical.com wrote:
We have core apps and 3rd party apps in the store. Currently each app
in the store has one published version and that has ubuntu-sdk-13.10
defined as the framework in the manifest.json. Related, as I
understand it we
IIRC (I'd have to look at the code) yes, we do send the SDK version (and if
we didn't, then we only need to add it before the switch happens).
This opens the door for devs to upload multiple versions with slightly
different names supporting different SDKs, which sucks.
On Mon, Dec 16, 2013 at
On Mon, Dec 16, 2013 at 10:38 AM, Roberto Alsina
roberto.als...@canonical.com wrote:
This opens the door for devs to upload multiple versions with slightly
different names supporting different SDKs, which sucks.
And why do you think this doesn't happen in Android or iOS?
--
Martin
--
On 13-12-16 08:27 AM, Martin Albisetti wrote:
On Mon, Dec 16, 2013 at 10:14 AM, Alan Pope alan.p...@canonical.com wrote:
We have core apps and 3rd party apps in the store. Currently each app
in the store has one published version and that has ubuntu-sdk-13.10
defined as the framework in the
On 16 December 2013 13:27, Martin Albisetti argent...@gmail.com wrote:
On Mon, Dec 16, 2013 at 10:14 AM, Alan Pope alan.p...@canonical.com wrote:
We have core apps and 3rd party apps in the store. Currently each app
in the store has one published version and that has ubuntu-sdk-13.10
defined
On 12/16/2013 01:56 PM, Dimitri John Ledkov wrote:
1) Simply because qmake encodes and assumes the same host
configration options as were used when qmake qmake modules were
created. To properly support multiarch, all qmake modules instlalation
path will need to transition from non-multiarch,
On Mon, Dec 16, 2013 at 3:06 PM, Alberto Mardegan
alberto.marde...@canonical.com wrote:
On 12/16/2013 01:56 PM, Dimitri John Ledkov wrote:
1) Simply because qmake encodes and assumes the same host
configration options as were used when qmake qmake modules were
created. To properly support
On 16.12.2013 14:14, Dimitri John Ledkov wrote:
On 16 December 2013 12:56, David Planella david.plane...@ubuntu.com wrote:
Really cool stuff. If I want to use my laptop to cross-compile a C++ QML
extension I'd like to ship as a binary in a .click package (and not
necessarily build a .deb
On 16 December 2013 14:06, Alberto Mardegan
alberto.marde...@canonical.com wrote:
On 12/16/2013 01:56 PM, Dimitri John Ledkov wrote:
1) Simply because qmake encodes and assumes the same host
configration options as were used when qmake qmake modules were
created. To properly support
Hello,
On 16.12.2013 15:57, Dimitri John Ledkov wrote:
On 16 December 2013 14:51, Daniel Holbach daniel.holb...@ubuntu.com wrote:
On 16.12.2013 14:14, Dimitri John Ledkov wrote:
On 16 December 2013 12:56, David Planella david.plane...@ubuntu.com wrote:
Really cool stuff. If I want to use my
On 12/16/2013 07:27 AM, Martin Albisetti wrote:
On Mon, Dec 16, 2013 at 10:14 AM, Alan Pope alan.p...@canonical.com wrote:
We have core apps and 3rd party apps in the store. Currently each app
in the store has one published version and that has ubuntu-sdk-13.10
defined as the framework in
On 16 December 2013 15:10, Daniel Holbach daniel.holb...@ubuntu.com wrote:
I think you want:
click chroot -a armhf install ubuntu-sdk-libs-dev:armhf cmake
does that work better? Note the arch qualified suffix :armhf on the
ubuntu-sdk-libs-dev.
This gets me into
On 12/16/2013 07:54 AM, Dimitri John Ledkov wrote:
On 16 December 2013 13:27, Martin Albisetti argent...@gmail.com wrote:
On Mon, Dec 16, 2013 at 10:14 AM, Alan Pope alan.p...@canonical.com wrote:
We have core apps and 3rd party apps in the store. Currently each app
in the store has one
On 12/13/2013 11:58 AM, Dimitri John Ledkov wrote:
As of latest cmake upload into trusty, it is now trivial to
cross-compile CMake based projects:
Awesome!
...
With chroots managed by click: one can simply use cmake ../; make direct.
This together with a working emulator completes
On 12/16/2013 04:28 PM, Thomas Voß wrote:
I think the policy and guideline is pretty simple: For every new
project that Canonical is upstream for, we will default to CMake
(language/runtime-specific build systems aside). With that, all
developers benefit from cross-build support and best
Hi Dimitri,
thanks for explaining things so clearly!
On 12/16/2013 04:54 PM, Dimitri John Ledkov wrote:
[...]
There is no technical limitation, why a qmake binary cannot be adapted
to read all configuration qmake modules from a configurable location
at runtime, instead of hard-coded one at
On 16 December 2013 15:27, Jamie Strandboge ja...@canonical.com wrote:
On 12/16/2013 07:54 AM, Dimitri John Ledkov wrote:
On 16 December 2013 13:27, Martin Albisetti argent...@gmail.com wrote:
On Mon, Dec 16, 2013 at 10:14 AM, Alan Pope alan.p...@canonical.com wrote:
We have core apps and
Hi
Thank you very much Roman, I am glad you like it :D
Bonjour José,
I hope you are considering to offer localized version of your app.
I'd be happy to coordinate the French translation for you.
Transifex is a great translation platform/site. Check it out. I coordinate
many software
On 13-12-16 11:05 AM, Dimitri John Ledkov wrote:
On 16 December 2013 15:27, Jamie Strandboge ja...@canonical.com wrote:
On 12/16/2013 07:54 AM, Dimitri John Ledkov wrote:
On 16 December 2013 13:27, Martin Albisetti argent...@gmail.com wrote:
On Mon, Dec 16, 2013 at 10:14 AM, Alan Pope
On 12/16/2013 10:05 AM, Dimitri John Ledkov wrote:
On 16 December 2013 15:27, Jamie Strandboge ja...@canonical.com wrote:
On 12/16/2013 07:54 AM, Dimitri John Ledkov wrote:
...
Fat packages are being implemented for shipping multiple binaries for
different
architectures in a single click
On Mon, Dec 16, 2013, Jamie Strandboge wrote:
To me it makes sense to support one version *per framework* per application.
This gives power to the developer to support what he/she wants[1]. Support the
latest framework only to always stay cutting edge-- fine, but you will likely
have fewer
-
some related to changing background images. Let's see how it goes tomorrow.
Today, a quick list of tasks related to 'going green':
* ubuntu-weather-app (Nicholas):
Still flaky tests it seems - one failure on mako, two on maguro:
-
http://ci.ubuntu.com/smokeng/trusty/touch/maguro/68:20131216
On Monday 16 December 2013 15:28:23 Thomas Voß wrote:
I think the policy and guideline is pretty simple: For every new
project that Canonical is upstream for, we will default to CMake
(language/runtime-specific build systems aside). With that, all
developers benefit from cross-build support
Hello,
Does someone can post 'ls' result under ubuntu rootfs?
I need to know if /system, /data (and some other) need to exist,
Regards
--
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help
/touch/mako/68:20131216:20131211.2/5483/gallery-app-autopilot/575353/
That’s a flaky test indeed, a MR that fixes it is pending review:
https://code.launchpad.net/~osomon/gallery-app/wait-for-confirm-dialogue/+merge/199076
.
However it is blocked on bug
#1261417https://bugs.launchpad.net/ubuntu
Hey everyone,
On Mon, Dec 16, 2013 at 1:15 PM, Łukasz 'sil2100' Zemczak
lukasz.zemc...@canonical.com wrote:
Right, it might sound a bit scary indeed. The main thing that Didier
wanted to say is that we want all the tests to be reliable.
I totally agree
We no longer
do re-runs in case
On Mon, Dec 16, 2013 at 12:06 PM, Łukasz 'sil2100' Zemczak
lukasz.zemc...@canonical.com wrote:
* unity8 (Kevin):
One failure on maguro. Is this still a random failure? I guess we need
to push on that as well:
http://ci.ubuntu.com/smokeng/trusty/touch/maguro/68:20131216:20131211.2/5485
On 16.12.2013 19:06, Łukasz 'sil2100' Zemczak wrote:
* unity8 (Kevin):
One failure on maguro. Is this still a random failure? I guess we need
to push on that as well:
http://ci.ubuntu.com/smokeng/trusty/touch/maguro/68:20131216:20131211.2/5485/unity8-autopilot/
That'd be:
https
/smokeng/trusty/touch/maguro/68:20131216:20131211.2/5485/unity8-autopilot/
That'd be:
https://bugs.launchpad.net/unity8/+bug/1260860
--
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help
On 16 December 2013 18:14, Michael Zanetti
michael.zane...@canonical.com wrote:
On Monday 16 December 2013 15:28:23 Thomas Voß wrote:
I think the policy and guideline is pretty simple: For every new
project that Canonical is upstream for, we will default to CMake
(language/runtime-specific
On Fri, Dec 13, 2013 at 4:25 PM, Barry Warsaw ba...@ubuntu.com wrote:
AFAIK, system-image and system-settings are not autopilot tested, but again
it's not clear that such testing would have caught *this* issue. Not that
autopiloting the upgrade sequence isn't still a good idea! We need to
On Sat, Dec 14, 2013 at 12:41 PM, Kevin Krammer anda.s...@gmail.com wrote:
On Saturday, 2013-12-14, 08:24:03, Thomas Voß wrote:
On Sat, Dec 14, 2013 at 12:05 AM, Dimitri John Ledkov x...@ubuntu.com
wrote:
On 13 December 2013 22:25, Barry Warsaw ba...@ubuntu.com wrote:
So, what steps can be
40 matches
Mail list logo
