Canonical Voices

Posts tagged with 'planet ubuntu'

David Planella

OSM GPS dump

We’re very excited to announce an agreement with Nokia HERE to provide A-GPS support on Ubuntu. The new platform service will enable developers to obtain accurate positioning data for their location-based apps in under two minutes, a significantly shorter Time To First Fix (TTFF) than the average for raw GPS technologies.

Faster positioning

While Ubuntu already features GPS-based location, it has always been a key requirement for the OS to provide application developers with rapid and efficient location positioning capabilities.

The new positioning service will be a hybrid solution integrating A-GPS and WiFi positioning, a powerful combo to help obtaining a very fast and accurate TTFF. The system is to be functional by the Release To Manufacturer (RTM) milestone, and available on the regular Ubuntu builds and for retail phones shipping Ubuntu.

Privacy and security

With the user’s explicit consent, anonymous data related to signal strength of local WiFi signals and radio cells can be contributed to crowd-sourcing location services, with the purpose of improving the overall quality of the positioning service for all users.

In line with Ubuntu’s privacy policy, no personal data of any nature is to be collected and released. Users will also be able to opt-out of this service if they do not wish their mobile handset to collect this type of data.

The positioning system will also be run under strict confinement, so that the service and its data cannot be accessed without the user explicitly granting access. With Ubuntu’s trust model, a confined application has to be granted trust by the user to gain access to security- or privacy-relevant system components.

Mapping capabilities

As the new service is to be focused on positioning, it will be decoupled from any mapping solution. Ubuntu Developers, as before, will have a choice of mapping services to use for their applications, including Nokia HERE, OpenStreetMap and others.

Header image based on “openstreetmap gps coverage” by Steven Kay, CC-BY-SA 2.0.

Read more
Michael Hall

As part of the continued development of the Ubuntu platform, the Content Hub has gained the ability to share links (and soon text) as a content type, just as it has been able to share images and other file-based content in the past. This allows applications to more easily, and more consistently, share things to a user’s social media accounts.

Consolidating APIs

facebook-sharing
Thanks to the collaborative work going on between the Content Hub and the Ubuntu Webapps developers, it is now possible for remote websites to be packaged with local user scripts that provide deep integration with our platform services. One of the first to take advantage of this is the Facebook webapp, which while displaying remote content via a web browser wrapper, is also a Content Hub importer. This means that when you go to share an image from the Gallery app, the Facebook webapp is displayed as an optional sharing target for that image. If you select it, it will use the Facebook web interface to upload that image to your timeline, without having to go through the separate Friends API.

This work not only brings the social sharing user experience inline with the rest of the system’s content sharing experience, it also provide a much simpler API for application developers to use for accomplishing the same thing. As a result, the Friends API is being deprecated in favor of the new Content Hub functionality.

What it means for App Devs

Because this is an API change, there are things that you as an app developer need to be aware of. First, though the API is being deprecated immediately, it is not being removed from the device images until after the release of 14.10, which will continue to support the ubuntu-sdk-14.04 framework which included the Friends API. The API will not be included in the final ubuntu-sdk-14.10 framework, or any new 14.10-dev frameworks after -dev2.

After the 14.10 release in October, when device images start to build for utopic+1, the ubuntu-sdk-14.04 framework will no longer be on the images. So if you haven’t updated your Click package by then to use the ubuntu-sdk-14.10 framework, it won’t be available to install on devices with the new image. If you are not using the Friends API, this would simply be a matter of changing your package metadata to the new framework version.  For new apps, it will default to the newer version to begin with, so you shouldn’t have to do anything.

Read more
David Planella

Ubuntu loves HTML5Here’s a reminder about next Monday’s 7th of July Ubuntu HTML5 apps session in Barcelona.

At this free event, I’ll be presenting Ubuntu’s HTML5 development story, together with a live coding session and a Q&A round at the end. You’ll learn how to use the Ubuntu SDK and the UI toolkit to easily reuse your web skills to create stunning Ubuntu apps.

HTML5 is the other side of the coin of the Ubuntu app developer offering, where both web and native are first class citizens, offering a very flexible yet focused approach for application development. Teaming up with BeMyApp meetups, the session will start at 7 p.m. at Barcelona’s Mobile World Centre.

I look forward to seeing you there!

Register here for the HTML5 session >

Read more
Michael Hall

It was less than a month that we announced crossing the 10,000 users milestone for Ubuntu phones and tablets, and we’ve already reached another: 100,000 app downloads!

Downloads

10k_downloads_by_countryThe new Ubuntu store used by phones, tablets, and soon the desktop as well, provides app developers with some useful statistics about how many times their app was downloaded, which version was downloaded, and what country the download originated from. This is very useful as it it lets the developer gauge how many users they currently have for their app, and how quickly they are updating to new versions.  One side-effect of these statistics is that we can see how many total downloads there have been across all of the apps in the store, and this week we reached (and quickly passed) the 100,000th download.

Users

app_storeWe’re getting close to having Ubuntu phones go on sale from our partners at Bq and Meizu, but there are still no devices on the market that came with Ubuntu.  This means that we’ve reached this milestone solely from developers and enthusiasts who have installed Ubuntu on one of their own devices (probably a Nexus device) or the device emulator.  

The continued growth in the download number validates the earlier milestone of 10,000 users, a large number of them are clearly still using Ubuntu on their device (or emulator) and keeping their apps up to date (the number represents new app installs and updates). This means that not only are people trying Ubuntu already, many of them are sticking with it too.  Yet another datapoint in support of this is the 600 new unique users who have been using the store since the last milestone announcement.

Pioneers

pioneers_shirtTo supply all of these users with the apps they want, we’re continuing to build our community of app developers around Ubuntu. The first of these have already received their limited edition t-shirts, and are listed on the Ubuntu Pioneers page of the developer portal.

