If you missed it, I posted an earlier round of SDK apps a couple weeks ago.  Well the pace of new app development didn’t slow down, so here I am again with another round of apps being written with what is still an alpha version of the Ubuntu SDK.

Core Apps Update

First an update on the Ubuntu Touch Core Apps project.  I highlighted a few of these already in my last post, but in the past week those apps have received several updates, and others have had the initial features start to land as well.

Calculator

In addition to being able to scroll back through previous calculations, the Calculator App developers have now added the ability to start a new calculation by dragging up and “tearing off” the current one, moving it into the history for later browsing.

Clock

The Clock app has been given a slight visual update on the main screen, and all new stop watch functionality too!

Calendar

The Calendar App now shows events for the day, and will take over the full screen to let you easily view your busy schedule.

Weather

The weather app too has added some visual features, and with the detailed design workflows just released, you can expect to see major changes coming to this app soon.

RSS Reader

The RSS Reader got off to a good start this week, allowing you to add feeds and read articles, either all aggregated together or one feed at a time.

File Manager

Finally, the File Manager is now working enough to let you browse through files and folders, and even open files in the appropriate application

Independent Apps

A man of many talents

Developer Ashley Johnson has been working on a couple of new apps using the Ubuntu SDK.  His first was a touch-friendly version of the Ubuntu Software Center:

Click for video

Followed up earlier this week with an Ubuntu Touch client for the Pivotal Tracker project management web service:

Click for video

Ubuntu Loves Reddit

We must, because there is not one, not two, but three separate Reddit apps being written with the Ubuntu SDK.

By Victor Thompson

By Bram Geelen

By yours truly

Ultimate Time Waster

Even Canonical’s VP of Engineering, Rick Spencer, has gotten in on the fun.  Though his app, which gathers funny pictures from across the internet for easy browsing, it’s as productivity-focuses as you might expect.

Dawning of the age of Aquarius

Canonical’s Stuart Langridge (aquarius on IRC, for those who don’t get the reference) is our resident audio-phile, which might explain why he’s written two music apps with the Ubuntu SDK, one for Ext.fm and another for Ubuntu One’s Music Streaming service.

Zeegaree

Developer Micha? Pr?dotka is porting his desktop timer app Zeegaree to the Ubuntu SDK

GPS Workout tracker

Fitness trackers are becoming more and more popular, especially as mobile apps.  Ready to meet this demand is Marin Bareta and his workout tracker for Ubuntu Touch

uQQ

QQ, the popular instant messaging service out of China, is getting it’s own native uQQ Ubuntu SDK client thanks to developer ? ? (shared to me by Szymon Waliczek)

Resistor Color Codes

I’m not electrical engineer, so I don’t know exactly what this does, but if you do I bet it would be handy to have available in your pocket, so thank Oliver Marks for making it.

Stock Tracker

Last but not least, I just saw this stock price tracker from Robert Steckroth

If you are writing an Ubuntu SDK app, or have come across one that I haven’t blogged about yet, be sure to drop me an email or ping me on IRC.  I get the feeling this isn’t the last SDK Apps update I’ll be posting.

Sitting on a cornflake, waiting for the van to come.
Corporation t-shirt, stupid bloody Tuesday.
– I am the walrus, The Beatles

Although the “OOo does not print on Tuesdays” OpenOffice.org-bug is long fixed, OpenOffice.org never indemnified Tuesday for its loss in reputation. This is unacceptable and Tuesdays rage at the event has even passed on to its successful successor: LibreOffice.

Now, Tuesday is a weekday and as such, money does not mean that much to it. After some consultation with Tuesday, it was concluded that the only way to indemnify Tuesday was to make the other weekdays suffer the same fate. Since the set of weekdays is luckily limited, this was easily considered technically feasible, even if at some minor inconvenience for the users of LibreOffice.

Toolbar popup of the new feature

To limit the impact for users, instead of silently failing to act when requested to print on a non-Tuesday, for the comfort of the users of LibreOffice a notification was added that explains the situation. Tuesday — after some heated discussion — gave license to this modification.

message on trying to print on non-Tuesdays

It is intended to ship this extension pre-bundled with all LibreOffice releases until Tuesdays rage is soothed. It is hoped this will happen quickly as both contributors and users of LibreOffice are known for their lack of sympathy for monopoly in any kind, shape or form — explicitly including the exclusive right of a weekday to print. For those of you excited to try out this thrilling new feature right now, the extension is available for download here:

