If you’re as keen as we are that the Ubuntu sound theme is on brand, now is your chance! We are calling for pitches for the Ubuntu sound theme!

The brief

As Ubuntu expands onto new form factors, with an increasingly definitive visual identity and brand, it is important to ensure that the theme of Ubuntu is reflected in all aspects of the experience. The auditory experience of Ubuntu must be included in this theme to maintain an immersive environment and consistency with the brand.

These values are a key component of our brand and should form the basis for the sound theme.

• Reliable
• Collaborative
• Freedom
• Precise

Our brand values : http://design.ubuntu.com/values

Objective

To define an Ubuntu soundscape that compliments look, feel and brand and produce a library of assets required for implementation. Provide a guideline for the Ubuntu soundscape that will allow for extension by internal and external stakeholders.

Project requirements

The concept for the sound theme should reflect the requirements of all form factors. Concepts should therefore be explored through signature moments in the Ubuntu soundscape; with an opportunity to refine a desktop startup sound for the 12.04 release. The emergent sound theme should then be articulated and guidelined.

The first stage of this project is the pitch – the deadline is Monday the 13th of February.

The pitch

One desktop startup sound

• This will be heard when the login screen (shown above) is ready for user interaction.
• The device is coming alive, awakening.

One notification

• This gives us a feel for how these sounds fit in a theme.
• An example notification would be a calendar event.

Participants can submit as many sample sounds as they like, however the minimum requirement is one of each.

Feedback will be given by Wednesday 15th February, and we will work with the successful participant to refine the startup sound for the 12.04 release and continue to work with them on the development of the Ubuntu soundscape.

This is an open pitch, and we encourage everyone to participate; including, hopefully, some of you sound professionals out there!

Some helpful links…

Design guidelines : http://design.ubuntu.com/
The Ubuntu tour : http://www.ubuntu.com/ubuntu/take-the-tour
Brand values : http://design.ubuntu.com/values

 

Recently, a thread has appeared on the ubuntu-desktop mailing list asking why Ubuntu (or specifically, Ubuntu 12.04 LTS) is not using the Extended Support Release of Firefox by default. I’ve also been asked this a few times on IRC over the last few weeks (from people inside and outside of Canonical), so I just wanted to clarify the reasoning for this, and why I think that our choice will offer the best experience for Ubuntu users.

Arguments against the ESR

Aside from the fact that offering the Firefox ESR by default to Ubuntu users would make our good friends at Mozilla unhappy (and from my perspective, we have a pretty good relationship with them. I certainly don’t want this to change), here are some reasons why I think that shipping the Firefox ESR by default would be bad for Ubuntu users. Some of these are points from the ESR proposal, and some of them are my own thoughts.

Over time, Firefox ESR will become less secure than Firefox

The ESR proposal states that:

Mozilla will backport security bugs qualified as “Critical” and “High” to the ESR where feasible (there may be cases where a backport cannot be applied with reasonable effort, and those cases are expected to be exceptional)

This means that people running the Firefox ESR may have to wait for the next major release to receive fixes for security bugs with sg:moderate, sg:low or sg:dos severity ratings. What is worse is that ESR users may also miss out on some sg:critical or sg:high rated bugs, where it is just not feasible to backport the fix to the ESR branch.

In addition to this, Firefox ESR users will have to wait longer than regular Firefox users for proactive security improvements such as support for the iframe sandbox attribute, CA pinning, the Mixed Content Blocker or any other new security features / improvements.

Because of this, the Firefox ESR will always become less secure than the regular Firefox releases.

Ubuntu 10.04 LTS users have already had to wait longer than Firefox users on other platforms for new security and privacy features such as Content Security Policy, HTTP Strict Transport Security and Do Not Track. We don’t want Ubuntu to lag behind other platforms in the future.

The risk of introducing bugs is greater with Firefox ESR

There is a common misconception that when a piece of software receives only reactive security fixes, it is the safest option for users and that the risk of breakage is minimal with this approach. In reality, this isn’t exactly true. There is always risk associated with backporting any form of code change from one branch to an older branch, and this risk increases as:

• The 2 branches diverge further apart, making the backport less straightforward
• The amount of testing exposure decreases

Clearly, the Firefox ESR will be affected by both of these factors.

The regular Firefox releases pass through the beta channel for 6 weeks before release, where they are exposed to a large community of users who are using the beta as their day-to-day browser. And, whilst the Linux testing community is relatively small (I would like to grow this though), we mustn’t take for granted the positive effects on quality that Ubuntu users get from Firefox beta testers across all platforms. The Firefox ESR will not benefit from this type of large scale pre-release exposure.

In my opinion, bug 667087 is a perfect example of how the ESR approach can lead to the introduction of bugs (this was a regression which only affected the 3.6 branch).

It is only supported for 1-year (well, 54 weeks, to be more exact)

The Firefox ESR is supported for 54 weeks (9 regular Firefox release cycles), with a 12-week (2-cycle) overlap. This means that it would be inevitable that we would have to upgrade users to a new version of Firefox ESR every year, if we provided this by default. Instead of small incremental changes every 6 weeks, users would be faced with much larger and more obvious changes every year. We believe this is generally worse for most users.

We have been following the new Firefox release process since Ubuntu 11.04, and users seem to have adapted to it quite well. Having just upgraded Ubuntu 10.04 LTS users from Firefox 3.6 to Firefox 10, we know that this scale of update is much more painful – for users and for us.

The web is not static

All of the major browser vendors are pushing new technologies on the web, and existing standards are constantly evolving. It is important that we provide Ubuntu users with a browser which keeps up with this, as users coming from competing platforms expect. In the time since Firefox 4 (which isn’t that dissimilar to the time between 2 ESR versions), Mozilla has added support for things such as the <bdi> element, page visibility API, Mozilla’s full screen API, CSS 3D transforms, CSS font-stretch property, cross-domain textures in WebGL, Web Timing, CSS hyphenation in languages other than English, HTML5 context menus and added a bunch of other improvements to IndexedDB, WebSockets, and canvas. Web developers and Firefox users on other platforms already have access to these features.

We don’t want Ubuntu users to regularly be the last people to have access to evolving technologies on the web, and I don’t think it’s great to say to them “if you want access to the latest web technologies like users on other platforms have, you need to upgrade your entire OS in 6 months or use this unsupported PPA instead”. It wouldn’t be good for Ubuntu if the function or appearance of our users favourite websites ends up being degraded by default on our flagship product, as the web evolves faster than the browser that we are shipping.

Until recently, Ubuntu 10.04 LTS users have already been missing out on major technologies such as CSS transitions (which is used in some places in Google+), WebGL and WebM (available on YouTube) whilst we have been shipping Firefox 3.6 to them. In addition to this, Google have already effectively dropped support for Firefox 3.6, as have Flickr, and we have had reports from other people saying that some online banking sites have already bumped their minimum browser requirements beyond Firefox 3.6.  As the web evolves faster, this type of thing may occur more frequently in the future (the alternatives to this are that web developers give themselves a hard time when trying to adopt new technologies by having to support fallbacks for older browsers, or innovation on the web just stagnates as developers are reluctant to adopt new features).

Over time, Firefox ESR will become slower than Firefox

In the same way that Firefox ESR will become less secure than Firefox, it will also become slower and less resource efficient than regular Firefox due to initiatives such as MemShrink, Snappy and continual work on improving performance in the JS engine.

Performance and memory consumption really matter to users, and these things can affect people’s perception of Ubuntu when they compare browser performance with browsers that are shipped on other platforms.

In addition to this, we offer the latest version of Chromium alongside Firefox in the Ubuntu archive. It would be bad for Mozilla for us to offer an outdated Firefox ESR against the very latest version of Chromium, as the difference in performance between the 2 can significantly influence our users perception of the quality of Mozilla’s product. I’m not the only person who thinks this:

I think it would hurt us competitively if Fedora or Ubuntu shipped ESR, because users or journalists would compare ESR with up-to-date Chrome

Arguments in favour of the ESR

Of course, other people have some good points about why the ESR might be a positive thing. I’ll list some of the more frequent points I hear, and explain why I disagree with them.

The Ubuntu LTS is for enterprise users

This isn’t true. Whilst it is true that enterprise users tend to stick with the LTS release for the longer period of support and less frequent upgrades between OS versions, the LTS is targeted and used by all types of users.

Users who stick with the LTS want stability. Users who want the latest-and-greatest should upgrade between the regular 6-month releases

There are several things wrong with this argument:

• It assumes that because a user doesn’t want to upgrade their entire OS every 6 months and because they want 3-5 years of support, that they don’t want the latest applications.  I don’t want to upgrade my cell phone more than once every 2 years because it is a pain to adapt to a new device, but I certainly do want to be offered the latest apps on it for the time that it is supported.
• It assumes that LTS users choose to stay on the LTS.  In fact, when somebody installs the LTS, we will only offer LTS – LTS upgrades for them unless they change a setting in the Updates tab of the Software Sources settings.
• It assumes that the Firefox ESR provides more stability than the regular Firefox release, and that we won’t get stability from shipping regular Firefox releases.  I’ve already explained above why I don’t think this is the case.
• It assumes that stability is all that is required to satisfy LTS users.  The reality is a lot more complicated than this.