There is still time to get your app published, and claim your place on that page and your t-shirt, but they’re filling up fast so don’t delay. Go to our Developer Portal and get started today, you could be only a few hours away from publishing your first app in the store!

Read more
Alan Pope

As previously blogged we’re inviting the community to hack on Core Apps and Community Apps this week.

All the details are in the post above, but here’s the executive summary:-

  • Hack days run from 30th June till 4th July
  • We’re hacking on the Core Apps Music, Calendar, Calendar, Clock, Weather & Calculator
  • In addition we’re also hacking on community apps including Beru Ebook Reader, OSM Touch mapping software, and Trojita email client
  • Join us in the #ubuntu-app-devel IRC channel on freenode, and on the ubuntu-phone mailing list to get started
  • Get all the details from the hack days wiki page

As always we welcome new contributions during the Hack Days, but also beyond that.

Read more
Alan Pope

Ready for RTM*: Ubuntu Touch Core App Hack Days!

* Release to Manufacturing

device-2014-06-25-121330

We’re running another set of Core Apps Hack Days next week. Starting Monday 30th June through to Friday 4th July we’ll be hacking on Core Apps, getting them polished for our upcoming RTM (Release To Manufacture) images. The goal of our hack days is as always to implement missing features, fix bugs, get new developers involved in coding on Ubuntu using the SDK and to have some fun hacking on Free Software.

For those who’ve not seen the hack days before, it’s really simple. We get together from 09:00 UTC till 21:00 UTC on #ubuntu-app-devel on freenode IRC and hack on the Core Apps. We will be testing the apps to destruction, filing and triaging bugs, creating patches, discussing and testing proposals and generally do whatever we can to get these apps ready for RTM. It’s good fun, relaxed and a great way to get started in Ubuntu app development with the SDK

We’ll have developers hanging around to answer questions, and can call on platform and SDK experts for assistance when required. We focus on specific apps each day, but as always we welcome contributions to all the core apps both during the designated days, and beyond.

Not just Core Apps

This time around we’re also doing things a little differently. Typically we only focus attention on the main community maintained Core Apps we ship on our device images. For this set of Hack Days we’d like to invite 3rd party community app developers to bring their apps along as well and hack with us. We’re looking for developers who have already developed their Ubuntu app using the SDK but maybe need help with the “last mile”. Perhaps you have design questions, bugs or feature enhancements which you’d like to get people involved in.

device-2014-06-25-122105 device-2014-06-25-122334

We won’t be writing your code for you, but we can certainly help to find experienced people to answer your questions and advise of platform and SDK details. We’d expect you to make your code available somewhere, to allow contributions and perhaps enable some kind of bug tracker or task manager. It’s up to you to manage your own community app, we’re here to help though!

Get involved

If you’re interested in bringing your app to hack days, then get in touch with popey (Alan Pope) on IRC or via email [popey@ubuntu.com] and we’ll schedule it in for next week and get the word out.

You can find out more about the Core Apps Hack Days on the wiki, and can discuss this with us on IRC in #ubuntu-app-devel.

Read more
Michael Hall

ubuntu-phone-three-1As we enter the final months before the first Ubuntu phones ship from our partners Meizu and Bq, the numbers of apps, users and downloads continues to grow at a steady pace. Today I’m excited to announce that we have more than ten thousand unique users of Ubuntu on phones or tablets!

Users

Ubuntu phone (and tablet) users sign into their Ubuntu One account on their device in order to download or update the applications on their phone. This allows us to provide many useful features that users expect coming from Android or iOS, such as being able to re-install their collection of apps on a new phone or after resetting their current one, or browsing the store’s website (coming soon) and having the option to install an app directly to their device from there. As a side effect, it means we know how many unique Ubuntu One accounts have connected to the store to in order to download an app, and that number has this week passed the 10,000 mark.

Excitement

Meizu-MX3Not only is this a milestone, but it’s down right amazing when you consider that there are currently no phones available to purchase with Ubuntu on them. The first phones from OEMs will be shipping later this year, but for now there isn’t a phone or tablet that comes with the new Ubuntu device OS on it. That means that each of these 10,000 people have purchased (or already had) either a supported Nexus device, or are using one of the community ports, and either wiped Android off them in favor of Ubuntu, or are dual booting. If this many people are willing to install the beta release of Ubuntu phone on their device, just imagine how many more will want to purchase a phone with Ubuntu pre-installed and with full support from the manufacturer.

Pioneers

In addition to users of Ubuntu phone, we’ve also seen a steady growth in the number of applications and application developers targeting Ubuntu phone and using the Ubuntu SDK. To celebrate them, we created Ubuntu App Pioneers page, and the first batch of Pioneers t-shirts are being sent out to those intrepid developers who, again, are so excited about a platform that isn’t even available to consumers yet that they’ve dedicated their time and energy into making it better for everyone.

Read more
David Planella

We’re thrilled to announce a new release of Ubuntu Dual boot, now supporting enhanced Ubuntu upgrades either from the Android or Ubuntu side.

The new Ubuntu Dualboot release, codenamed M9, enables developers to run both Ubuntu and Android on a single device and is packed with new features that make it the power tool to use for those doing development in both platforms.

For developers only

Dual boot is not a feature suitable for regular users. It is recommended to be installed only by developers who are comfortable with flashing devices and with their partition layout. Dual boot rewrites the Android recovery partition and those installing it should be intimately familiar with re-flashing it in case something goes wrong.

Multiple Android flavours are supported (AOSP or stock, CyanogenMod) and installation of Ubuntu can be done for all versions available in the regular distribution channels.

What’s new

The new release fixes a number of bugs, brings under-the-hood enhancements and includes a bunch of exciting features. Here are the highlights:

Enhanced Ubuntu upgrades

The most prominent feature is the addition of support for the upgrades on the Ubuntu side. Now image upgrades can be downloaded using the standard procedure in System Settings › Updates from Ubuntu. To complete the installation, a reboot to Android will have the Dualboot app pick up the downloaded image upgrade, install it in the right location and reboot to the new Ubuntu image.

