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

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

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

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

• At 15:05 UTC: App Development Roundtable
• At 16:05 UTC SDK UI Toolkit Theming
• At 16:05 UTC SDK Feedback from App Developers
• At 18:05 UTC SDK Roadmap
• At 19:05 UTC Growing the Ubuntu SDK Apps Collection

Looking forward to seeing you there!

The (second virtual) Ubuntu Developer Summit is being held this week. Of the many topics being discussed, I’ve come across a few that I find interesting.

Chromium as default browser

Great to see a session on this topic. I spend most of my time computing in a browser, so it’d be nice to see my favourite browser as the default. Although I have no objections to Firefox as the default, I usually download the .deb from Google on each install, mainly due to the chromium-browser package being fairly outdated. It will be interesting to see the outcome for 13.10 and 14.04 LTS.

Growing a strong translation community

I still find translations to be a core concept of the Ubuntu. No matter where you’re from, you should be able to download a copy of Ubuntu, ready in your native language.

Planning for documentation and positioning of the development release

The last cycle entailed a barrage of fireworks and cracking decisions. The standard release support cycle was halved and more effort was to be put to backporting important features and enhancements to the LTS. Although the development release, by nature, doesn’t directly affect end users, it is the test bed for what will become ubuntu+1. The quality of the development releases have been superb and I’d argue that they are much more ready for testing than where we were a few years ago.

Shaping a plan for the future of (the) Ubuntu Documentation Team

There’s a lot of computer users out there that still haven’t even tried Ubuntu. We have a more usable, sleek and fun desktop than what we did many moons ago, but the documentation of the Ubuntu Desktop is certainly an area that needs attention. We can’t just assume people know how to use the Dash, Scopes and find help. People come and go from the team and it’s time to reshape and recruit more Ubuntu Doc folks.

Desktop Unity Polish for 13.10

In most of the releases since Unity has been released (11.04!), there have been radical changes and controversial moves to the Ubuntu Desktop. It’s nice to see everything calming down and focus shifting to the little details. Probably not a thrilling session for the non-developers, but it would be nice to see what is coming up in Unity+1.

As a pretty simple-minded person, I am a big fan of simplicity. The world is filled with too much complexity and too much detail. Many often feel the detail is necessary for particular outcomes or to solve particular problems. The lesson I have learned as I have gotten older though is that while the skill is in matching the level of detail to the mind of the observer, the real elegance is in delivering the same level of detail but in a way that feels simpler than expected to the observer. This results in delightful experiences.

Ross Gardler recently quoted Einstein who said “everything should be made as simple as possible, but not simpler“. This so beautifully summarizes my view of the world; life should be as simple as we can make it, but we should not compromise in our goals merely to make things simple. In other words, if we can boil our projects, processes, interfaces, and ideas down into simpler parts that still let us be productive, they become more enjoyable to engage with and thus more successful. Of course, making complex things simple is…complex. It is though, worthwhile, and for many (myself included), a fun challenge. I am sure I am not alone.

As we step into our Ubuntu Developer Summit this week I would like to encourage everyone to think about ways in which we can simplify all aspects of how create and deliver Ubuntu to others as a means to further the project and experience. This doesn’t just apply to user interface design though. How do we make our teams easier to navigate and participate in? How do we make it easier to create your first app, charm, bug fix, translation, document, mailing list post, question, answer, or otherwise? If we can make in-roads this week in simplicity, I am confident it will continue the bold stride Ubuntu is making into the future of devices and the cloud.

Just a quick note to remind everyone that our next Ubuntu Developer Summit is taking place this week on Tuesday, Wednesday and Thursday, and is open and available to everyone to participate. This is the event where we get together to discuss, debate, and plan the next three months of work.

The event takes place online from 2pm – 8pm UTC. All sessions will run using a combination of Google+ streaming video hangouts and IRC, and you can see the full schedule on summit.ubuntu.com. Consequently, for those who cannot attend or might miss certain sessions, all sessions will be available pre-recorded from the session pages when the session is complete.

The event kicks off on Tuesday at 2pm with our keynote. We hope to see you there!

Welcome to the Ubuntu Weekly Newsletter. This is issue #316 for the week 6 – 13 May, 2013, and the full version is available here.

In this issue we cover:

• Ubuntu 8.04 (Hardy Heron), 10.04 (Lucid Lynx) Desktop, and 11.10 (Oneiric Ocelot) End of Life reached on May 9, 2013
• Virtual Ubuntu Developer Summit 13.05
• Our Community Website
• Ubuntu Stats
• Jono Bacon: Sprinting In Oakland
• Nicholas Skaggs: People behind Ubuntu quality: Javier, Howard and Jackson
• Rick Spencer: Ugly Duckling to Beautiful Swan, or How an App Developer Benefits from Designer/Developer Collaboration
• Ian Weisser: Brainstorm Big 5 – May 2013
• London OpenStack & MySQL Meetups May 23rd
• Samsung U1000 Sexier Than Galaxy S4 But Doesn’t Run Android [First Samsung Ubuntu Concept]
• Ubuntu vs Android Tablets, Smartphones: Canonical’s Secret Weapon
• Where’s my Ubuntu for Android?
• First looks at Ubuntu and Kubuntu 13.04
• In The Blogosphere
• In Other News
• Other Articles of Interest
• Upcoming Meetings and Events
• Updates and Security for 8.04, 10.04, 11.10, 12.04, 12.10 and 13.04
• And much more!

The issue of The Ubuntu Weekly Newsletter is brought to you by:

• Amber Graner
• Craig Sargent
• Paul White
• John Kim
• Javier Lopez
• Tiago Carrondo
• Jim Connett
• Jose Antonio Rey
• And many others

If you have a story idea for the Weekly Newsletter, join the Ubuntu News Team mailing list and submit it. Ideas can also be added to the wiki!

Except where otherwise noted, content in this issue is licensed under a Creative Commons Attribution 3.0 License BY SA Creative Commons License

Want a button for Ubuntu Components that plays a sound when pressed, and stops when released? Here's SoundButton . Perfect for your typical Sound Board type app.