LTS users actually do seek out the latest software.  As the maintainer of the Firefox Beta PPA and the (now retired) Firefox Stable PPA, I have some interesting download statistics for these PPA’s:

• Ubuntu 10.04 LTS users are consistently the second highest consumer of the Firefox Beta PPA.  In fact, the number of downloads from Ubuntu 10.04 LTS users is around the same as (and sometimes exceeds) the number of downloads from Ubuntu 10.10 and Ubuntu 11.04 combined.  Note that the highest consumer is always the most recent supported release.
• The last upload to the Firefox Stable PPA (9.0.1, which was also uploaded to lucid-proposed) was downloaded by 3-times as many users on Ubuntu 10.04 LTS as it was from users on Ubuntu 10.10.

Also, I accidentally introduced a packaging bug in to our daily builds last week which temporarily broke upgrades for daily build users on Ubuntu 10.04 LTS and Ubuntu 11.04.  To my surprise, we got a bug report from a 10.04 user within minutes of the broken packages being published. We then got a fairly steady stream of bug reports from 10.04 users until the packages were fixed.  In total, we had 7 bug reports from Ubuntu 10.04 LTS users, and 1 bug report from an Ubuntu 11.04 user.  Prior to this, I had always made the assumption that Ubuntu 10.04 LTS users would be the smallest consumer of Firefox daily builds, but I may have to reevaluate this view now.

Ok, it’s difficult to read too much in to this relatively small amount of data and I’m not sure how much it really proves.  In any case, I think you’ll find that the LTS users aren’t quite as conservative as some people make them out to be.

The LTS should be stable, secure, supported, predictable

The regular Firefox releases are more secure than the ESR, will be just as stable (with the significantly larger audience of beta testers) and are better supported. The 6 weekly releases are also predictable.

Of course our flagship product needs to be stable, secure and supported. But, it needs to be much more than this too.

Addons break between releases

Whilst this was problematic in the early stages of the rapid release process, this isn’t as much of a problem now. Starting in Firefox 10, most addons are compatible by default (the exceptions are themes and addons with binary components). Prior to this, addon compatibility has been regularly exceeding 95% before each new Firefox release (for the top 95% of addons which were compatible with the previous Firefox version).

Soooooo…..

I hope this answers some of your questions about why Ubuntu is not shipping the Firefox ESR by default. Of course, I’m more than happy to listen to peoples concerns.

It is entirely possible that we might provide a Firefox ESR build for people who are managing large deployments of Ubuntu, although the details of this aren’t decided yet. However, this isn’t going to be the default browser for our LTS. If it existed, it would be shipped in a PPA (much like we have been doing for the Firefox Stable PPA), and we would have to be clear to users that it wouldn’t receive the same level of support we give to the regular Firefox versions.

Thank you for reading

The following announce is lazily copied from Paul Wise’s announce. There is only one thing I like to add: the screenshots that are submitted and collected on screenshots.debian.net are visible on the packages websites (both Debian and Ubuntu) and are also used by the software-center package, so they help people to get a first impression of the package they might want to install.

Have you ever wondered how to start getting involved in Debian/Ubuntu? Do you enjoy discovering new games and playing them? You might want to come to the games screenshot party! We hope that the party will be a fun, easy, low-commitment way to get involved.

The Debian/Ubuntu Games Team is organizing a half-day screenshots party on the weekend of 25th-26th February for creating screenshots for all the games that are available in Debian/Ubuntu.

If you are interested in attending, please add your availability to the poll linked from the announcement so that we can get some idea of attendance and when is a good time for the people who are interested.

Look forward to lots of game playing, screenshots and merry time, hope to see you all there!

/debian |
permanent link |
Comments: 0 |

As I announced on debian-devel, Guillem Jover uploaded a snapshot of dpkg’s multiarch branch to experimental (version 1.16.2~wipmultiarch). Beware: There will
likely be some small “interface” changes between this version and the version that will be released later in unstable (possibly in the output of dpkg --get-selections, dpkg --list, maybe other commands).

multiarch allows you to install packages from different architectures on the same machine. This can be useful if your computer can run programs from 2 architectures (eg. x86 CPU supporting i386 and amd64), or if you often need to cross-compile software and thus need the libraries of your target architecture.

Test dpkg with multiarch support

If you want to test multiarch support in dpkg, install the package from experimental (apt-get install dpkg/experimental assuming you have experimental in your sources.list).

Then you can add a supplementary architecture to your system by doing sudo dpkg --add-architecture <arch> (e.g. i386 if you are on amd64, and vice-versa). APT will automatically pick up the new architecture and start downloading the Packages file for the new architecture (it uses dpkg --print-foreign-architectures to know about them).

From there on you can install packages from the “foreign” architectures with “apt-get install foo:<arch>“. Many packages will not be installable because some of their dependencies have not yet been updated to work with in a multiarch world (libraries must be installed in a multiarch-compliant path so as to be co-installable, and then marked “Multi-Arch: same“). Other dependencies might need to be marked “Multi-Arch: foreign“. See wiki.debian.org/Multiarch/Implementation for more HOWTO-like explanations.

Now is a good time to see if you can install the foreign packages that you could need in such a setup and to help to convert the required libraries.

You can also read Cyril Brulebois’ article which quickly shows how to hunt for the problematic packages which have not been converted to multiarch (in his sample, “ucf” is not ready. Since it’s an “Architecture: all” package which can run on any architecture, it means that it’s lacking a “Multi-Arch: foreign” field).

Report bugs

If you discover any bug in dpkg’s multiarch implementation, please report it to the Bug Tracking System (against “dpkg” with the version “1.16.2~wipmultiarch”).

If you notice important libraries or packages which are not yet multiarch ready, please open wishlist bug reports requesting the conversion and point the maintainers towards the wiki page linked above. Even better, prepare patches and submit those with your bug reports.

Again, you can follow the lead of Cyril Brulebois who filed 6 bugs!

Review the multiarch implementation

If you’re a C programmer and have some good knowledge of dpkg (or are willing to learn more of it), we would certainly benefit from more eyes reviewing the multiarch branch. If you want to discuss some design issues of the multiarch implementation in dpkg (or have questions related to your review), please get in touch via debian-dpkg@lists.debian.org.

The latest version of the branch is pu/multiarch/master in Guillem’s personal repository. I have my own version of the branch (pu/multiarch/full) which is usually a snapshot of Guillem’s branch with my own submitted fixes.

$ git clone git://git.debian.org/dpkg/dpkg.git
$ cd dpkg
$ git remote add guillem git://git.hadrons.org/git/debian/dpkg/dpkg.git
$ git remote add buxy git://git.debian.org/~hertzog/dpkg.git
$ git fetch guillem && git fetch buxy

If you followed the instructions above, the relevant branches are thus guillem/pu/multiarch/master and buxy/pu/multiarch/full. Both branches are regularly rebased on top of master where Guillem merges progressively the commits from the multi-arch branch as his review progresses.

Thank you in advance for your help bringing multiarch in shape for Debian Wheezy,

No comment | Liked this article? Click here. | My blog is Flattr-enabled.

Ubuntu Global Jam: Call For Events!

From 2nd – 4th March 2012 we will be running the Ubuntu Global Jam. This is a global event in which we ask Ubuntu users and contributors to organize events in their local areas to meet other Ubuntu people and help contribute to Ubuntu.

The Ubuntu Global Jam is a fun event, and a great way to meet other Ubuntu and Free Software folks. It is also really easy to organize an event if there is not one near you.

To explain more, tonight I created a video explaining what the Ubuntu Global Jam is, and how to organize an event:

Can’t see it? Click here!

We are going to be encouraging you good folks to start organizing your events. You can find out more about the events here at loco.ubuntu.com and more information on the wiki.

Please feel free to ask whatever questions you like about how to organize an event in the comments here. Do let me know if you organize an event!

Mike is also working on some website updates on loco.ubuntu.com that will make the event a little more interested both before and when the event is running.

Welcome to the Ubuntu Weekly Newsletter. This is issue #251 for the week January 30 – February 5, 2012, and the full version is available here.

In this issue we cover:

• Precise Pangolin Alpha 2 Released!
• Developer Week: Summaries Days 1-3
• The Ubuntu Weekly Newsletter Needs You!
• Ubuntu 12.04 Development update
• Ubuntu Stats
• LoCo News
• Launchpad News
• Canonical Design Team: Multi-Monitor Update and Greeter Prototype
• Didier Roche: Unity 5.2 is now released!
• Paul Tagliamonte: Mapping the Ubuntu Community
• With GOV.UK, British government redefines the online government platform
• You Don’t Have To Quit Ubuntu!
• Canonical Promotes Standard Ubuntu Branding with New Website
• Other Articles of Interest
• Weekly Official Ubuntu Flavors Team Meetings
• Upcoming Meetings and Events
• Updates and Security
• And much much more

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