It has to be noted that the extension is written purely in Python and is completely self-contained: it can either be treated as the oxt to be installed or as a zip file containing the source code: unpack it with the archive program of your choice, modify it to your hearts content and run the script called ‘build’ that you find in there. This will recreate a new (modified) extension.

I’ve been involved with Ubuntu for quite a while now, and part of my journey has included accumulating a bunch of Ubuntu T-shirts. I now have so many that I can’t possibly wear them all, so my wife gave me a really cool gift today: a quilt made out of a bunch of my old Ubuntu T-shirts! :) Check it out:

Fun *and* cozy!!

The quality team invites you to a testing event for the final beta iso images. We'll be providing real-time help (IRC, or even one on one video hangouts if needed), encouraging you to download the final beta images, install, upgrade and test them out with us. You only need yourself, a machine (virtual or real!) and a bit of willingness to learn. We'll even be broadcasting for part of the event on ubuntuonair. So here's the details you need to know:

Tuesday April 2nd, 2013

• 1800 UTC - 2200 UTC 
• Quality team members are dedicated to hanging out in #ubuntu-quality executing testcases and helping answer questions
•  2000 UTC: 
• We'll be streaming live on ubuntuonair doing live testing demos and offering help
• Basic iso test install
• More exotic examples -- netboot, server, non-english
• Your requests!

As some of you may know the dash team has been working to get the new smart scopes functionality in the dash ready for 13.04; this functionality delivers a far more comprehensive dash experience, performing searches over 50 or more different data sources. This feature makes the dash dramatically more useful by searching a far wider range of data sources and returning more relevant results.

The team has been working in a PPA to get the feature ready, and as we are past feature freeze, had filed a Feature Freeze Exception (FFe) to get this into 13.04. After an extensive amount of work to get the feature ready, unfortunately the dash team doesn’t consider it mature enough for 13.04 — it is nearly there, but doesn’t meet the quality needs for Ubuntu. As such the team has decided not to pursue landing in in 13.04 and to instead move it to the Ubuntu 13.10 cycle where it will be developed as soon as the archive opens. As I mentioned earlier, this feature has been developed in a PPA and has not landed in 13.04 yet, so there are no actual changes to the archive.

Some of you may have some questions about this so we have prepared a short FAQ below. I have also notified our governance boards to ensure they are aware of the change. Feel free to ask any questions in the comments!

The FFE (1154229) got a sabdfl override and is now being rejected, how come?

A sabdfl override always has high requirements regarding code quality and User Experience. After looking at the current status of the smart scopes project we decided that the User Experience simply needs more work and it does not meet the quality requirements for Ubuntu. We would prefer to delay the feature until the next release cycle to ensure that it is rock solid.

Why was this feature being pushed at the last minute?

We believe the feature does provide additional benefit to Ubuntu Users by improving the search experience in the Dash, which is Unity’s weak spot. Landing the feature in 13.04 would have given us 1 additional cycle on the way to 14.04 to train and improve the suggestions provided by the server and further refine the overall Dash experience.

When, if at all, will the feature make its way into Ubuntu?

We are planning to provide the feature in a PPA for Ubuntu Raring which will be always rebased on Unity shipped on Raring. It will land it as soon as we are confident enough on the feature quality in Ubuntu S.

What about the in-dash purchases feature? Will that be landing?

There were some final outstanding issues with in-dash purchases and we are striving to have a conclusion to this ready for early next week (week beginning 1st April).

What about the privacy enhancements that were part of the smart scopes project?

It is unfortunately not possible to get the privacy enhancements from the smart scopes projects without the larger project itself. Smart Scopes would have allowed to disable individual scopes and limit network access for searches at all. In Ubuntu 13.04 you will still be able to disable all server communications through the settings apps. You can also remove the scopes and lenses you are not interested in using them by directly uninstalling the corresponding packages.

Today with my paycheck Canonical reminded me that I started working at Linaro 35 months ago…

Time flies fast and things are changing even faster. I am working in the same team as started but it has 4th or even 5th name with most of first members gone or moved to other teams. 3rd manager at Linaro (and first one not from Canonical) and 5th or 6th at Canonical (depends on how to count).

At the same time Linaro grown from 20-25 people who met at private meeting on first day of UDS-M in Belgium to a much bigger number. I lost track long time ago as it is hard to remember everyone especially when people move into Linaro and then go back to member companies, switch teams, companies (like going from member company to Linaro directly).

I will have to make such decision in next 1-2 months as I am one of the few reminding Canonical ones…