import QtQuick 2.0import Ubuntu.Components 0.1import QtMultimedia 5.0 Button { id: soundButton property string soundUrl: "" onPressedChanged: { if(pressed) { audio.play() } else { audio.stop() } } Audio { id: audio source:soundButton.soundUrl; }}

I’d like to give an update on upcoming plans for Ubuntu.com and to respond to recent concerns about the positioning of the community within the website.

Earlier in the year we worked on an evolution of Ubuntu.com to reflect the expanded scope of the project in the main site structure. Our re-structuring conversations went beyond the existing website to cover the broader Ubuntu web ecosystem. We wanted to review how users gained access to key websites that were not linked to directly from Ubuntu.com. For example: developer.ubuntu.com, design.ubuntu.com, askubuntu.com…

Our target users for these journeys were mainly community members or those new to Ubuntu who might be interested in getting involved or finding out more about how the community and Canonical work together to create Ubuntu.

Our proposed solution consisted of a global navigation menu that was to go across all key sites so that – no matter which site users arrived at – they would be able to reach the main destinations in our ecosystem. This was to include a new community site that has been under discussion for some time by Canonical employees and members of the community. One key factor for this community site is the ability for community members to have direct input so that the site reflects current community topics and areas of focus. By adding it to the global navigation we hoped to increase traffic and make it more accessible across the Ubuntu web ecosystem.

We created some prototypes to test our proposals in terms of interaction, design, site positioning, labeling etc. Laura Czajkowski helped us reach UK-based community members who came into the office to meet with an independent researcher to test the prototypes. Based on the feedback, we have made amendments and planned to implement the work in two phases:

Phase one of the restructure consisted of updating Ubuntu.com to reflect the expanded scope of the project.

Phase two is in progress and consists of adding the global navigation to all the key sites and making sure they work together across domains etc.

I’m sure you can understand that there is a large amount of coordination that needs to go into a restructure of this scale, across a number of sites, on different domains, that are managed and maintained by different teams across Canonical and beyond.

The limited scope of phase one meant the community link was temporarily dropped from the primary navigation menu. We appreciate why this might cause concern in the community, specially in the absence of an understanding of the broader context of our global navigation project. The global navigation project will restore the balance and provide access to various key community sites that need to be surfaced and will benefit from the increased traffic this new positioning will drive.

All of this work is in progress and we are aiming to go live with the changes by the end of this month.

I hope this will address some of the concerns in the community about this topic and that our roadmap shows how we will improve Ubuntu.com for all our audiences.

In cooperation with Dell, we’re thrilled to announce the Ubuntu Billboard Photo Contest in Russia and Ukraine. From today on, and until the end of May, you can participate in this challenge to submit pictures of one or more of the billboards with Dell and Ubuntu adverts spread across 6 major cities in Russia and Ukraine. You can win exciting prizes, including a Dell laptop with Ubuntu preinstalled.

The prizes

The lucky winners will be taking home one of these succulent prizes:

1st Prize 2nd Prize 3rd Prize Dell XPS 13 Ultrabook Laptop, Developer Edition Bundle of articles from the Ubuntu Store: including an Ubuntu Messenger Bag, an Ubuntu Neoprene Laptop Sleeve, and a Circle of Friends T-Shirt 100GB Ubuntu One storage + Music streaming for a year The rules

1. Term: 3 weeks , from the 13th of May to the 2nd of June
2. Judging Criteria:

• Quality (40%) – e.g. is the photographic quality good? Is the picture available at high resolutions?
• Creativity (40%) – e.g. is the content original, creative?
• Number of views (20%) – i.e. how popular is the content?

Each participant can submit up to 3 pictures according to the topic: “Ubuntu Billboards in Russia and Ukraine” and featuring at least one such billboard. Each picture must provide location metadata to pinpoint it to one of the major cities in each country where billboards are being displayed.

Pictures can be altered digitally with editing tools, but no logos, brand names or trademarks are allowed. Pictures must be submitted under a CC-BY-SA 3.0 license and their content must be suitable for general audiences, respecting the Ubuntu Code of Conduct.

How to participate

Taking part in the contest is easy:

1. Find a billboard near you. The cities in Russia are Chelyabinsk, Novosibirsk and Izhevsk; the cities in Ukraine are Kiev, Lvov, and Dnepropetrovsk. Russian billboard samples >
2. Take an awesome picture or more!. If you wish, edit it digitally. Remember to keep the geolocation data in the picture
3. Upload your pictures to Flickr. You might need to create an account there if you don’t have one already.
4. Go to the Ubuntu Billboards group in Flickr, and join it
5. Add your pictures to the Ubuntu Billboards group in Flickr. Remember there is a maximum of 3 pictures per participant.
6. Promote your work! Show off your cool Ubuntu pictures in the social networks

If you’ve got any question related to the contest, feel free to use the comments on this announcement or start a thread in the group’s discussion.

Looking forward to seeing more of those Ubuntu billboards in the wild!

Last cycle we saw quite a number of changes to the way that planning works for Ubuntu. Some of these changes are causing issues that the current implementation of the Ubuntu Status Tracker is not easily able to handle. The main issue that I have noticed from helping people setup their work items and blueprints for tracking is that tracking needs to not be so closely dependent on the Ubuntu release cycles. This is causing issues in two ways. The first that I have seen is that a feature is planned to be released in stages essentially X number of cycles. It currently isn’t possible to track a single blueprint across different cycles, let alone multiple cycles. If you try to do this anyway by changing the cycle every 6 months, then the Status Tracker sends out what are essentially validation errors because as far as it is aware, any milestone that isn’t in the cycle that it is looking at is in valid (ubuntu-13.04 is a raring milestone and isn’t valid on a saucy blueprint).

In order to discuss these issues and hopefully come up with a solution, I have created a meeting for the virtual Ubuntu Developer Summit which starts tomorrow.