• Elizabeth Krumbach
• Chris Druif
• Vikram Dhillon
• Liraz Siri
• 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

As I discussed last year, Ubuntu has been restricting the use of ptrace for a few releases now. I’m excited to see Fedora starting to introduce similar restrictions, but I’m disappointed at the specific implementation:

• A method for doing this already exists (Yama). Yama is not plumbed into SELinux, but I would argue that’s not needed.
• The SELinux method depends, unsurprisingly, on an active SELinux policy on the system, which isn’t everyone.
• It’s not possible for regular developers (not system developers) to debug their own processes.
• It will break all ptrace-based crash handlers (e.g. KDE, Firefox, Chrome) or tools that depend on ptrace to do their regular job (e.g. Wine, gdb, strace, ltrace).

Blocking ptrace blocks exactly one type of attack: credential extraction from a running process. In the face of a persistent attack, ultimately, anything running as the user can be trojaned, regardless of ptrace. Blocking ptrace, however, stalls the initial attack. At the moment an attacker arrives on a system, they cannot immediately extend their reach by examining the other processes (e.g. jumping down existing SSH connections, pulling passwords out of Firefox, etc). Some sensitive processes are already protected from this kind of thing because they are not “dumpable” (due to either specifically requesting this from prctl(PR_SET_DUMPABLE, ...) or due to a uid/gid transition), but many are open for abuse.

The primary “valid” use cases for ptrace are crash handlers, debuggers, and memory analysis tools. In each case, they have a single common element: the process being ptraced knows which process should have permission to attach to it. What Linux lacked was a way to declare these relationships, which is what Yama added. The use of SELinux policy, for example, isn’t sufficient because the permissions are too wide (e.g. giving gdb the ability to ptrace anything just means the attacker has to use gdb to do the job). Right now, due to the use of Yama in Ubuntu, all the mentioned tools have the awareness of how to programmatically declare the ptrace relationships at runtime with prctl(PR_SET_PTRACER, ...). I find it disappointing that Fedora won’t be using this to their advantage when it is available and well tested.

Even ChromeOS uses Yama now.

© 2012, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.

I’ve been running Kubuntu ever since I decided to switch to Linux on my computers. Kubuntu is what got me hooked on KDE’s software. I was on it’s council for 2 years. It has a special place in my Free Software world.

At FOSDEM I had a long chat with Jonathan. He told me that he’ll no longer be able to work full-time on Kubuntu soon. This was sad news because I know how much it means to him.  For more details read his blog. While this is sad it is also good news. It clarifies Canonical’s position and gives the team behind Kubuntu more power.

I’d like to thank Canonical for sponsoring Jonathan for the past years. It was important for Kubuntu and for KDE. Kubuntu is important for KDE because a diverse distro eco-system is vital for us. Let this be a much-needed wake-up call and take it into our hands.

Hop over to #kubuntu-devel on freenode and see where you can help out for the next cycle.

From my kubuntu-devel posting. See also Jason’s posting.

Today I bring the disappointing news that Canonical will no longer be funding my work on Kubuntu after 12.04. Canonical wants to treat Kubuntu in the same way as the other community flavors such as Edubuntu, Lubuntu, and Xubuntu, and support the projects with infrastructure. This is a big challenge to Kubuntu of course and KDE as well.

The practical changes are I won’t be able to work on KDE bits in my work time after 12.04 and there won’t be paid support for versions after 12.04. This is a rational business decision, Kubuntu has not been a business success after 7 years of trying, and it is unrealistic to expect it to continue to have financial resources put into it.

I have been trying for the last 7 years to create a distro to show the excellent KDE technology in its best light, and we have a lovely community now built around mostly that vision, but it has not taken over the world commercially and shows no immediate signs of doing so despite awesome successes like the world’s largest Linux deployment.

The first question to answer is whether the world needs Kubuntu – a regularly released community-friendly distro with a strong KDE focus. There is no other major distro out there that matches that description but others arguably come close.

If it does then we need people to step up and take the initiative in doing the tasks that are often poorly supported by the community process. ISO testing, for example, is a long, slow, thankless task, and it is hard to get volunteers for it. We can look at ways of reducing effort from what we do such as scrapping the alternate CD or automating KDE SC packaging.

I expect to do other desktop team tasks in my work time such as Qt. I can’t do much free software work in my spare time for now because of my poor health (slowly recovering I’m pleased to say).

I hope and expect Kubuntu can continue. I encourage Kubuntu devs to apply to UDS so we can have discussions on how to continue it and keep the dream alive.

Jonathan

With Ubuntu Global Jam events being scheduled for  March this year I wanted to share my recipe for organizing memorable events. The methods I have deployed in the past and continue to use have so far been pretty effective and I’m sure as a LoCo Leader you could easily replicate the success of Ubuntu Oregon’s events by using some of these practices.

 

Finding the perfect time

While to most picking a date and time for an event seems like an easy thing this is something to be taken seriously because it can play a role in whether five people or thirty arrive to your event.  Polling potential attendees for their availability is a recipe for success when it comes to planning a Ubuntu event and especially a Ubuntu Global Jam.

Some tools to use for find the best availability of your potential attendees:

• Doodle

 

Finding a venue

Once you have an idea of availability you should also have a good idea of how many people are interested in attending your Ubuntu Global Jam at that point you should reach out to potential venues. When seeking a venue you need to take into consideration what kind of amenities and capacity they can offer your event. I strongly encourage reaching out to venues such as local tech companies that might let you use their offices for the event or perhaps a co-working space or even a restaurant or cafe.

Tips for venue selection:

• Wireless Internet access with plenty of bandwidth is almost always a must for a Ubuntu event.
• Ensure that your venue will have plenty of seating and workspaces for attendees.
• If you are not having food and beverage sponsored ensure both are available for sale on-site or nearby.

 

Engage potential sponsors

Ubuntu LoCo’s may not always have the financial resources necessary to fund every event or initiative they hope for and as such it may be important to seek our local tech companies or even a bakery or restaurant to sponsor some of the related costs of an event. The easiest way to do this is make a list of local companies and identify their contact information and reach out to someone in management or if they have a community manager and explain your event to them and what you are seeking. In some cases a company may ask to have a sign next to some sponsored food or might ask to have someone from their IT staff available to network with your attendees and how you accommodate a sponsor is totally a decision you should make but feel free to seek guidance from the Ubuntu LoCo Council if need be.

Examples of success:

• In 2011 Ubuntu Oregon sought sponsorships and received them from PuppetLabs, Eucalyptus Systems, Rackspace, Rentrak, Linux Journal, ThinkGeek, Linbit, Ubuntu User and many more.

Setup RSVP and Announce the event

Once you have a Venue, Availability and perhaps a sponsor or two the next step is registering your event on the LoCo Directory and then announcing it to your LoCo Mailing List. In your announcement e-mail I suggest including a paragraph or two describing the planned event and focus and who the key organizers are and of course where it will be held and how to use the LoCo Directory to RSVP so you have a proper headcount.

Engage, Engage and Engage some more

Now that you have announced the event the job is not close to being over. You should spend the weeks before the event continuing to engage your community about how exciting the upcoming event is going to be and getting them excited. Getting people motivated, excited and ready for the event is a big role in keeping your community engaged and helps in making your community feel close-knit.

Tips for engaging before an event:

• Try and engage people who have been less active than others and encourage to step up their participation by taking part in the upcoming event and perhaps helping with the logistics of the event or using one of their talents to help make the event a success.
• Everyone wants to be reminded that their contributions are valued as such it is important for us to remind people of how much they are appreciated and how their previous participation at events made the event great and how much you look forward to future participation.

Thats a wrap!

On the day of your event I suggest always being at the venue 30 minutes early but also plan to go over all the details of your event the night before in case something doesn’t line up properly. If you have taken all of the above advice and used it then your event should come together quite precisely the way you wanted it to.

Remember organizing an event isn’t hard but it does require plenty of planning and several weeks of it if not months. If you have any tips you use for event planning with your LoCo do no hesitate to share your practices in the comments below so we can all learn from each other and improve our best practices for organizing events.

Originally Posted At: Benjamin Kerensa dot Com

A common thing I end up doing while working on code is to make a series of commits, and  then end up work changes in my working directory which I need to apply to an earlier revision in the history than the top-most one.

One common way to do this is to make a temporary commit with those changes, then use git rebase -i and move that commit below the one I want to amend and choose fixup to have it applied.

But that’s annoying manual work. There’s a more fun way. I have this script in my path as git-smash, it takes a revision as a single argument, e.g. git smash deadbeef:

