Canonical Voices

Posts tagged with 'ubuntu'

Michael Hall

Screenshot from 2014-03-20 21:57:06Yesterday we made a big step towards developing a native email client for Ubuntu, which uses the Ubuntu UI Toolkit and will converge between between phones, tablets and the desktop from the start.

We’re not starting from scratch though, we’re building on top of the incredible work done in the Trojitá project.  Trojitá provides a fast, light email client built with Qt, which made it ideal for using with Ubuntu. And yesterday, the first of that work was accepted into upstream, you can now build an Ubuntu Components front end to Trojitá.

None of this would have been possible without the help up Trojitá’s upstream developer Jan Kundrát, who patiently helped me learn the codebase, and also the basics of CMake and Git so that I could make this first contribution. It also wouldn’t have been possible without the existing work by Ken VanDine and Joseph Mills, who both worked on the build configuration and some initial QML code that I used. Thanks also to Dan Chapman for working together with me to get this contribution into shape and accepted upstream.

This is just the start, now comes the hard work of actually building the new UI with the Ubuntu UI Toolkit.  Andrea Del Sarto has provided some fantastic UI mockups already which we can use as a start, but there’s still a need for a more detailed visual and UX design.  If you want to be part of that work, I’ve documented how to get the code and how to contribute on the EmailClient wiki.  You can also join the next IRC meeting at 1400 UTC today in #ubuntu-touch-meeting on Freenode.

Read more
Timo Jyrinki

Qt 5.2.1 in Ubuntu

Ubuntu running Qt 5.2.1
Ubuntu running Qt 5.2.1
Qt 5.2.1 landed in Ubuntu 14.04 LTS last Friday, hooray! Making it into a drop-in replacement for Qt 5.0.2 was not trivial. Because of the qreal change, it was decided to rebuild everything against the new Qt, so it was an all at once approach involving roughly 130 source packages while the parts were moving constantly. The landing last week meant pushing to archives around three thousand binary packages - counting all six architectures - with the total size of closer to 10 gigabytes.

The new Qt brings performance and features to base future work on, and is a solid base for the future of Ubuntu. You may be interested in the release notes for Qt 5.2.0 and 5.2.1. The Ubuntu SDK got updated to Qt Creator 3.0.1 + new Ubuntu plugin at the same time, although updates for the older Ubuntu releases is a work in progress by the SDK Team.

How We Got Here

Throughout the last few months before the last joint push, I filed tens of tagged bugs. For most of that time I was interested only in build and unit test results, since even tracking those was quite a task. I offered simple fixes here and there myself, if I found out a fix.

I created automated Launchpad recipe builds for over 80 packages that rely on Qt 5 in Ubuntu. Meanwhile I also kept on updating the Qt packaging for its 20+ source packages and tried to stay on top of Debian's and upstream's changes.

Parallel to this work, some like the Unity 8 and UI Toolkit developers started experimenting with my Qt 5.2 PPA. It turned out the rewritten QML engine in Qt 5.2 - V4 - was not entirely stable when 5.2.0 was released, so they worked together with upstream on fixes. It was only after 5.2.1 release that it could be said that V4 worked well enough for Unity 8. Known issues like these slowed down the start of full-blown testing.

Then everything built, unit tests passed, most integration tests passed and things seemed mostly to work. We had automated autopilot integration testing runs. The apps team tested through all of the app store to find out whether some needed fixes - most were fine without changes. On top of the found autopilot test failures and other app issues, manual testing found a few more bugs

Sudoku
Some critical pieces of software
like Sudoku needed small fixing
Finally last Thursday it was decided to push Qt in, with a belief that the remaining issues had fixes in branches or not blockers. It turned out the real deployment of Qt revealed a couple of more problems, and some new issues were raised to be blockers, and not all of the believed fixes were really fixing the bugs. So it was not a complete success. Considering the complexity of the landing, it was an adequate accomplishment however.

Specific Issues

Throughout this exercise I bumped into more obstacles that I can remember, but those included:
  • Not all of the packages had seen updates for months or for example since last summer, and since I needed to rebuild everything I found out various problems that were not related to Qt 5.2
  • Unrelated changes during 14.04 development broke packages - like one wouldn't immediately think a gtkdoc update would break a package using Qt
  • Syncing packaging with Debian is GOOD, and the fixes from Debian were likewise excellent and needed, but some changes there had effects on our wide-spread Qt 5 usage, like the mkspecs directory move
  • xvfb used to run unit tests needed parameters updated in most packages because of OpenGL changes in Qt
  • arm64 and ppc64el were late to be added to the landing PPA. Fixing those archs up was quite a last minute effort and needed to continue after landing by the porters. On the plus side, with Qt 5.2's V4 working on those archs unlike Qt 5.0's V8 based Qt Declarative, a majority of Unity 8 dependencies are now already available for 64-bit ARM and PowerPC!
  • While Qt was being prepared the 100 other packages kept on changing, and I needed to keep on top of all of it, especially during the final landing phase that lasted for two weeks. During it, there was no total control of "locking" packages into Qt 5.2 transition, so for the 20+ manual uploads I simply needed to keep track of whether something changed in the distribution and accommodate.