It was a great pleasure to see the Reduced Shakespeare Company again last week. They are currently touring the UK with their show “The Complete Works of Shakespeare (abridge) (revised)” before they take up residence at the Leicester Square Theatre over the summer. This was the third time I’ve seen the Shakespeare show, albeit the first time in the “(revised)” form.

I’ve seen some of their other shows (I wrote about seeing the Complete World of Sports last summer) but have always had a soft spot for the Shakespeare show: It’s funny, but in an incredibly endearing way. The central concept is simple: Three people (Americans! Shock, horror) try to perform all of Shakespeare’s plays in an hour and a half, without realising how impossible their task is.

You don’t have to be familiar with Shakespeare to enjoy the show, although a little GCSE-level knowledge of a play or two helps. For the most part the updates in this revised version are subtle, work well and make sure that the show appeals to every

I was lucky enough to get plucked from the audience by Matt Pearson (right) to run around on stage like an idiot. This means I can chalk up playing Hamlet’s ego alongside a pig and a urine tester in other RSC productions. As I got onto stage Matt Rippy (second from right) managed to work into the melee of dialogue that was flying around that he recognised me from Twitter!

I chatted to the guys briefly afterwards, and got to recommend a local curry house to Gary Fannin (left). One of the great things about RSC shows is that they differ depending on who is performing in them. This cast are great guys and work really well together, so get along to see them.

Pin It

Today when going through the list of Google+ communities I saw a message in a Linux G+ community that links to a blog post in Sprial Linear that talks about GNOME developers ignoring user requests. This is heartbreaking.

The incident commenced when a user Eduard Valiauka reported this bug in GNOME’s bugzilla. A feature in GNOME 3.6′s GNOME Terminal (background configuration tab in Profile Preferences) is missing in GNOME 3.8. He described the problem with some detail and asked the GNOME Terminal developers to add back the feature in later GNOME releases.

The conflict started when Christian Persch, a GNOME Terminal developer, simply replied “No.” and marked the bug as “Resolved” and “Won’t fix”.

This is a serious improper repsonse. If one developer wants to object to this feature, he can explain it with reasons that will please the bug reporter and other users. A “No.” will make users confused as to why this feature should removed at the first place, let alone whether it should be re-added. Developers shouldn’t shut the conversation at once. If a lot of users agree that this feature should be included, there is no good reason to object.

Many users then left a comment on the bugzilla page to support this proposal, and most of them argued that this feature is a major one. Some even thought that GNOME is reducing features too much.

But at comment #40 GNOME Developer and Bugzilla admin Olav Vitters responded by threatening that all users who left a comment shall be banned from the Bugzilla.

Why? Users HAVE the right to make feature requests and support proposals. This isn’t trolling. This is just a way to make their favourite desktop environment better. And the developers are closing their ears.

If you are a developer, ALWAYS listen to your application/operating system/kernel’s feedback. They are the key to your success, they are the gold to your code.

So, don’t deny other’s feedback or bugs early, they actually help.

I blogged about the progress on our community website a while ago and we’re getting closer. A few community members helped on getting the content for the site ready. Here I’d like to take the time and thank all of them – they are all not the kind of person who end up in long arguments, but those who see that a task is important, ask what needs to get done and get right to it. A big kudos to all of you!

The first stage of the work is largely done. Michael Hall set up a wordpress test instance here where we put all the updated content, which is a great achievement already. It’s not only up to date, but also much more welcoming and friendly. The Canonical Web team should help us update the style to match the new ubuntu.com site.

What we need now is to get a few eyes over the test instance, so we can make sure all the content is accurate and makes sense. Any help is appreciated. Please just leave a comment on the blog post and we’ll take care of it.

Once we’re happy with the content, we will ask for the site to be put up in a more official place and then ask for redirects and links to be placed into all the right spots.

Thanks everyone. Let’s make the new community website happen together!

KDE Project:

• DCOP

A repost of Martin Gräßlin's blog Mir in Kubuntu for the benefit of Planet Ubuntu

As you might have seen in Jonathan’s blog post we discussed Mir in Kubuntu at the “Mataro Sessions II”. It’s a topic I would have preferred to not have to discuss at all. But the dynamics in the free software world force us to discuss it and obviously our downstream needs to know why we as an upstream do not consider Mir adoption as a valid option.
This highlights a huge problem Canonical created with Mir. I cannot just say “Canonical sucks”[1] to discard Mir as an option, I have to provide proper technical arguments why we won’t integrate Mir. I have to invest time to investigate the differences, advantages and disadvantages. As I have those arguments, I thought it might be a good idea to share them in a blog post.
The discussion started during a presentation about X11 and Wayland to my fellow team mates at Blue Systems. I decided to first explain X11 as I think one cannot understand the needs for Wayland without understanding X11. I did not intend to discuss Mir at all, but somehow the discussion drifted into the direction and the valid questions were raised about what are the differences and advantages of Mir or Wayland. What followed was kind of a rant about Ubuntu and Canonical [2]. So later the week we discussed “Mir in Kubuntu” in more detail to try to find answers to the many questions this raises for our downstream.
Introduction
Frustration and lost Motivation
Before I go into more detail I want to make one thing clear: Canonical is totally allowed to develop whatever they want. I’m totally fine with this and don’t care whether they develop another display server, an own os kernel or yet another desktop shell. I couldn’t care less. It’s Canonical/Mark’s money and he can invest it in any way he considers as useful. I wouldn’t even care if it would be proprietary software, that’s all fine.
What is not fine is causing a major disruption in the free software ecosystem by giving false technical arguments and doing bold statements about software Canonical does not contribute to. This is not acceptable. This was very frustrating and destroyed lots of trust I had in Canonical. It will be difficult to rebuild this trust. Canonical can be glad that it is the free software world and not the normal corporate world. There were quite some statements which could have raised the legal department in the normal corporate world[3]. It also cost lots of motivation at least on my side and I even questioned whether it’s still worth to be a member of the free software ecosystem. Instead of working together we now have a situation where members of the ecosystem become a competitor and which badmouth part of the software stack. A very frustrating situation.
There certainly are valid reasons for developing Mir which also make sense. Unfortunately they have not been presented so far. I’m quite sure that I know the reasons and if they would have been said straight away it would have been for me and other projects probably much easier. It would have taken away the frustration which the announcement caused and we would not need to discuss it at all, because those question marks would not exist. But apparently Canonical decided to give false technical arguments over the real ones.
Not ready yet
At the moment Mir is not there yet, this is important to remember. With the announcement we basically had four options on how to handle the situation.