git reset --keep "$1"
EDITOR=true git commit -a --amend
git checkout HEAD@{2}
git rebase --onto HEAD@{1} HEAD@{2}

This resets the revision history, keeping local changes, back to the given revision. Unfortunately git reset doesn’t have a mode which preserves the index so we then have to use commit -a to capture all of the local changes.

Now we use the reflog (history of revisions in the working tree) to manipulate the tree back to the previous state, first checking out the revision that was two back (before the amended commit and the reset, i.e. where we began). Then we rebase that onto the revision one back (before the checkout, i.e. the amended revision) using the revision that’s now two back (before the checkout and commit, i.e. the original revision we changed).

Mental gymnastics over, this is the same as what we were doing before, just in one handy command.

Git still sucks though.

On Friday we had the first Google+ Hangout with the full Canonical Community team. To observe this important moment we all showed how happy we were:

Sponsored by Colgate.

L-R: Daniel Holbach, David Planella, Yours Truly, Jorge Castro, Michael Hall, and Nicholas Skaggs.

Google Hangouts are awesome for team meetings.

This week I will be attending Linaro Connect Q1.12 in Redwood City, California. Infact, I’m in an American Airlines plane at 34,000 feet heading there now. In-flight WiFi is awesome!

Over the past two months Michael Hall and myself have been doing a large amount of work on The Summit Scheduler to get it ready for Connect this week including modifying more than 2,400 lines of Summit code. You can find out more about that in my previous post.

I have a few things that I want to get out of Connect. The first is that I want to get feedback on the changes to Summit, as well as figure out what other things we may need to change. The second thing that I want to do is to learn more about the Beagleboard-xM that I have and how to use it for the many different things it can be used for. The third thing that I want to do is to learn about Linaro’s LAVA.

LAVA is an automated validation suite used to run all sorts of different tests on the products that Linaro produces. The things that I would like to get out of Connect in relation to LAVA are how to setup and run LAVA, how to set it up to run tests, and how to produce results and display those results the way that I want them.

If you are at Linaro Connect, and would be willing to talk with me about Summit and the way you use it and your thoughts on the changes, please contact me and we will set aside a time to meet.

DISCLAIMER: By sending me email, you agree to the following:

• I am, by definition, “the intended recipient”.
• All information in the email is mine to do with as I see fit and make such financial profit, political mileage, or good joke as it lends itself to. In particular, I may quote it where I please.
• I may take the contents as representing the views of your company.
• This disclaimer overrides any disclaimer or statement of confidentiality that may be included on your message.

Another Linux distro updated now with Lubuntu in its core: DEFT Linux 7. This is a great recovery and forensic distro with lots of tools to aid for repairing partitions, damaged clusters, recover lost data, make network tests and configurations, etc. I can’t write the whole list of apps included in this release, not enough space

 

Mmm, thatartwork sounds familiar to me…

In playing with some tools I’ve run into at $work, I’ve tried loading in some Ubuntu datasets in some fun and interesting ways.

Today, I’ve chosen to map all Ubuntu Members with a public lat/lon, sized by Karma.

The sizes relate to if the Karma is greater then:

1: 10

2: 50

3: 100

4: 500

5: 1000

6: 2000

7: 7000

8: 15000

9: 25000

10: 50000

So, without further adieu, here’re some maps!

We’re going out for the Planning Curry for season five of the Ubuntu Podcast this week. Over the years, it has become a tradition for all the presenters to go out for a curry before the start of the season. It’s a time to catch up in person, as we haven’t seen much of each other since the end of the last season. But it’s also a chance to discuss any changes we want to make to the show and throw ideas for new segments around. So, if there’s anything you’d like to see in the new season, whether it’s an idea for a segment or a change to something we already do, please let us know. You can leave a comment on this blog post or get in touch using any of the methods on the show website. Thanks!

FCM reader Brian has pulled together my Scribus tutorials from the early issues of FCM and even added updated screenshots to it. So, if you’re thinking of creating a publication of any kind, you might want to check out this special edition.

http://fullcirclemagazine.org/scribus-special-edition/

I have been passionate about Free Software for a long time now. My contributions have always revolved around helping people make amazing things happen and realize what they are really capable of. I’ve shown many people that small niche that just fits them perfectly and seen them grow from there and make a difference.
Along the way I’ve always come accross two problems:

1. “I can’t do X (usually programming), how could I ever be useful to a project”
2. “This is so overwhelming, I don’t even know where to start.”

I’ve done a lot of things to overcome this but it wasn’t ever enough somehow. Today I am at FOSDEM presenting a book, that will be another step towards fixing these problems. Today I am releasing Open Advice.

Open Advice is the result of the collaboration of more than 50 people from all across Free Software. It is a collection of short essays about key things the authors wished they had known when they started contributing to Free Software. It’ll give a headstart to everyone who wants to contribute. It’ll also be useful for existing contributors who want to know a bit more about other projects and areas of contribution.

The book is available as a paperback and free PDF and is licensed under CC-BY-SA.

What are you waiting for? Download the PDF version today or order a printed version.

Additional goodies: The LaTeX source is available and a bug tracker exists as well.

A year ago I started working on this project and today it is reality. If you’re at FOSDEM I’m sure you can see me bouncing around with joy

It’s that time again. Alpha 2 was released yesterday, here is one members experience:

http://ubuntuforums.org/showthread.php?t=1919854

There have also been several threads on kernel panics with the 3.2 version:

http://ubuntuforums.org/showthread.php?t=1913073

http://ubuntuforums.org/showthread.php?t=1896087

http://ubuntuforums.org/showthread.php?t=1910857

My own problem was solved by removing an SD card from the card reader, but that really is only a work around. The problem looks to be solved with the next kernel release.

The classroom session effenberg0x0 and I put on at UDW went well, but we found we had to much information for the length of the session. We are in discussion about doing some sessions using the Community Learning Project.

You’re gonna catch a cold
From the ice inside your soul
Christina Perri — Jar of Hearts

I bet at four o’clock this morning you weren’t in a police station.

Or, at least, if you were I bet you were drunk and I bet it wasn’t voluntary.

After the usual Friday night poor showing from my local pub (people who
follow me on twitter will be aware that
the torture of watching a hundred people think they’re affirming their lives
by singing Mr Brightside at the top of their voices is a regular part of my
balanced weekly diet), I walked home, on a cold and cloudless night. I live
about ten minutes walk from town, so the walk’s no hardship, except that I was
dressed in shirt and no coat and it was, as mentioned, cold.

I need to be clear about this. Ten degrees below zero, Celsius, is seriously
chilly when you’re standing in it in shirt-sleeves. I’m sure people in actually
cold places like Canada or Minneapolis or Refrigeration, North Dakota will be
laughing mockingly at this point, but firstly, bugger off, secondly I bet you
lot bother to put a coat on when you go out, thirdly it’s not two in the morning
for you, and fourthly bugger off.

Anyway, I get home and… no door key in my pocket.

You know that feeling when the Fist of Fear grabs your balls when you realise
something disastrous has happened? (I don’t know what the Fist grabs for women.
Feel free to fill me in, or actually maybe not.) Anyway: yeah, that. I went
through the usual search-all-pockets-and-then-search-them-all-again routine,
just in case a mischievous cold-tolerant leprechaun hid my key from the first
search and then put it back, and… no door key. Oh dear.

I’ll tell you this; the walk back to the pub again seems a much longer trek.
Nowhere near as long as the second return to the house without my key, though,
after it turned out no-one had handed it in. And now, what the hell to do, eh?
I’m not prescient enough to hide a key in the garden, especially since that’s
a damned good way to come home one night and find no television where a
television used to be, so… locksmith? Do they have 24-hour locksmiths? I can’t
be the first moron to have done this.

If you’re bored today, I have a suggestion for you. Go and find a dude who
claims to be a 24-hour locksmith and punch him in his stupid lying face.

Incidentally, how in Jah’s name did anyone manage in this situation five years
ago without a smartphone, huh?

Not that the internet helps when no-one frigging answers their
supposedly-24-hour phone. Also, it turns out that about four of the local
24-hour locksmith companies are actually the same company, who did answer their
phone, agreed to send someone, and then after an hour of me standing in the
freezing bloody freezing cold confessed that they didn’t actually have anyone
to send.

It’s now half three in the morning, and the shivering is starting to get on
my nerves, and I can’t get into my house without destroying something like
a double-glazed plate glass window which will cost me hundreds of pounds to fix
and my hands are shaking enough that I can barely light a cigarette, let alone
throw a brick through a door that probably wouldn’t break anyway, and I’d like
to avoid the police showing up since I have no way of proving that I actually
live here except for being able to describe where all the broken bits of
skirting-board are, and everywhere is closed and the doors are all locked
and it’s really spectacularly bone-shudderingly mightily arse-clenchingly
ridiculously psychopathically cold, and what to do? I tried sleeping in the
shed. Now, cold is not like wind. Being inside a thin empty
wooden building does not protect you from it. I was shivering like a jackhammer
on a bouncy castle and it was becoming clear, even in my not-very-operational
brain state, that lying on the floor at minus ten with only a shirt on could
quite possibly lead to me actually freezing to death for real.

