Canonical Voices

Mark Baker

It is pretty well known that most of the OpenStack clouds running in production today are based on Ubuntu. Companies like Comcast, NTT, Deutsche Telekom, Bloomberg and HP all trust Ubuntu Server as the right platform to run OpenStack. A fair proportion of the Ubuntu OpenStack users out there also engage Canonical to provide them with technical support, not only for Ubuntu Server but OpenStack itself. Canonical provides full Enterprise class support for both Ubuntu and OpenStack and has been supporting some of the largest, most demanding customers and their OpenStack clouds since early 2011. This gives us a unique insight into what it takes to support a production OpenStack environment.

For example, in the period January 1st 2014 to end of March, Canonical processed hundreds of OpenStack support tickets averaging over 100 per month. During that time we closed 92 bugs whilst customers opened 99 new ones. These are bugs found by real customers running real clouds and we are pleased that they are brought to our attention, especially the hard ones as it helps makes OpenStack better for everyone.

The type of support tickets we see is interesting as core OpenStack itself only represents about 12% of the support traffic. The majority of problems arise between the interaction of OpenStack, the operating system and other infrastructure components – fibre channel drivers used by nova volume, or, QEMU/libvirt issues during upgrades for example. Fixing these problems requires deep expertise Ubuntu as well as OpenStack which is why customers choose Canonical to support them.

In my next post I’ll dig a little deeper into supporting OpenStack and how this contributes to the OpenStack ecosystem.

Read more
Inayaili de León Persson

Ubuntu Resources — beta 2!

A new version of the Ubuntu Resources site is now live, with many tweaks and layout improvements targeted mainly at visitors using medium-sized screens, such as tablets.

Resources homepage on a Kindle Fire HDUbuntu Resources homepage viewed on a Kindle Fire HD

Filtered search

If you search for a specific term, you can now filter the search results by topic (such as cloud, phone, support, etc.) or type (case study, white paper, event, etc.). Further down the line, we’d like to expand this so people are able to sort the results by date, popularity and more, and filter by date, language and other options.

Search result filtersSearch results filters

Still on the subject of search, some users mentioned that their phones didn’t necessarily show a “Go” button in the keypad when typing inside the search box, so we’ve added a search icon which doubles as a “Go” button inside the input field but doesn’t get in the way if you have no need for it.

Search input field on a Nexus 7Search input field, viewed on a Nexus 7

Layout and font sizes

We’ve added a maximum width to text areas instead of the full width text blocks that were optimised for small screen view, so visitors to the site using tablets and other medium sized screens won’t have to deal with really long text lines. This can be seen in screens such as the homepage and topic landing pages, but most importantly in single article views, where we’ve also moved the content that followed the article text to the right hand side. In future versions of the site, we might review the order in which these right column elements appear and perhaps their content too.

News page on iPadA news page with sidebar viewed on an iPad

Following the typographic scale that we introduced in the new canonical.com website, the font sizes and spacing between elements in medium sized views have also been updated: everything is slightly larger, as there is more screen real estate and elements can have a little more breathing space.

We’ve made some tweaks to the spacing between elements, namely in the homepage and landing pages, like adding more space between articles to make lists clearer to understand.

‘Add to’

We’ve also added links to “Add to Instapaper” and “Add to Pocket” in single article view screens, which we hope will be useful for anyone that wants to save a resource for later.

Colour consistency

A hardly noticeable change, but one that we thought was important in order to keep consistency across different Ubuntu products and platforms was the update of the grey colour we were using in tags, labels and event details. The new grey now matches the new phone greys: we went from #AEA79F to a slightly darker and more readable #888888. If warm grey is used on dark aubergine, the HEX reference is now #B2B2B2.

Darker grey textDarker grey in event details

Even more changes

We’ve also fixed many other bugs and issues like 404 pages, incorrect tagging, elements’ positioning, incorrect title tags, errors in the email sharing default text, and more.

Next steps

In the next few weeks we’ll be focusing on extending our styles to accommodate larger screens nicely and improving the medium screen size layouts based on the feedback we’ll receive from users.

We hope you have a look at the updated site and let us know your thoughts on it. You can use the handy feedback link at the bottom of the site or just comment here!

Read more
Daniel Holbach

ubuntu-phone-three-1

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

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