1. Continue with the Wayland plan and ignore Mir
2. Switch to Mir and ignore Wayland
3. Support Mir and Wayland
4. Delay decision till Mir is ready

If I map our time line for Plasma Workspaces 2 against the time line of Mir I see no overlap. We want to support Wayland before Mir is ready. So delaying the decision would be a rather bad idea. It would just throw us back. This also means that option 2 is not valid especially as we would need to delay till Mir is ready for this to happen. So the only valid options are supporting both Mir and Wayland or only Wayland. At the moment the code is not ready yet to properly decide whether supporting Mir in addition to Wayland is a valid approach or not. Last time I checked the source base I hit a few stubs and then obviously stopped looking at the code as it’s not worth the effort yet. So we have to evaluate on the knowledge we already have and that doesn’t look good on the Mir side.
Wayland vs Mir
Possible Advantages of Mir over Wayland
The differences between Mir and Wayland are rather minimal. One of the differences is that Mir uses server allocated buffers while Wayland uses client side buffer allocation. I cannot judge whether this is an advantage or disadvantage. But I trust Kristian and the Wayland team more on that topic.
Another difference is that Mir uses test-driven development. To me development methodology is not a technical argument. I rather use a working system without unit tests than a system with unit tests that doesn’t work [4]. Also KWin does not use TDD. If I would consider TDD superior I would have to question my own development methodology.
But that’s it. That are the differences I found so far which could count as an advantage for Mir. But of course there is the advantage that Mir is going to be awesome. For the disadvantages I will spend a complete section on each point.
Distro specific
So far Mir is a one-distribution solution. So far no other distribution has shown any interest in packaging Mir even if it would become a working solution. Unfortunately I don’t have the ability to see into the future, but I can use the past and the present to get ideas for the future. The past tells me that there are other Canonical specific solutions which are not available in other distributions. I do not know of any distribution which packages Unity and from all I have heard it’s even impossible to package Unity on non-Ubuntu distributions. Given that it is quite likely that Mir will go the same road. It’s designed as a solution for Unity and if distros don’t package Unity there is no need to package Mir.
This has quite some influence on a possible adoption. I do not know of any kde-workspace developer using (K)Ubuntu. I do not see how anyone would work on it or how we should be able to review code or even maintain code. It would mean all the adoption would have to go into ifdef sections nobody compiles and nobody runs. This is the best way to ensure that it starts to bit-rot. Even more our CI system runs on openSUSE so not even the CI would be able to detect breakage. Of course a downstream like Kubuntu could develop the adoption and carry it as a patch on top of upstream, but I would highly recommend them to not do this as KWin’s source code churn is too high. Also we all agree that downstream patches are evil and we would no longer be able to help in any way downstream’s user from a support perspective.
Architecture
Mir’s architecture is centered around Unity. It is difficult to really understand the architecture of Mir as the specification is so full of buzz-words that I don’t understand it [5]. From all I can see and understand Unity Next is a combination of window manager and desktop shell implemented on top of Mir. How exactly this is going to look like I do not know. Anyway it does not fit our design of having desktop shell and window manager separated and we do not know whether Mir would support that. We also do not know whether Mir would allow any other desktop shell except Unity Next, given that this is the main target. Wayland on the other hand is designed to have more than one compositor implementations. Using KWin as a session compositor is an example in the spec.
License
Wayland is licensed like X under the MIT license, which served us well for a display server. I think this is a very good choice and I am glad that the Wayland developers decided for this license. Mir is licensed under GPLv3-only with CLA. I think this is very unsuited for such a part of the stack and would render quite a risk for usage in KDE Plasma. KWin (and most KDE software) is GPLv2-or-later, this would no longer be possible, it would turn our code into GPLv3-only as KWin (or any other software which would depend on mir-server) would be a derived work of Mir. I do not consider GPLv3-only software as a possible dependency of any core part of our application stack. It renders a serious threat for the future in case of a GPLv4 which is not compatible with GPLv3. I also dislike the CLA [6]. So from a licensing perspective Mir is hardly acceptable.
Unity Specific/No Protocol
One of the most important aspects from Wayland for us is the ability to extend the protocol. This has already been a quite important feature in X and we are using our own extensions over ICCCM and EWMH to implement additional functionality. Of course our workspace has own ideas and it is important for us to be able to “standardize” those and also make them available to others if they are interested. This is possible thanks to protocol extensions.
Mir doesn’t have a real protocol. The “inner core” is described as “protocol-agnostic”. This renders a problem to us if we would want to use it. Our architecture is different (as described above) and we need a protocol between the desktop shell and the compositor. If Mir doesn’t provide that we would need to use our own protocol. And that already exists, it is called “Wayland”. So even if we would support Mir, we would need the Wayland protocol?!? That doesn’t make any sense to me. If we need to run Wayland on top of Mir just to get the features we need, why should we run Mir at all?
But it gets worse, the protocol between Mir server and Mir clients is defined as not being stable. In fact it’s promised that it will break. That’s a huge problem, I would even call it a showstopper. For Canonical that’s fine – they control the complete stack and can just adjust all bits using the protocol like QMir.
For us this looks quite different. Given that the protocol may change any time and given that the whole thing is developed for the needs of Unity we have to expect that the server libraries are not binary compatible or that old version of the server libraries cannot talk with the latest client libraries. We would constantly have to develop against an unstable and breaking base. I know that this sounds overly pessimistic but I know of one case where a change got introduced in a Canonical protocol late in the release cycle completely breaking an application in Kubuntu which wanted to use the protocol. Given this experience I would not trust that the protocol doesn’t change one day before the release meaning that Kubuntu cannot ship.
This is not awesome, it’s awful. It means KWin will not work just fine on Mir.
I hope this shows that using Mir inside the KDE Plasma workspaces is not an option. There are no advantages which would turn Mir into a better solution than Wayland and at the same time there are several showstoppers which mean that we cannot integrate Mir – not even optionally in addition to Wayland. The unstable protocol and the licensing choice are clearly not acceptable.
What this means to Kubuntu
Question marks
For Kubuntu the Mir switch by Canonical created quite some questions. One of those questions is answered: Upstream has no interest in supporting it and would most likely not accept patches for support. With upstream not using Mir the question is how the graphics stack for Kubuntu will look like once Ubuntu switched to Mir? The questions cannot be answered right now but it doesn’t look good.
Patches to the stack
Ubuntu has always had one of the worst graphics stack in the free software world. I can see this in the bug tracker. The quality of the Mesa stack in Ubuntu is really bad. For Mir Ubuntu will have to patch the Mesa stack even further. This is nothing which I would like to see. Also Mesa needs to be packaged with Wayland support. But will Canonical continue to do this? If not, would Kubuntu (and other Ubuntu flavors) need to ship their own Mesa stack? What if the changes by Canonical are so large that a standard Mesa stack doesn’t run on top of the Ubuntu stack?
Switching Sessions
One of the advantages of free software is that one can select the desktop environment in the login manager. This looks like no longer be possible in a Mir world. Unity will run with a Mir system compositor with LightDM nested underneath. We will need either the X Server or a Wayland system compositor. So from the login manager it will not be possible to start directly into a session using a different system compositor. How will it continue to be possible to use both Unity and KDE Plasma on the same system? Running a Unity and a KDE Plasma (or GNOME or XFCE or anything) session at the same time seems to no longer be possible.
System Compositor
How deep into the system is the system compositor going to be? Will it be possible to disable the Mir system compositor and replace it with X or Wayland? What if the packages start to conflict? Will it still be possible to install Kubuntu and Ubuntu on the same system? Will Canonical care about it? Will the system compositor mean that one has to decide in Grub whether to boot Ubuntu or Kubuntu?
Packages from Where
So far X, Wayland and Mesa have been packaged by Canonical. But what about the future? Will there still be packages for X, will there be packages for Wayland? If not, where to take them from? Debian unstable, most likely. But Debian might be frozen. Will it be possible at all to use the Debian packages for X and Wayland in the Ubuntu stack? Will they meet the requirements for KDE Plasma[7]? If Canonical doesn’t provide Wayland packages, they would drop to universe, so Mesa in main cannot depend on them. How to get then Mesa with Wayland support?
Only Future can tell
Those questions cannot be answered right now. It will have to wait till Mir is integrated into the Ubuntu stack. Then Kubuntu developers will see how far the stack broke. I’m not really optimistic that it will still be possible to provide the Ubuntu flavors once the transition to Mir is done. I don’t think that Canonical has any interest in the community provided distributions on top of Ubuntu any more. There are many small changes in the direction which indicate that. But we will see, maybe I’m too pessimistic.
[1] Given how Canonical introduced Mir with incorrect information about Wayland I consider this as a valid approach to dismiss the technology.
[2] I was very fed up with Ubuntu at the time anyway because our bug tracker once again exploded after the Ubuntu release.
[3] I do admit that I thought about asking KDE e.V. to send an Abmahnung after the statement that KWin would just work fine on Mir.
[4] In fact I consider TDD as utter non-sense and as a useless methodology though some aspects are useful.
[5] “with our protocol- and platform-agnostic approach, we can make sure that we reach our goal of a consistent and beautiful user experience across platforms and device form factors”
[6] Yes I know that Qt also has a CLA, which I have signed. But for Qt there is also the KDE Free Qt Foundation agreement.
[7]Last week a feature hit KWin which I cannot test/use because the X-Server is too old in Debian testing.