One issue related to the last one was that some things needed were in progress at the time. There was no support for automated AP test running using a PPA. There was also no support on building images. If migration to Ubuntu Touch landing process (CI Train, a middle point on the way to CI Airlines) had been completed for all the packages earlier, handling the locking would have been clearer, and the "trunk passes all integration tests too" would have prevented "trunk seemingly got broken" situations I ended up since I was using bzr trunks everywhere.

Qt 5.3?

We are near to having a promoted Ubuntu image for the mobile users using Qt 5.2, if no new issues pop up. Ubuntu 14.04 LTS will be released in a month to the joy of desktop and mobile users alike.

It was discussed during the vUDS that Qt 5.3.x would be likely Qt version for the next cycle, to be on the more conservative side this time. It's not entirely wrong to say we should have migrated to Qt 5.1 in the beginning of this cycle and only consider 5.2. With 5.0 in use with known issues, we almost had to switch to 5.2.

Kubuntu will join the Qt 5 users next cycle, so it's no longer only Ubuntu deciding the version of Qt. Hopefully there can be a joint agreement, but in the worst case Ubuntu will need a separate Qt version packaged.

Read more
Daniel Holbach

Ubuntu Apps in China

The last weeks have been very exciting. New features have been added to the SDK (among other things these things were added: cross-compiling through ‘click chroot’ support, running the click reviewers tools automatically), HTML5 support was improved a lot (update to Cordova 3.4, new JavaScript APIs surfaced and many other great things) and new docs went up on developer.ubuntu.com as well. To me it feels like it’s getting easier and easier to write great apps every day. The choice of technology is sound (enables app authors very quickly), the design choices are both beautiful and consistent and the technology around it (packaging and publishing is so fast and easy!) just takes care of so many things for you.

It will be great to see more and more apps for Ubuntu coming in soon, and it will be especially fantastic since all of them are going to work on all current and future form-factors, being written in the same code.

What I was really happy to be involved with was our push for Ubuntu Apps in China. For the Ubuntu App Showdown (which is still running for around 3.5 weeks, until 9th April) we added a prize category for Chinese apps, which became the starting point for other activities.

App Showdown Judges

I’m super happy we have a diverse judges for the Ubuntu App Showdown. Jack Yu from Ubuntu Kylin, Joey Chan from the Ubuntu Core Apps team and Shuduo Sang from the PES team at Canonical. All of them have helped with lots of different questions and bits of organisation. Thanks a lot for your help!

App Development Events

We had a fantastic Ubuntu App Developer Week some two weeks ago, and while having the videos on YouTube works great for a lot of us, it’s not the best choice for China. Thanks a lot Shuduo for uploading all of the videos to youku.

This means that if you’re in China, you can just go ahead and get all the video goodness from there and learn all about Ubuntu App Development.

More events

I’m very grateful for all the help from the people at Ubuntu Kylin.

ubuntukylin

In no time they invited Joey Chan (who has worked on the RSS Reader Core App, among others) to give a talk at the NUDT university in Chansha. The event was well-attended and well-received – around 100 Ubuntu enthusiasts turned up and Joey explained about Ubuntu for phones and using QML to write apps.

Joey Chan in action

Videos are available here.

More events are planned, so stayed tuned for more news there. China was one of the first LoCos to have Ubuntu App Dev School events! :-)

Translations of Chinese App Development Docs

The Ubuntu Community in China was super helpful in translating an initial set of developer documentation up at developer.ubuntu.com/zh. Translations, peer review and getting the docs online was done in just a couple of days, which is just fantastic. Right now we are looking at translating more content, which should make translations a lot easier. Thanks a lot everyone!

Getting involved

If you have more ideas for what we could do for Ubuntu apps being more interesting to and in China, get in touch with me.

If you are into writing apps yourself, there is still 3.5 weeks to get into the Ubuntu App Showdown. What you have to do is simple:

Read more
Daniel Holbach

App development for Ubuntu is a hot topic and many have blogged and talked about this in the past months. Still I’d like to point out two things which never cease to amaze me:

  • Writing the code of the app once and have it work on everything from a phone to a TV.
  • It’s easy. We had people join the Ubuntu Core Apps team, who had never written apps using QML or HTML5. These people now delivered some of the apps which will come preinstalled with Ubuntu phones in stores this year. Getting their feet wet and initial drafts of the apps up and running was a matter of days only.

This is just fantastic and something we should share.

Ubuntu App Dev Schools?

 

At UDS we had a really nice discussion about how to bring more App Development training events to our Ubuntu community. We came up with a number of work items, focusing on

  • improving our presentation materials,
  • making it easier for newcomers to step in, learn and present,
  • reaching out to app developer communities and our LoCo teams at the same time.