All rights reserved © Marcin Juszkiewicz
35 months at Linaro was originally posted on Marcin Juszkiewicz website

Continuing with the work to refine and improve how we build Ubuntu in an open, transparent, and collaborative way, I want to take a few minutes to discuss some work going on to improve the regularity of our planning and the benefits this brings.

Traditionally planning for Ubuntu has worked like this.

• We ship a release.
• Shortly before a release we rapidly prepare blueprints for the next Ubuntu Developer Summit (UDS). Everyone is welcome to participate.
• We discuss topics at the UDS and jot down work items into blueprints.
• We then execute on those work items over the course of the six month period.
• We track this work on status.ubuntu.com and use burndown charts to visualize this progress.

While this has served us well, there are a few problems with this approach. The most notable issue is that we work in software, and a lot changes in software in a six month period. This means we define a set of work items, prepare the burndown, and then if requirements or direction changes it can be difficult to reflect those changes across our community and we have to go and postpone a bunch of work items and re-build our burndowns. This means that even though the changes are made to open blueprints, it can cause folks across our community to be out of sync. It also presents the misconception that everything at UDS is locked in for the duration of the six month cycle. If something changes in our strategy or a new opportunity opens up, it can be difficult to change course with everyone on the same page.

Solving this is part of our theme of making Ubuntu engineering as transparent and agile as possible.

One approach we are experimenting with in the Ubuntu Engineering Management team at Canonical is to increase the regularity and transparency of how we plan. Instead of locking in every six months we will do it like this:

• We host the virtual UDS (vUDS) every three months and use the event as a means to plan out the next three months of work. All discussions are open, everyone is welcome to participate.
• Blueprints will be used to track that work and work items will be divided up into monthly milestones.
• On the last week of every month we will review the work performed in the last month to see how well it was completed and then plan the forthcoming month’s work. This provides an open opportunity to identify blockers, define new goals, and change coarse if needed.
• A new burndown chart will be generated on status.ubuntu.com and we will host a Google+ Hangout presenting the goals for the next month to ensure that everyone is fully up to speed on what is going on.

Now, to set expectations clearly: this is just an idea for how to improve this workflow, and we are doing it for the first time this week, but the idea is that it will dramatically increase the transparency of which teams are working on what, making it easier for others to (a) know what is going on and (b), participate in areas of interest.

My team is currently preparing the work items for April and you will be able to see the final burndown here when it is complete. From there you will be able to see all the blueprints.

I will provide plenty of feedback on what is working well and less well, and your feedback is welcomed, as ever, in the comments.

Building Re-usable Processes

As I mentioned in my previous blog entry, we want to make virtual UDS an event that is repeatable and useful for not just UDS but also for domain-specific events too (such as a LoCo themed UDS). The goal is that this event format is repeatable for our wider community.

Likewise, the monthly planning process is also designed to be repeatable for our wider community too, making it simple to get everyone on the same page for planning and executing on awesome projects.

As ever, feedback is always welcome, but I think this combo of a wider planning event every three months combined with monthly work item sync-ups and planning will result in a pretty effective formula for helping Ubuntu to be as effective, transparent, and collaborative as possible.

The Ubuntu Developer Advisory Team has been in place for two or three release cycles already and it’s been a fun journey so far. We’ve got in touch with many many new contributors and old contributors as well. If you don’t know what this team does, here’s what our wiki page has to say:

We

• Reach out to new contributors, thank them for their work and get feedback.
• Reach out to people who might be ready to apply for upload rights and help them.
• Reach out to contributors that went inactive and get feedback from them and offer help.

I personally found this very rewarding as I got to talk to many new contributors and see how they feel about Ubuntu Development.

You can help!

If the above sounds interesting to you and you enjoy engaging socially, if you have made a few experiences in Ubuntu Development and want to help out, please talk to me or comment below. It’d be great to have you on board!

This site is using cookies. Some of them are to track you as I use Google Analytics. Other may keep your name/email/website when you write comments on my blog.

We have new law here in European Union that visitors should get notification when website is using cookies. You know — privacy stuff etc. Lot of people does not even have any idea what this whole noise is about. There are websites for them with all that not even needed information — your search engine will point you there (and use few cookies in meantime).

I do not plan to add any of those annoying popups which will tell that there are cookies in use. Once you see such one you get cookie — cause website needs a way to remember that you clicked “yes, I know, get off my screen” button. You will not see such one here.

There is a text box in right column about cookies — go, read, decide would you read my blog or not. It is your choice and always was.

PS. I added tags into post just to get this post shown on each RSS aggregator I am/was listed.