Well, if the police came, either I’d get into the house or they’d arrest me,
and being arrested would at least make me warm, and right now I’d cut my right
hand off if Pol Pot showed up as long as he brought a pair of gloves and some
soup.

And then, through the frozen and frosty neurons came the sparkling thought
that the police station would be open, wouldn’t it?

I actually felt warmer just at the thought. Not much warmer, though.

Anyway, that’s how I came to be sitting in the cop shop voluntarily at
four am. One lovely copper even made me a cup of tea after I poured out my
tale of woe in one long sentence, breaking only for my teeth to chatter together
like I was trying to bite through the world.

Police stations: while I appreciate that you’re generally there to deal with
miscreants and so on, it wouldn’t kill you to get rid of two
screwed-to-the-ground plastic chairs and put in, say, a chaise longue. After
switching my phone to airplane mode I managed to eke out enough battery life
that I could sit and read while huddled up against the radiator for five hours
until nine o’clock this morning, whereupon I went and fetched the spare key from
my estate agent after the longest and coldest and most sleepless night I have
ever experienced.

So, tips, for surviving a similar situation.

1. Have a spare key. Note: I do not have a spare key hidden in my garden,
   burglars, so don’t go looking for it. I do not know how to have a spare key
   somewhere where you can get at it but thieves cannot; suggestions
   welcomed.
2. Have a girlfriend so that there’s someone to let you back in.
3. Next time you see a policeman, be nice to him.

I think I might have a nap now.

I prefer the following CSS:

<html><body><head><style type="text/css">        @import url(/css/style.css);      </style></head></body></html>

But not all browsers support @import. I wanted to see exactly which ones didn’t so I used browsershots.org with a simple test.

Here are the results: http://browsershots.org/http://volatileminds.net/import_test.html

Black means it supports it. White means it doesn’t.

We have uploaded a new Precise linux kernel. Please note the ABI bump. The most notable changes are as follows:

* Rebase to upstream stable v3.2.3 and essentially v3.2.4

The full changelog can be seen at:

https://launchpad.net/ubuntu/+source/linux/3.2.0-14.23

Even though some of these tools have been around for years, I have only recently started using them.

A new great tool ready for using with our beloved Lubuntu: LxScreenshot! This is another brilliant creation from the Stefano, the same author of LxFind. You can imagine what’s its purpose, creating screen captures with ease and a simple interface, with timing capture (in seconds) and the option to choose the folder to save it on.

  

You can install this tool just by looking for it withHaven’t tried LxFind yet? For those who doesn’t know it, it will be the default file and document search tool or Lubuntu. For trying it (remember, it’s not an ultimate comilation) put this on a terminal:

sudo add-apt-repository ppa:lubuntu-desktop/ppa && sudo apt-get update && sudo apt-get install lxfind

 If you already added our PPA just install the package “lxfind”.

0 A.D. is an awesome cross-platform game that is fun, has stunning graphics and is completely open source.
There’s even a PPA for Ubuntu.
It works wonderfully on both my laptops.

They are looking for a round of donations to pay for some more development work, and as of this moment they’re $634 USD short. I’ve just sent $50 their way.
If you’ve got a few bucks to spare, please send some money their way. Or maybe you want to get into some development work, they have detailed instructions on how to do just that!

It took a while to get some apt resolver bugs fixed, a few packages marked for multi-arch and some changes in the Ubuntu LXC template, but since yesterday, you can now run (using up to date Precise):

• sudo apt-get install lxc qemu-user-static
• sudo lxc-create -n armhf01 -t ubuntu — -a armhf -r precise
• sudo lxc-start -n armhf01
• Then login with root as both login and password

And enjoy an armhf system running on your good old x86 machine.

Now, obviously it’s pretty far from what you’d get on real ARM hardware.
It’s using qemu’s user space CPU emulation (qemu-user-static), so won’t be particularly fast, will likely use a lot of CPU and may give results pretty different from what you’d expect on real hardware.

Also, because of limitations in qemu-user-static, a few packages from the “host” architecture are installed in the container. These are mostly anything that requires the use of ptrace (upstart) or the use of netlink (mountall, iproute and isc-dhcp-client).
This is the bare minimum I needed to install to get the rest of the container to work using armhf binaries. I obviously didn’t test everything and I’m sure quite a few other packages will fail in such environment.

This feature should be used as an improvement on top of a regular armhf chroot using qemu-user-static and not as a replacement for actual ARM hardware (obviously), but it’s cool to have around and nice to show what LXC can do.

I confirmed it to work for armhf and armel, powerpc should also work, though it didn’t succeed to debootstrap when I tried it earlier today.

Enjoy!

Last month i get a call  and email from FOMCA representative asking community to support their national program  Access to Knowledge- National Campaign on A2K Policies  , Campaign to promote Open Source Software to consumers . We (Ubuntu-my) are more than happy to corporate and collaborate with FOMCA to do our best to make the policy & campaign success. I will bring this topic to our 1st Ubuntu-my Meetup for 2012

Overall objective: Increase the uptake of free, legal software for Malaysian consumers
Specific objective: Create awareness among Malaysian suppliers and consumers to encourage the use of open source software which is the Ubuntu Linux instead of FreeDOS to provide a better computing experience and also reduce piracy

Activities:
1. Conduct an awareness seminar/workshop on piracy issue and access to knowledge. In this session, we can introduce the Ubuntu Linux operating system and how vendors and consumers can play a role in fostering the uptake of open source software and thereby reducing piracy.
2. Collaborating with the local community to promote the use of Ubuntu Linux among consumers
3. Promoting this campaign in our existing consumer websites under FOMCA.

Impact expected:
Consumer to have at least an awareness of the existence of free open source software and that they do have an alternative choice and at the same time can help in reducing piracy without having any disadvantage. We aim for this campaign to get the attention of the
industries as well as the government to come up with policies to encourage more open source software and move towards having more awareness session to make consumers understand and aware of their choices.

Here i share the full post by FOMCA and draft brochure for the awareness program.

I also hope that Ubuntu Community Globally & FOSS Community will give us support to make this happen ! \0/ May Ubuntu will r0cking all over Malaysia …

(This is part 2 of the PyQt+WebKit experiments series)

In Part 1 I described how to embed WebKit in a PyQt application and how to expose PyQt objects in WebKit and manipulate them with JavaScript.

Even if you are a great JavaScript master, you can’t avoid the occasional typo while writing JavaScript code in your application. This can be quite frustrating with QtWebKit because it likes to stay quiet: it won’t tell you about any error.

Let’s have a look at an example.

First here is loader.py, a simple Python script which loads a block of HTML:

import sys

from PyQt4.QtCore import *
from PyQt4.QtGui import *
from PyQt4.QtWebKit import *

class Window(QWidget):
    def __init__(self):
        super(Window, self).__init__()
        self.view = QWebView(self)

        layout = QVBoxLayout(self)
        layout.setMargin(0)
        layout.addWidget(self.view)

def main():
    app = QApplication(sys.argv)
    window = Window()
    html = open(sys.argv[1]).read()
    window.show()
    window.view.setHtml(html)
    app.exec_()

if __name__ == "__main__":
    main()

And here is “broken.html”, our broken HTML code:

<html>
<head>
<script>
function brokenFunction(arg1, arg2) {
    var result;
    result = arg1 * 2;
    result += arg2;
    resul /= 4;
    return result;
}
</script>
</head>
<body>
Complex computation:
<script>
document.write(brokenFunction(2, 3));
</script>
</body>
</html>

Notice the missing ‘t’ in “resul /= 4″?

The last-resort, grandpa-debugged-js-this-way, debugging tool is still there: the mighty alert() function. Just stuff your code with calls to alert() and be happy… Anyone ever wrote code like that?

<html>
<head>
<script>
function brokenFunction(arg1, arg2) {
    var result;
    result = arg1 * 2;
    alert("1");
    result += arg2;
    alert("2");
    resul /= 4;
    alert("3");
    return result;
}
</script>
</head>
<body>
Complex computation:
<script>
document.write(brokenFunction(2, 3));
</script>
</body>
</html>

Easy enough, no? With the great alert() function we can quickly pinpoint the bug in our brokenFunction() is between alert(“2″) and alert(“3″).

Can we do better?

alert()-style debugging gets old very fast. Clicking that “OK” button is a pain. Fortunately, there is a way to get more useful feedback from our PyQt application.