With the Ubuntu Global Jam coming up in just 3 weeks and soon followed by the 14.04 release and its release parties, we have to move fast to make this happen. To coordinate this better, David and I decided to have a daily standup meeting on Google Hangout at 9:30 UTC. Let us know (maybe on #ubuntu-locoteams) if you want to join the conversation.

We need help.

Obviously we need teams to organise events, but we need other help as well:

  • Planning. Join our planning events mentioned above.
  • Hosting. If you are interested in running an event, you should check our docs and see if there’s anything missing in there.
  • Collaborating. Talk to your LoCo team and see if you can host an Ubuntu App Dev School for Ubuntu Global Jam or your local 14.04 release party. Give us feedback on how it’s going.
  • Slightly unrelated. Help me with a VirtualBox question: I set up a VirtualBox image using Trusty, so we can have an up-to-date image with the newest SDK preinstalled, so we’re prepared if Mac or Windows users turn up to an event. Unfortunately the resolution is just up to 640×480, even with the Guest Additions loaded. Can anyone help me out?

If you are preparing to run the event, please check our Materials section, review what we have and give us feedback. Either leave a comment on this page, or…

On the following days we are going to have some Feedback / Q&A sessions on Ubuntu on Air:

There you will not only have the opportunity to ask questions about organising your event, but also all the technical questions you should have for running your presentations.

Another opportunity to find out more, is the LoCo Teams Update on Air on Saturday at 19 UTC.

Bringing more apps to Ubuntu is lots of fun and will make Ubuntu for phones/tablets/laptops/desktops/TVs/everything else a lot more interesting! :-)

Read more
mitechie

The Juju UI team has been hard at work making it even easier for you to get started with Juju. We’ve got a new tool for everyone that is appropriately named Juju Quickstart and when you combine it with the power of Juju bundles you’re in for something special.

Quickstart is a Juju plugin that aims to help you get up and running with Juju faster than any set of commands you can copy and paste. First, to use Quickstart you need to install it. If you’re on the upcoming Ubuntu Trusty release it’s already there for you. If you’re on an older version of Ubuntu you need to get the Juju stable ppa

sudo add-apt-repository ppa:juju/stable
sudo apt-get update

Installing Quickstart is then just:

sudo apt-get install juju-quickstart

Once you’ve got Quickstart installed you are ready to use it to deploy Juju environments. Just run it with `juju-quickstart`. Quickstart will then open a window to help walk you through setting up your first cloud environment using Juju.

Quickstart can help you configure and setup clouds using LXC (for local environments), OpenStack (which is used for HP Cloud), Windows Azure, and Amazon EC2. It knows what configuration data is required for each cloud provider and provides hints on where to find the information you’ll need.

Once you’ve configured  your cloud provider, Quickstart will bootstrap a Juju environment on it for you. This takes a while on live clouds as this is bringing up instances.

Quickstart does a couple of things to make the environment nicer than your typical bootstrap. First, it will automatically install the Juju GUI for you. It does this on the first machine brought up in the environment so that it’s co-located, which means it comes up much faster and does not incur the cost of a separate machine.  Once the GUI is up and running, Quickstart will automatically launch your browser and log you into the GUI. This saves you from having to copy and paste your admin secret to log in.

If you would like to setup additional environments you can re-launch Quickstart at any time. Use juju-quickstart -i to get back to the guided setup.

Once the environment is up Quickstart still helps you out by providing a shortcut to get back to the Juju GUI running. It will auto launch your browser, find the right IP address of the GUI, and auto log you in. Come back the next day and Quickstart is still the fastest way to get back into your environment.

Finally, Quickstart works great with the new Juju charm bundles feature. A bundle is a set of services with a specific configuration and their corresponding relations that can be deployed together via a single step. Instead of deploying a single service, they can be used to deploy an entire workload, with working relations and configuration. The use of bundles allows for easy repeatability and for sharing of complex, multi-service deployments. Quickstart can accept a bundle and will deploy that bundle for you. If the environment is not bootstrapped it will bring up the environment, install the GUI, and then deploy the bundle.

For instance, here is the one command needed to deploy a bundle that we’ve created and shared:

juju-quickstart bundle:~jorge/mongodb-cluster/1/mongodb-cluster

If the environment is already bootstrapped and running then Quickstart will just deploy the bundle. The two features together work great for testing repeatable deployments. What’s great is that the power of Juju means you can test this deployment on multiple clouds effortlessly.  For instance you can design and configure your bundle locally via LXC and, when satisfied, deploy it to a real environment, simply by changing the environment command-line option when launching Quickstart.

Try out Quickstart and bundles and let us know what you think. Feel free to hop into our irc channel #juju on Freenode if you’ve got any questions. We’re happy to help.

Make sure to check out Mat’s great YouTube video walk through as well over on the Juju GUI blog.


Read more
David Murphy (schwuk)

Zach Holman writes about how GitHub communicates:

here’s a look at most of the communication that happened at GitHub on one random recent day: February 4, 2014