UPDATE: added small header.

All rights reserved © Marcin Juszkiewicz
Cookies blabla… was originally posted on Marcin Juszkiewicz website

I just pushed out a new python-dbusmock release 0.6.

Calling a method on the mock now emits a MethodCalled signal on the org.freedesktop.DBus.Mock interface. In some cases this is easier to track than parsing the mock’s log or using GetMethodCalls. Thanks to Lars Uebernickel for this.

DBusMockObject.AddTemplate() and DBusTestCase.spawn_server_template() can now load local templates from your own project by specifying a path to a *.py file as template name. Thanks to Lucas De Marchi for this feature.

I also wrote a quite comprehensive template for systemd’s logind. It stubs out the power management functionality as well as user/seat/session objects, and is convincing enough for loginctl. Some bits like AttachDevice is missing, as this sounds unlikely to be required for D-BUS mock tests, but please let me know if you need anything else.

The mock processes now terminate automatically if their connected D-BUS goes down, as advertised in the documentation.

You can get the new tarball from Launchpad, and I uploaded it to Debian experimental now.

Enjoy!

The latest entry in my critically acclaimed series on Mir and Wayland!

Wayland, Mir, and X - different projects

Apart from the architectural differences between them, which I've covered previously, Mir and Wayland also have quite different project goals. Since a number of people seem to be confused as to what Wayland actually is - and that's not unreasonable, because it's a bit complicated - I'll give a run-down as to what all these various projects are and aim to do, throwing in X11 as a reference point.

X11, and X.org

Everyone's familiar with their friendly neighbourhood X server. This is what we've currently got as the default desktop Linux display server. For the purposes of this blog post, X consists of:

The X11 protocol

You're all familiar with the X11 protocol, right? This gentle beast specifies how to talk to an X server - both the binary format of the messages you'll send and receive, and what you can expect the server to do with any given message (the semantics). There are also plenty of protocol extensions; new messages to make the server do new things, like handle more than one monitor in a non-stupid way.

The X11 client libraries

No-one actually fiddles with X by sending raw binary data down a socket; they use the client libraries - the modern XCB, or the boring old Xlib (also known as libX11.so.6). They do the boring work of throwing binary data at the server and present the client with a more civilised view of the X server, one where you can just XOpenDisplay(NULL) and start doing stuff.
Actually, the above is a bit of a lie. Almost all the time people don't even use XCB or Xlib, they use toolkits such as GTK+ or Qt, and they use XLib or XCB.

The Xorg server

This would be the bit most obviously associated with X - the one, the only, the X.org X server! This is the actual /usr/bin/X display server we all know and love. Although there are other implementations of X11, this is all you'll ever see on the free desktop. Or on OS X, for that matter.

So that's our baseline stack - a protocol, one or more client libraries, a display server implementation. How about Wayland and Mir?

The Wayland protocol

Also different from X11 is that everything's treated as an extension - you deal with all the interfaces in the core protocol the same way as you deal with any extensions you create. And you create a lot of extensions - for example, the core protocol doesn't have any buffer-passing mechanism other than SHM, so there's an extension for drm buffers in Mesa. The Weston reference compositor also has a bunch of extensions, both for ad-hoc things like the compositor<->desktop-shell interface, and for things like XWayland.

The Wayland client library

Or libwayland. A bit like XCB and Xlib, this is basically just an IPC library. Unlike XCB and Xlib it can also used by a Wayland server for server?client communication. Also unlike XCB and Xlib, it's programmatically generated from the protocol definition. It's quite a nice IPC library, really. Like XCB and Xlib, you're not really expected to use this, anyway; you're expected to use a toolkit like Qt or GTK+, and EGL + your choice of Khronos drawing API if you want to be funky.
There's also a library for reading X cursor themes in there.

The Wayland server?

This is where it diverges; there is no Wayland server in the sense that there's an Xorg server. There's Weston, the reference compositor, but that's strictly intended as a testbed to ensure the protocol works.

Desktop environments are expected to write their own Wayland server, using the protocol and client libraries.

The Mir protocol?

We kinda have an explicit IPC protocol, but not really. We don't intend to support re-implementations of the Mir client libraries, and will make no effort to not break them if someone tries. We're using Google Protobuf for our IPC format, by the way.

The Mir client libraries

What toolkit writers use; it's even called mir_toolkit. Again, you're probably not going to use this directly; you're going to use a toolkit like GTK+ or Qt, and like Wayland if you want to draw directly you'll be using EGL + GL/GLES/OpenVG.