As an alternative, installations can still be done fully on the Android side. In a nutshell:

  • Download of a new Ubuntu version can happen on either the Ubuntu or Android side
  • Installation of a new Ubuntu version needs to be done from the Android side via the Dualboot app

Learn more about upgrading to a new Ubuntu image ›

Android notifications and background execution improvements

The Dualboot Android app now provides notifications for when new Ubuntu images are available, so no more excuses not to be running the latest Ubuntu! In addition, improvements have been added to download and install Ubuntu in the background, while showing progress also using standard Android notifications.

Sideload support

For those cases in which bandwidth is at a premium, the dual boot installer now supports sideload mode. This enables downloading images on a fast network and saving them for later installation: these can be downloaded on a laptop and then transferred via USB to the device. It also opens the door for easily flashing custom images other than the ones downloaded from the official channels.

Learn more about sideload support ›

Custom servers

A nifty feature our heroic community of porters of Ubuntu images to devices not officially supported, and for users of those ports: dual boot now supports setting a custom server to directly install new Ubuntu images from there

Learn more about using a custom server ›

Installing dual boot

Installing and running dual boot can be done in a few easy steps. In a nutshell, it requires performing a one-off installation of the dual boot app in Android, which will enable you to both install the version of Ubuntu of your choice, and to reboot into Ubuntu.

Install dual boot on your device

Read more
Michael Hall

Ubuntu has always been about breaking new ground. We broke the ground with the desktop back in 2004, we have broken the ground with cloud orchestration across multiple clouds and providers, and we are building a powerful, innovative mobile and desktop platform that is breaking ground with convergence.

The hardest part about breaking new ground and innovating is not having the vision and creating the technology, it is getting people on board to be part of it.

We knew this was going to be a challenge when we first took the wraps off the Ubuntu app developer platform: we have a brand new platform that was still being developed, and when we started many of the key pieces were not there such as a solid developer portal, documentation, API references, training and more. Today the story is very different with a compelling, end-to-end, developer story for building powerful convergent apps.

We believed and always have believed in the power of this platform, and every single one of those people who also believed in what we are doing and wrote apps have shared the same spirit of pioneering a new platform that we have.

As such, we want to acknowledge those people.

And with this, I present Ubuntu Pioneers.

The idea is simple, we want to celebrate the first 200 app developers who get their apps in Ubuntu. We are doing this in two ways.

Firstly, we have created http://developer.ubuntu.com/pioneers which displays all of these developers and lists the apps that they have created. This will provide a permanent record of those who were there right at the beginning.

Secondly, we have designed a custom, limited-edition Ubuntu Pioneers t-shirt that we want to send to all of our pioneers. For those of you who are listed on this page, please ensure that your email address is correct in MyApps as we will be getting in touch soon.

Thank-you so much to every single person listed on that page. You are an inspiration for me, my team, and the wider Ubuntu project.

If you have that pioneering spirit and wished you were up there, fear not! We still have some space before we hit 200 developers, so go here to get started building an app.

Original by Jono Bacon

Read more
David Planella

The judging is finished and the scores are in, we now have the winners of our third Ubuntu App Showdown! Over the course of six weeks, and using the Ubuntu SDK, our community of app developers were able to put together a number of stunningly beautiful, useful, and often highly entertaining apps.

We had everything from games to productivity tools submitted to the competition, written in QML, C++ and HTML5. Some were ports of apps that already existed on other platforms, but the vast majority were original apps created specifically for the Ubuntu platform.

Best of all, these apps are all available to download and install from the Apps Scope on Ubuntu phones and tablets, so if you have a Nexus device or one with a community image of Ubuntu, you can try these and many more for yourself. Now, on to the winners!

QML Apps: Project Dashboard

dashboard

Judges were astounded by the beautifully crafted Project Dashboard app, the winner of the QML category. Not only the idea and execution were brilliant, but also the fact that it’s a convergent QML application that runs on phones, tablet and desktop got it those coveted extra points from the jury.

With Project Dashboard you can keep track of different projects you’re managing or participating right from your device, in a very intuitive and easy way. For the geeks in us who contribute in several Open Source project, the excellent integration with Github makes it a pleasure to participate or manage the day to day of projects hosted in there.

Well done Michael Spencer!

HTML5 Apps: BE Mobile

bemobile

Say you’re in Belgium and want to get quickly from A to B with public transport? Then you’ll definitely want to use the winner of the HTML5 apps category: BE Mobile.

BE Mobile helps travellers find the best routes and times to travel within Belgium by selecting a journey and searching through a list of public transport services that can be enabled or disabled at will. In addition to that, a set of Twitter feeds for the services are provided, so that commuters and occasional travellers get informed in real time of disruptions and news for the lines they’re wanting to use.

What’s beautiful about it is the way in which using the SDK’s HTML5 components the app blends into the system exactly as a QML app. Convergence is also well-catered for with a responsive HTML design.

Congrats to Jelmer Prins!

Ported Apps: 2048

2048

Whoever has been online lately has surely heard about or played 2048. This addictive game created by 19-year-old Gabriele Cirully has quicky reached Internet popularity status and quite a following. And now Ubuntu has got its own ported version thanks to developer Victor Thompson, who takes home the prize for the best ported app in this Showdown!

A simple yet beautiful UI, combined with an engaging game experience will certainly grant hours of fun trying to reach that craved for 2048 tile!

Chinese Apps: QmlTextReader and Simple Dict

Chinese apps: QmlTextReader on the left, Simple Dict on the right

Chinese apps: QmlTextReader on the left, Simple Dict on the right