The expected methods are all there: chat (Campfire in their case), email, and – of course – GitHub itself.

One thing that piqued my interest was their internal-only social network “Team” which seems very reminiscent of how Automattic use WordPress & P2. Since I learned how Automattic use P2, I’ve been wondering if we could do something similar at Canonical. Perhaps we could use Google+  for this as we already use it for internal HangoutsUbuntu Developer Summit, and to power Ubuntu On-Air. There are ways to limit Google+ communities to members of your Google Apps domain.

(Side note: I hate having two Google+ accounts!)

I really need to finish coalescing my thoughts and put them into their own post…

The other point I noted was that their use of email was both minimal and individual – Team and GitHub itself are their primary ways of disseminating information.

It always interesting to see how others do achieve similar goals to yourself.

Read more
David Murphy (schwuk)

Zach Holman writes about how GitHub communicates:

here’s a look at most of the communication that happened at GitHub on one random recent day: February 4, 2014

The expected methods are all there: chat (Campfire in their case), email, and – of course – GitHub itself.

One thing that piqued my interest was their internal-only social network “Team” which seems very reminiscent of how Automattic use WordPress & P2. Since I learned how Automattic use P2, I’ve been wondering if we could do something similar at Canonical. Perhaps we could use Google+  for this as we already use it for internal Hangouts, Ubuntu Developer Summit, and to power Ubuntu On-Air. There are ways to limit Google+ communities to members of your Google Apps domain.

(Side note: I hate having two Google+ accounts!)

I really need to finish coalescing my thoughts and put them into their own post…

The other point I noted was that their use of email was both minimal and individual – Team and GitHub itself are their primary ways of disseminating information.

It always interesting to see how others do achieve similar goals to yourself.

The post How GitHub communicates appeared first on David Murphy.

Read more
Nicholas Skaggs

Keeping ubuntu healthy: Core Apps

Continuing our discussion of testing within ubuntu, today's post will talk about how you can help the community core apps stay healthy.

As you recall the core apps go through a series of QA before being released to the store. However bugs in the application, or in the platform itself can still be exposed. The end result is that the dashboard contains tests failures for that application. To release a new stable image, we need a green dashboard, and more importantly we need to make sure the applications work properly.

Getting plugged in
So to help out, it's important to first plug into the communication stream. After all, we're building these applications and images as a community! First, join the ubuntu phone group on launchpad and sign up for the phone mailing list. The list is active and discussing all issues pertaining to the ubuntu phone. Most importantly, you will see landing team emails that summarize and coordinate issues with the phone images.

From there you can choose a community core app to help improve from a quality perspective. These applications all have development teams and it's helpful to stay in contact with them. Your merge proposal can serve as an introduction!

Finding something to work on
So what needs fixing? A landing team email might point out a failing test. You might notice a test failure on the dashboard yourself. In addition each application keeps a list of bugs reported against it, including bugs that point out failing tests or testing needs. For example here's the list of all new autopilot tests that need to be written for all of the core apps. Pick an app, browse the buglist, assign a bug to yourself, and fix it.

For example, here's the list of bugs for music app. As of this writing you can see several tests that need written, as well as a bug for a test improvement.

You can also simply enhance the app's existing testsuite by fixing a flaky test, or improving the test to use best practices, etc. As a bonus for those reading this near it's original publication date, we just had a session @ vUDS covering the core apps and the testing needs we have. Watch the session / browse the pad and pick something to work on.

Fixing things
Look into any failures you find and have a look at the tests. Often the tests can use a little improvement (or maybe an additional test), and you can help out here! Sometimes failures won't happen every run -- this is the sign of a weird bug, or more likely a flaky test.  Fix the test(s), improve them, or add to them. Then commit your work and submit a merge proposal. Follow the guide on the wiki if you need help with doing this.

Remember, you can iteratively run the tests on your device as you work. Read my post on click-buddy for help with this. If you are lacking a device, run the tests on your desktop instead and a reviewer can test against a real device before merging.

Getting Help
For realtime help, check out #ubuntu-quality and #ubuntu-autopilot on freenode. You'll find a group of folks like yourself working on tests, hacking on autopilot and sharing advice. If IRC isn't your thing, feel free to contact us through another method instead. Happy hacking!

Read more
pitti

Our current autopkgtest machinery uses Jenkins (a private and a public one) and lots of “rsync state files between hosts”, both of which have reached a state where they fall over far too often. It’s flakey, hard to maintain, and hard to extend with new test execution slaves (e. g. for new architectures, or using different test runners). So I’m looking into what it would take to replace this with something robust, modern, and more lightweight.

In our new Continuous Integration world the preferred technologies are RabbitMQ for doing the job distribution (which is delightfully simple to install and use from Python), and OpenStack’s swift for distributed data storage. We have a properly configured swift in our data center, but for local development and experimentation I really just want a dead simple throw-away VM or container which gives me the swift API. swift is quite a bit more complex, and it took me several hours of reading and exercising various tutorials, debugging connection problems, and reading stackexchange to set it up. But now it’s working, and I condensed the whole setup into a single setup-swift.sh shell script.