The Mir server?

Kind of. Where the Wayland libraries are all about IPC, Mir is about producing a library to do the drudge work of a display-server-compositor-thing, so in this way it's more like Xorg than Wayland. In fact, it's a bit more specific - Mir is about creating a library to make the most awesome Unity display-server-compositor-thingy. We're not aiming to satisfy anyone's requirements but our own. That said, our requirements aren't likely to be hugely specific, so Mir will likely be generally useful.

To some extent this is why GNOME and KDE aren't amazingly enthused about Mir. They already have a fair bit of work invested in their own Wayland compositors, so a library to build display-server-compositor-thingies on isn't hugely valuable to them. Right now.

Perhaps we'll become so awesome that it'll make sense for GNOME or KDE to rebase their compositors on Mir, but that's a long way away.

¹: Last time I saw anyone try this on #wayland there were problems around the interaction with the Mesa EGL platform which meant you couldn't really implement the protocol without using the C existing library. I'm not sure if that got resolved.

I have been a Google Chrome user for a while now, and I have two different ‘Users’ in Chrome. The default user is my personal account, and then I have a work account. For my personal email I use a Google Apps Gmail account and just check my email with Chrome. I use Thunderbird to check my work email. For a while now I have had an issue where I click a link from Thunderbird and it tries to open in my default Chrome user. This doesn’t work very well as I am not logged into most of my work accounts on my personal user. This drove me nuts! Now I have to copy and paste the URL into the work user Chrome window. After a little Googling tonight, I was able to setup Thunderbird to open URLs in my work user Chrome browser. Life is much better now! To do this, I had to add two lines to prefs.js. On Ubuntu 13.04, prefs.js is located at ~/.thunderbird/ /prefs.js where is what appears to be a random set of numbers/letters followed by .default.

The two lines I added are:

user_pref(“network.protocol-handler.app.http”, “/opt/google/chrome/google-chrome –profile-directory=’Profile 1′”);
user_pref(“network.protocol-handler.app.https”, “/opt/google/chrome/google-chrome –profile-directory=’Profile 1′”);

If the profile-directory for the Chrome user you are wanting the links to open in is different than what I have, you may need to edit the directory name. This worked for me on Raring (what will become Ubuntu 13.04) with Thunderbird 17.0.4.

As discussed and planned, Smart Scopes have landed! Unity 7 too is landing, with many more features around getting 100 scopes installed, privacy, and dash improvements. For details on what Unity 7 is bringing, check out this post.

In support of the Unity changes, the Unity development team is asking for some extra testing on these specific features. So, we've updated and added a new testcase to our unity suite for these smart scopes. Pay attention to the cases marked mandatory and optional. The testcases relating to the smart scopes have all been marked as mandatory, and are the essential tests to run. That said, it doesn't hurt to run through the optional cases if you have time. We don't like regressions either :-)

So, here's what you need to know!

Never done a call for testing before? Read/Watch this first!; Call for testing walkthrough

Install the new unity from a ppa; Installation Instructions
 
Load the testcases and select one; Unity 7 Testing

Read the testcase, perform the actions listed and record your results.

If you run into any issues, please file a bug

Finally, please note the changelogs and build status found on the tracker, as well as any known bugs while testing. New builds will continue to trickle in over the next few days with new changes coming in. I'd encourage you to test and then re-test later in the week to follow-up on bugs you find, or test the new things that land.

As always please contact me if you run into issues, or have a question.
Thank you in advance for your help, and happy testing everyone!

“That’s not a knife — THAT’s a knife.”

– Michael J. Crocodile Dundee

I recently worked a bit to see this line showing up in my favorite editor:

ubtree0t-junit-subsequentcheck PASS

LibreOffice has multiple sets of testsuites and during the build of the package we run them all (although not yet on all platforms). However, LibreOffice depends on ~1/3 of main — so there are a lot of things that might break LibreOffice. A lot of things just break at build time and not at run time and thus prevent the such a broken package to enter the archive in the first place as we run the tests during the build already. Thats as: unless the breakage is caused by an update of a dependency of LibreOffice, therefore making the LibreOffice package in the archive FTBFS (or at least broken) in a sneaky way. Thats whats happened for the e.g. the libjpeg, boost, kdelibs examples above.

But lets keep those aside for now and concentrate on the runtime issues. Running the tests at build-time is a good early-warning already and prevents some serious breakage to enter the archive. On the other hand, these tests do not run against LibreOffice as we install it in the system from packages — it runs them against a installation set aside in the build tree. While I can not come up with an immediate example, where LibreOffice was broken when installed from the packages in a way that would have been detected by tests but missed when run against the in-tree installation, it would still be good to have the additional confidence that:

• LibreOffice passes the tests as installed on the system
• LibreOffice is not broken at runtime by some update of a dependency

In short: Its highly desirable to test that LibreOffice does still run and work as the ground below it keeps moving — this is even more important when Ubuntu is considering to move towards a more rolling way of releasing. And we have a means to do that: Autopkgtests.

So, what was needed to get this working for LibreOffice?

First, some parts of the testsuites are quite large and — as we run the tests during the build anyway — are already build during the build. Therefore it made sense to package these, which was done very early in the cycle (actually: during UDS).

Second, we would need to get LibreOffice to run the tests without trying to build the product. That originally wasnt as easy as it may seem. For one, LibreOffice build system was reasonably expecting that you need a product to test it and therefore would have dependencies on the product to be build. In addition, when I started considering this, we still had a lot of the old build system around — which was a pain to bend to your will. Luckily, these times are over. So, by now a patch changing some ~15 lines get us what we want.

Third, we need a config_host.mk (the output of ./configure), so that we can run the LibreOffice build. And for that, we unfortunately need the build dependencies (which are generated) of LibreOffice — otherwise we would not really test what we did build. But for a missing feature of autopkgtests, we can not reuse the existing dependencies, but have to do manual double bookkeeping there. Im not thrilled by the prospect of hunting false positives there. Some possible ways out would be:

• to package the config_host.mk file into the package containing the other testsuite helpers, but that would make that package architecture dependendant
• or to not really specify the dependencies at all and pragmatically and greedily request the restrictions needs-root and breaks-testbed and then — as we are root now — run this before starting the tests:

  apt-get build-dep -y libreoffice

Finally, we should be able to run:

apt-get build-dep libreoffice
apt-get install libreoffice-subsequentcheckbase
apt-get source libreoffice
cd libreoffice-*
./debian/tests/junit-subsequentcheck

and this should run the tests locally and headless — and indeed it does and the tests happily finish and report success. Great, lets quickly check if it also runs in the ‘official’ VM with:

run-adt-test

Nope, and this is why I choose the Crocodile Dundee quote below the title for this post: The VM fails before it even starts the tests — it does not even have enough discspace to copy in the LibreOffice source package. This needs to be fixed on the side of the image, there is nothing on the test side that could fix this. But to test if LibreOffice would finish if only the image could handle it, I began cannibalizing, removing one after another the directories of the icon-themes, translations and external sources from the package, each time getting a bit further: from failing to start to failing when installing the 501 additional packages and so on. With this hollowed out package, I could verify: yes, the autopkgtest would pass in the image, if only it had enough discspace.

Finally, once this is in the archive (or ppa) you will also be able to run:

apt-get build-dep libreoffice
apt-get install libreoffice-subsequentcheckbase
apt-get source libreoffice
cd libreoffice-*
libreoffice '--accept=pipe,name=blickenlights;urp'&
./debian/tests/junit-subsequentcheck 'connect:pipe,name=blinkenlights' 1

This will connect to the LibreOffice you started in the second-to-last step (which is not headless, but running in your session) and run the tests against it. The “1″ tells it not to use parallelization, but just run one suite at a time, as otherwise you have a very good chance to lock/hang your own session by compiz (or the dash or other components) being mightly confused by all the windows flashing up and closing in fast progression. With “1″ you might still get some test failures (mostly from the a11y integration) — but at least your session will survive:

ZO RELAXEN UND WATSCHEN DER BLINKENLICHTEN.

Addendum:

Preparing an adt-image with:

./bin/prepare-testbed -r raring amd64 -S12GB

seems to solve the issue. The “df -h” at the start of the test reports some 3GB of free space (with 2.6GB being needed still to create a rw-copy of the source tree after that point). So 12GB is likely the size the images on Jenkins roughly currently need (plus maybe another 1GB of wiggle room).

The community team for wallpaper selection got together last week #1304wallpaper on Freenode and between us we’ve determined that we’d like to submit the following images as our delightful wallpaper selection for 13.04.

Many thanks to everyone who came to discuss options and help with the selection and in particular those who highlighted that some of the images shortlisted previously might not be the submitted user’s own image and or appear in other distros. Your constant vigilance is much appreciated!

So what now? Well the compressed file has been uploaded to a bug marked against the wallpapers package on Launchpad and this is where Seb, Didrocks and others will ensure that the images make it into the release before UI freeze.

