Canonical Voices

Posts tagged with 'planet ubuntu'

Stéphane Graber

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

More templates

So at this point you should have a working Ubuntu container that’s called “p1″ and was created using the default template called simply enough “ubuntu”.

But LXC supports much more than just standard Ubuntu. In fact, in current upstream git (and daily PPA), we support Alpine Linux, Alt Linux, Arch Linux, busybox, CentOS, Cirros, Debian, Fedora, OpenMandriva, OpenSUSE, Oracle, Plamo, sshd, Ubuntu Cloud and Ubuntu.

All of those can usually be found in /usr/share/lxc/templates. They also all typically have extra advanced options which you can get to by passing “--help” after the “lxc-create” call (the “--” is required to split “lxc-create” options from the template’s).

Writing extra templates isn’t too difficult, they basically are executables (all shell scripts but that’s not a requirement) which take a set of standard arguments and are expected to produce a working rootfs in the path that’s passed to them.

One thing to be aware of is that due to missing tools not all distros can be bootstrapped on all distros. It’s usually best to just try. We’re always interested in making those work on more distros even if that means using some rather weird tricks (like is done in the fedora template) so if you have a specific combination which doesn’t work at the moment, patches are definitely welcome!

Anyway, enough talking for now, let’s go ahead and create an Oracle Linux container that we’ll force to be 32bit.

sudo lxc-create -t oracle -n p2 -- -a i386

On most systems, this will initially fail, telling you to install the “rpm” package first which is needed for bootstrap reasons. So install it and “yum” and then try again.

After some time downloading RPMs, the container will be created, then it’s just a:

sudo lxc-start -n p2

And you’ll be greated by the Oracle Linux login prompt (root / root).

At that point since you started the container without passing “-d” to “lxc-start”, you’ll have to shut it down to get your shell back (you can’t detach from a container which wasn’t started initially in the background).

Now if you are wondering why Ubuntu has two templates. The Ubuntu template which I’ve been using so far does a local bootstrap using “debootstrap” basically building your container from scratch, whereas the Ubuntu Cloud template (ubuntu-cloud) downloads a pre-generated cloud image (identical to what you’d get on EC2 or other cloud services) and starts it. That image also includes cloud-init and supports the standard cloud metadata.

It’s a matter of personal choice which you like best. I personally have a local mirror so the “ubuntu” template is much faster for me and I also trust it more since I know everything was downloaded from the archive in front of me and assembled locally on my machine.

One last note on templates. Most of them use a local cache, so the initial bootstrap of a container for a given arch will be slow, any subsequent one will just be a local copy from the cache and will be much faster.

Auto-start

So what if you want to start a container automatically at boot time?

Well, that’s been supported for a long time in Ubuntu and other distros by using some init scripts and symlinks in /etc, but very recently (two days ago), this has now been implemented cleanly upstream.

So here’s how auto-started containers work nowadays:

As you may know, each container has a configuration file typically under
/var/lib/lxc/<container name>/config

That file is key = value with the list of valid keys being specified in lxc.conf(5).

The startup related values that are available are:

  • lxc.start.auto = 0 (disabled) or 1 (enabled)
  • lxc.start.delay = 0 (delay in second to wait after starting the container)
  • lxc.start.order = 0 (priority of the container, higher value means starts earlier)
  • lxc.group = group1,group2,group3,… (groups the container is a member of)

When your machine starts, an init script will ask “lxc-autostart” to start all containers of a given group (by default, all containers which aren’t in any) in the right order and waiting the specified time between them.

To illustrate that, edit /var/lib/lxc/p1/config and append those lines to the file:

lxc.start.auto = 1
lxc.group = ubuntu

And /var/lib/lxc/p2/config and append those lines:

lxc.start.auto = 1
lxc.start.delay = 5
lxc.start.order = 100

Doing that means that only the p2 container will be started at boot time (since only those without a group are by default), the order value won’t matter since it’s alone and the init script will wait 5s before moving on.

You may check what containers are automatically started using “lxc-ls”:

stgraber@castiana:~$ sudo lxc-ls --fancy
NAME    STATE    IPV4        IPV6                                    AUTOSTART     
---------------------------------------------------------------------------------
p1      RUNNING  10.0.3.128  2607:f2c0:f00f:2751:216:3eff:feb1:4c7f  YES (ubuntu)
p2      RUNNING  10.0.3.165  2607:f2c0:f00f:2751:216:3eff:fe3a:f1c1  YES

Now you can also manually play with those containers using the “lxc-autostart” command which let’s you start/stop/kill/reboot any container marked with lxc.start.auto=1.

For example, you could do:

sudo lxc-autostart -a

Which will start any container that has lxc.start.auto=1 (ignoring the lxc.group value) which in our case means it’ll first start p2 (because of order = 100), then wait 5s (because of delay = 5) and then start p1 and return immediately afterwards.

If at that point you want to reboot all containers that are in the “ubuntu” group, you may do:

sudo lxc-autostart -r -g ubuntu

You can also pass “-L” with any of those commands which will simply print which containers would be affected and what the delays would be but won’t actually do anything (useful to integrate with other scripts).

Freezing your containers

Sometimes containers may be running daemons that take time to shutdown or restart, yet you don’t want to run the container because you’re not actively using it at the time.

In such cases, “sudo lxc-freeze -n <container name>” can be used. That very simply freezes all the processes in the container so they won’t get any time allocated by the scheduler. However the processes will still exist and will still use whatever memory they used to.

Once you need the service again, just call “sudo lxc-unfreeze -n <container name>” and all the processes will be restarted.

Networking