You can run this in a standard ubuntu container or VM as root:

sudo apt-get install lxc
sudo lxc-create -n swift -t ubuntu -- -r trusty
sudo lxc-start -n swift
# log in as ubuntu/ubuntu, and wget or scp setup-swift.sh
sudo ./setup-swift.sh

Then get swift’s IP from sudo lxc-ls --fancy, install the swift client locally, and talk to it:

$ sudo apt-get install python-swiftclient
$ swift -A http://10.0.3.134:8080/auth/v1.0 -U testproj:testuser -K testpwd stat

Caveat: Don’t use this for any production machine! It’s configured to maximum insecurity, with static passwords and everything.

I realize this is just poor man’s juju, but juju-local is currently not working for me (I only just analyzed that). There is a charm for swift as well, but I haven’t tried that yet. In any case, it’s dead simple now, and maybe useful for someone else.

Read more
Prakash Advani

Many schools in Romania today are using proprietary software like Microsoft Windows and Microsoft Office — most of which are either unlicenced copies or old unsupported versions, for which the schools may face legal issues, according to the Education Ministry of Romania. To tackle this problem, the Ministry recommends the schools to either purchase newer, licenced copies of these software, or switch to open source solutions like GNU/Linux, particularly Ubuntu and Edubuntu.

Read More: http://www.muktware.com/2014/02/romanian-edu-ministry-recommends-ubuntu-schools/21844

Read more

A couple of weeks ago, Gunnar Wolf mentioned on IRC that his CuBox-i4 had arrived. This resulted in various jealous noises from me; having heard about this device making the rounds at the Kernel Summit, I ordered one for myself back in December, as part of the long-delayed HDification of our home entertainment system and coinciding with the purchase of a new Samsung SmartTV. We've been running an Intel Coppermine Celeron for a decade as a MythTV frontend and encoder (hardware-assisted with a PVR-250), which is fine for SD video, but really doesn't cut it for anything HD. So after finally getting a TV that would showcase HD in all its glory, I figured it was time to upgrade from an S-Video-out, barely-limping-along tower machine to something more modern with HDMI out, eSATA, hardware video decoding, and whose biggest problem is it's so small that it threatens to get lost in the wiring!

Since placing the order, I've been bemused to find that the SmartTV is so smart that it has had a dramatic impact on how we consume media; between that and our decision to not be a boiled frog in the face of DISH Network's annual price increase, the MythTV frontend has become a much less important part of our entertainment center, well before I ever got a chance to lay hands on the intended replacement hardware. But that's a topic for another day.

Anyway, the CuBox-i4 finally arrived in the mail on Friday, so of course I immediately needed to start hacking on it! Like Gunnar, who wrote last week about his own experience getting a "proper" Debian install on the box, I'm not content with running a binary distribution image prepared by some third party; I expect my hardware toys to run official distro packages assembled using official distro tools and, if at all possible, distributed on official distro images for a minimum of hassle.

Whereas Gunnar was willing to settle for using third-party binaries for the bootloader and kernel, however, I'm not inclined to do any such thing. And between my stint at Linaro a few years ago and the recent work on Ubuntu for phones, I do have a little knowledge of Linux on ARM (probably just enough to be dangerous), so I set to work trying to get the CuBox-i4 bootable with stock Debian unstable.

Being such a cutting-edge piece of hardware, that does pose some challenges. Support for the i.MX6 chip is in the process of being upstreamed to U-Boot, but the support for the CuBox-i devices isn't there yet, nor is the support for SPL on i.MX6 (which allows booting the variants of the CuBox-i with a single U-Boot build, instead of requiring a different bootloader build for each flavor). The CuBox-i U-Boot that SolidRun makes available (with source at github) is based on U-Boot 2013.10-rc4, so more than a full release behind Debian unstable, and the patches there don't apply to U-Boot 2014.01 without a bit of effort.

But if it's worth doing, it's worth doing right, so I've taken the time to rebase the CuBox-i patches on top of 2014.01, publishing the results of the rebase to my own github repository and submitting a bug to the Debian U-Boot maintainers requesting its inclusion.