Beginners, you are not alone! Many of us have tried to work through problems, only to be stymied when the steps to work through the problem don't work, and efforts to google those error messages yields nothing helpful. In fact, that's why I started this blog; not just to remind myself how to fix various problems, but to point the way to others who are trying to learn the way to CLI-foo.

A word to the wise who are trying to help beginners -- please don't leave out "obvious" steps!

I'll illustrate with a recent experience I had, trying to help a user work through a problem using Krusader.  A bit of googling told me that s/he wasn't alone; there are bugs filed on both launchpad[1] and bugs.kde.org[2]. First, kudos to the unnamed person for asking for help in IRC. That's an excellent place to get step-by-step help.

In the launchpad bug, a helpful person posted a series of step to fix the bug by building an updated version from source:
Made my own deb from 2.4.0.beta3 which solved the `krarc` problem.
How to:
0 Uninstall Krusader
1 download source from http://www.krusader.org/
2 cd krusader-2.4.0-beta3
3 cmake -DCMAKE_INSTALL_PREFIX=/usr/ -DQT_INCLUDES=/usr/share/qt4/include
4 make
5 sudo checkinstall
Don´t forget in step 5 to set version on 3 instead of beta3, only digits are allowed in versions in debs nowadays.The unfortunate user came back into IRC, and posted this error message:
xy@xy-ubuntu:~/Downloads$ cmake -DCMAKE_INSTALL_PREFIX=/home/user/app/krusader-2.4.0-b3-2 -DQT_INCLUDES=/usr/share/qt4/include
CMake Error: The source directory "/home/jony/Downloads" does not appear to contain CMakeLists.txt.Having struggled through this process myself, I see what's missing in the instructions. The person posting them didn't realize, I'm sure, that steps were being left out, because they have become automatic. To a beginner, they are bewildering.

Step zero, uninstall, is unambiguous. So far, so good.
Step one, download source, leaves out the best practice, which is to create a directory into which you want your source file! Probably not specified as people have their own schemes of organization, but in general, I advise a ~/kde folder into which I put all source files and builds (thank you for your advice on that, Myriam!)