The job of the QWebView class is to show the content of a QWebPage instance. By default QWebView creates its own instance of QWebPage, but it is possible to replace this instance with our own QWebPage. The QWebPage class has a few virtual methods. Among them, the javaScriptConsoleMessage() method is the one we are looking for: it is called every time console.log() is called from JavaScript.

Here is an implementation of WebPage which uses Python logging module to get JavaScript console messages out:

import logging

from PyQt4.QtWebKit import *

class WebPage(QWebPage):
    """
    Makes it possible to use a Python logger to print javascript console messages
    """
    def __init__(self, logger=None, parent=None):
        super(WebPage, self).__init__(parent)
        if not logger:
            logger = logging
        self.logger = logger

    def javaScriptConsoleMessage(self, msg, lineNumber, sourceID):
        self.logger.warning("JsConsole(%s:%d): %s" % (sourceID, lineNumber, msg))

And here is “loader-log.py”, a loader which uses this class:

import os
import sys

from PyQt4.QtCore import *
from PyQt4.QtGui import *
from PyQt4.QtWebKit import *

from webpage import WebPage

class Window(QWidget):
    def __init__(self):
        super(Window, self).__init__()
        self.view = QWebView(self)
        self.view.setPage(WebPage())

        layout = QVBoxLayout(self)
        layout.setMargin(0)
        layout.addWidget(self.view)

def main():
    app = QApplication(sys.argv)
    window = Window()
    html = open(sys.argv[1]).read()
    window.show()
    window.view.setHtml(html)
    app.exec_()

if __name__ == "__main__":
    main()

If we load “broken.html” with “loader-log.py” we get the following on stderr:

$ python loader-log.py broken.html
WARNING:root:JsConsole(undefined:0): ReferenceError: Can't find variable: resul

That should make it easier to find and fix our bug, even if we don’t get very useful file names or line numbers.

javaScriptConsoleMessage() receives all console messages. This means our logger will also print out calls to console.log(). Here is “console-log.html”:

<html>
<head>
<script>
function chattyFunction(arg1, arg2) {
    var result;
    result = arg1 * 2;
    console.log("result" + result);
    result += arg2;
    console.log("result" + result);
    result /= 4;
    console.log("result" + result);
    return result;
}
</script>
</head>
<body>
Complex computation:
<script>
document.write(chattyFunction(2, 3));
</script>
</body>
</html>

When loaded with “loader-log.py”, we get this output:

$ python loader-log.py console-log.html
WARNING:root:JsConsole(about:blank:5): result: 4
WARNING:root:JsConsole(about:blank:5): result: 7
WARNING:root:JsConsole(about:blank:5): result: 1.75

Not good enough?

Getting the output of console.log() is nice, but modern browsers have much more efficient tools: if you open “broken.html” with Rekonq and look at the output in the Web Inspector Console, you can not only see console output, but you can also easily inspect your HTML tree and many other things.

Like us, Rekonq uses QtWebKit, so is there a way to get a similar tool?

It is actually possible. Rekonq uses a class named QWebInspector. All that is necessary to get a nice inspector tool for our application is to:

1. Get the QWebView page
2. set the QWebSettings.DeveloperExtrasEnabled attribute on this page
3. Instantiate a QWebInspector
4. Pass the view page to the inspector

Here is “loader-webinspector.py”, a new HTML loader which can show a web inspector when one presses F12:

import os
import sys

from PyQt4.QtCore import *
from PyQt4.QtGui import *
from PyQt4.QtWebKit import *

from webpage import WebPage

class Window(QWidget):
    def __init__(self):
        super(Window, self).__init__()
        self.view = QWebView(self)

        self.setupInspector()

        self.splitter = QSplitter(self)
        self.splitter.setOrientation(Qt.Vertical)

        layout = QVBoxLayout(self)
        layout.setMargin(0)
        layout.addWidget(self.splitter)

        self.splitter.addWidget(self.view)
        self.splitter.addWidget(self.webInspector)

    def setupInspector(self):
        page = self.view.page()
        page.settings().setAttribute(QWebSettings.DeveloperExtrasEnabled, True)
        self.webInspector = QWebInspector(self)
        self.webInspector.setPage(page)

        shortcut = QShortcut(self)
        shortcut.setKey(Qt.Key_F12)
        shortcut.activated.connect(self.toggleInspector)
        self.webInspector.setVisible(False)

    def toggleInspector(self):
        self.webInspector.setVisible(not self.webInspector.isVisible())

def main():
    app = QApplication(sys.argv)
    window = Window()
    html = open(sys.argv[1]).read()
    window.show()
    window.view.setHtml(html)
    app.exec_()

if __name__ == "__main__":
    main()

The four steps I described are done in the “setupInspector()” method.

And here is “console-webinspector.html”:

<html>
<head>
<script>
function chattyFunction(arg1, arg2) {
    var result;
    result = arg1 * 2;
    console.log("result: %d", result);
    result += arg2;
    console.warn("result: %d", result);
    result /= 4;
    console.error("result: %d", result);
    return result;
}
</script>
</head>
<body>
Complex computation:
<script>
document.write(chattyFunction(2, 3));
</script>
</body>
</html>

It is similar to “console-log.html” but takes advantage of two new features which do not work with the previous approach:

• printf-style formatting: that is, printing the value of result with "result: %d", result, not "result: " + result
• log categorization: you can use console.warn() and console.error() to get different type of output. These methods worked with the previous approach, but the categorization was lost.

Loading “console-webinspector.html” with “loader-webinspector.py” and pressing F12 we get this:

Closing words

These two approaches should help you track down the nastiest bugs in your embedded JavaScript code. The Web Inspector approach is probably the most powerful one, but the Python logging approach can also be useful when tracking down bugs where it is more practical to have one single log output for both the PyQt and the JavaScript sides.

I recently had the pleasure of being among the first to use the new sponsorship system in Debian.

For a non-insider (that is, someone who is not an official Debian Developer), getting a package into the Debian distribution and, by proxy, into the Ubuntu distribution requires getting the attention of someone with sufficient interest and privilege to do the actual upload. It’s called finding a sponsor in Debian parlance, and it’s sometimes a bit of a challenge.

The traditional approach for the last while is to build a source package for your software, make it available somewhere over the internet, and then post a message to the debian-mentors@lists.debian.org mailing list and hope that someone takes the bait. This is usually followed by pleads in IRC and follow-up messages to the mainling list.

Recently, a new workflow was set up in which you file a bug against the sponsorship-requests pseudopackage and hope that someone is interested. Among the advantages of this new workflow is that (a) it’s similar to other Debian workflows you need to learn when packaging software for Debian (for example, the WNPP pseudo-package) and (2) there is a place where sponsorship requests are aggregated.

It’s a fast, easy to use, and (in my experience) effective way to find a sponsor for your package in Debian. Here’s the basic workflow you need to follow.

1. State your intention by filing and ITP or ITA bug with WNPP.
2. Package your software.
3. Upload the source package to mentors.debian.net.
4. Use reportbug or send an email to submit@bugs.debian.org with a carefully formatted message — see this for an example.  There is no reportbug template available for the sponsorship-requests pseudo-package, so using your usual mail program will probably be easier for now.
5. When your new bug is confirmed, link to to your WNPP bug if necessary (and it should be necessary). The command “bts affects SRbug + src:srcpkg . block WNPPbug by SRbug” will do.
6. Sit back and wait.

This new workflow is remarkably similar to filing an upload request through Launchpad.  I assure you it’s a complete coincidence and convergent evolution at work.

I have been using Scrum for a while. Back at my previous role, we tried using Scrum within the integration team that was creating the nightly builds and our bi-weekly releases. It brought good results, the team specially liked the visibility of the task board and the daily stand-ups.

We did found a bit artificial to have a cadence. We were suppose to put out a release every two weeks but we end up doing it as often as we could (or made sense), as we were not in control of when the new software was landing in our plate.

Since then, I’ve this nagging thought that Scrum might not be appropriated to service teams or teams with a large portion of maintenance/customer support work. I have found iterations shorter than 2 weeks, can be over burden by the demo, planning and sizing overheads. In the other hand, two weeks is too much time for teams with Service Level Agreements of days or hours. It also seems a bit cumbersome for short project (~1 month), were you end up with 2 or 1 iterations… What to do!?

In Canonical several teams have used Kanban in order to improve their development processes, so I started reading up on it when I stumbled on this excellent article on Kanban vs Scrum.

The author won me over straight away by not trying to decide which of the two practices is best but instead doing a great job at remaining impartial.

Looking back at the Symbian Foundation’s integration team it seems that Kanban would have been better suited. It retains the focus on making information visible while concentrating on reducing WIP.  It seems better suited to a “specialist” team, where most members share the same skills and work on similar tasks. Scrum seems to work better for cross-discipline project teams.

Also, the emphasis on managing constant flow of work is one that resonates with teams that have a work “currency” measured in days of effort (bugs?) rather in large projects lasting months at the time.