As a new category, we added “Chinese apps” for this third round of the App Showdown. Boren Zhang, who is also a Core Apps developer, contributed QmlTextReader, which had a simple design as its focus. It allows you to read novels and other texts and works very well for Chinese text. Font size and encoding can be changed and you can jump to where you left the text before. Perfect for long rides on the train or bus! Shenjing Zhu submitted a simple English/Chinese dictionary which is easy to use and very straight-forward. Both apps are very useful for readers and will come in handy quite often.

Go and get them all!

With retail Ubuntu phones getting closer and closer, the third Ubuntu App Showdown Ubuntu was a good opportunity to put the Ubuntu SDK, our documentation and our general approach to apps in Ubuntu to the test. In particular our HTML5 story has evolved to be on par with QML, so thanks a lot to all community developers and the Webapps team Engineers who have made this possible. During the course of these six weeks we’ve received great feedback from our developer community, worked out a large number of bugs in the SDK, and added or plan to add many new features to our platform.

It was also great to see how quickly all the apps were published in the app store and how little time had to be spent in reviews. The great thing is: if you have a device to run Ubuntu on or use the emulator, you can very easily install all the apps and take them for a spin. Six weeks is not a long time to write an app and get it to completion, but everybody worked hard, got their app in and we are very likely going to see more updates to the apps in the coming weeks.

Once again congratulations to Boren Zhang, Jelmer Prins, Michael Spencer, Shengjing Zhu, Victor Thompson and a big thank you to everybody who participated or helped those who participated, and everyone who has worked on building the Ubuntu SDK, Click tools and the App Store. And if you’re an app developer, or want to become an app developer, now is your time to get started with the Ubuntu SDK!

?? for all the submissions everyone!

Read more
Daniel Holbach

Shortly before the submission deadline last night we had some small technical hiccups in the Ubuntu Software Store. This was fixed resolved very quickly (thanks a lot everyone who worked on this!), but we decided to give everyone another day to make up for it.

The new deadline is today, 10th April 2014, 23:59 UTC.

Please all verify that your app still works, everythings is tidy, you submitted it to the store and filled out the submission form correctly. Here’s how.

Submit your app

This is obviously the most important bit and needs to happen first. Don’t leave this to the last minute. Your app might have to go through a couple of reviews before it’s accepted in the store. So plan in some time for that. Once it’s accepted and published in the store, you can always, much more quickly, publish an update.

Submit your app.

Register your participation

Once your app is in the store, you need to register your participation in the App Showdown. To make sure your application is registered for the contest and judges review it, you’ll need to fill in the participation form. You can start filling it in already and until the submission deadline, it should only take you 2 minutes to complete.

Fill out the submission form.

Questions?

If you have questions or need help, reach out (also rather sooner than later) to our great community of Ubuntu App Developers.

Read more
Daniel Holbach

image-app-showdown

Here’s the final reminder. The App Showdown is almost over and you can win some beautiful devices if you get your app in tomorrow, Wednesday, April 9th 2014 (23:59 UTC).

Getting your app in is very easy: just follow these two steps.

Submit your app

This is obviously the most important bit and needs to happen first. Don’t leave this to the last minute. Your app might have to go through a couple of reviews before it’s accepted in the store. So plan in some time for that. Once it’s accepted and published in the store, you can always, much more quickly, publish an update.

Submit your app.

Register your participation

Once your app is in the store, you need to register your participation in the App Showdown. To make sure your application is registered for the contest and judges review it, you’ll need to fill in the participation form. You can start filling it in already and until the submission deadline, it should only take you 2 minutes to complete.

Fill out the submission form.

Questions?

If you have questions or need help, reach out (also rather sooner than later) to our great community of Ubuntu App Developers.

Good luck everyone, we’re looking forward to lots and lots of great apps! :-)

Read more
James Westby

We’ve recently rolled out some changes to the submission process for Click Applications that should make it easier for you to submit new applications, and allow them to be approved more quickly.

Previously when submitting an application you would have to enter all the information about that application on the website, even when some of that information was already included in the package itself. This was firstly an irritation, but sometimes developers would make a mistake when re-entering this information, meaning that the app was rejected from review and they would have to go back and correct the mistake.

With the new changes, when you submit an application you will wait a few seconds while the package is examined by the system, and you will then be redirected to the same process as before. However this time some of the fields will be pre-filled with information from the package. You won’t have to type in the application name, as it will already be there. This will speed up the process, and should reduce the number of mistakes that happen at that stage.

We’ve also been working on a command-line interface for submitting applications. It’s not polished yet, but if you are intrepid you can try out click-toolbelt.

Read more
Daniel Holbach

image-app-showdown

The app showdown is still in full swing and we have seen lots and lots of activity already. The competition is going to end on Wednesday, April 9th 2014 (23:59 UTC). So what do you need to do to enter and submit the app?

It’s actually quite easy. It takes three steps.

Submit your app

This is obviously the most important bit and needs to happen first. Don’t leave this to the last minute. Your app might have to go through a couple of reviews before it’s accepted in the store. So plan in some time for that. Once it’s accepted and published in the store, you can always, much more quickly, publish an update.

Submit your app.

Register your participation

Once your app is in the store, you need to register your participation in the App Showdown. To make sure your application is registered for the contest and judges review it, you’ll need to fill in the participation form. You can start filling it in already and until the submission deadline, it should only take you 2 minutes to complete.

Fill out the submission form.

 

Questions?

If you have questions or need help, reach out (also rather sooner than later) to our great community of Ubuntu App Developers.

Read more
Daniel Holbach

ubuntu-phone-three-1

There is lots of excitement around Ubuntu on phones and tablets. Especially with two handsets coming out later this year and features and more beauty landing every single week, it’s a lot of fun to watch the whole story unfold.

What many haven’t realised yet, is how easy it is to write apps for Ubuntu and that new apps are not only going to run on phones and tablets, but also on the desktop as well. To remedy that we put some work into making it easy to go out to events and give talks about Ubuntu and its app ecosystem.

What we have available now is:

  • improved presentation materials,
  • we made it easier for newcomers to step in, learn and present,
  • we reach out to app developer communities and our LoCo teams at the same time.