As you may have noticed in the configuration file while you were setting the auto-start settings, LXC has a relatively flexible network configuration.
By default in Ubuntu we allocate one “veth” device per container which is bridged into a “lxcbr0″ bridge on the host on which we run a minimal dnsmasq dhcp server.

While that’s usually good enough for most people. You may want something slightly more complex, such as multiple network interfaces in the container or passing through physical network interfaces, … The details of all of those options are listed in lxc.conf(5) so I won’t repeat them here, however here’s a quick example of what can be done.

lxc.network.type = veth
lxc.network.hwaddr = 00:16:3e:3a:f1:c1
lxc.network.flags = up
lxc.network.link = lxcbr0
lxc.network.name = eth0

lxc.network.type = veth
lxc.network.link = virbr0
lxc.network.name = virt0

lxc.network.type = phys
lxc.network.link = eth2
lxc.network.name = eth1

With this setup my container will have 3 interfaces, eth0 will be the usual veth device in the lxcbr0 bridge, eth1 will be the host’s eth2 moved inside the container (it’ll disappear from the host while the container is running) and virt0 will be another veth device in the virbr0 bridge on the host.

Those last two interfaces don’t have a mac address or network flags set, so they’ll get a random mac address at boot time (non-persistent) and it’ll be up to the container to bring the link up.

Attach

Provided you are running a sufficiently recent kernel, that is 3.8 or higher, you may use the “lxc-attach” tool. It’s most basic feature is to give you a standard shell inside a running container:

sudo lxc-attach -n p1

You may also use it from scripts to run actions in the container, such as:

sudo lxc-attach -n p1 -- restart ssh

But it’s a lot more powerful than that. For example, take:

sudo lxc-attach -n p1 -e -s 'NETWORK|UTSNAME'

In that case, you’ll get a shell that says “root@p1″ (thanks to UTSNAME), running “ifconfig -a” from there will list the container’s network interfaces. But everything else will be that of the host. Also passing “-e” means that the cgroup, apparmor, … restrictions won’t apply to any processes started from that shell.

This can be very useful at times to spawn a software located on the host but inside the container’s network or pid namespace.

Passing devices to a running container

It’s great being able to enter and leave the container at will, but what about accessing some random devices on your host?

By default LXC will prevent any such access using the devices cgroup as a filtering mechanism. You could edit the container configuration to allow the right additional devices and then restart the container.

But for one-off things, there’s also a very convenient tool called “lxc-device”.
With it, you can simply do:

sudo lxc-device add -n p1 /dev/ttyUSB0 /dev/ttyS0

Which will add (mknod) /dev/ttyS0 in the container with the same type/major/minor as /dev/ttyUSB0 and then add the matching cgroup entry allowing access from the container.

The same tool also allows moving network devices from the host to within the container.

Read more
Stéphane Graber

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

So what’s LXC?

Most of you probably already know the answer to that one, but here it goes:

“LXC is a userspace interface for the Linux kernel containment features.
Through a powerful API and simple tools, it lets Linux users easily create and manage system or application containers.”

I’m one of the two upstream maintainers of LXC along with Serge Hallyn.
The project is quite actively developed with milestones every month and a stable release coming up in February. It’s so far been developed by 67 contributors from a wide range of backgrounds and companies.

The project is mostly developed on github: http://github.com/lxc
We have a website at: http://linuxcontainers.org
And mailing lists at: http://lists.linuxcontainers.org

LXC 1.0

So what’s that 1.0 release all about?

Well, simply put it’s going to be the first real stable release of LXC and the first we’ll be supporting for 5 years with bugfix releases. It’s also the one which will be included in Ubuntu 14.04 LTS to be released in April 2014.

It’s also going to come with a stable API and a set of bindings, quite a few interesting new features which will be detailed in the next few posts and support for a wide range of host and guest distributions (including Android).

How to get it?

I’m assuming most of you will be using Ubuntu. For the next few posts, I’ll myself be using the current upstream daily builds on Ubuntu 14.04 but we maintain daily builds on 12.04, 12.10, 13.04, 13.10 and 14.04, so if you want the latest upstream code, you can use our PPA.

Alternatively, LXC is also directly in Ubuntu and quite usable since Ubuntu 12.04 LTS. You can choose to use the version which comes with whatever release you are on, or you can use one the backported version we maintain.

If you want to build it yourself, you can do (not recommended when you can simply use the packages for your distribution):

git clone git://github.com/lxc/lxc
cd lxc
sh autogen.sh
# You will probably want to run the configure script with --help and then set the paths
./configure
make
sudo make install

What about that first container?

Oh right, that was actually the goal of this post wasn’t it?

Ok, so now that you have LXC installed, hopefully using the Ubuntu packages, it’s really as simple as:

# Create a "p1" container using the "ubuntu" template and the same version of Ubuntu
# and architecture as the host. Pass "-- --help" to list all available options.
sudo lxc-create -t ubuntu -n p1

# Start the container (in the background)
sudo lxc-start -n p1 -d

# Enter the container in one of those ways## Attach to the container's console (ctrl-a + q to detach)
sudo lxc-console -n p1

## Spawn bash directly in the container (bypassing the console login), requires a >= 3.8 kernel
sudo lxc-attach -n p1

## SSH into it
sudo lxc-info -n p1
ssh ubuntu@<ip from lxc-info>

# Stop the container in one of those ways
## Stop it from within
sudo poweroff

## Stop it cleanly from the outside
sudo lxc-stop -n p1

## Kill it from the outside
sudo lxc-stop -n p1 -k