So step one should be: a) open a konsole, and type or paste: mkdir kde && cd kde && mkdir krusader && cd krusader && wget http://downloads.sourceforge.net/krusader/krusader-2.4.0-beta3.tar.bz2
Then, step b) tar xf krusader-2.4.0-beta3.tar.bz2

Then, do step two, which is correctly stated as cd krusader-2.4.0-beta3

Step three is almost all there, with a missing note: be sure you have cmake installed! My bet is that my troubled user did not.

Cmake ran uneventfully, as did make, so steps three and four are perfect. Step five, however, does not work at all for me, because I don't have checkinstall installed. And I don't think I'll do that for the sake of finishing this blogpost! I don't need a deb file, when Krusader is available from source.

I hope our Kubuntu packagers will get the newest version packaged soon, and make it easy for my troubled user.

1. https://bugs.launchpad.net/ubuntu/+source/krusader/+bug/1065110
2. https://bugs.kde.org/show_bug.cgi?id=294542

In the broadest sense Chrome OS is a consumer of Google Services. But it is not alone in this role. This topic has been broadly discussed in the context of Google services for Apple’s iOS and others. I am thinking of Google Maps and Google Now.

I’ve been on the fence relative to Chrome OS; I’m waiting for it to mature to the level where it offers something I can not get elsewhere. In many ways Chrome OS will not be wildly successful until it does.

In addition to being a supporter of Chrome OS and I am also an avid supporter of Ubuntu. I recently discovered if you add the Chrome Browser (Version 27.0.1453.81 beta) to Ubuntu 13.04 something magical happens. View the image at the top of this post as evidence.

I have Ubuntu running with all of my Google Chrome apps docked to the Unity launcher.

If this excites you then the next question becomes how hard is it to make the transformation? The answer is easy.

Install Chrome Beta

I was only able to get this to work using the Chrome beta package from Google. To be clear, Chrome stable from Google or the Ubuntu Software Centre did not work. A little frustrating is the fact the installation of the Google package throws an error.

Rumor has it a fix is coming, but until it arrives install the dependent “libudev0″ file from launchpad.

• For Ubuntu 13.04 32 bit click here
• For Ubuntu 13.04 64 bit click here

Next – download the Chrome installation package from here.

Open and install with the Ubuntu Software Centre by right clicking from Nautilus.

Add Your Apps to Chrome

When Chrome is installed, the next item of business is to add your apps from the Chrome Web Store. If you have sync enabled, login and they will install from the cloud.

Update Ubuntu Unity

The last step is to update Unity with your Google Chrome Apps. Open Chrome and go to the apps page. Right click the desired app and select “create shortcuts”.

Ubuntu will prompt for the location(s) of the shortcut; select applications menu.

Close Chrome and open Unity and select applications. Scroll through the application list until the Chrome app you just installed appears and click to open. When the Chrome apps loads right click the icon on the launcher to lock it into place. Repeat with other apps until you are satisfied with the result.

Wrap Up

The result of all this is Chrome apps are first class citizens on the Ubuntu desktop. In addition, all of your local apps are available. The advantages of this solution are numerous. For one, your’re not locked into Google hardware if you already have your own or prefer something different. You also benefit from the other features of Ubuntu which include messaging and fast execution. The only disadvantage is this is not Chrome OS.

I will admit I love living in the cloud or on the fringes of the cloud as I feel I have access to whatever I need whenever I want it.

The only issue I have is the lack of apps in some cases. For example, I am looking for an adequate replacement for the graphic applications Gimp and Inkscape. They may or may not exist.

Either way the Ubuntu Chrome solution is a good fit.

The post Ubuntu – A Replacement for Chrome OS appeared first on j-Baer.

I’ve been very busy with life and work in general and I haven’t blogged for a few months now. I finally get the chance to talk about something I worked on in my spare time.

I use Cryptkeeper to decrypt and mount some encrypted directories that I have in my Ubuntu One space but I noticed that its applet didn’t make use of Ubuntu’s Appindicators. Since the whitelist for old style applets had been removed in Raring, I was left with no way to use Cryptkeeper. For this reason I rolled up my sleeves and I worked on a patch to (optionally) enable support for Appindicators in the program.

The main problem I had to face is the fact that Appindicators don’t support right click gestures, so I had to create an entry in the indicator (labelled “Edit”) to allow users to get information, change passwords or delete encrypted directories. Clicking on that entry pops up a dialog which then hooks into the old dialogs to perform the said operations.

I uploaded my work in Saucy and made packages for Precise and Raring available in my PPA.

I hope you enjoy my work!

I mentioned in my last post that I have been using Taskwarrior. I have grown fond of this command line application. Applications like this remind me that just because it is a command line only application does not mean that it skimps on the features.
One concern I had is I wanted an application for my Android phone. After subscribing to the Google Group I realized their  is a functional Android app in development. Although still in development it looks promising, I installed it on my Android phone and have been using it the last couple weeks. One drawback is no auto sync capability yet so you have to manually copy over your completed.data and pending.data files.
If interested in trying out the Android app I will briefly outline the steps. You can get the APK here. If you subscribe to the mailing list new versions will be posted as they become available. I downloaded the APK to my computer and copied it to my phone. I copied it to the base level of my SD card so it was easy to find. I then installed the application APK manager developed by Magma Mobile Apps. Their are a couple versions of this app, by different developers, but this particular one was recommended to me and is available in the app store. After launching this app select 'Install' and the application should find the APK for you. On my phone the APK was called org.svij.taskwarriorapp.
NOTE:Be sure to enable the option to install the applications from unknown source on our Android. Open your Android system settings and click on Applications (Programs for some of the HTC devices) and check the option Unknown source. Those of you who are on Android ICS 4.0 you will find these settings under the Security settings.
After installing the app you can copy your completed.data and pending.data files from the hidden directory. ~/.task on your Ubuntu computer to the Taskwarior folder on your sdcard.
If you are interested you can get the code from the git repo here. The project is looking for some android developers so If you would like to build up some karma points please consider lending your skills to this fine project.