While Scrum has been very successfully adopted by the Certification team at Canonical, My previous experience with the Integration team had stopped me from cheering on Scrum in teams that have a constant flow of work. Now, we are thinking on going Kanban! Don’t get me wrong, we are going to continue using Scrum. It is just a case of using the right tool for each job. I will keep you posted on how it goes.

If you have any advice, tips or gotchas that you could share with us, I would be most grateful if you could drop your comments here!

 

It’s sad news, yes – Ubuntu Developer Week for the 12.04 cycle is over. It’s been three fantastic days full of action-packed sessions. If you couldn’t attend, check out the logs of the sessions, all of them are posted on the UDW page.

Here’s what happened on day 3, yesterday:

1. Fixing Desktop bugs — seb128Sébastien Bacher kicked off our last day. At first he took some time to explain how the Desktop team works and how they go about fixing bugs, then he took a quite recent example and explained how to work all the individual packaging bits to fix a Desktop bug in Ubuntu. For bonus points he explained how to get Wanda the Fish working in Ubuntu.
2. Triaging Desktop bugs — om26erNext up was Omer Akram, who first gave us an update about his personal life, then quickly dived into triaging bugs. He explained all the actors involved, what to bear in mind and general things to make sure when you are reviewing bug reports. Omer, who started out by triaging bugs himself, did a great job explaining how to get involved and why it’s so important.
3. Simple Lenses with Singlet — mhall119Michael Hall, an unstoppable force throughout UDW, provided a great session about how to write lenses for Unity using Singlet. For developers who have used Python in the past, this might be an even easier (and more pythonic way) to interact with Unity and Desktop bits.
4. Building locally with pbuilder — tumbleweed
   Those of you venturing into the land of Ubuntu development will have to deal with packaging and it’s good to do it in a safe, clean and reproducible manner. Stefano Rivera explained a lot of options for doing that including some advanced features useful if you want to debug builds. Great work.
5. Writing Crisp Changelogs — coolbhavi
   Again for those of you interested in package maintenance: it’s important to document your work properly. You don’t want anybody (including yourself) having to go back in a few months or years and dive into the archaelogy of a package to understand what exactly was changed and why. Bhavani Shankar shared his experience in writing crisp changelog entries.
6. Getting started with contributing to Ubuntu Documentation — jbicha
   The Ubuntu Documentation project is of vital importance to everyone who is new to Ubuntu. Also is it a great way to get involved with Ubuntu, as Jeremy Bicha showed. He explained how to the team works generally and how to actually go and contribute improvements.
7. Adding Ubuntu One to your applications — aquarius
   If you want to allow you application to sync data to the internet, it never was easier. Stuart Langridge showed and explained some easy examples which demoed how to tie in Ubuntu One services into your app.
8. Pair Programming and Code Review in the Cloud! — kirkland
   Dustin Kirkland did an impressive live demo of how to use EC2 to do pair programming, review of code and builds. He used tmux and byobu and explained in detail how to drive the infrastructure. Unfortunately the log is a bit colourless without the live demo right next to it.
9. Syncing your app data everywhere with U1DB — aquarius
   Nothing stops Stuart Langridge when he’s on a roll. He delivered his second session all about the new Ubuntu One Database. For those of you new to the initiative: “U1DB is for syncing data — that is, something structured — to every device you want”. The session is short, has lots of good information in it and a nice example of how to work with it.
10. Automated packaging with pkgme — james_w
    James Westby gave a great introduction to the pkgme project he has been working on and it’s fantastic to see that a lot of repetitive tasks are done by a tool. It was nice to see pkgme package itself. Give it a whirl and let James know how it works out for you.
11. Fixing internationalisation bugs — kelemengabor
    Gábor Kelemen is one of the heroes of Ubuntu’s internationalisation. Keeping all packages translatable and translations in shape matters deeply to him and he gave a nice overview over how common problems can easily be resolved. Köszönöm Gábor!
12. How to fix small bugs in Ubuntu — warp10
    Andrea Colangelo took over and quickly ran us through a couple of examples of fixed bugs and explained how exactly they were fixed. By the end of the session it was clear that in a lot of cases it’s no rocket science to go and fix a bug. Grazie mille, Andrea – I hope many will find your session as encouraging as we did.
13. Problem Lifecycle in Ubuntu — cprofitt
    Charles Profitt delivered the last session of the event and explained how all teams in Ubuntu work together to go from problem to solution, involving the lifecycle of a bug report, which was a big enough topic on its own already. Throughout the session he showed how you can join each of the teams and make a difference. Awesome!

What a fantastic day. Thanks a lot to all the speakers who made this Ubuntu Developer Week possible. Thanks a lot to everyone who attended as well. It was great to see a lot of interaction, questions and interest. Until next time!

Back in September, we announced our first fastdowntime deployment. That was a new way to do deployment involving DB changes. This meannt less downtime for you the user, but we were also hoping that it would speed up our development by allowing us to deliver changes more often.

How can we evaluate if we sped up development using this change? The most important metric we look at when making this evaluation is cycle time. That’s the time it takes to go from starting to make a change to having this change live in production.  So before fastdowntime, our cycle time was about 10 days, and it is now about 9 days. So along the introduction of this new deployment process, we cut 1 day off the average, or a 10% improvement. That’s not bad.

But comparing the cumulative frequency distribution of the cycle time with the old process and the new will give us a better idea of the improvement.

On this chart, the gap between the orange (fastdowntime deployment) and blue (original process) lines shows the improvement to us.  We can see that more changes were completed sooner. For example, under the old process about 60% of the changes were completed in less than 9 days whereas about 70% were completed under the same time in the new process. It’s interesting to note that for changes that took less than 4 days to complete or that took more than 3 weeks to complete, there is no practical difference between the two distributions. We can explain that by the fact that things that were fast before are still fast, and things that takes more than 3 weeks would usually have also encountered a deployment point in the past.

That’s looking at the big picture. Looking at the overall cycle time is what gives us confidence that the process as a whole was improved. For example, the gain in deployment could have been lost by increased development time. But the closer picture is more telling.

The cycle time charted in this case is from the time a change is ready to be deployed until it’s actually live. It basically excludes the time to code, review, merge and test the changes. In this case, we can see that 95% of the changes had to wait less than 9 days to go live under the new process whereas it would take 19 days previously to get the same ratio. So an
improvement of 10 days! That’s way more nice.

Our next step on improving our cycle time is to parallelize our test suite. This is another major bottleneck in our process. In the best case, it usually takes about half a day between the time a developer submits their branch for merging until it is ready for QA on qastaging. The time in between is passed waiting and  running the test suite. It takes about 6 hours to our buildbot to validate a set of revisions. We have a project underway to run the tests in parallel. We hope to reduce the test suite time to under an hour with it. This means that it now would be possible for a developer to merge and QA a change on the same day! With this we expect to shave another day maybe two from the global cycle time.

Unfortunately, there are no easy silver bullets to make a dent in the time it takes to code a change. The only way to be faster there would be to make the Launchpad code base simpler. That’s also under way with the services oriented architecture project. But that will take some time to complete.

Photo by Martin Heigan. Licence: CC BY NC ND 2.0.