And there you go, that’s your first container. You’ll note that everything usually just works on Ubuntu. Our kernels have support for all the features that LXC may use and our packages setup a bridge and a DHCP server that the containers will use by default.
All of that is obviously configurable and will be covered in the coming posts.

Read more
Stéphane Graber

So it’s almost the end of the year, I’ve got about 10 days of vacation for the holidays and a bit of time on my hands.

Since I’ve been doing quite a bit of work on LXC lately in prevision for the LXC 1.0 release early next year, I thought that it’d be a good use of some of that extra time to blog about the current state of LXC.

As a result, I’m preparing a series of 10 blog posts covering what I think are some of the most exciting features of LXC. The planned structure is:

While they are all titled LXC 1.0, most of the things I’ll be showing will work just as well on older LXC. However some of the features will need a very very recent version of LXC (as in, current upstream git). I’ll try to make that clear and will explain how to use our stable backports in Ubuntu or current upstream snapshots from our PPA.

I’ll be updating this first blog post with links to all of the posts in the series. So if you want to bookmark or refer to these, please use this post.

Read more
Michael Hall

Convergent File ManagerConvergence is going to be a major theme for Ubuntu 14.04, not just at the OS and Unity 8 levels, but also for the apps that run on it. The Core Apps, those apps that were developed by the community and included by default in the last release, are no exception to this. We want to make sure they all converge neatly and usefully on both a tablet and on the desktop. So once again we are asking for community design input, this time to take the existing application interfaces and extend them to new form factors.

How to submit your designs

We have detailed the kind of features we want to see for each of the Core Apps on a Convergence wiki page. If you have a convergence design idea you would like to submit, send it as a file attachment or link to it online in an email to design@canonical.com along with any additional notes, descriptions, or user stories.  The design team will be reviewing the submitted designs live on their bi-weekly Design Clinics (Dec 4th and Dec 18th) at 1400 UTC.  But before you submit your ideas, keep reading to see what they should include.

Extend what’s there

We don’t want to add too many features this cycle, there’s going to be enough work to do just building the convergence into the app.  Use the existing features and designs as your starting point, and re-imagine those same features and designs on a tablet or desktop.  Design new features or modify existing ones when it makes the experience better on a different form factor, but remember that we want the user to experience it as the same application across the board, so try and keep the differences to a minimum.

Form follows function

There’s more to a good design than just a good looking UI, especially when designing convergence.  Make sure that you take the user’s activity into account, plan out how they will access the different features of the app, make sure it’s both intuitive and simple.  The more detail you put into this the more likely you are to discover possible problems with your designs, or come up with better solutions that you had originally intended.

Think outside the screen

There is more to convergence that just a different screen size, and your designs should take that into consideration.  While it’s important to make good use of the added space in the UI, think about how the user is going to interact with it.  You hold a tablet differently than you do a phone, so make sure your designs work well there.

On the desktop you have even more to think about, when the user has a keyboard and mouse, but likely not a touch screen, you want to make sure the interface isn’t cumbersome.  Think about how scrolling will be different too, while it’s easy to swipe both vertically and horizontally on a phone or tablet, you usually only have a vertical scroll wheel on a desktop mouse.  But, you also have more precise control over a mouse pointer than you do with a finger-tip, so your interface should take advantage of that too.

Resources available to you

Now that you know what’s needed, here are some resources to help you.  Once again we have our community Balsamiq account available to anybody who wants to use it to create mockups (email me if you need an account).  I have created a new project for Core Apps Convergence that you can use to add your designs.  You can then submit links to your designs to the Design Team’s email above.  The Design Team has also provided a detailed Design Guide for Ubuntu SDK apps, including a section on Responsive Layouts that give some suggested patterns for different form factors.  You can also choose to use any tools you are comfortable with, as long as they Design Team and community developers can view it.

Read more
Michael Hall

At the same time that Ubuntu 13.10 was released, we also went live with a new API documentation website here on the Ubuntu Developer Portal. This website will slowly replace our previous static docs, which came in a variety of formats, with a single structured place for all of our developer APIs. This new site, backed by Python and Django, will let us make our API documentation more easily discoverable, more comprehensive, and more interactive over time.

Screenshot from 2013-10-17 09:54:41

We launched the site with only the documentation for the Ubuntu UI Toolkit, as well as upstream QtQuick components. But in the past week we’ve added on to that API documentation for the new Content Hub, which allows confined apps to request access to files (pictures, music, etc) stored outside of their sandbox, as well as a full new section of HTML5 API docs covering the visual components developed to match the look and feel of their Qt/QML counterparts.

Read more
David Planella

Today a major milestone in the history of Ubuntu and the mobile industry has been reached: we’re extremely proud to celebrate the release of Ubuntu 13.10, the free, open source operating system for smartphones, desktop and server.

A release for mobile developers

phone-apps-grid-extended-cut

As of today, Ubuntu is available on the desktop, on servers and on smartphones. Ubuntu’s first ever mobile edition provides an operating system with all applications phone users need for their day-to-day, in addition to a thriving app ecosystem and a platform application authors can target.

This is the first leap on the road to convergence and having an OS to rule all devices and form factors.

Native or web: your choice

The Ubuntu SDK enables developers to easily create applications that make use of the full capabilities of the platform and integrate naturally with the OS. It contains Qt Creator, a full-fledged IDE with code-editing, debugging and device deployment features; the UI toolkit, with a set of widgets and components to be used as building blocks for Ubuntu apps; and detailed developer documentation, including API docs and tutorials.

As part of the app developer story both native and web are first-class citizens. For the native approach, QML combined with JavaScript is the easiest way to write Ubuntu apps, while C++ is also fully supported. The SDK is powered by the widely used Qt framework.