When I bought Samsung ARM Chromebook few months ago I had no idea about UCM profiles and burnt speakers (left is dead, right is resting)…

This was good lesson. I learnt more about how UseCase Manager works, took profiles from ChromeOS and added them into Ubuntu so other users will be a bit more safe (due to lack of testers it took months to merge it into “precise” and “quantal” releases).

During last months I had discussions with some Debian, Ubuntu, Fedora developers about how to solve such problems and how to keep UCM profiles shared between distributions.

In meantime Liam Girdwood pointed me to (not used) UCM git tree at ALSA Project server. So finally I spent some time and sent Ubuntu ones for merging.

I also got newer profiles for OMAP4 devices and some updates for Chromebook ones.

The idea is to collect UCM profiles, keep them in one place and share in each distribution packages. So if your hardware has profiles created then join us to make users life easier.

Related content:

1. Chromebook hackers: unite!
2. Chromebook support for Ubuntu
3. I did not finished with Chromebook
4. Dear Samsung: @#$@%@!!!!11!!$#$# you!
5. How to fry speakers in your Chromebook

All rights reserved © Marcin Juszkiewicz
Call for ALSA UCM profiles was originally posted on Marcin Juszkiewicz website

I'm writing a bunch of new code these days for Ubuntu Touch's Image Based Upgrade system.  Think of it essentially as Ubuntu Touch's version of upgrading the phone/tablet (affectionately called phablet) operating system in a bulk way rather than piecemeal apt-gets the way you do it on a traditional Ubuntu desktop or server.  One of the key differences is that a phone has to detour through a reboot in order to apply an upgrade since its Ubuntu root file system is mounted read-only during the user session.

Anyway, those details aren't the focus of this article.  Instead, just realize that because it's a pile of new code, and because we want to rid ourselves of Python 2, at least on the phablet image if not everywhere else in Ubuntu, I am prototyping all this in Python 3, and specifically 3.3.  This means that I can use all the latest and greatest cool stuff in the most recent stable Python release.  And man, is there a lot of cool stuff!

One module in particular that I'm especially fond of is contextlib.  Context managers are objects implementing the protocol behind the with statement, and they are typically used to guarantee that some resource is cleaned up properly, even in the event of error conditions.  When you see code like this:

with open(somefile) as fp:
    data = fp.read()

you are invoking a context manager.  Python was clever enough to make file objects support the context manager protocol so that you never have to explicitly close the file; that happens automatically when the with statement completes, regardless of whether the code inside the with statement succeeds or raises an exception.

It's also very easy to define your own context managers to properly handle other kinds of resources.  I won't go into too much detail here, because this is all well-established; the with statement has been, er, with us since Python 2.5.

You may be familiar with the contextlib module because of the @contextmanager decorator it provides.  This makes it trivial to define a new context manager without having to deal with all the intricacies of the protocol.  For example, here's how you would implement a context manager that temporarily changes the current working directory:

import os
from contextlib import contextmanager

@contextmanager
def chdir(dir):
    cwd = os.getcwd()
    try:
        os.chdir(dir)
        yield
    finally:
        os.chdir(cwd)

In this example, the yield cedes control back to the body of the with statement, and when that completes, the code after the yield is executed.  Because the yield is wrapped inside a try/finally, it is guaranteed that the original working directory is restored.  You would use this code like so:

with chdir('/tmp'):
    print(os.getcwd())

So far, so good, but this is nothing revolutionary.  Python 3.3 brings additional awesomeness to contextlib by way of the new ExitStack class.

The documentation for ExitStack is a bit dense, and even the examples didn't originally make it clear to me how amazing this new API is.  In my opinion, this is so powerful, it changes completely the way you think about deploying safe code.

So what is an ExitStack?  One way to think about it is as an extensible context manager.  It's used in with statements just like any other context manager:

from contextlib import ExitStack
with ExitStack() as stack:
    # do some magical stuff

Just like any other context manager, the ExitStack's "exit" code is guaranteed to be run at the end of the with statement.  It's the programmable extensibility of the ExitStack where the cool stuff happens.

The first interesting method of an ExitStack you might use is the callback() method.  Let's say for example that in your with statement, you are creating a temporary directory and you want to make sure that temporary directory gets deleted when the with statement exits.  You could do something like this:

import shutil, tempfile
with ExitStack() as stack:
    tempdir = tempfile.mkdtemp()
    stack.callback(shutil.rmtree, tempdir)

Now, when the with statement completes, it calls all of its callbacks, which includes removing the temporary directory.

So, what's the big deal?  Let's say you're actually creating three temporary directories and any of those calls could fail.  To guarantee that all successfully created directories are deleted at the end of the with statement, regardless of whether an exception occurred in the middle, you could do this:

with ExitStack() as stack:
    tempdirs = []
    for i in range(3):
        tempdir = tempfile.mkdtemp()
        stack.callback(shutil.rmtree, tempdir)
        tempdirs.append(tempdir)
    # Do something with the tempdirs

If you knew statically that you wanted three temporary directories, you could set this up with nested with statements, or a single with statement containing multiple backslash-separated targets, but that gets unwieldy very quickly.  And besides, that's impossible if you only know the number of directories you need dynamically at run time.  On the other hand, the ExitStack makes it easy to guaranteed everything gets cleaned up and there are no leaks.

That's powerful enough, but it's not all you can do!  Another very useful method is enter_context().

Let's say that you are opening a bunch of files and you want the following behavior: if all of the files open successfully, you want to do something with them, but if any of them fail to open, you want to make sure that the ones that did get open are guaranteed to get closed.  Using ExitStack.enter_context() you can write code like this:

files = []
with ExitStack() as stack:
    for filename in filenames:
        # Open the file and automatically add its context manager to the stack.
        # enter_context() returns the passed in context manager, i.e. the 
        # file object.
        fp = stack.enter_context(open(filename))
        files.append(fp)
    # Capture the close method, but do not call it yet.
    close_all_files = stack.pop_all().close

(Note that the contextlib documentation contains a more efficient, but denser way of writing the same thing.)