We have two great sets of events coming up soon: the Ubuntu Global Jam coming up in just 2 weeks and soon followed by the 14.04 release and its release parties.

Interested? So how do you prepare? Easy:

  • As somebody who can organise events, but might need to find a speaker: Ask in #ubuntu-app-devel on Freenode or on the ubuntu-app-devel@ mailing list, to see if anyone is in your area to give a talk. Ask on your LoCo’s or LUG’s mailing list as well. Even if somebody who’s into programming hasn’t developed using Ubuntu’s SDK yet, they should be able to familiarise themselves with the technologies quite easily.
  • As somebody who has written code before and didn’t find the Ubuntu app development materials too challenging, but might need to find some help with organising the event: Ask on the loco-contacts@ mailing list. There are LoCos all around the world and most of them will be happy to see somebody give a talk at an event.

Whichever camp you’re in:

  • Check out our docs. They explain what’s required to make the event a success.
  • Join our Q&A session. It’ll be at 27 March 2014, 18:00 UTC on Ubuntu on Air. (The video of session today is up here.)
  • Talk to us. Just comment on the blog post and we can surely help you out somehow.

Let’s make this happen together. Writing apps for Ubuntu and publishing them has never been easier, and they’ll make Ubuntu on phones/tablets much more interesting, and will run on the desktop as well.

Read more
Daniel Holbach

Announcing the latest Ubuntu App Showdown contest!

image-app-showdown

????????

Today we are announcing our third Ubuntu App Showdown! Contestants will have six weeks to build and publish their apps using the new Ubuntu SDK and Ubuntu platform. Both original apps and ported apps, QML and HTML 5, will qualify for this competition.

Categories and prizes

This App Showdown is going to be very special, because we will have four dedicated categories in which you can participate and win a prize.

  1. QML: original apps written in QML or with a combination of QML and JavaScript/C++
  2. HTML5: original apps written using web technologies, be it pure HTML (and CSS/JavaScript) or with platform access using Apache Cordova
  3. Ported: apps ported from another platform, regardless of the technology used
  4. Chinese apps: apps in this category will have to be original and specific to China and the Chinese culture. They will be judged by two native experts in our jury.

The set of prizes will consist of a Nexus 7 (2013) per category for QML, HTML5 and ported apps.
Nexus7-2013


The top two Chinese apps will receive a Meizu device each.
Meizu-MX3

Review criteria

Apps in the HTML5/QML/Ported categories will be reviewed by a jury composed by an international team of five judges:

  • Jono Bacon, Ubuntu Community Manager
  • Adnane Belmadiaf, Ubuntu HTML5 expert
  • Lucas Romero di Benedetto, Ubuntu Community Design Team
  • Nekhelesh Ramananthan, Ubuntu Core App Developer
  • Joey-Elijah Sneddon, OMG!Ubuntu editor

The judges for the Chinese apps are:

  1. Shuduo Sang?Software Engineer in Canonical PES
  2. Joey Chan, Ubuntu Core App Developer
  3. Jack Yu, Ubuntu Kylin Lead/Ubuntu Member

The jury will judge applications according to the following criteria:

  • General Interest – apps that are of more interest to general phone users will be scored higher. We recommend identifying what most phone users want to see, and identifying gaps that your app could fill.
  • Convergence – apps that have a convergent layout that expands to dedicated tablet mode or optionally run well on the desktop will also be scored higher.
  • Features – a wide range of useful and interesting features.
  • Quality – a high quality, stable, and bug-free application experience.
  • Design – your app should harness the Ubuntu Design Guidelines so it looks, feels, and operates like an Ubuntu app.
  • Awareness / Promotion – we will award extra points to those of you who blog, tweet, facebook, Google+, reddit, and otherwise share updates and information about your app as it progresses.
  • Chinese culture – apps optionally submitted in the China category will be reviewed with the same criteria above, plus their relevance to Chinese users of the app. This can be by providing access to Chinese services, being related to Chinese culture or being generally useful to somebody in the People’s Republic of China.

Learn how to write Ubuntu apps

To make it easier for you to get started with writing apps for Ubuntu on the phone and tablets, we’ve set up a week packed with video streaming tutorials where experts from the Ubuntu community will teach you how to use Ubuntu platform technologies to write apps.

Join the Ubuntu App Developer Week! >

If you cannot join, review our app developer documentation.

How to participate

If you are not a programmer and want to share some ideas for cool apps, be sure to add and vote apps on our reddit page.

The contest is free to enter and open to everyone.

The six week period starts on the Wed 26th February and runs until Wed 9th April 2014!

Enter the Ubuntu App Showdown >

Read more
Stéphane Graber

After 10 months of work, over a thousand contributions by 60 or so contributors, we’ve finally released LXC 1.0!

You may have followed my earlier series of blog post on LXC 1.0, well, everything I described in there is now available in a stable release which we intend to support for a long time.

In the immediate future, I expect most of LXC upstream will focus on dealing with the bug reports and questions which will no doubt follow this release, then we’ll have to discuss what our goals for LXC 1.1 are and setup a longer term roadmap to LXC 2.0.

But right now, I’m just happy to have LXC 1.0 out, get a lot more users to play with new technologies like unprivileged containers and play with our API in the various languages we support.

Thanks to everyone who made this possible!

Read more
Stéphane Graber

This is post 10 out of 10 in the LXC 1.0 blog post series.

Logging

Most LXC commands take two options:

  • -o, –logfile=FILE: Location of the logfile (defaults to stder)
  • -l, –logpriority=LEVEL: Log priority (defaults to ERROR)

The valid log priorities are:

  • FATAL
  • ALERT
  • CRIT
  • ERROR
  • WARN
  • NOTICE
  • INFO
  • DEBUG
  • TRACE

FATAL, ALERT and CRIT are mostly unused at this time, ERROR is pretty common and so are the others except for TRACE. If you want to see all possible log entries, set the log priority to TRACE.