For those writing or porting HTML5 applications, the SDK features various levels of support to cover all web developer needs:

  • HTML5 apps – use web technologies to write apps
  • HTML5 Cordova apps – use web technologies to access native device functions such as camera and sensors
  • Webapps – integrate a website with Ubuntu and launch it as an app

The SDK also uses the full capabilities of OpenGL ES graphics acceleration, providing high-quality 3D rendering for the most demanding games.

Start writing an Ubuntu app ›

From concept to millions of users

With the Ubuntu Software Store Beta, the final big piece of infrastructure that completes the development workflow is now in place. Ubuntu now assists developers throughout the whole app lifecycle: from idea to implementation to publishing and to updates.

Publish your app in Ubuntu ›

Community-driven core apps

app_shocase-700px

As a testament to the stunning result that can be achieved combining a vibrant community of developers, a team of designers and the Ubuntu SDK, we’re also thrilled to announce the availability of the 12 core apps for the phone. Core applications have been designed from the ground up to provide the basic functionality a user needs for their every day, and more. They include:

  • Daily apps: Music, Clock, Weather, Calendar, RSS reader, Calculator
  • Games: Sudoku, Dropping Letters
  • Developer tools: Terminal, File Manager

These apps complement the offer of pre-installed software on the phone, including Dialer, Messaging, Browser, Camera, Gallery, Notes, Contacts and a set of webapps such as Twitter and Facebook.

Core apps have been entirely created by teams of community contributors and Canonical designers. Volunteer contributions have ranged from development, design, QA to bug reporting and support.

We’d like to thank all developers and any contributors who have in any way made the core apps happen. The work you’ve done in the last few months and the commitment you’ve shown to the project is just unbelievable, you rock!

Learn more about Ubuntu core apps ›

Industry-ready: differentiation without fragmentation

phone-naturally-neat-cut

Ubuntu is built for the phone industry. Equally suited for entry-level or high-end smartphones, it provides a powerful, yet lightweight platform with a clear and consistent user experience that can be easily customized for different operators.

At the core of Ubuntu’s design vision, scopes provide dedicated views to find, organize and show a variety of content types. Be it your contacts, your messages, pictures or online videos, dedicated scopes work for you transparently to bring you the best results when you do a search on your device.

Operators can customize the default experience by:

  • Prioritising which results are displayed first
  • Using the Apps scope to return results from multiple stores
  • Customising the home screen for their service, including integrated online payment support
  • Highlighting their own content on the default scopes

Info for operators and OEMs ›
Learn more about scopes ›

Developer.ubuntu.com 2.0

Developer-2-0

Coinciding with the release of the OS, a fully redesigned developer site has been unveiled. The Ubuntu developer site now provides a hub to all resources and information needed to develop and publish different types content for the Ubuntu platform, including:

  • Apps – how to create applications for Ubuntu
  • Scopes – how to create scopes to customize the content shown to users
  • Cloud – how to create charms for Juju cloud deployments
  • Web – how to create webapps to integrate websites into Ubuntu

Each development area has been expanded to add technology overviews, tutorials, development recipes and extensive API documentation to make the development experience easier – and fun!

Go to the Ubuntu developer site ›

Today it’s time to celebrate our first mobile release, enjoy the amazing work that has been done in the past six months and start looking at the next steps to bring Ubuntu to the masses. And while talking about celebration, which better way than actually creating an app for Ubuntu?

Install Ubuntu on your phone

Read more
Michael Hall

App Showdown Winners

The judging is finished and the scores are in, we now have the winners of this year’s Ubuntu App Showdown!  Over the course of six weeks, and using a beta release of the new 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 new Click store 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!

Original Apps #1: Karma Machine

karma_machine_subredditkarma_machine_contentkarma_machine_commentsKarma Machine is wonderful app for browsing Reddit, and what geek wouldn’t want a good Reddit app?  Developed by Brian Robles, Karma Machine has nearly everything you could want in a Reddit app, and takes advantage of touch gestures to make it easy to upvote and downvote both articles and comments.  It even supports user accounts so you can see your favorite subreddits easily.  On top of it’s functionality, Karma Machine is also visually appealing, with a good mix of animations, overlays and overall use of colors and layouts.  It is simply one of the best Reddit clients on any platform (having written my own Reddit client, that’s saying something!), and having it as an original Ubuntu app makes it a valuable addition to our ecosystem.  With all that, it’s little wonder that Karma Machine was tied for the top spot on the judges list!

Original Apps #1: Saucy Bacon

saucy_bacon_searchsaucy_bacon_toolbarsaucy_bacon_editSomething for the foodies among us, Saucy Bacon is a great way to find and manage recipes for your favorite dish. Backed by food2fork.com, this app lets you search for recipes from all over the web.  You can save them for future reference, and mark your favorites for easy access over and over again.  And since any serious cook is going to modify a recipe to their own tastes, Saucy Bacon even lets you edit recipes downloaded from somewhere else.  You can of course add your own unique recipe to the database as well.  It even lets you add photos to the recipe card directly from the camera, showing off some nice integration with the Ubuntu SDK’s sensor APIs and hardware capabilities.  All of this mouth-watering goodness secured developer Giulio Collura’s Saucy Bacon app a tie for the #1 stop for original Ubuntu apps in our contest.

Ported Apps #1: Snake

snake_introsnake_play2snake_play

The game Snake has taken many forms on many platforms throughout the years.  It’s combination of simple rules and every-increasing difficulty has made it a popular way to kill time for decades.  Developer Brad Wells has taken this classic game from Nokia’s discontinued Meego/Harmattan mobile OS, which used a slightly older version of Qt for app development, and updated it to work on Ubuntu using the Ubuntu SDK components.  Meego had a large number of high quality apps written for it back in it’s day, and this game proves that Ubuntu for phones and tablets can give those apps a new lease on life.