Ubuntu our LEB and the overall Developer Experience on ARM are hot topics again for Linaro Platform Team this Connect (http://connect.linaro.org).

Be sure that you have checked and subscribed to your preferred sessions by the Developer Platform Team. Even if you cannot attend the event in person, there is no reason to not participate remotely. To make this even more convenient and interactive, Linaro will experiment with google hangouts this time. Be sure to check this out!

Here a convenience list of sessions by the DevPlatform Team announced by Ricardo Salveti a few days ago on linaro-dev:

Ubuntu LEB and LAVA: Current status and future planning for proper
image testing and validation
https://blueprints.launchpad.net/linaro-ubuntu/+spec/linaro-platforms-q112-lava-and-ubuntu-leb-testing-validation

Improvements and future discussions for LTs and the Ubuntu LEB
https://blueprints.launchpad.net/linaro-ubuntu/+spec/linaro-platforms-q112-lt-platform-discussions

Packaged Kernel CI: Current Status and Next Steps
https://blueprints.launchpad.net/linaro-ubuntu/+spec/linaro-platforms-q112-packaged-kernel-ci-next-steps

Sysroots: Automation, Maintenance and Future Work
https://blueprints.launchpad.net/linaro-ubuntu/+spec/linaro-platforms-q112-sysroots-automation-maintenance

U-Boot-Linaro Future Planning
https://blueprints.launchpad.net/linaro-ubuntu/+spec/linaro-platforms-q112-u-boot-linaro-future-future-planning

Developer Platform: Future Planning
https://blueprints.launchpad.net/linaro-ubuntu/+spec/linaro-platforms-q112-dev-plat-future-planning

Cross Build with Multi-Arch: Current state and future planning
https://blueprints.launchpad.net/linaro-ubuntu/+spec/linaro-platforms-q112-cross-multi-arch-support

Maximizing the usefulness of the LEB for customers and members
https://blueprints.launchpad.net/linaro-ubuntu/+spec/linaro-platforms-q112-maximizing-usefulness-leb 

Exciting stuff! The original post to the mailing list can also be found in the archives:

• http://lists.linaro.org/pipermail/linaro-dev/2012-January/009919.html

Phew! It’s been a crazy ride to release Unity 5.2 once ubuntu precise released its alpha 2, but we finally get there!

Thanks a lot for all the community participation, we actually got 27 testers answering to Nick’s call for testing. Those were high quality contributions and enabled us to get closer to the unity release.

So, what’s new since 5.0? Well, a lot! More precisely, we got multimonitor support with screen edge detection, “push to reveal” launcher behavior to avoid false positive when hitting the back button of firefox, per workspace alt-tab switcher, new home dash, automaximize only on netbooks and a lot of small details that matter.

Test results

Here are some feedback after 5 hours that I took to collect and analyze the test results from all the (numerous) comments that were on the test results:

• Testers confirmed that some of the issues spotted on 5.0 are now fixed, which is a great news! Not all of them, and of course, we have some minor regressions. I added those issues to the list of “distro priorities”. You can look at them there. This list doesn’t show all the defects we have, of course, but give a good overview of the big ones we track to ensure they are fixed as soon as possible.
• Some tests have been updated due to new upstream behavior (like the per workspace scale option and new home dash which now retains its search status). Thanks for people testing it and to have spotted that we missed those changes when updating the tests! We also rephrased with the given suggestions some of them.
• Some people seem to get difficulties to open menus from the application and the indicator when clicking on them in the panel (only Alt or F10 seems to work). I strongly invite them to open a bug repot with a video attached and giving more info as I couldn’t reproduce it there.
• There is a bamf bug revealing only on some particular circumstances (8 fails, and last time, we also get some failures on this test) when testing launcher/quicklist-pin. I personnaly couldn’t reproduce it here. Then, I asked seb128 to give it a shot and he could get the issue. I tried again and this time, I got it! However, this seems to not be reliable or reproducible 100%. We opened a bug and put it on the priority list. Well spotted everyone!
• Also some testers made some interesting design request, I’m reminding you of this link on how to join the relevant mailing list to participate in unity design (the introduction text stated it though ).
• We got also some comments of “key above tab” and why we used this terminology rather than directly telling, let’s say “`”. Please remember that this is a keyboard dependent configuration! The usa keyboard is normally using `, my azerty keyboard is using ², it seems that for some other configuration it’s < or ~. So yeah, we have to keep the test cases as generic as possible, bare with us, please!
• We added some new test cases as well due to a very particular way of triggering some bugs like for instance bug #877778. Thanks to the one adding a comment to explain how to trigger it!
• Despite our strong efforts to make an easy way for unity restarting on a simple click from the tests (and improving it), it seems that the glibmm/compiz bug preventing to restart it reliably on demand is still an issue. It’s not a very important bug for everyday use, however, it will be nice that we can get it over for the tests in particular. Fortunately, checkbox enables you to continue the tests where you stopped even if you had to restart your session.

A story of boot time

Finally and probably the most important feedback from the whole list, peope started to feel that “it was longer to start/boot”. Jumping on this fact, we made some bootcharts on our machines to get real and precise values and you know what… the comments were right! The multimonitor support made the boot time badly regressing. Consequently, we decided to delay the release until today to get that fixed rather than pushing a version with this performance impact on intel cards. We finally got the fix, push it to trunk and now, this is all old story! Thanks to all the community for spotting this one, it’s better to remark it earlier than later and this participation really had a visible impact (or rather avoided some real visible impact ) for a bunch of users. Well done!

The importance of testing defaults

Some testers remarked that in the system settings test, we never told to add gnome control center to the launcher. However, in the introduction text, we clearly expressed that we expect testers having the default settings (you have the guest session for it, use it, love it!) and the system settings is by default pinned in the launcher. For instance, intellihide is the default behavior and we didn’t say anything to ensure that intellihide is there. If we did it, there will be a long list of prerequesites on the top of each test that I’m sure testers don’t want to see? We strongly recommend people using the guest session to ensure all settings and environment are correct for the tests!

To sum up

Unity 5.2 is now building in the official repositories and should soon be available to all precise users. Thanks again to everyone participating in this project and see you soon for… 5.4 (or maybe a little bit before for an incoming compiz release that I heard of) !

After upgrading to Precise, I noticed that Skype was uninstalled.  But it was easily fixed by downloading the deb from Skype’s site.

But now, at each update via-update manager, it says the skype package should have been removed and I need to remove it before proceeding?

Is this a bug?  Any workaround?

PackageKit has a “WhatProvides” API for mapping distribution independent concepts to particular package names. For example, you could ask “which packages provide a decoder for AC3 audio files?

$ pkcon what-provides  "gstreamer0.10(decoder-audio/ac3)"
[...]
Installed   	gstreamer0.10-plugins-good-0.10.30.2-2ubuntu2.amd64	GStreamer plugins from the "good" set
Available  	gstreamer0.10-plugins-ugly-0.10.18-3ubuntu4.amd64	GStreamer plugins from the "ugly" set

This is the kind of question your video player would ask the system if it encounters a video it cannot play. In reality they of course use the D-BUS or the library API, but it’s easier to demonstrate with the PackageKit command line client.

PackageKit provides a fair number of those concepts; I recently added LANGUAGE_SUPPORT for packages which provide dictionaries, spell checkers, and other language support for a given language or locale code.

However, PackageKit’s apt backend does not actually implement a lot of these (only CODEC and MODALIAS), and aptdaemons’s PackageKit compatibility API does not implement any. That might be because their upstreams do not know enough how to do the mapping for a particular distro/backend, because doing so involves distro specific code which should not go into upstreams, or simply because of the usual chicken-egg problem of app developers rather doing their own thing instead of using generic APIs.

So this got discussed between Sebastian Heinlein and me, and voila, there it is: it is now very easy to provide Python plugins for “what-provides” to implement any of the existing types. For example, language-selector now ships a plugin which implements LANGUAGE_SUPPORT, so you can ask “which packages do I need for Chinese in China” (i. e. simplified Chinese)?

$ pkcon what-provides "locale(zh_CN)"
[...]
Available   	firefox-locale-zh-hans-10.0+build1-0ubuntu1.all	Simplified Chinese language pack for Firefox
Available   	ibus-sunpinyin-2.0.3-2.amd64            	sunpinyin engine for ibus
Available   	language-pack-gnome-zh-hans-1:12.04+20120130.all	GNOME translation updates for language Simplified Chinese
Available   	ttf-arphic-ukai-0.2.20080216.1-1.all    	"AR PL UKai" Chinese Unicode TrueType font collection Kaiti style
[...]

Rodrigo Moya is currently working on implementing the control-center region panel redesign in a branch. This uses exactly this feature.

In Ubuntu we usually do not use PackageKit itself, but aptdaemon and its PackageKit API compatibility shim python-aptdaemon.pkcompat. So I ported that plugin support for aptdaemon-pkcompat as well, so plugins work with either now. Ubuntu Precise got the new aptdaemon (0.43+bzr769-0ubuntu1) and language-selector (0.63) versions today, so you can start playing around with this now.

So how can you write your own plugins? This is a trivial, although rather nonsense example:

from packagekit import enums

def my_what_provides(apt_cache, provides_type, search):
    if provides_type in (enums.PROVIDES_CODEC, enums.PROVIDES_ANY):
        return [apt_cache["gstreamer-moo"]]
    else:
        raise NotImplementedError('cannot handle type ' + str(provides_type))

The function gets an apt.Cache object, one of enums.PROVIDES_* and the actual search type as described in the documentation (above dummy example does not actually use it). It then decides whether it can handle the request and return a list of apt.package.Package objects (i. e. values in an apt.Cache map), or raise a NotImplementedError otherwise.

You register the plugin through Python pkg-resources in your setup.py (this needs setuptools):

   setup(
       [....]

       entry_points="""[packagekit.apt.plugins]
what_provides=my_plugin_module_name:my_what_provides
""",
       [...])

You can register arbitrarily many plugins, they will be all called and their resulting package lists joined.

All this will hopefully help a bit to push distro specifics to the lowest possible levels, and use upstream friendly and distribution agnostic APIs in your applications.

We have uploaded a new Precise linux kernel. Please note the ABI bump. The most notable changes are as follows:

* Fixes for radeon issues on MacBook Pro 8,2
* Nouveau: nvidia optimus vga_switcheroo support
* Bluetooth: Add support for BCM20702A0 devices
* Enable USB3.0 in d-i
* mtip32xx driver updates
* Misc regression fixes

The full changelog can be seen at:

https://launchpad.net/ubuntu/+source/linux/3.2.0-13.22