There are also two matching configuration options which you can put in your container’s configuration:

  • lxc.logfile
  • lxc.loglevel

They behave exactly like their command like counterparts. However note that if the command line options are passed, any value set in the configuration will be ignored and instead will be overridden by those passed by the user.

When reporting a bug against LXC, it’s usually a good idea to attach a log of the container’s action with a logpriority of at least DEBUG.

API debugging

When debugging a problem using the API it’s often a good idea to try and re-implement the failing bit of code in C using liblxc directly, that helps get the binding out of the way and usually leads to cleaner stack traces and easier bug reports.

It’s also useful to set lxc.loglevel to DEBUG using set_config_item on your container so you can get a log of what LXC is doing.

Testing

Before digging to deep into an issue with the code you are working on, it’s usually a good idea to make sure that LXC itself is behaving as it should on your machine.

To check that, run “lxc-checkconfig” and look for any missing kernel feature, if all looks good, then install (or build) the tests. In Ubuntu, those are shipped in a separate “lxc-tests” package. Most of those tests are expecting to be run on an Ubuntu system (patches welcome…) but should do fine on any distro that’s compatible with the lxc-ubuntu template.

Run each of the lxc-test-* binaries as root and note any failure. Note that it’s possible that they leave some cruft behind on failure, if so, please cleanup any of those leftover containers before processing to the next test as unfortunately that cruft may cause failure by itself.

Reporting bugs

The primary LXC bug tracker is available at: https://github.com/lxc/lxc/issues

You may also report bugs directly through the distributions (though it’s often preferred to still file an upstream bug and then link the two), for example for Ubuntu, LXC bugs are tracked here: https://bugs.launchpad.net/ubuntu/+source/lxc

If you’ve already done some work tracking down the bug, you may also directly contact us on our mailing-list (see below).

Sending patches

We always welcome contributions and are very happy to have such an active development community around LXC (Over 60 people contributed to LXC 1.0). We don’t have many rules governing contributions, we just ask that your contributions be properly licensed and that you own the copyright on the code you are sending us (and indicate so by putting a Signed-off-by line in your commit).

As for the licensing, anything which ends up in the library (liblxc) or its bindings must be LGPLv2.1+ or compatible with it and not adding any additional restriction. Standalone binaries and scripts can either be LGLPv2.1+ (the project default) or GPLv2. If unsure, LGPLv2.1+ is usually a safe bet for any new file in LXC.

Patches may be sent using two different ways:

  • Inline to the lxc-devel@lists.linuxcontainers.org (using git send-email or similar)
  • Using a pull request on github (we will then grab the .patch URL and treat it as if they were e-mails sent to our list)

Getting in touch with us

The primary way of contacting the upstream LXC team is through our mailing-lists. We have two, one for LXC development and one for LXC users questions:

For more real-time discussion, you can also find a lot of LXC users and most of the developers in #lxcontainers on irc.freenode.net.

Final notes

So this is my final blog post before LXC 1.0 is finally released. We’re currently at rc3 with an rc4 coming a bit later today and a final release scheduled for tomorrow evening or Thursday morning.

I hope you have enjoyed this blog post series and that it’ll be a useful reference for people deploying LXC 1.0.

Read more
Stéphane Graber

Ubuntu Touch images

For those not yet familiar with this, Ubuntu Touch systems are setup using a read-only root filesystem on top of which writable paths are mounted using bind-mounts from persistent or ephemeral storage.

The default update mechanism is therefore image based. We build new images on our build infrastructure, generate diffs between images and publish the result on the public server.

Each image is made of a bunch of xz compreseed tarballs, the actual number of tarballs may vary, so can their name. At the end of the line, the upgrader simply mounts the partitions and unpacks the tarball in the order it’s given them. It has a list of files to remove and the rest of the files are simply unpacked on top of the existing system.

Delta images only contain the files that are different from the previous image, full images contain them all. Partition images are stored in binary format in a partitions/ directory which the upgrader checks and flashes automatically.

The current list of tarballs we tend to use for the official images are:

  • ubuntu: Ubuntu root filesystem (common to all devices)
  • device: Device specific data (partition images and Android image)
  • custom: Customization tarball (applied on top of the root filesystem in /custom)
  • version: Channel/device/build metadata

For more details on how this all works, I’d recommend reading our wiki pages which act as the go-to specification for the server, clients and upgrader.

Running a server

There are a lot of reasons why you may want to run your own system-image server but the main ones seem to be:

  • Supporting your own Ubuntu Touch port with over-the-air updates
  • Publishing your own customized version of an official image
  • QA infrastructure for Ubuntu Touch images
  • Using it as an internal buffer/mirror for your devices

Up until now, doing this was pretty tricky as there wasn’t an easy way to import files from the public system-image server into a local one nor was there a simple way to replace the official GPG keys by your own (which would result in your updates to be considered invalid).

This was finally resolved on Friday when I landed the code for a few new file generators in the main system-image server branch.

It’s now reasonably easy to setup your own server, have it mirror some bits from the main public server, swap GPG keys and include your local tarballs.

Before I start with step by step instructions, please note that due to bug 1278589, you need a valid SSL certificate (https) on your server. This may be a problem to some porters who don’t have a separate IP for their server or can’t afford an SSL certificate. We plan on having this resolved in the system-image client soon.

Installing your server

Those instructions have been tried on a clean Ubuntu 13.10 cloud instance, it assumes that you are running them as an “ubuntu” user with “/home/ubuntu” as its home directory.

Install some required packages:

sudo apt-get install -y bzr abootimg android-tools-fsutils \
    python-gnupg fakeroot pxz pep8 pyflakes python-mock apache2

You’ll need a fair amount of available entropy to generate all the keys used by the test suite and production server. If you are doing this for testing only and don’t care much about getting strong keys, you may want to install “haveged” too.