Go and get them all!

The 2013 Ubuntu App Showdown was an opportunity for us to put the new Ubuntu SDK beta through some real-world testing, and kick off a new app ecosystem for Ubuntu.  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.

In addition to being some of the first users of the Ubuntu SDK, the app developers were also among the first to use the new Click packaging format and tools as well as the new app upload process that we’ve been working on to reduce review times and ease the process of publishing apps.  The fact that all of the submitted apps have already been published in the new app store is a huge testament to the success of that work, and to the engineers involved in designing and delivering it.

Once again congratulations to Brian Robles, Giulio Collura and Brad Wells, and a big thank you to everybody who participated or helped those who participated, and all of the engineers who have worked on building the Ubuntu SDK, Click tools and app store.  And if you have a supported device, you should try out the latest Ubuntu images, and try these and the many other apps already available for it.  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!

Read more
David Planella

Mostly everything is ready for the judges to start reviewing the Ubuntu App Showdown apps next week, exciting times ahead!

roll-dice

As of now, all applications that were submitted for the App Showdown contest have been reviewed and submitted to the Software Store. They can also be installed and run from the Dash on an Ubuntu phone, just two taps away.

We will be doing a final round of testing on Monday to double-check all apps indeed install and run flawlessly. We will then set up the review forms for the judges and also publish the final list of contest apps.

Thanks to everyone who has participated in the contest. Good luck with the judging, you all rock!

?Roll of the dice? by Katie Harbath under a Creative Commons Attribution 2.0.

Read more
Stéphane Graber

After over 3 months of development and experimentation, I’m now glad to announce that the system images are now the recommended way to deploy and update the 4 supported Ubuntu Touch devices, maguro (Galaxy Nexus), mako (Nexus 4), grouper (Nexus 7) and manta (Nexus 10).

Anyone using one of those devices can choose to switch to the new images using: phablet-flash ubuntu-system

Once that’s done, further updates will be pushed over the air and can be applied through the Updates panel in the System Settings.

Ubuntu Touch Upgrader

You should be getting a new update every few days, whenever an image is deemed of sufficient quality for public consumption. Note that the downloader UI doesn’t yet show progress, so if it doesn’t do anything, it doesn’t mean it’s not working.

Those new images are read-only except for a few selected files and for the user profile and data, this is a base requirement for the delta updates to work properly.
However if the work you’re doing requires installation of extra non-click packages, such as developing on your device using the SDK, you have two options:

  1. Stick to the current flipped images which we’ll continue to generate for the foreseeable future.
  2. Use the experimental writable flag by doing touch /userdata/.writable_image and rebooting your device.
    This will make / writable again, however beware that applying image updates on such a system will lead to unknown results, so if you do choose to use this flag, you’ll have to manually update your device using apt-get (and possibly have to unmount/remount some of the bind-mounted files depending on which package needs to be updated).

From now on, the QA testing effort will focus on those new images rather than the standard flipped ones. I’d also highly recommend to all our application developers to at least test their apps with those images and report any bug that they see in #ubuntu-touch (irc.freenode.net).

 

Read more
Michael Hall

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

phone-naturally-neat

The winners of this contest will each receive an LG Nexus 4 phone running Ubuntu Touch with their application pre-installed. Furthermore, each of the winners will have an opportunity to have their app included in the default Ubuntu install images for phones and tablets.

All valid entries will also become available for install on Ubuntu Touch devices from the Apps lens in the Dash, using the new Click packages and MyApps submission process.

Judges

The jury will be composed by a team of five judges:

  • Jono Bacon, Ubuntu Community Manager
  • Joey-Elijah Sneddon, writer and editor-in-chief of OMG!Ubuntu
  • Lisette Slegers, User Experience Designer at Canonical
  • Nekhelesh Ramananthan, Ubuntu Touch Core App developer
  • Bill Filler, Engineering Manager for the Phone & Tablet App Team

Review criteria

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.
  • 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+, and otherwise share updates and information about your app as it progress.

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.

How To Enter

The contest is free to enter and open to everyone.

The six week period starts on the Wed 7th August 2013!

Enter the Ubuntu App Showdown

Read more
Steve George

Today we are pleased to announce the beta release of the Ubuntu SDK! The SDK is the toolkit that will power Ubuntu’s convergence revolution, giving you one platform and one API for all Ubuntu form factors. This lets you write your app one time, in one way, and it will work everywhere.  You can read the full Ubuntu SDK Beta announcement here.

For the developers who are already writing apps using the Ubuntu SDK most of the beta’s features will already be known, as they have been landing in the daily releases as they become finished. Here’s a list of the features that have been added since the alpha:

  • Cordova Ubuntu HTML5 app template – leverage the Apache Cordova APIs to write Ubuntu apps with web technologies: HTML, JavaScript and CSS. Write your first HTML5 with the Cordova Ubuntu tutorial.
  • Ubuntu SDK HTML5 theme – a companion to all HTML5 apps: stylesheets and JavaScript code to provide the same look and feel as native apps
  • Responsive layout – applications can now adopt a more natural layout depending on form factor (phone, tablet, desktop) and orientation
  • Scope template – Scopes enable operators to prioritise their content, to achieve differentiation without fragmentation. Now easier to create with a code template
  • Click packaging preview – initial implementation of the Click technology to distribute applications. Package your apps with Click at the press of a button
  • Theme engine improvements – a reworked theme engine to make it easier and more flexible to customise the look and feel of your app
  • Unified Actions API – define actions to be used across different Ubuntu technologies: the HUD, App Indicators, the Launcher, the Messaging Menu
  • U1DB integration – the SDK now provides a database API to easily synchronise documents between devices, using the Ubuntu One cloud