Thank you again to everyone who helped and to Ken, Seb, John and Didrocks for the final push.

I’m still signed into #1304wallpaper most of the day, UK time so come find me or drop me a mail if you have any questions, concerns or the like.

See you next cycle/ rolling release!

I’m particularly happy to announce that the Brazilian team managed to get their translation of the Ubuntu Packaging Guide up to more than 70% of completion, which is the magic threshold to get it accepted and posted on developer.ubuntu.com. This means that our current list of available languages is:

• English
• Spanish (99%)
• Russian (85%)
• Brazilian Portuguese (74%)

You can view the individual forms of the Packaging Guide in Brazilian Portuguese here:

• HTML, multiple pages
• single HTML page
• one PDF document
• in EPUB format

Right at the start I said that I was “particularly happy” about this translation. That’s because I recently picked up a little bit of Portuguese. Mostly useful sentences like “Meu irmão gosta de cerveja” or “O leão escreve cartas”. Thanks Duolingo!

A big big big “obrigado” to the tireless Brazilian Portuguese translators. You all are heroes! This is great news for everyone who wants to get involved in Ubuntu development, as it smoothes the first steps considerably.

You can help out with translations. Just head to the Packaging Guide’s translation page in Launchpad, pick your language and get started. Current runners-up to the translations mentioned earlier are:

• German (32%)
• Japanese (15%)
• French (7%)
• Indonesian (5%)
• Dutch (4%)

The available translations are not entirely complete yet either, so please do get involved.

Our community is at the heart of how we build Ubuntu. Recently there were some concerns expressed about some aspects of our community and I have been working with various community members and internally at Canonical to resolve some of these issues to make things smoother.

I just wanted to summarize some updates:

• Regular, transparent planning – we want to improve how we plan the delivery of work items, and make that planning more nimble. While the major decisions are reserved for primary discussion at UDS, we want to regularly and transparently checkpoint progress on those projects, and ensure things are moving along. To do this the engineering managers at Canonical will perform this planning on a monthly basis with our community. An an example, with my team, we will decide at UDS what major projects we will work on and document the work items in those blueprints, and every month I will ask the team to commit to delivering an agreed set of work items that month and update the blueprints accordingly. This will make it easier to understand who is working on what, what needs to be done, and areas in which people can participate. This entire process will be completely open and transparent and I would like to encourage our wider community to use the same approach. As an example, this could be a useful technique for our LoCo community to use for planning their work too around advocacy campaigns. All of this work will continue to be tracked openly in status.ubuntu.com.
• Training our engineers – our engineers at Canonical are expected to openly and transparently perform all work that is not considered customer/company confidential. While this expectation is clear, there are sometimes cases when this doesn’t happen (e.g. if someone joins Canonical without the experience of working in an open environment and isn’t really sure how to do this). I have prepared an internal slide deck with these expectations and workflows clearly laid out; my team will be working to ensure everyone gets the deck, reads it, and gets an answer to any of their questions.
• Regular leadership problem solving meetings – one problem we have today is that we don’t have a regular problem solving meeting in our community in which our governing leaders are present at. Instead our different leadership boards (e.g. Community Council, Forums Council) tend to resolve issues pertinent to that specific board. We think it could be useful to have a meeting every two weeks that has representatives from our different governance boards and our community can join and raise topics for discussion. We are going to run the first one of these sessions tomorrow (Tue 19th March 2013) on Ubuntu On Air at 8pm UTC. We invite you to bring your topics there on IRC for discussion.
• Online UDS refinements – as I blogged about last week we have released a survey to gather feedback about how to refine and improve UDS. We have already made some plans for some improvements but I plan on organizing a community meeting to discuss this more next week (I can’t later this week as I am at an event). I think there is an opportunity to refine the format of UDS into a form that becomes a useful and repeatable way of coordinating meetings in a community.
• Weekly Updates – I have reached out to the engineering managers on some of the core projects at Canonical and asked them to provide weekly updates of work going on. We have already seen the first updates for Ubuntu Touch and Mir.
• Prepping announcements better – while the major announcements are now out, one piece of feedback I received is that our community felt ill-prepared around things such as the Ubuntu Touch announcement, and people such as our IRC/Forums/Community councils were inundated with questions and didn’t have good answers to those questions. If we need to make future announcements in the same way again, I am going to ensure our core governance boards are clued up first and we provide a FAQ for our community to refer to when getting these kinds of questions. This should relieve this concern.
• Improving our community on-ramp – one area where I want to drive some improvements is making it easier for people to join the community. We started some work a while back to improve the community landing page on ubuntu.com and I have asked Daniel Holbach to drive that work to completion. I am also working with the Ubuntu Touch and Mir teams to ensure that they have awesome documentation and guidance for how people can participate. A good example of the progress being made here is the Mir documentation. If you would like to help improve these docs, then feel free to dig in and help, or share your ideas on the mailing lists.

