It’s been a long standing policy that bugs are off-topic for Ask Ubuntu and for good reason, we have Launchpad which is the best place for bugs in Ubuntu to end up. Before I dive too deeply into the history of this issue and what we’re doing to fix this, if you have a bug please see here on how to report it! Despite having formed the “No bugs on Ask Ubuntu” policy over a year and a half ago we’ve ended up being too lax in how we identified and handled bugs. As a result the site is swimming with “Questions” that have no answer and likely never will because they are bugs.
We can improve Ask Ubuntu by just pointing the user to bug filing advice and promptly closing the question. - Martin Pool
To combat this we’ve mobilized the community to weed out, flag, and close these buggy questions which means a lot of questions will end up closed as off-topic. This isn’t a bad thing – in fact it’s quite a good thing. With each question getting a sign post saying “This is a bug, report your bug to Launchpad” any future users who stumble on to these questions from search engines will now know where to look, instead of finding disappointment in an answer-less ”question”.
We need more help! If you happen to come across a question on Ask Ubuntu that’s a duplicate of an existing bug report, or clearly should be submitted as a bug report, click the “flag” button at the bottom of the post and let us know! The sooner we prune and notify users these are actually bugs the quicker we can get them logged against the appropriate Launchpad project/package. The result will be a more fluid experience for new users and future users (since all these bugs will be fixed!). If you have questions about whether a question is a bug you can join the Ask Ubuntu chat or ask on the Ask Ubuntu Meta site.
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:
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:
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:
Get the QWebView page
set the QWebSettings.DeveloperExtrasEnabled attribute on this page
Instantiate a QWebInspector
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:
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.
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!
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.
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) !
One of the "good problems" I think we have is there's always things to do. As Charlie Kravetz points out, this can be a bad thing too.
I wanted to post this on Planet to get a better feel for what other people think.
I see my own participation in Xubuntu and Ubuntu development slowing down. Too many events, scheduled on top or close to each other, making it impossible to participate easily.
We are either scheduling too many things, or not checking calendars any more. In past years, it was quite easy to attend all the events held and still participate in development testing.
So for certain things I think we're doing too much, which is why we've streamlined some of the IRC workshops to be shorter. However as I thought of a more detailed answer to Charlie's concern I came up with the answer (I think).
I don't think we have too many events, in fact, as we grow the number of events will grow, and our community will need to scale to match that. I am starting to realize that it's not a bad thing that people can't find the time to participate in everything.
The real problem isn't that Charlie doesn't scale, it's that someone needs to have his back. So perhaps when events do clash we should look at which teams have what coverage in what events. For example, Charlie clearly needs to do ISO testing, but at the same time Xubuntu should have coverage in developer week because it's really one of the best places to find new contributors that can .... help Charlie do ISO testing. Catch 22.
So maybe from a team level instead of an individual level we should be focusing on finding people who can jump in when a team is overtaxed for a week. For example, in hindsight maybe we could have done a better job helping Charlie find someone to cover developer week for Xubuntu. A forum thread, a planet post, a tweet, a mention on our Facebook page?
These are all things we could do to help the creaking an overburdened person might face. It's a bummer that one person can't scale, but at the same time having different people focusing on different individual things will probably be healthier in the long run.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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!
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.
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!
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:
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:
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.
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!
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... :D
Bringing your app to Ubuntu — dpm David Planella kicked of day 2 and gave a well-structured session about how to get your app into Ubuntu and managed to answer heaps and heaps of questions. If you missed the session, make sure you go back and read the log.
How to update a package to the latest upstream version in the repositories — coolbhavi
Bhavani Shankar gave an excellent session about how to take an actual source package from Ubuntu and update it to a newer upstream release. He placed great importance on all the pitfalls and explained how to make sure it gets reviewed by our Ubuntu sponsors.
Ubuntu Technology overview — mhall119
Indicators, lenses, scopes, APIs, Michael Hall got the best out of half an hour by explaining everything to tightly integrate your app or code in general with Ubuntu technologies. Great work.
Charming Juju — m_3 Mark Mims was up next and talked about juju, a great way to deploy services in all kinds of scenarios. Unfortunately he struggled with his internet connection towards the beginning, but quickly found back into the session and explained the basics and how it works. Server admins: go and check it out.
If you always wanted to take a peek at the new development release but were afraid to do it, check out this great session by our dynamic duo Alvaro Leal and Jim Kielman. They quickly went through all the available options to do this in a safe manner, answered questions and mentioned this as a great way to play around with the new development release, to test it or to develop on it.
Ubuntu is based on Debian and has a great relationship with it. Stefano Rivera took great care to explain why it is important we work closely, how to work with Debian maintainers and also where differences in the chosen infrastructure are. I was very pleased to see how much interest was in the session.
Bazaar and Ubuntu Distributed Development have come a very way and nowadays make many many packaging and package maintenance tasks a lot easier. Barry Warsaw has been working closely with the Launchpad and Bazaar team, so he did a great job explaining how it all works and demo with a few examples how you can make use of it and how it can make your life easier.
Iain Lane basically started where Stefano Rivera’s session stopped earlier and talked about how to get things done in Debian. He showed how Debian’s instrastructure is used and who to talk to if you might ever get stuck. Awesome!
Starting with HTML/CSS — benonsoftware
We mentioned it earlier already: Ben Donald-Wilson not only gave the session at 7:30 in the morning, but also on his birthday! We couldn’t find out if he had a long party before the session, but in any case it was an excellent session. With a small example he explained basics of HTML and CSS use. A great introduction who are new to the topic. Thanks again and happy birthday Ben!
Italy took over the last session of the day and it was Marco Trevisan and Andrea Azzarone who brought a great introduction into making Unity even more awesome. Everything was covered here: what’s what, where to find simple tasks to work on, how to build it, how to debug it and much much more. Grazie mille guys!
What a lot of excellent content. What a huge amount of great people and great questions.
The good thing is, there’s more. Here’s what our last day has for you:
15:30 UTC: Triaging Desktop bugs — om26er Omer Akram is up next and will make sure you find Desktop bugs to work on most easily. When looking at Desktop bugs there’s common things to look out for, there’s other projects to interact with and many more things to bear in mind. After this session it will be all clear to you.
16:00 UTC: Simple Lenses with Singlet — mhall119 Do you like Unity Lenses? Learn how to use Singlet to create simple lenses to further enhance Unity. Michael Hall has been playing around with and can give you all the details.
16:30 UTC: Building locally with pbuilder — tumbleweed You have been compiling software before? Excellent. Watch Stefano Rivera’s session and see how you can build packages in a clean and safe environment very easily.
17:00 UTC: Writing Crisp Changelogs — coolbhavi
In a software world with thousands of other developers, it’s important that you document your changes carefully. Bhavani Shankar will share his Dos and Don’ts with you.
17:30 UTC: Getting started with contributing to Ubuntu Documentation — jbicha Jeremy Bicha will introduce you to the Ubuntu Documentation project. A team full of unsung heroes who bring clean and crisp documentation to every single release. Join in for the fun and find out how to contribute.
18:00 UTC: Automated packaging with pkgme — james_w So you wrote an app and are afraid of packaging? Don’t worry, James Westby will be here to talk about pkgme and all the goodness it can do for you.
18:30 UTC: Pair Programming and Code Review in the Cloud! — kirkland Dustin Kirkland is up next and will show you ways in which you can collaborate most easily and directly. Stay tuned for a great session about pair programming and doing code review, in the cloud!
19:30 UTC: Adding Ubuntu One to your applications — aquarius Stuart Langridge doesn’t stop at the database side of things, he will also show you how to integrate this great service tightly into your app. Stop worrying about data storage, just do it.
20:00 UTC: Syncing your app data everywhere with U1DB — aquarius The Ubuntu One team has lots of experience with syncing terrabytes of data across devices. U1DB is here to make data syncing for app easier. Stuart Langridge will show you how.
20:30 UTC: Fixing internationalisation bugs — kelemengabor Gábor Kelemen is an expert, when it comes to internationalisation or short i18n. Sometimes problems in the code prevent the software to be translatable. He Gábor will go through a list of common mistakes and show you how to fix them.
21:00 UTC: How to fix small bugs in Ubuntu — warp10 Andrea Colangelo and his friends from the Italian Ubuntu developer team will be here to pick a few examples of fixed bugs and give you the blow-by-blow analysis about how it was done. Join in to start your bug fixing story today.
21:30 UTC: Problem Lifecycle in Ubuntu — cprofitt We have to face the reality. Software comes with problems, call them bugs or defects, they are still there. Charles Profitt will be here to explain the common lifecycle of a bug report in Ubuntu and how they are dealt with.
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 …
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
In this blog post the Launchpad team uses juju to deploy oops-tool, a Django-based tool that aggregates bug reports for the Launchpad project.
We typically talk about services that people commonly deploy, such as Mediawiki or WordPress. However there is another use case for juju that is just as powerful, as a tool to help iterate on whatever you’re working on faster. oops-tool is not a general tool that most people will want to use; it’s very specialized.
However the Launchpad team have encapsulated their service in a charm. Any person can now deploy oops-tool in 4 commands. Now have a think about a project you and your team might be working on and the complexities of that service and how wonderful it would be if any person on any team could deploy any service in your project’s code base with that kind of ease. You’re codifying the management of your service so that as you work on a feature branch you can deploy, test, and then iterate.
juju strives to deploy your service in the same way that people strive to have their software build in one set of processes, but it’s more than just that. Deploy-and-forget is nice, but being able to manage a service over its lifetime is what people need in the cloud and you can do that with a juju charm.
Launchpad has a myriad of services it provides, we’ll keep you in touch on how that team is using juju to simplify their processes. Got more questions about juju and how we can help you manage in the cloud? Feel free to Contact Us and ask questions!
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):
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.
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.
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:
Recently the Launchpad Red Squad and Product Team started working on a new cloud project. As part of that project we’ll be using Juju, a tool that helps you easily deploy services on the cloud.
As an opportunity to learn more about how Juju works, I wrote a charm to deploy oops-tools, an open source Django application that helps visualize and aggregate error reports from Launchpad, on Amazon’s EC2 and Canonical’s private Openstack cloud.
You might be asking, what’s a charm? Charms are basically instructions on how to deploy services, that can be shared and re-used.
Assuming you already have a bootstrapped juju environment, deploying oops-tools using this charm is as easy as:
$ juju deploy --repository=. local:oops-tools
$ juju deploy --repository=. local:postgresql
$ juju add-relation postgresql:db oops-tools
$ juju expose oops-tools
That’s it! With just a few commands, I have an instance of oops-tools up and running in a few minutes.
Under the hood, the oops-tools charm:
starts two Ubuntu instances in the chosen cloud provider, one for the webserver and another for the database server
downloads the latest trunk version of oops-tools and its dependencies from Launchpad
configures oops-tools to run under Apache’s mod_wsgi
configures oops-tools to use the database server
There’s still work to do, like add support for RabbitMQ (oops-tools uses rabbit to provide real-time error reports), but this initial iteration proved useful to learn about Juju and how to write a charm. As it is, it can be used by developers who want to hack on oops-tools and can be easily changed to deploy oops-tools in a production environment.