Some of the biggest news here is the Cordova support and HTML5 theme, which brings together our goal of making first class HTML5 app that look and feel like native apps.  Cordova support means that apps written using the PhoneGap framework can be easily ported to Ubuntu Touch, and the HTML5 themes, written largely by community developer Adnane Belmadiaf, will allow those apps to match the native SDK components in both the way they look as well as the way the user interacts with them.

The Responsive Layouts, which landed in the daily SDK packages weeks go, gives developers the ability to adjust their application’s GUI dynamically at runtime, depending on the amount of screen space available or any number of other variables.  This is one key to making convergent apps that can adapt to be useful on both small touch screens and large monitors with a keyboard and mouse.

We’ve also put out the first set of Click packaging tools, which will provide an easier way for developers to package and distribute their applications both on their own and through the Ubuntu Software Center.  There is still a lot more work to do before all of the Click infrastructure is in place, but for now developers can start trying getting a feel for it.

All of that and more is now available, so grab the latest SDK packages, read the QML and HTML5 app development tutorials, and get a head start building your convergent Ubuntu application today!

Read more
Stéphane Graber

Some of you may be aware that I along with Barry Warsaw and Ondrej Kubik have been working on image based upgrades for Ubuntu Touch.
This is going to be the official method to update any Ubuntu Touch devices. When using this system, the system will effectively be read-only with updates being downloaded over the air from a central server and applied in a consistent way across all devices.
Design details may be found at: http://wiki.ubuntu.com/ImageBasedUpgrades

After several months of careful design and implementation, we are now ready to get more testers. We are producing daily images for our 4 usual devices, Galaxy Nexus (maguro), Nexus 4 (mako), Nexus 7 (grouper) and Nexus 10 (manta).
At this point, only those devices are supported. We’ll soon be working with the various ports to see how to get them running on the new system.

So what’s working at this point?

  • Daily delta images are generated and published to
    http://system-image.ubuntu.com
  • We have a command line client tool (system-image-cli), an update server and an upgrader sitting in the recovery partition
  • The images usually boot and work

What doesn’t work?

  • Installing apps as the system partition is read-only and we’re waiting for click packages to be fully implemented in our images
  • Data migration. We haven’t implemented any migration script from the current images to the new ones, so switching will wipe everything from your device
  • Possibly quite some more features I haven’t tested yet

So how can I help?

You can help us if:

  • You have one of the 4 supported devices
  • You don’t use that device for your everyday work
  • You don’t need to install any extra apps
  • You don’t care about losing all your existing data
  • You’re usually able to use adb/fastboot to recover from any problems that might happen

If you don’t fit all of the above criteria, please stick to the current flipped images.
If you think you’re able to help us and want to test those new images, then here’s how to switch to them:

  1. Get the latest version of phablet-tools (>= 0.15+13.10.20130720.1-0ubuntu1)
  2. Boot your device
  3. Backup anything you may want to keep as it’ll be wiped clean!!!
  4. Run: phablet-flash --ubuntu-bootstrap
  5. Wait for it to finish downloading and installing
  6. You’re done!
  7. To apply any further update, use: adb shell system-image-cli
    (never use phablet-flash after the initial flash, updates can only be applied through system-image-cli!)

Reverting to standard flipped images:

  • Boot your device
  • Backup anything you may want to keep as it’ll be wiped clean!!!
  • Run: phablet-flash –bootstrap
  • Wait for it to finish downloading and installing
  • You’re back to standard flipped images!

To report bugs, the easiest is to go to:
https://launchpad.net/ubuntu-image-image/+filebug

We also all hangout in #ubuntu-touch on irc.freenode.net

 

Read more
Chris Johnston

I blogged a couple of weeks ago about the addition of the key performance indicators to the Ubuntu QA Dashboard. Since that post the QA team has been hard at work. We have added a bootspeed KPI to the dashboard, giving you a quick look at today vs yesterday. Another cool feature that has been added to the dashboard is the addition of bug information. Previously the dashboard just provided a link to the bug in Launchpad. The dashboard now fetches the bug data from Launchpad and displays it for you when the mouse hovers over the link. No more having to click through to see what the bug is that is causing issues!

The other big things that we have added goes back to one of the most basic types of testing that we do, the smoke test. We have added two new big things to smoke testing in the past few weeks. The first is that you are now able to see, from the dashboard, which tests pass and which fail. The new test case results page shows you quite a number of things about the testing that was done. You get the basics that you see on the other smoke testing pages (total tests, pass/fail/error count, pass rate, as well as image and machine information) but you now see a list of test cases and their return codes. As you see on the results page I linked to, there were 19 test cases that ran plus four setup type commands. The setup commands are shown since it is possible for them to error. Clicking on the individual command types will give you more details about the specific test to include the test suite and the command that was run. This is all valuable data in determining the quality of Ubuntu each day and easily pinpointing any problems that there are.

The final thing that has changed with smoke testing isn’t so much a change in the dashboard but an addition of a type of test. The QA team is now running daily Ubuntu Touch testing with autopilot. Adding the autopilot testing provides us with a new and much better grasp of the daily quality of Ubuntu. Previously, we relied on manual testing for much of the functional testing of Ubuntu to determine if things where the way that they were supposed to be. While the manual testing is still an important part of the overall indication of quality, the addition of the autopilot tests provides us with the ability to test many more things at a much higher frequency than relying completely on manual testing. The autopilot testing results show up in the smoke testing results each day after they run.