The next step is to get a Debian kernel that not only works, but fully supports the hardware out of the box (a 3.13 generic arm kernel will boot on the machine, but little things like ethernet and hdmi don't work yet). I've created a page in the Debian wiki for tracking the status of this work.

Read more
Mark Shuttleworth

Check out “loving the bottom edge” for the most important bit of design guidance for your Ubuntu mobile app.

This work has been a LOT of fun. It started when we were trying to find the zen of each edge of the screen, a long time back. We quickly figured out that the bottom edge is by far the most fun, by far the most accessible. You can always get to it easily, it feels great. I suspect that’s why Apple has used the bottom edge for their quick control access on IOS.

progresion

We started in the same place as Apple, thinking that the bottom edge was so nice we wanted it for ourselves, in the system. But as we discussed it, we started to think that the app developer was the one who deserved to do something really distinctive in their app with it instead. It’s always tempting to grab the tastiest bit for oneself, but the mark of civility is restraint in the use of power and this felt like an appropriate time to exercise that restraint.

Importantly you can use it equally well if we split the screen into left and right stages. That made it a really important edge for us because it meant it could be used equally well on the Ubuntu phone, with a single app visible on the screen, and on the Ubuntu tablet, where we have the side stage as a uniquely cool way to put phone apps on tablet screens alongside a bigger, tablet app.

The net result is that you, the developer, and you, the user, have complete creative freedom with that bottom edge. There are of course ways to judge how well you’ve exercised that freedom, and the design guidance tries to leave you all the freedom in the world while still providing a framework for evaluating how good the result will feel to your users. If you want, there are some archetypes and patterns to choose from, but what I’d really like to see is NEW patterns and archetypes coming from diverse designs in the app developer community.

Here’s the key thing – that bottom edge is the one thing you are guaranteed to want to do more innovatively on Ubuntu than on any other mobile platform. So if you are creating a portable app, targeting a few different environments, that’s the thing to take extra time over for your Ubuntu version. That’s the place to brainstorm, try out ideas on your friends, make a few mockups. It’s the place you really express the single most important aspects of your application, because it’s the fastest, grooviest gesture in the book, and it’s all yours on Ubuntu.

Have fun!

Read more
David Henningsson

Headsets come in many sorts and shapes. And laptops come with different sorts of headset jacks – there is the classic variant of one 3.5 mm headphone jack and one 3.5 mm mic jack, and the newer (common on smartphones) 3.5 mm headset jack which can do both. USB and Bluetooth headsets are also quite common, but that’s outside the scope for this article, which is about different types of 3.5 mm (1/8 inch) jacks and how we support them in Ubuntu 14.04.

You’d think this would be simple to support, and for the classic (and still common) version of having one headphone jack and one mic jack that’s mostly true, but newer hardware come in several variants.

If we talk about the typical TRRS headset – for the headset itself there are two competing standards, CTIA and OMTP. CTIA is the more common variant, at least in the US and Europe, but it means that we have laptop jacks supporting only one of the variants, or both by autodetecting which sort has been plugged in.

Speaking of autodetection, hardware differs there as well. Some computers can autodetect whether a headphone or a headset has been plugged in, whereas others can not. Some computers also have a “mic in” mode, so they would have only one jack, but you can manually retask it to be a microphone input.
Finally, a few netbooks have one 3.5 mm TRS jack where you can plug in either a headphone or a mic but not a headset.

So, how would you know which sort of headset jack(s) you have on your device? Well, I found the most reliable source is to actually look at the small icon present next to the jack. Does it look like a headphone (without mic), headset (with mic) or a microphone? If there are two icons separated by a slash “/”, it means “either or”.

For the jacks where the hardware cannot autodetect what has been plugged in, the user needs to do this manually. In Ubuntu 14.04, we now have a dialog:
What-did-you-plug-in
In previous versions of Ubuntu, you would have to go to the sound settings dialog and make sure the correct input and output were selected. So still solvable, just a few more clicks. (The dialog might also be present in some Ubuntu preinstalls running Ubuntu 12.04.)

So in userspace, we should be all set. Now let’s talk about kernels and individual devices.

Quite common with Dell machines manufactured in the last year or so, is the version where the hardware can’t distinguish between headphones and headsets. These machines need to be quirked in the kernel, which means that for every new model, somebody has to insert a row in a table inside the kernel. Without that quirk, the jack will work, but with headphones only.
So if your Dell machine is one of these and not currently supporting headset microphones in Ubuntu 14.04, here’s what you can do:

  • Check which codec you have: We currently can enable this for ALC255, ALC283, ALC292 and ALC668. “grep -r Realtek /proc/asound/card*” would be the quickest way to figure this out.
  • Try it for yourself: edit /etc/modprobe.d/alsa-base.conf and add the line “options snd-hda-intel model=dell-headset-multi”. (A few instead need “options snd-hda-intel model=dell-headset-dock”, but it’s not that common.) Reboot your computer and test.
  • Regardless of whether you manage to resolve this or not, feel free to file a bug using the “ubuntu-bug audio” command. Please remove the workaround from the previous step (and reboot) before filing the bug. This might help others with the same hardware, as well as helping us upstreaming your fix to future kernels in case the workaround was successful. Please keep separate machines in separate bugs as it helps us track when a specific hardware is fixed.

Notes for people not running Ubuntu

  • Kernel support for most newer devices appeared in 3.10. Additional quirks have been added to even newer kernels, but most of them are with CC to stable, so will hopefully appear in 3.10 as well.
  • PulseAudio support is present in 4.0 and newer.
  • The “what did you plug in”-dialog is a part of unity-settings-daemon. The code is free software and available here.

Read more
Nicholas Skaggs

Continuing our discussion of the testing within ubuntu, today's post will talk about how you can help ubuntu stay healthy by manually testing the images produced. No amount of robots or automated testing in the world can replace you (well, at least not yet, heh), and more specifically your workflow and usage patterns.

As discussed, everyday new images are produced for ubuntu for all supported architecture types. I would encourage you to follow along and watch the progression of the OS through these images and your testing. Every data point matters and testing on a regular basis is helpful. So how to get started?

Settle in with a nice cup of tea while testing!

The Desktop
For the desktop images everything you need is on the image tracker. There is a wonderful video and text tutorial for helping you get started. You report your results on the tracker itself in a simple web form, so you'll need a launchpad account if you don't have one.

The secondary way to help keep the desktop images in good shape is to install and run the development version of ubuntu on your machine. Each day you can check for updates and update your machine to stay in sync. Use your pc as you normally would, and when you find a bug, report it! Bugs found before the release are much easier to fix than after release.

Phablet
Now for the phablet images you will need a device capable of running the image. Check out the list. Grab your device and go through the installation process as described on the wiki. Make sure to select the '-proposed' channel when you install so you will see updates to get the latest images being worked on every time they are built. From there you can update everyday. Use the device and when you find a bug, report it! Here's a wiki page to help guide your testing and help you understand how and where to report bugs.

Don't forget there's a whole team of people within ubuntu dedicated to testing just like you. And they would love to have you join them!

Read more
Iain Farrell

Happy by Sergei Pozdnyak

The submissions process for Ubuntu 14.04 is now closed. If you’d like to look at the images head over to the Flickr Group. From here on a group of dedicated and splendid individuals will get together to select the images that are going to go into the next release of Ubuntu. We’ll be hanging out on #1404wallpaper on Freenode and you can come listen in :)

We generally welcome discussion but please remember that a decision is needed from the time that people volunteer so not too much additional debate.

We’ll start with a meeting tomorrow, Friday 7th March, at 19:00GMT.


Read more
olli

Mir and Chromium

Ubuntu’s Display Server Mir is gaining more and more traction and the team is making good progress on the platforms that are at the core of Ubuntu. Mir is proving itself everyday to be the exact technology that Ubuntu needs to power mobile devices. Mir’s features are on par with the requirements that we put […]

Read more
Nicholas Skaggs

Since just before the last LTS, quality has been a buzzword within the ubuntu community. We've come a long way since precise and I wanted to provide some help and prospective on what ubuntu's process for quality looks like this cycle. In simple terms. Or as reddit would say, "explain to me like I'm 5".

I'll try and define terms as we go. First let me define CI, which is perhaps the buzzword of this cycle, lest I lose all of you! CI stands for continuous integration, and it means we are testing ubuntu. All the time. Non-stop. Every change we make, we test. The goal behind this idea is to find and fix problems, before well, they become problems on your device!

CI Dashboard
The CI dashboard then is a way to visually see the results of this testing. It acts as a representation of the health of ubuntu as a distribution. At least once a day runs are executed, apps and images are tested and benchmarked, and the results are populated on ci.ubuntu.com. This is perhaps the most visible part of the CI (our continuous testing efforts) that is happening within ubuntu. But let's step back a minute and look at how the overall CI process works within ubuntu.

CI Process
App developers hack on a bit of code, fixing bugs or adding new features to the codebase. Once the code is ready, a merge proposal1 is created by the developer and feedback is sought. If the code passes the peer review and the application's tests, it will then become part of the image after a journey through the CI train.


For the community core apps, the code is merged after peer review, and then undergoes a similar journey to the store where it will become part of the image as well. Provided of course it meets further review criteria by myself and Alan (we'll just call him the gatekeeper).
Though menacing, Alan assures me he doesn't bite

Lest we forget, upstream2 uploads3 are done as well. We can hope some form of testing was done on them before we received them. Nevertheless, tests are run on these as well, and if they pass successfully, the new packages will enter the archive4 and become part of the image.

Generating Images
Now it's time to generate some images. For the desktop a snapshot of what's in the ubuntu archive is taken each day, built, and then subjected to a series of installation tests. If the tests pass, it is released for general testing called Image (or ISO) testing. An image is tested and declared stable as part of a milestone (or testing event) and can become the next version of ubuntu!
Adopted images are healthy images!

On the ubuntu phone side of things, all the new uploads are gathered and evaluated for risk. If something is a large change, it might be prudent to not land it with other large changes so we can tell what broke should the image not work properly. Once everything is ready, a new image is created and is released for testing.  The OTA updates (over-the-air; system updates) on your ubuntu phone come from this process!

How you can help?
Still with me I hope? As you can see there's many things happening each day in regards to quality and lots of places where you can create a positive change for the health of the distro! In my next few posts, I'll cover each of the places you can plug in to help ubuntu be healthy everyday!

1. A merge proposal is a means of changing an applications code via peer review.
2. By upstream, I mean the communities and people who make things we use inside of ubuntu, but are not directly a part of it. Something like the browser (firefox) and kernel are good examples.
3. This can happen via a general sync at the beginning of the cycle from debian. This sync copies part of the debian archive into the ubuntu archive, which in effect causes applications to be updated. Applications are also updated whenever a core ubuntu developer or a MOTU uploads a new version to the archive. 
4. In case you are wondering, "the archive" is the big repository where all of your updates and new applications come from!

Read more
Michael Hall

Starting at 1400 UTC today, and continuing all week long, we will be hosting a series of online classes covering many aspects of Ubuntu application development. We have experts both from Canonical and our always amazing community who will be discussing the Ubuntu SDK, QML and HTML5 development, as well as the new Click packaging and app store.

You can find the full schedule here: http://summit.ubuntu.com/appdevweek-1403/

We’re using a new format for this year’s app developer week.  As you can tell from the link above, we’re using the Summit website.  It will work much like the virtual UDS, where each session will have a page containing an embedded YouTube video that will stream the presenter’s hangout, an embedded IRC chat window that will log you into the correct channel, and an Etherpad document where the presenter can post code examples, notes, or any other text.

Use the chatroom like you would an Ubuntu On Air session, start your questions with “QUESTION:” and wait for the presenter to get to it. After the session is over, the recorded video will be available on that page for you to replay later. If you register yourself as attending on the website (requires a Launchpad profile), you can mark yourself as attending those sessions you are interested in, and Summit can then give you a personalize schedule as well as an ical feed you can subscribe to in your calendar.

If you want to use the embedded Etherpad, make sure you’re a member of https://launchpad.net/~ubuntu-etherpad

That’s it!  Enjoy the session, ask good questions, help others when you can, and happy hacking.

Read more
Jono Bacon

So, we have announced the Ubuntu App Showdown where you can build some awesome Ubuntu apps and win prizes such as the Nexus 7 (2013) tablet and the Meizu MX3, we have provided an update on lots of great updates going on such as refined HTML5 support and a raft of developer.ubuntu.com updates, we have revised and improved how the dash and scopes work (more developer docs on this coming soon!), we have simplified how apps are uploaded to the store, and of course, Ubuntu handsets are hitting the market later this year so our app devs will have plenty of new users to consume their apps. But, why stop there?

We are not here to build a good app developer community, we are here to build the most empowering, rewarding, and fun app developer community there is, all powered by openness and collaboration.

As such, I am delighted to announce that next week Ubuntu App Developer Week beginning on Monday 3rd March at 2pm UTC and running all week

This is a week with a range of tutorial sessions for how to build apps for Ubuntu across QML, HTML5 and more. All of these sessions take place online in a series of Google Hangouts, complete with embedded chat channels where you can interact with the speaker and ask questions.

This includes sessions such as the following for QML apps:

  • Game Development with QML and Box2D
  • Internationalize your apps
  • Extending QML with a C++ Plugin
  • Ubuntu UI Toolkit tips and tricks for beginners
  • Responsive Layouts
  • Testing with qmltestrunner
  • Making the perfect user acceptance test
  • Integrating U1DB in your app
  • Content Exchange in a confined world
  • Add download capabilities to your apps

and the following for HTML5 apps:

  • Building HTML5 apps with Ubuntu
  • Cordova in HTML5 Apps
  • Platform APIs for HTML5 Apps
  • HTML5 UbuntuUI Components
  • Debugging HTML5 apps

We also have a few other sessions such as a feedback session on the software store and how to get compiled code into click packages.

How Do I Join?

Ubuntu App Developer Week is available freely to anyone who chooses to join. You don’t have to be an expert, and you don’t have to know how to write apps with the Ubuntu SDK yet. Beginners are very welcome!

All of the sessions, their times, and how to join them are available on the Ubuntu App Developer Week schedule. Just show up at the right time, click a session, and you are ready to go!

We still have some slots free if you want to volunteer to run a session. If you would like to, please email Michael Hall.

The fun starts next week on Monday 3rd March at 2pm UTC and runs all week. We hope to see you there!

Read more
Michael Hall

Today we announced the start of the next Ubuntu App Showdown, and I have very high hopes for the kinds of apps we’ll see this time around. Our SDK has grown by leaps and bounds since the last one, and so much more is possible now. So go get yourself started now: http://developer.ubuntu.com/apps/

Earlier today Jono posted his Top 5 Dream Ubuntu Apps, and they all sound great.  I don’t have any specific apps I’d like to see, but I would love to get some multi-player games.  Nothing fancy, nothing 3D or FPS.  Think more like Draw Something or Words With Friends, something casual, turn-based, that lets me connect with other Ubuntu device users. A clone of one of those would be fun, but let’s try and come up with something original, something unique to Ubuntu.

What do you say, got any good ideas?  If you do, post them in the App Showdown subreddit or our Google+ App Developers community and let’s make it happen.

Read more