What we have available now is:

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

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

Interested? So how do you prepare? Easy:

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

Whichever camp you’re in:

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

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

Read more
Nicholas Skaggs

It may be hard to believe but the next, and dare I say, best, LTS for ubuntu is releasing very soon. We need your help in polishing out critical bugs and issues!

How can I help? 
To help test, visit the iso tracker milestone page for 'Trusty Beta 2'.  The goal is to verify the images in preparation for the release. Find those bugs! The information at the top of the page will help you if you need help reporting a bug or understanding how to test. 

So what's new? 
Besides the usual slew of updates to the applications, stack and kernel, unity has new goodies like minimize on click, menus in toolbar, new lockscreen, and borderless windows!

What if I'm late?
The testing runs through this Thursday March 27th, when the the images for beta 2 will be released. If you miss the deadline we still love getting results! Test against the daily image milestone instead.

Thanks and happy testing everyone!

Read more
Joseph Salisbury

Meeting Minutes

IRC Log of the meeting.

Meeting minutes.

Agenda

20140325 Meeting Agenda


ARM Status

nothing new to report this week


Release Metrics and Incoming Bugs

Release metrics and incoming bug data can be reviewed at the following link:

http://people.canonical.com/~kernel/reports/kt-meeting.txt


Milestone Targeted Work Items

   apw    core-1311-kernel    4 work items   
      core-1311-cross-compilation    2 work items   
      core-1311-hwe-plans    1 work item   
   ogasawara    core-1311-kernel    1 work item   
      core-1403-hwe-stack-eol-notifications    2 work items   
   smb    servercloud-1311-openstack-virt    3 work items   


Status: Trusty Development Kernel

The 3.13.0-19.40 Trusty kernel has been uploaded to the archive. We’ll
anticipate one more upload before kernel freeze on Thurs Apr 3. If
there are any patches which need to land in our 14.04 Trusty kernel, get
them submitted to the Ubuntu kernel team mailing list asap. After
kernel freeze, all patches are subject to our Ubuntu SRU policy.
—–
Important upcoming dates:
Thurs Apr 03 – Kernel Freeze (~1 week away)
Thurs Apr 17 – Ubuntu 14.04 Final Release (~3 weeks away)


Status: CVE’s

The current CVE status can be reviewed at the following link:

http://people.canonical.com/~kernel/cve/pkg/ALL-linux.html


Status: Stable, Security, and Bugfix Kernel Updates – Saucy/Raring/Quantal/Precise/Lucid

Status for the main kernels, until today (Mar. 25):

  • Lucid – No changes this cycle
  • Precise – No changes this cycle
  • Quantal – Testing
  • Saucy – Testing

    Current opened tracking bugs details:

  • http://people.canonical.com/~kernel/reports/kernel-sru-workflow.html

    For SRUs, SRU report is a good source of information:

  • http://people.canonical.com/~kernel/reports/sru-report.html


Open Discussion or Questions? Raise your hand to be recognized

No open discussions.

Read more
bigjools

My Road Through Hell

 

Hell

I’ve now been on treatment for Lyme disease for a little over twelve months.  Without a doubt, this has been the worst twelve months of my entire life.  It’s almost impossible to convey the range of pain that I have endured, the mental anguish, and the struggle to find the will to live.

Six months ago I was about at rock bottom.  I was going trough herxes from hell, suffering from heart complications including cardiac pauses (my heart would stop for several seconds at a time), and headaches that felt like someone was driving a pick axe into my skull. Then there was the brain fog; the confusion and memory loss that left me feeling stupid and helpless in front of people who just didn’t understand how I could not remember simple things I had talked about with them only a few hours ago.

On top of that, I had extreme fatigue that left me unable to climb the stairs at home without stopping every few steps to get my strength back in my legs.  Many of my days have been spent as a quivering mess on the floor, unable to speak, move or do anything because I was in so much pain and close to passing out.

In short, I was pretty fucked and thought I was about to die at any time.

Then I discovered an antibiotic that was actually making a difference to my heart symptoms—it’s called Bactrim (or Trimethoprim/sulfamethoxazole to give it its full name).  I started taking it in late December and two weeks later I was heart symptom free!  The course of drugs then ran out (I had 4 weeks’ worth) and ten days later I had relapsed and was getting chest pains and palpitations again.  I started another month’s course and felt better again after a couple of weeks, so it was clear that this drug was doing something to help me with my Bartonella infection.