Read more
David Planella

Participate in the Ubuntu Core Apps Hack Days and get involved in developing the essential apps of Ubuntu on phones.

Starting this Wednesday, and during the next three weeks, we’re organizing a set of Hack Days inviting all interested contributors to bring Ubuntu Touch up another step closer to a production release and to ensure all core apps have reached a state of functionality to be used every day.

With the Core Apps Hack Days we’re targeting several objectives:

  • Get all core apps into a ‘dogfoodable’ state
  • Find and fix critical bugs in core apps and their dependencies
  • Identify, record and fix gaps in functionality
  • Get new developers involved in Core Apps and Ubuntu Touch development in general
  • Have fun with Ubuntu App Development!

How the Hack Days will work

  • The Ubuntu Core Apps Hack Days will be run as virtual hackfests on the #ubuntu-app-devel IRC channel on Freenode
  • Everyone is free to join the channel and encouraged to pick a task related to the set of goals to get core apps to a dogfoodable state
  • The development and testing tasks will be posted on the Hack Days wiki before each day’s hackfest starts
  • Ask Michael Hall (mhall119), David Planella (dpm) or Alan Pope (popey) on the channel for any help when you join (or just say hi!)

When

  • Starting on Wednesday 10th of July until Thursday 25th of July
  • From 9:00 UTC to 21:00 UTC
  • We’ll be following this schedule:
10 July Calendar
11 July Music
12 July Clock
15 July Calculator
16 July Weather
17 July Sudoku Touch
18 July RSS Reader
19 July File Manager
22 July Document Viewer
23 July Terminal
24 July Dropping Letters
25 July Stock Ticker

Join us!

Participating in the Hack Days is extremely easy: you just need a working Internet connection and access to IRC. We simply recommend some preparation beforehand:

  1. Learn how to get started developing core apps
  2. Join the #ubuntu-app-devel IRC channel on Freenode

Looking forward to seeing you next Wednesday at the Calendar hackfest!

Read more
Chris Jones

Help shaping up Ubuntu Touch by joining the core apps development teams

Community-driven apps that will power the next million phones

The Ubuntu Core Apps project started as an initiative born out of the initial Ubuntu Touch announcement, with a call to our community to participate in building the core set of applications which will be considered for shipping on Ubuntu phones.

With this, we started an exciting project that provides a unique opportunity for community members to create Free Software that could run on millions of handsets.

If you’re running Ubuntu Touch on a device, you can already see the results of the work our amazing volunteer developers have been doing: Calculator, Clock, Calendar, Weather, Terminal, File Manager… these apps and more are part of this project. Together with the Canonical designers and other community designers, we’ve also got a solid UX and design story for our applications.

In essence, each core app development team organizes their work and time in the way that works best for them, where the Canonical Community, Design and Engineering teams participate in several different areas:

  • Development infrastructure
  • Engineering management
  • Community mentorship and support
  • Design guidance

With this post I’d like to share how any developer can contribute to core apps and join the core dev teams. It’s not only an opportunity to shape up Ubuntu Touch, but also to work in a truly open development environment, with the best Open Source developers and designers out there!

Participating in the core apps project

Getting started to contributing to core apps is just a few minutes away. Here are some really easy steps for developers to get all set up.

Step 1: install all core apps

While some of the apps are already installed on the Ubuntu Touch image, you’ll be doing your development on the desktop. As part of the convergency story, core apps run equally well on phones, tablets or desktops, so the first step will be to get familiar with them and do some dogfooding.

  1. Open a terminal by pressing Ctrl+t and type the commands below, followed by Enter.
  2. Install the Ubuntu SDK: sudo add-apt-repository ppa:canonical-qt5-edgers/qt5-proper && sudo add-apt-repository ppa:ubuntu-sdk-team/ppa && sudo apt-get update && sudo apt-get install ubuntu-sdk
  3. Install the core apps: sudo add-apt-repository ppa:ubuntu-touch-coreapps-drivers/daily && sudo apt-get update && sudo apt-get install touch-coreapps

If you get stuck here, check out the SDK’s getting started page or ask on Ask Ubuntu

At this point you’ll be able to launch any of the core apps from the Dash.

  • Try opening the Dash clicking on the Ubuntu button in the Launcher, and type the first letters of each one of the apps to launch them. You should now be able to install:
    1. Calculator
    2. Calendar
    3. Clock
    4. Document viewer
    5. Dropping Letters
    6. Email
    7. File Manager
    8. Music
    9. RSS Reader
    10. Stock Ticker
    11. Sudoku
    12. Terminal
    13. Weather

Step 2: pick an app and find something to work on

Once you’ve road-tested all of the apps, you’ll have a good overview of their functionality, and where you think you can help. At this point, the best thing to do is to pick an app you’re interested in contributing to and find more about it:

  1. Go to the core apps overview page
  2. Click on the app you’re interested in. This will show you:
    • The public project where the app is being developed and where the code is hosted
    • The development team who is writing the app
    • The IRC channel where to discuss about the app’s development in real time
    • The blueprint we use to track the items to work on to implement the functional requirements
    • The burn-down chart we use to provide an overview of the status of the work