So what's going on here?  First, the open(filename) does what it always does of course, it opens the file and returns a file object, which is also a context manager.  However, instead of using that file object in a with statement, we add it to the ExitStack by passing it to the enter_context() method.  For convenience, this method returns the passed in object.

So what happens if one of the open() calls fail before the loop completes?  The with statement will exit as normal and the ExitStack will exit all the context managers it knows about.  In other words, all the files that were successfully opened will get closed.  Thus, in an error condition, you will be left with no open files and no leaked file descriptors, etc.

What happens if the loop completes and all files got opened successfully?  Ah, that's where the next bit of goodness comes into play: the ExitStack's pop_all() method.

pop_all() creates a new ExitStack, and populates it from the original ExitStack, removing all the context managers from the original ExitStack.  So, after stack.pop_all() completes, the original ExitStack, i.e. the one used in the with statement, is now empty.  When the with statement exits, the original ExitStack contains no context managers so none of the files are closed.

Well, then, how do you close all the files once you're done with them?  That's the last bit of magic.  ExitStacks have a .close() method which unwinds all the registered context managers and callbacks and invokes their exit functionality.  So, after you're finally done with all the files and you want to clean everything up, you would just do:

close_all_files()

And that's it.

Hopefully that all makes sense.  I know it took a while to sink in for me, but now that it has, it's clear the enormous power this gives you.  You can write much safer code, in the sense that it's easier to ensure much better guarantees that your resources are cleaned up at the right time.

The real power comes when you have many different disparate resources to clean up for a particular operation.  For example, in the test suite for the Image Based Upgrader, I have a test where I need to create a temporary directory and start an HTTP server in a thread.  Roughly, my code looks like this:

@classmethod
def setUpClass(cls):
    cls._cleaner = ExitStack()
    try:
        cls._serverdir = tempfile.mkdtemp()
        cls._cleaner.callback(shutil.rmtree, cls._serverdir)
        # ...
        cls._stop = make_http_server(cls._serverdir)
        cls._cleaner.callback(cls._stop)
    except:
        cls._cleaner.pop_all().close()
        raise

@classmethod
def tearDownClass(cls):
    cls._cleaner.close()

Notice there's no with statement there at all. :)   This is because the resources must remain open until tearDownClass() is called, unless some exception occurs during the setUpClass().  If that happens, the bare except will ensure that all the context managers are properly closed, leaving the original ExitStack empty.  (The bare except is acceptable here because the exception is re-raised after the resources are cleaned up.)  Even though the exception will prevent the tearDownClass() from being called, it's still safe to do so in case it is called for some odd reason, because the original ExitStack is empty.

But if no exception occurs, the original ExitStack will contain all the context managers that need to be closed, and calling .close() on it in the tearDownClass() does exactly that.

I have one more example from my recent code.  Here, I need to create a GPG context (the details are unimportant), and then use that context to verify the detached signature of a file.  If the signature matches, then everything's good, but if not, then I want to raise an exception and throw away both the data file and the signature (i.e. .asc) file.  Here's the code:

with ExitStack() as stack:
    ctx = stack.enter_context(Context(pubkey_path))
    if not ctx.verify(asc_path, channels_path):
        # The signature did not verify, so arrange for the .json and .asc
        # files to be removed before we raise the exception.
        stack.callback(os.remove, channels_path)
        stack.callback(os.remove, asc_path)
        raise FileNotFoundError

Here we create the GPG context, which itself is a context manager, but instead of using it in a with statement, we add it to the ExitStack.  Then we verify the detached signature (asc_path) of a data file (channels_path), and only arrange to remove those files if the verification fails.  When the FileNotFoundError is raised, the ExitStack in the with statement unwinds, removing both files and closing the GPG context.  Of course, if the signature matches, only the GPG context is closed -- the channels_path and asc_path files are not removed.

You can see how an ExitStack actually functions as a fairly generic resource manager!

To me, this revolutionizes the management of external resources.  The new ExitStack object, and the methods and semantics it exposes, make it so much easier to manage those resources, guaranteeing that they get cleaned up at the right time, once and only once, regardless of whether errors occur or not.

ExitStack takes the already powerful concept of context managers and turns it up to 11.  There's more you can do, and it's worth spending some time reading the contextlib documentation in Python 3.3, especially the examples and recipes.

As I mentioned on Twitter, it's features like this that make using Python 2 seem downright barbaric.

This is a follow-up to the End of Life warning sent last month to
confirm that as of today (May 9, 2013), Ubuntu 11.10 is no longer
supported. No more package updates will be accepted to 11.10, and
it will be archived to old-releases.ubuntu.com in the coming weeks.

The original End of Life warning follows, with upgrade instructions:

Ubuntu announced its 11.10 (Oneiric Ocelot) release almost 18 months
ago, on October 13, 2011. As with the earlier releases, Ubuntu
committed to ongoing security and critical fixes for a period of 18
months. The support period is now nearing its end and Ubuntu 11.10
will reach end of life on Thursday, May 9th. At that time, Ubuntu
Security Notices will no longer include information or updated
packages for Ubuntu 11.10.

The supported upgrade path from Ubuntu 11.10 is via Ubuntu 12.04.
Instructions and caveats for the upgrade may be found at
https://help.ubuntu.com/community/PreciseUpgrades. Ubuntu 12.04
continues to be actively supported with security updates and
select high-impact bug fixes. All announcements of official security
updates for Ubuntu releases are sent to the ubuntu-security-announce
mailing list, information about which may be found at
https://lists.ubuntu.com/mailman/listinfo/ubuntu-security-announce.

Since its launch in October 2004 Ubuntu has become one of the most
highly regarded Linux distributions with millions of users in homes,
schools, businesses and governments around the world. Ubuntu is Open
Source software, costs nothing to download, and users are free to
customise or alter their software in order to meet their needs.

On behalf of the Ubuntu Release Team,

Adam Conrad

Originally posted on the ubuntu-announce mailing list on Thu May 9 20:06:34 UTC 2013.