I want to get as much feedback on these steps moving forward as well as other ideas and areas in which we can focus. You can always grab me on IRC on freenode (my nick is jono) and I hang out in #ubuntu-community-team. Also feel free to drop me an email and join my regular Q+A session every week. Unfortunately, this week’s Q+A session is canceled as I need to be at an event, but I will be back in the regular slot next week on Wednesday at 7pm UTC on Ubuntu On Air.

I’m posting this on behalf of the Ubuntu Touch team. (Originally posted here.)

The interest in Ubuntu Touch is still going strong, many work on apps, many helped with porting, some started fixing bugs in Ubuntu Touch, so here’s a few highlights of Ubuntu Touch development of the last week:

• Jim Hodapp worked on enabling Qt multithreaded rendering in the camera app.
• The media app received a number of updates. Jim also enabled Qt multithreaded rendering here and greatly simplified the UI orientation/rotation support. It’s based on Screen.orientation instead of directly using QtSensors now. Renato Filho added some autopilot tests.
• qtubuntu-media-signals (a library that coordinates qtvideo-node, qtubuntu-camera and qtubuntu-media across thread contexts) was added by Jim and Francis Ginther.
• Gustavo Boiko put quite a bit of work into the telephony app, which was optimised to load data from telepathy-logger by reading it just once and dispatching the events to the correct model. Also some unit tests were added, the autopilot tests now pass as well. HUD actions were added and the app now uses the toolbar from the SDK.
• Guenter Schwann worked on the gallery app, which had its event view updated to use Listview. Also “Add album” and opening the photos view from the album view were reenabled.
• The Platform API was updated by Jim and Ricardo Mendoza to read the resolution and getting the updated rates of sensors. The accelerometer support was refactored so that it supports calling more than one observer listener per Sensor instance. Sessions can now be tracked in a different namespace than the app manager. Various tests were fixed.
• ubuntu-session had support added for SMDK4210 (Samsung GT-I9100) by Oliver Grawert.

Many other fixes have gone into the lower levels of the stack which were not considered for this update.

The ports team was busy as well and many Ubuntu Touch ports received updates. Some of them regularly and daily (just like the normal images on cdimage.u.c). Newly added ports are:

• working: Samsung Galaxy Tab 7.7 (GT-P6800)
• work in progress: HTC Sensation XL, SGS III (Qualcomm AT&T), Toshiba AC100

Thanks to everyone involved for your fantastic work!

—-

Ubuntu Touch runs on tablets, phones and other devices. We are open to suggestions, fixes and new crazy ideas. If you want go get involved, please get in touch: https://wiki.ubuntu.com/Touch/Contribute

I just released a new PyGObject for GNOME 3.7.92. This fixes a couple of crashes and marshalling errors again, but most importantly got a change to automatically mute the PyGIDeprecationWarnings for stable versions. Please run pythonX.X with the -Wd option to still be able to see them.

We got through all our bugs that were milestoned for GNOME 3.8 and don’t want to or plan to introduce any major behavioural change at this point, so barring catastrophes this is what will be in GNOME 3.8.0.

Thanks to all contributors!

• Fix stack smasher when marshaling enums as a vfunc return value (Simon Feltman) (#637832)
• Change base class of PyGIDeprecationWarning based on minor version (Simon Feltman) (#696011)
• autogen.sh: Source gnome-autogen to fix out of source builddir (Alban Browaeys) (#694889)
• pygtkcompat: Make gdk.Window.get_geometry return tuple of 5 (Simon Feltman)
• pygtkcompat: Initialize hint to zero in set_geometry_hints (Simon Feltman)
• Remove incorrect bounds check with property helper flags (Simon Feltman)
• Fix crash when setting property of type object to an incorrect type (Simon Feltman) (#695420)
• Remove skipping of object property tests (Simon Feltman) (#695420)
• Give more informative error when setting property to incorrect type (Simon Feltman) (#695420)

Shortly after introducing the Vagrant images, a number of users provided very valuable feedback. The general gist was "sure this is a nice, but useless." For Cloud Images, we definitely take our user feedback to heart.