It struck me that I have been so ill for a long time that I hadn’t really noticed that I was slowly getting better lately.  At least I hope I am getting better — I’m now at a “wait and see” stage after having stopped the Bactrim for a second time and hoping to hell that I don’t have another relapse.  I’m probably about 50% better than I was a year ago, I now have to wait for the last remnants of the Lyme and Bartonella bacteria to be driven out of my system.


Read more
Prakash Advani

Mozilla Thunderbird is one of the most powerful email clients. However I used to find that it used to keep the active window open while sending emails. This was a bit irritating specially if the email has large attachments.

On searching for background send, I found that the feature exists but doesn’t show up in the preference. You need to enable it.

After enabling it, it works very well. The only thing you need to be careful is not to send an email and immediately close your email client or shut down your PC. What happens is that email will not go as it take a few minutes (depending on the size of the email) for the email to go. The good part is that the email don’t disappear, they still in the Outbox.  It will try to re-send the next time you start Thunderbird, but there is no way for you to know if its gone or not, unless you check.

Read more: http://woikr.com/howto/send-emails-in-background-in-thunderbird-tips/

Read more
Daniel Holbach

Teaching Ubuntu App Development

Tablet and phone, running Ubuntu

At the vUDS in November we talked about having events where local communities could learn more about app development for Ubuntu for the first time. Since then we have come a long way:

  • We have some really nice materials set up.
  • The first events were held in a number of places around the world.
  • We got feedback and improved our docs.
  • Before the Ubuntu Global Jam and the release parties for 14.04 LTS we will have two Q&A sessions where you can ask all organisational and technical questions you might have.

You don’t have to do everything yourself!

When we started the initiative, we first talked to members of the Ubuntu community who knew a bit of app development already. Many of them liked the idea, but didn’t quite know how to set up an event or how to organise everything. We tried to address this by bringing them in touch with some of the LoCo teams which helped in a bunch of cases where events have already happened or are going to happen quite soon. We want more of this to happen.

It’s only understandable that you can’t do everything yourself, or that one person’s skills lie in a more organisational field and somebody else has some more experience with app development. Bringing the two together, we are going to have more interesting events, more people introduced to writing apps for Ubuntu, which will be great for everyone involved.

Getting started

Sounds good so far? Here’s what you can do to get more folks exposed to how sweet and easy it is to write apps for Ubuntu.

As somebody who can organise events, but might need to find a speaker: Ask in #ubuntu-app-devel on Freenode or on the ubuntu-app-devel@ mailing list, to see if anyone is in your area to give a talk. Ask on your LoCo’s or LUG’s mailing list as well. Even if somebody who’s into programming hasn’t developed using Ubuntu’s SDK yet, they should be able to familiarise themselves with the technologies quite easily.

As somebody who has written code before and didn’t find the Ubuntu app development materials too challenging, but might need to find some help with organising the event: Ask on the loco-contacts@ mailing list. There are LoCos all around the world and most of them will be happy to see somebody give a talk at an event.

Whichever camp you’re in:

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

Read more
Michael Hall

I’ve been using Ubuntu on my only phone for over six months now, and I’ve been loving it. But all this time it’s been missing something, something I couldn’t quite put my finger on. Then, Saturday night, it finally hit me, it’s missing the community.

That’s not to say that the community isn’t involved in building it, all of the core apps have been community developed, as have several parts of our toolkit and even the platform itself. Everything about Ubuntu for phones is open source and open to the community.

But the community wasn’t on my phone. Their work was, but not the people.  I have Facebook and Google+ and Twitter, sure, but everybody is on those, and you have to either follow or friend people there to see anything from them. I wanted something that put the community of Ubuntu phone users, on my Ubuntu phone. So, I started to make one.

Community Cast

Community Cast is a very simple, very basic, public message broadcasting service for Ubuntu. It’s not instant messaging, or social networking. It doesn’t to chat rooms or groups. It isn’t secure, at all.  It does just one thing, it lets you send a short message to everybody else who uses it. It’s a place to say hello to other users of Ubuntu phone (or tablet).  That’s it, that’s all.