Then setup the web server:

sudo adduser $USER www-data
sudo chgrp www-data /var/www/
sudo chmod g+rwX /var/www/
sudo rm -f /var/www/index.html
newgroups www-data

That being done, now let’s grab the server code, generate some keys and run the testsuite:

bzr branch lp:~ubuntu-system-image/ubuntu-system-image/server system-image
cd system-image
tests/generate-keys
tests/run
cp -R tests/keys/*/ secret/gpg/keys/
bin/generate-keyrings

Now all you need is some configuration. We’ll define a single “test” channel which will contain a single device “mako” (nexus4). It’ll mirror both the ubuntu and device tarball from the main public server (using the trusty-proposed channel over there), repack the device tarball to swap the GPG keys, then download a customization tarball from an http server, stack a keyring tarball (overriding the keys in the ubuntu tarball) and finally generating a version tarball. This channel will contain up to 15 images and will start at image ID “1”.

Doing all this can be done with that bit of configuration (you’ll need to change your server’s FQDN accordingly) in etc/config:

[global]
base_path = /home/ubuntu/system-image/
channels = test
gpg_key_path = secret/gpg/keys/
gpg_keyring_path = secret/gpg/keyrings/
publish_path = /var/www/
state_path = state/
public_fqdn = system-image.test.com
public_http_port = 80
public_https_port = 443

[channel_test]
type = auto
versionbase = 1
fullcount = 15
files = ubuntu, device, custom-savilerow, keyring, version
file_ubuntu = remote-system-image;https://system-image.ubuntu.com;trusty-proposed;ubuntu
file_device = remote-system-image;https://system-image.ubuntu.com;trusty-proposed;device;keyring=archive-master
file_custom-savilerow = http;https://jenkins.qa.ubuntu.com/job/savilerow-trusty/lastSuccessfulBuild/artifact/build/custom.tar.xz;name=custom-savilerow,monitor=https://jenkins.qa.ubuntu.com/job/savilerow-trusty/lastSuccessfulBuild/artifact/build/build_number
file_keyring = keyring;archive-master
file_version = version

Lastly we need to actual create the channel and device in the server, this is done by calling “bin/si-shell” and then doing:

pub.create_channel("test")
pub.create_device("test", "mako")
for keyring in ("archive-master", "image-master", "image-signing", "blacklist"):
    pub.publish_keyring(keyring)

And that’s it! Your server is now ready to use.
To generate your first image, simply run “bin/import-images”.
This will take a while as it’ll need to download files from those external servers, repack some bits but once it’s done, you’ll have a new image published.

You’ll probably want to run that command from cron every few minutes so that whenever any of the referenced files change a new image is generated and published (deltas will also be automatically generated).

To look at the result of the above, I have setup a server here: https://phablet.stgraber.org

To use that server, you’d flash using: phablet-flash ubuntu-system –alternate-server phablet.stgraber.org –channel test

Read more
Stéphane Graber

This is post 9 out of 10 in the LXC 1.0 blog post series.

Some starting notes

This post uses unprivileged containers, this isn’t an hard requirement but makes a lot of sense for GUI applications. Besides, since you followed the whole series, you have those setup anyway, right?

I’ll be using Google Chrome with the Google Talk and Adobe Flash plugins as “hostile” piece of software that I do not wish to allow to run directly on my machine.
Here are a few reasons why:

  • Those are binaries I don’t have source for.
    (That alone is usually enough for me to put an application in a container)
  • Comes from an external (non-Ubuntu) repository which may then push anything they wish to my system.
    (Could be restricted with careful apt pining)
  • Installs a daily cronjob which will re-add said repository and GPG keys should I for some reason choose to remove them.
    (Apparently done to have the repository re-added after dist-upgrades)
  • Uses a setuid wrapper to setup their sandbox. Understandable as they switch namespaces and user namespaces aren’t widespread yet.
    (This can be worked around by turning off the sandbox. The code for the sandbox is also available from the chromium project, though there’s no proof that the binary build doesn’t have anything added to it)
  • I actually need to use those piece of software because of my work environment and because the web hasn’t entirely moved away from flash yet…

While what I’ll be describing below is a huge step up for security in my opinion, it’s still not ideal and a few compromises have to be made to make those software even work. Those are basically access to:

  • pulseaudio: possibly recording you
  • X11: possibly doing key logging or taking pictures of your screen
  • dri/snd devices: can’t think of anything that’s not already covered by the first two, but I’m sure someone with a better imagination than mine will come up with something

But there’s only so much you can do while still having the cool features, so the best you can do is make sure never to run the container while doing sensitive work.

Running Google chrome in a container

So now to the actual fun. The plan is rather simple, I want a simple container, running a stable, well supported, version of Ubuntu, in there I’ll install Google Chrome and any plugin I need, then integrate it with my desktop.

First of all, let’s get ourselves an Ubuntu 12.04 i386 container as that’s pretty well supported by most ISVs:

lxc-create -t download -n precise-gui -- -d ubuntu -r precise -a i386

Let’s tweak the configuration a bit by adding the following to ~/.local/share/lxc/precise-gui/config (replacing USERNAME appropriately):

lxc.mount.entry = /dev/dri dev/dri none bind,optional,create=dir
lxc.mount.entry = /dev/snd dev/snd none bind,optional,create=dir
lxc.mount.entry = /tmp/.X11-unix tmp/.X11-unix none bind,optional,create=dir
lxc.mount.entry = /dev/video0 dev/video0 none bind,optional,create=file

lxc.hook.pre-start = /home/USERNAME/.local/share/lxc/precise-gui/setup-pulse.sh

Still in that same config file, you’ll have to replace your existing (or similar):

lxc.id_map = u 0 100000 65536
lxc.id_map = g 0 100000 65536

By something like (this assume your user’s uid/gid is 1000/1000):

lxc.id_map = u 0 100000 1000
lxc.id_map = g 0 100000 1000
lxc.id_map = u 1000 1000 1
lxc.id_map = g 1000 1000 1
lxc.id_map = u 1001 101001 64535
lxc.id_map = g 1001 101001 64535

So those mappings basically mean that your container has 65536 uids and gids mapped to it, starting at 0 up to 65535 in the container. Those are mapped to host ids 100000 to 165535 with one exception, uid and gid 1000 isn’t translated. That trick is needed so that your user in the container can access the X socket, pulseaudio socket and DRI/snd devices just as your own user can (this saves us a whole lot of configuration on the host).

Now that we’re done with the config file, let’s create that setup-pulse.sh script:

#!/bin/sh
PULSE_PATH=$LXC_ROOTFS_PATH/home/ubuntu/.pulse_socket

if [ ! -e "$PULSE_PATH" ] || [ -z "$(lsof -n $PULSE_PATH 2>&1)" ]; then
    pactl load-module module-native-protocol-unix auth-anonymous=1 \
        socket=$PULSE_PATH
fi

Make sure the file is executable or LXC will ignore it!
That script is fairly simple, it’ll simply tell pulseaudio on the host to bind /home/ubuntu/.pulse_socket in the container, checking that it’s not already setup.

Finally, run the following to fix the permissions of your container’s home directory:

sudo chown -R 1000:1000 ~/.local/share/lxc/precise-gui/rootfs/home/ubuntu

And that’s all that’s needed in the LXC side. So let’s start the container and install Google Chrome and the Google Talk plugin in there:

lxc-start -n precise-gui -d
lxc-attach -n precise-gui -- umount /tmp/.X11-unix
lxc-attach -n precise-gui -- apt-get update
lxc-attach -n precise-gui -- apt-get dist-upgrade -y
lxc-attach -n precise-gui -- apt-get install wget ubuntu-artwork dmz-cursor-theme ca-certificates pulseaudio -y
lxc-attach -n precise-gui -- wget https://dl.google.com/linux/direct/google-chrome-stable_current_i386.deb -O /tmp/chrome.deb
lxc-attach -n precise-gui -- wget https://dl.google.com/linux/direct/google-talkplugin_current_i386.deb -O /tmp/talk.deb
lxc-attach -n precise-gui -- dpkg -i /tmp/chrome.deb /tmp/talk.deb
lxc-attach -n precise-gui -- apt-get -f install -y
lxc-attach -n precise-gui -- sudo -u ubuntu mkdir -p /home/ubuntu/.pulse/
echo "disable-shm=yes" | lxc-attach -n precise-gui -- sudo -u ubuntu tee /home/ubuntu/.pulse/client.conf
lxc-stop -n precise-gui

At this point, everything you need is installed in the container.
To make your life easier, create the following launcher script, let’s call it “start-chrome” and put it in the container’s configuration directory (next to config and setup-pulse.sh):

#!/bin/sh
CONTAINER=precise-gui
CMD_LINE="google-chrome --disable-setuid-sandbox $*"

STARTED=false

if ! lxc-wait -n $CONTAINER -s RUNNING -t 0; then
    lxc-start -n $CONTAINER -d
    lxc-wait -n $CONTAINER -s RUNNING
    STARTED=true
fi

PULSE_SOCKET=/home/ubuntu/.pulse_socket

lxc-attach --clear-env -n $CONTAINER -- sudo -u ubuntu -i \
    env DISPLAY=$DISPLAY PULSE_SERVER=$PULSE_SOCKET $CMD_LINE

if [ "$STARTED" = "true" ]; then
    lxc-stop -n $CONTAINER -t 10
fi

Make sure the script is executable or the next step won’t work. This script will check if the container is running, if not, start it (and remember it did), then spawn google-chrome with the right environment set (and disabling its built-in sandbox as for some obscure reasons, it dislikes user namespaces), once google-chrome exits, the container is stopped.

To make things shinier, you may now also create ~/.local/share/applications/google-chrome.desktop containing:

[Desktop Entry]
Version=1.0
Name=Google Chrome
Comment=Access the Internet
Exec=/home/USERNAME/.local/share/lxc/precise-gui/start-chrome %U
Icon=/home/USERNAME/.local/share/lxc/precise-gui/rootfs/opt/google/chrome/product_logo_256.png
Type=Application
Categories=Network;WebBrowser;

Don’t forget to replace USERNAME to your own username so that both paths are valid.

And that’s it! You should now find a Google Chrome icon somewhere in your desktop environment (menu, dash, whatever…). Clicking on it will start Chrome which can be used pretty much as usual, when closed, the container will shutdown.
You may want to setup extra symlinks or bind-mount to make it easier to access things like the Downloads folder but that really depends on what you’re using the container for.

Chrome running in LXC

Obviously, the same process can be used for many different piece of software.

Skype

Quite a few people have contacted me asking about running Skype in that same container. I won’t give you a whole step by step guide as the one for Chrome cover 99% of what you need to do for Skype.

However there are two tricks you need to be aware of to get Skype to work properly:

  • Set “QT_X11_NO_MITSHM” to “1”
    (otherwise you get a blank window as it tries to use shared memory)
  • Set “GNOME_DESKTOP_SESSION_ID” to “this-is-deprecated”
    (otherwise you get an ugly Qt theme)

Those two should be added after the “env” in the launcher script you’ll write for Skype.

Apparently on some NVidia system, you may also need to set an additional environment variable (possibly useful not only for Skype):
LD_PRELOAD=/usr/lib/i386-linux-gnu/mesa/libGL.so.1

Steam

And finally, yet another commonly asked one, Steam.

That one actually doesn’t require anything extra in its environment, just grab the .deb, install it in the container, run an “apt-get -f install” to install any remaining dependency, create a launcher script and .desktop and you’re done.
I’ve been happily playing a few games (thanks to Valve giving those to all Ubuntu and Debian developers) without any problem so far.

Read more