The best way to get started is to look at the existing code for the app. Here’s how:

  1. If you haven’t already, open a terminal with Ctrl+t and type this command to install the Bazaar revision control system: sudo apt-get install bzr
  2. Get a local copy of the code. Run this command, replacing ubuntu-clock-app by the app you’ve chosen. You’ll find the exact name to replace on the project section of the app’s detail page you opened earlier on: bzr branch lp:ubuntu-clock-app
  3. Start Qt Creator, the Ubuntu’s SDK IDE by clicking the Ubuntu button on the Launcher and typing “ubuntu sdk”
  4. In Qt Creator, press Ctrl+o to navigate to the location where you’ve just downloaded the code to and choose the .qmlproject file to open the app’s project in the IDE
  5. You can now study the code and launch it with either the Ctrl+r key combination or by pressing the big green “Run” button in Qt Creator

Before you start doing any changes in the code, you might want to get in touch with us to ensure no one is already working on what you’re intending to start on. Two good places to look at are:

Step 3: send a merge proposal with your contribution

In our distributed collaborative environment, where thousands of volunteers participate in Ubuntu from all over the world, we use a distributed version control system, Bazaar to manage the code’s revisions.  The code for all core apps is hosted in public projects in Launchpad, the online tool where we do all development.

You can easily do your changes to the code locally, publish them in a public branch and then send a request for the core app development teams to review and merge your code.

Check out the core apps development guide for the full details ›

Many ways to contribute

Although development is where you can make most of an impact at this point, there are many other ways to participate. You can:

Get in touch

We’d like to hear from you!. If you’ve got QML programming skills and would be interested in joining one of the core apps teams, get in touch with Michael Hall, David Planella or Alan Pope and we’ll gladly guide you in the first steps to becoming a core app dev.

You can also join any of the public IRC core app development meetings.

Looking forward to welcoming you in the core apps project!

Read more
Chris Johnston

Recently there has been a huge push for quality in Ubuntu. The goal is to have a stable and usable daily image of the development version of Ubuntu. To do this, the QA teams have spent a lot of time writing tests and manually testing everything in Ubuntu to ensure this high level quality. The QA Team is also developing the QA Dashboard to display all of the results from the testing that is being performed. The goal of the QA Dashboard is to start at high level overviews of testing results, and drill down to the small details that make up the overall big picture to give users and developers the ability to quickly and easily be able to identify that a problem exists, determine the cause of the problem and then fix the problem. Certain tests or types of tests are part of what we call ‘key performance indicators’ or KPI. These key performance indicators will give someone a very quick overview of the quality of today’s Ubuntu image.

Of the types of testing that is being done, the smoke testing is the most important one. Smoke testing is the most basic level of what to test. Essentially, does it install and after it installs does it work? If the image doesn’t install, none of the other testing can be completed. Infact, the daily builds part of cdimage now has a current and a pending. Current is the most recent image to pass the automated smoke testing whereas pending has not yet passed smoke testing. Because smoke test results are so important, it is now listed as a key performance indicator on the QA Dashboard. The Smoke Testing KPI shows each release that is currently being tested as well as the pass rate for the latest image of that release as well as which arches are being tests. It also will show you the number of bugs effecting a release by hovering over the pass rate.

The other test that is currently listed as a key performance indicator is Eventstat Wakeups testing. Essentially, this test is measuring the number of wakeup events each process has. The reason this is important is each wakeup prevents the kernel from going into low power mode, or idling. With the push towards cell phone and tablet devices battery life is a big deal. It is important that power consumption is properly measured and understood in order to make an operating system that performs well on these small factor devices which have a limited power source. The eventstat testing tells developers which processes are causing too many wakeups, allowing the developers to look into the root cause of all of the wakeup events. This KPI shows each machine that the tests are run on and the average number of total wakeups for all processes on that machine as well as the percent that it is higher or lower than the last image.

There are quite a few other types of power related tests that will hopefully soon be added as key performance indicators for the overall quality of Ubuntu. We have sort term goals of adding bootspeed testing results and memory usage as key performance indicators. If you have any questions about the QA Dashboard, feel free to jump into #ubuntu-quality on Freenode and ask away.

Read more
Chris Jones

One of the key aspects in developing the Ubuntu Touch core apps has been Quality Assurance. With that goal in mind, we’ve been adding functional tests to each and every one of the applications, using Autopilot.

We want to ensure our core apps are rock-solid, and we’d like to invite each of you who want to help make it happen to participate in the Autopilot Hackfest today. Here’s how:

  1. Join the #ubuntu-quality IRC channel ›
  2. Read the Autopilot tutorial ›
  3. Read Nick Skagg’s blog post for more details ›

Looking forward to the new autopilot tests for core apps. See you there!

Image: Autopilot Engaged CC-BY-SA by Mike Miley

Read more
David Planella

Time does fly, and we’re alread on the last day of the Ubuntu Developer Summit. Lots of content covered and still lots of interesting discussions to be had. We’re thrilled to bring you the summary on what’s on today on the App Development track.

Here’s the list of app development sessions for today at UDS:

Hope to see you there!

Read more
David Planella

After a very productive kick off, we’re back with the second day of the Ubuntu Developer Summit on the App Development track and the summary of sessions for today. Thank you everyone who participated in the sessions yesterday, either in hangouts or in IRC.

Here’s the list of app development sessions for today:

See you there!

Read more
David Planella

UDS, the Ubuntu Developer Summit, is here again, starting in just a few hours. A week packed with content that will define the plans for the new Ubuntu development cycle, and as usual, a with a full track dedicated to application development.

So for all of you interested in helping and being part of the effort of making Ubuntu a platform of choice for application developers, here’s a quick list with an overview of the sessions we’ve got in store for today.

The links in the list below will take you to the each session, ready to participate on the live hangout or on IRC. You can also check out the full UDS schedule.

So, without further ado, here’s the list of app development sessions for today:

Looking forward to seeing you there!

Read more