As I mentioned at the start, I only realized what I wanted Saturday night, but after spending just a few hours on it, I’ve managed to get a barely functional client and server, which I’m making available now to anybody who wants to help build it.

Server

The server piece is a very small Django app, with a single BroadcastMessage data model, and the Django Rest Framework that allows you to list and post messages via JSON. To keep things simple, it doesn’t do any authentication yet, so it’s certainly not ready for any kind of production use.  I would like it to get Ubuntu One authentication information from the client, but I’m still working out how to do that.  I threw this very basic server up on our internal testing OpenStack cloud already, but it’s running the built-in http server and an sqlite3 database, so if it slows to a crawl or stops working don’t be surprised.  Like I said, it’s not production ready.  But if you want to help me get it there, you can get the code with bzr branch lp:~mhall119/+junk/communitycast-server, then just run syncdb and runserver to start it.

Client

The client is just as simple and unfinished as the server (I’ve only put a few hours into them both combined, remember?), but it’s enough to use. Again there’s no authentication, so anybody with the client code can post to my server, but I want to use the Ubuntu Online Accounts to authenticate a user via their Ubuntu One account. There’s also no automatic updating, you have to press the refresh button in the toolbar to check for new messages. But it works. You can get the code for it with bzr branch lp:~mhall119/+junk/communitycast-client and it will by default connect to my test instance.  If you want to run your own server, you can change the baseUrl property on the MessageListModel to point to your local (or remote) server.

Screenshots

There isn’t much to show, but here’s what it looks like right now.  I hope that there’s enough interest from others to get some better designs for the client and help implementing them and filling out the rest of the features on both the client and server.

communitycast-client-1communitycast-client-2communitycast-client-3

Not bad for a few hours of work.  I have a functional client and server, with the server even deployed to the cloud. Developing for Ubuntu is proving to be extremely fast and easy.

 

Read more
niemeyer

As part of the on going work on Ubuntu Touch phones, I was invited to contribute a Go package to interface with ubuntuoneauth, a C++ and Qt library that authenticates against Ubuntu One using the system account made available by the phone owner. The details of that library and its use case are not interesting for most people right now, but the work to interface with it is a good example to talk about because, besides the result (uoneauth) being an external and independent Go package that extends the qml package, ubuntuoneauth is not a QML library, but rather a plain Qt library. Some of the callbacks use even traditional C++ types that do not inherit from QObject and have no Qt metadata, so offering that functionality from Go nicely takes a bit more work.

What follows are some of the highlights of that integration logic, to serve as a reference for similar extensions in the future. Note that if your interest is in creating QML applications with Go, none of this is necessary and the documentation is a better place to start.

As an initial step, the following examples demonstrate how the original C++ library and the Go package being designed are meant to be used. The first snippet contains the relevant logic taken out of the examples/signing-main.cpp file, tweaked for clarity:

int main(int argc, char *argv[]) {
    (...)
    UbuntuOne::SigningExample *example = new UbuntuOne::SigningExample(&a);
    QTimer::singleShot(0, example, SLOT(doExample()));
    (...)
}

SigningExample::SigningExample(QObject *parent) : QObject(parent) {
    QObject::connect(&service, SIGNAL(credentialsFound(const Token&)),
                     this, SLOT(handleCredentialsFound(Token)));
    QObject::connect(&service, SIGNAL(credentialsNotFound()),
                     this, SLOT(handleCredentialsNotFound()));
    (...)
}

void SigningExample::doExample() {
    service.getCredentials();
}

void SigningExample::handleCredentialsFound(Token token) {
    QString authHeader = token.signUrl(url, QStringLiteral("GET"));
    (...)
}
 
void SigningExample::handleCredentialsNotFound() {
    qDebug() << "No credentials were found.";
}

The example hooks into various signals in the service, one for each possible outcome, and then calls the service’s getCredentials method to initiate the process. If successful, the credentialsFound signal is emitted with a Token value that is able to sign URLs, returning an HTTP header that can authenticate a request.

That same process is more straightforward when using the library from Go:

service := uoneauth.NewService(engine)
token, err := service.Token()
if err != nil {
        return err
}
signature := token.HeaderSignature("GET", url)

Again, this gets a service, a token from it, and signs a URL, in a “forward” way.

