Planet UBUNTU

Even though some of these tools have been around for years, I have only recently started using them.
* byobu - nicer than plain screen with good defaults, for example key binding for scrolling is like in a regular terminal.* sbuild - nicer than pbuilder, defaults to overlay directory instead of tarball, hence fast by default, nice colors, build summary. I have heard about it for a long time, but the recent mention during Ubuntu devel week made me curious. It is friendlier now - no need for LVM snapshots. http://wiki.debian.org/mk-sbuild* syncpackage - which now allows syncing from Debian if you have Ubuntu upload rights. No need to burden the archive team members anymore for every sync or go the roundabout way of getting from Debian and then uploading manually without changes.* Modern Debian packaging in the form of the 3.0(quilt) source format and the new dh tools. The former allows a cleaner separation between the upstream and distro bits while the latter makes the debian/rules file much shorter and cleaner even than with CDBS, let alone with the classic debhelper way.* Twitter Bootstrap - mostly unrelated to packaging or command line stuff, but very nice regardless. CSS+Javascript UI elements that for me at least make jQueryUI superfluous, while being promoted as 'oh, just a CSS framework and style guide, not much else'.

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 with

Haven'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 [...]

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!

Time to try something new (by theonlyanla)

 

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

I’ve been maintaining the gedit documentation since the run-up to the gedit 3.0 release, and doing so has helped me to get to know some of the ins-and-outs of the program. What can I say, it’s one of the perks of writing documentation – you get to know the software that you’re documenting.

With that, though, I thought I’d pass along some of the basic configurations that help me to write documentation more quickly, and in a more consistently-formatted way.

Here’s a quick run-down of some settings that you may find helpful:

View Preferences – Edit > Preferences > View:

• Check the following items:
• Display line numbers (this helps with locating validation errors)
• Display right margin at column (80 characters) (breaking lines at 80 characters makes diffs look prettier)
• Highlight the current line
• Highlight matching brackets (optional: I don’t use this feature, but some people prefer it)
• Uncheck:
• Enable text wrapping (not needed if you’re breaking lines at 80 characters)

Editor Preferences: Edit > Preferences > Editor

• Tab Width: 2
• Check
• Insert spaces instead of tabs
• Enable automatic indentation
• Uncheck
• Create a backup copy of files before saving (not needed if you’re using revision control, like git or bzr)

With regards to plugins, I recommend enabling the dashboard plugin (which will be available as part of gedit 3.4, included in Ubuntu 12.04, Fedora 17, OpenSUSE 12.2, etc.), and the gedit snippets plugin. In the near future I’ll be writing up a post about using gedit snippets.

One other neat feature that I often use with gedit is the keyboard shortcut for moving a line up or down within the text. If you position your mouse cursor on any point in a line, and then press Alt + Up Arrow, it will move the entirety of that line up within the text. Pressing Alt + Down Arrow will move that line down within the text. Simple enough! (The complete list of gedit shortcut keys is available in the user help, by the way. Just open up gedit and press F1.)

Do you have any suggestions or tips for using gedit to write documentation? If so, I’d appreciate you sharing them with me in the comments.

The alpha release for our development version, codenamed Precise, is available for download. Early testers can try it to provide feedback and bug reports. This is the first alpha for Kubuntu in the Precise series but the second from the Ubuntu family.

12.04 (Precise Pangolin) Alpha 2 is now available for those developers and testers interested in helping find and fix bugs before we beta.

More details can be found at: https://wiki.ubuntu.com/PrecisePangolin/TechnicalOverview/Alpha2

Welcome to Precise Pangolin Alpha 2, which will in time become Ubuntu 12.04.

Pre-releases of Precise Pangolin are *not* encouraged for anyone needing a stable system or anyone who is not comfortable running into occasional, even frequent breakage. They are, however, recommended for Ubuntu developers and those who want to help in testing, reporting, and fixing bugs.

Alpha 2 is the second in a series of milestone images that will be released throughout the Precise development cycle.

This is the first Ubuntu milestone release to include images for the armhf architecture, for the ARM CPUs using the hard-float ABI.

New packages showing up for the first time include:

• Linux Kernel 3.2.2 (3.2.0-12.21)
• Upstart 1.4
• Unity 5.0
• LibreOffice 3.5 beta 2

You can download Alpha 2 images here:

http://cdimage.ubuntu.com/releases/precise/alpha-2/ (Ubuntu, Ubuntu Server)

Additional images are also available at:

http://cloud-images.ubuntu.com/releases/precise/alpha-2/ (Ubuntu Cloud Server)
http://cdimage.ubuntu.com/ubuntu-core/releases/precise/alpha-2/ (Ubuntu Core)
http://cdimage.ubuntu.com/netboot/precise/ (Ubuntu Netboot)
http://cdimage.ubuntu.com/edubuntu/releases/precise/alpha-2/ (Edubuntu DVD)
http://cdimage.ubuntu.com/kubuntu/releases/precise/alpha-2/ (Kubuntu)
http://cdimage.ubuntu.com/lubuntu/releases/precise/alpha-2/ (Lubuntu)
http://cdimage.ubuntu.com/mythbuntu/releases/precise/alpha-2/ (Mythbuntu)
http://cdimage.ubuntu.com/xubuntu/releases/precise/alpha-2/ (Xubuntu)

Alpha 2 includes a number of software updates that are ready for wider testing. This is quite an early set of images, so you should expect some bugs. For a more detailed description of the changes in the Alpha 2 release and the known bugs (which can save you the effort of reporting a duplicate bug, or help you find proven workarounds), please see:

http://www.ubuntu.com/testing/

If you’re interested in following the changes as we further develop 12.04, we suggest that you subscribe initially to the ubuntu-devel-announce list. This is a low-traffic list (a few posts a week) carrying announcements of approved specifications, policy changes, alpha releases, and other interesting events.

http://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-announce

Originally sent to the ubuntu-release mailing list by Kate Stewart on Thu Feb 2 20:27:28 UTC 2012