So the goal is turning the initial C++ workflow into this simpler Go API. A good next step is looking into how the NewService function is implemented:

func NewService(engine *qml.Engine) *Service {
        s := &Service{reply: make(chan reply, 1)}

        qml.RunMain(func() {
                s.obj = *qml.CommonOf(C.newSSOService(), engine)
        })

        runtime.SetFinalizer(s, (*Service).finalize)

        s.obj.On("credentialsFound", s.credentialsFound)
        s.obj.On("credentialsNotFound", s.credentialsNotFound)
        s.obj.On("twoFactorAuthRequired", s.twoFactorAuthRequired)
        s.obj.On("requestFailed", s.requestFailed)
        return s
}

NewService creates the service instance, and then asks the qml package to run some logic in the main Qt thread via RunMain. This is necessary because a number of operations in Qt, including the creation of objects, are associated with the currently running thread. Using RunMain in this case ensures that the creation of the C++ object performed by newSSOService happens in the main Qt thread (the “GUI thread”).

Then, the address of the C++ UbuntuOne::SSOService type is handed to CommonOf to obtain a Common value that implements all the common logic supported by C++ types that inherit from QObject. This is an unsafe operation as there’s no way for CommonOf to guarantee that the provided address indeed points to a C++ value with a type that inherits from QObject, so the call site must necessarily import the unsafe package to provide the unsafe.Pointer parameter. That’s not a problem in this context, though, since such extension packages are necessarily dealing with unsafe logic in either case.

The obtained Common value is then assigned to the service’s obj field. In most cases, that value is instead assigned to an anonymous Common field, as done in qml.Window for example. Doing so means qml.Window values implement the qml.Object interface, and may be manipulated as a generic object. For the new Service type, though, the fact that this is a generic object won’t be disclosed for the moment, and instead a simpler API will be offered.

Following the function logic further, a finalizer is then registered to ensure the C++ value gets deallocated if the developer forgets to Close the service explicitly. When doing that, it’s important to ensure the Close method drops the finalizer when called, not only to facilitate the garbage collection of the object, but also to avoid deallocating the same value twice.

The next four lines in the function should be straightforward: they register methods of the service to be called when the relevant signals are emitted. Here is the implementation of two of these methods:

func (s *Service) credentialsFound(token *Token) {
        s.sendReply(reply{token: token})
}

func (s *Service) credentialsNotFound() {
        s.sendReply(reply{err: ErrNoCreds})
}

func (s *Service) sendReply(r reply) {
        select {
        case s.reply <- r:
        default:
                panic("internal error: multiple results received")
        }
}

Handling the signals consists of just sending the reply over the channel to whoever initiated the request. The select statement in sendReply just ensures that the invariant of having a reply per request is not broken without being noticed, as that would require a slightly different design.

There’s one more point worth observing in this logic: the token value received as a parameter in credentialsFound was already converted into the local Token type. In most cases, this is unnecessary as the parameter is directly useful as a qml.Object or as another native type (int, etc), but in this case UbuntuOne::Token is a plain C++ type that does not inherit from QObject, so the default signal parameter that would arrive in the Go method has only a type name and the value address.

Instead of taking the plain value, it is turned into a more useful one by registering a converter with the qml package:

func convertToken(engine *qml.Engine, obj qml.Object) interface{} {
        // Copy as the one held by obj is passed by reference.
        addr := unsafe.Pointer(obj.Property("plainAddr").(uintptr))
        token := &Token{C.tokenCopy(addr)}
        runtime.SetFinalizer(token, (*Token).finalize)
        return token
}

func init() {
        qml.RegisterConverter("Token", convertToken)
}

Given that setup, the Service.Token method may simply call the getCredentials method from the underlying UbuntuOne::SSOService method to fire a request, and block waiting for a reply:

func (s *Service) Token() (*Token, error) {
        s.mu.Lock()
        qml.RunMain(func() {
                C.ssoServiceGetCredentials(unsafe.Pointer(s.obj.Addr()))
        })
        reply := <-s.reply
        s.mu.Unlock()
        return reply.token, reply.err
}

The lock ensures that a second request won’t take place before the first one is done, forcing the correct sequencing of replies. Given the current logic, this isn’t strictly necessary since all requests are equivalent, but this will remain correct even if other methods from SSOService are added to this interface.

The returned Token value may then be used to sign URLs by simply calling the respective underlying method:

func (t *Token) HeaderSignature(method, url string) string {
        cmethod, curl := C.CString(method), C.CString(url)
        cheader := C.tokenSignURL(t.addr, cmethod, curl, 0)
        defer freeCStrings(cmethod, curl, cheader)
        return C.GoString(cheader)
}

No care about using qml.RunMain has to be taken in this case, because UbuntuOne::Token is a simple C++ type that does not interact with the Qt machinery.

This completes the journey of creating a package that provides access to the ubuntuoneauth library from Go code. In many cases it’s a better idea to simply rewrite the logic in Go, but there will be situations similar to this library, where either rewriting would take more time than reasonable, or perhaps delegating the maintenance and stabilization of the underlying logic to a different team is the best thing to do. In those cases, an approach such as the one exposed here can easily solve the problem.

Read more
Colin Ian King

One of my on-going projects is to try to reduce system activity where possible to try to shave off wasted power consumption.   One of the more interesting problems is when very short lived processes are spawned off and die and traditional tools such as ps and top sometimes don't catch that activity.   Over last weekend I wrote the bulk of the forkstat tool to track down these processes.

Forkstat uses the kernel proc connector interface to detect process activity.  Proc connector allows forkstat to receive notifications of process events such as fork, exec, exit, core dump and changing the process name in the comm field over a socket connection.

By default, forkstat will just log fork, exec and exit events, but the -e option allows one to specify one or more of the fork, exec, exit, core dump or comm events.  When a fork event occurs, forkstat will log the PID and process name of the parent and child, allowing one to easily identify where processes are originating.    Where possible, forkstat attempts to track the life time of a process and will log the duration of a processes when it exits (note: this is not an estimate of the CPU used).

The -S option to forkstat will dump out a statistical summary of activity.  This is useful to identify the frequency of processes activity and hence identifying the top offenders.

Forkstat is now available in Ubuntu 14.04 Trusty Tahr LTS.  To install forkstat use:

 sudo apt-get install forkstat  

For more information on the tool and examples of the forkstat output, visit the forkstat quick start page.

Read more
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
David Murphy (schwuk)

Today I was adding tox and Travis-CI support to a Django project, and I ran into a problem: our project doesn’t have a setup.py. Of course I could have added one, but since by convention we don’t package our Django projects (Django applications are a different story) – instead we use virtualenv and pip requirements files - I wanted to see if I could make tox work without changing our project.

Turns out it is quite easy: just add the following three directives to your tox.ini.

In your [tox] section tell tox not to run setup.py:

skipsdist = True

In your [testenv] section make tox install your requirements (see here for more details):

deps = -r{toxinidir}/dev-requirements.txt

Finally, also in your [testenv] section, tell tox how to run your tests:

commands = python manage.py test

Now you can run tox, and your tests should run!

For reference, here is a the complete (albeit minimal) tox.ini file I used:

[tox]
envlist = py27
skipsdist = True

[testenv]
deps = -r{toxinidir}/dev-requirements.txt
setenv =
    PYTHONPATH = {toxinidir}:{toxinidir}
commands = python manage.py test

The post Using tox with Django projects appeared first on David Murphy.

Read more
Prakash Advani

If you are still on XP, whats your plans ?

11% of the (admittedly small) 641 companies queried stated they intend to switch to Linux. The low-cost, robust security and growing reputation in enterprise use are likely key factors informing such plans.

Perhaps more shockingly is that 37% of those asked intend to stick with Windows XP past the expiry date. Of those, 40% reason that as ‘it works’ there’s little need to change, while 39% claim software they rely on depends on XP.

Read More: http://www.omgubuntu.co.uk/2014/02/windows-xp-users-may-switch-linux

 

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
Joseph Salisbury

Meeting Minutes

IRC Log of the meeting.

Meeting minutes.

Agenda

20140318 Meeting Agenda


ARM Status

nothing new to report this week


Release Metrics and Incoming Bugs

Release metrics and incoming bug data can be reviewed at the following link:

http://people.canonical.com/~kernel/reports/kt-meeting.txt


Milestone Targeted Work Items

   apw    core-1311-kernel    4 work items   
      core-1311-cross-compilation    2 work items   
      core-1311-hwe-plans    1 work item   
   ogasawara    core-1311-kernel    1 work item   
      core-1403-hwe-stack-eol-notifications    2 work items   
   smb    servercloud-1311-openstack-virt    3 work items   
      servercloud-1311-openstack    1 work item   


Status: Trusty Development Kernel

The 3.13.0-18.38 Trusty kernel has been uploaded to the archive. This
is based on the v3.13.6 upstream stable kernel. I would also like to
remind everyone that Trusty Kernel Freeze is fast approaching on Thurs,
Apr 3. Please make sure to get any outstanding patches submitted to our
Ubuntu kernel team mailing list for review asap. After kernel freeze,
all patches are subject to our Ubuntu SRU policy.
—–
Important upcoming dates:
Thurs Mar 27 – Final Beta (~1 week away)
Thurs Apr 03 – Kernel Freeze (~2 weeks away)


Status: CVE’s

The current CVE status can be reviewed at the following link:

http://people.canonical.com/~kernel/cve/pkg/ALL-linux.html


Status: Stable, Security, and Bugfix Kernel Updates – Saucy/Raring/Quantal/Precise/Lucid

Status for the main kernels, until today (Nov. 26):

  • Lucid – No changes this cycle
  • Precise – No changes this cycle
  • Quantal – Verification
  • Saucy – Verification

    Current opened tracking bugs details:

  • http://people.canonical.com/~kernel/reports/kernel-sru-workflow.html

    For SRUs, SRU report is a good source of information:

  • http://people.canonical.com/~kernel/reports/sru-report.html


Open Discussion or Questions? Raise your hand to be recognized

No open discussion.

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
Colin Ian King

Keeping cool with thermald

The push for higher performance desktops and laptops has inevitably lead to higher power dissipation.  Laptops have also shrunk in size leading to increasing problems with removing excess heat and thermal overrun on heavily loaded high end machines.

Intel's thermald prevents machines from overheating and has been recently introduced in the Ubuntu Trusty 14.04 LTS release.  Thermald actively monitors thermal sensors and will attempt to keep the hardware cool by modifying a variety of cooling controls:
 

* Active or passive cooling devices as presented in sysfs
* The Running Average Power Limit (RAPL) driver (Sandybridge upwards)
* The Intel P-state CPU frequency driver (Sandybridge upwards)
* The Intel PowerClamp driver

Thermald has been found to be especially useful when using the Intel P-state CPU frequency scaling driver since this can push the CPU harder than other CPU frequency scaling drivers.

Over the past several weeks I've been working with Intel to shake out some final bugs and get thermald included into Ubuntu 14.04 LTS, so kudos to Srinivas Pandruvada for handling my patches and also providing a lot of timely fixes too.

By default, thermald works without any need for configuration, however, if one has incorrect thermal trip settings or other firmware related thermal zone bugs one can write one's own thermald configuration. 

For further details, consult the Ubuntu thermald wiki page.

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
Inayaili de León Persson

This post is part of the series ‘Making ubuntu.com responsive‘.

The rules document we drafted proved a useful and good guide for those few development days, and a proof of concept was created and presented to the rest of the team.

When we all sat down to review the result, a few things were clear:

  • Even though lots (and lots) of tweaks and design thinking were needed, our desktop style guide did not look bad at all in small screens — the result was promising
  • The main places where things looked broken were custom hero and background images
  • Some one-off overriding styles applied in some pages did not play well in small screens, as they might have been added in absolute sizes (like pixels) or weren’t flowing as they should
  • Some pages that were long on the desktop quickly became very long at small screen sizes

First responsive prototypeFirst ubuntu.com responsive prototype.

Since this was a ‘quick and dirty’ test of some common-sense responsive rules, a lot had not been done in the code that would eventually have to be done, such as:

  • Refactoring the original Sass files to be mobile-first
  • Cleaning up the existing Sass files as much as possible: as websites grow, the need for custom, one-off exceptions increases, so we needed to set aside some time to rationalise some of these sneaky overrides

However, the exercise showed us that our existing framework was indeed flexible enough to be converted to be responsive, but it also showed us that we still had a lot of work to do!

Read the next post in this series: “Making ubuntu.com responsive: pilot projects”

Reading list

Read more