fidzu : Ubuntu

We've just upgraded Launchpad's builder machines to Bazaar 2.4. Most importantly, this means that recipe builds of very large trees like will work reliably, such as the daily builds of the Linaro ARM-optimized gcc. (This was bug 746822 in Launchpad).

We are going to do some further rollouts over the next week to improve supportability of recipe builds, support building non-native packages, handle muiltiarch package dependencies, improve the buildd deployment story etc.

10 Nov 2011 4:04am GMT

Laura Cowen, Mark Johnson, Alan Pope, and Tony Whitmore are in Studio A for episode 19 of season 4 of the Ubuntu Podcast from the UK LoCo Team!

In this week's show:-

• We chat about someone's new job at Canonical, going to a murder mystery party in costume, upgrading RAM in laptops and getting a new Android phone, and playing with Ruby and xvfb. Can you guess who's who?
• We also interview James Smith from AMEE who we met at Homecamp 4 and we have the second installment of the second wave of The UUPC Quiz - this time brought to you by Mark.
• In the news:-
  • Apple release ALAC under Apache…
  • HP announce ARM servers…
  • Canonical and RedHat partner up again…
  • Cabinet Office talks a lot of sense about Open Source…
  • Microsoft contributes to Samba project…?!?
• Events:-
  • BitCoin conference, Prague, 25-27 Nov
  • Indiana LinuxFest April 13-15, 2012 2012. Indiana
  • Yes, you guessed it (again), FOSDEM will happen in Brussels on 4th - 5th February 2012.
• We have a Bit About Ubuntu, in which we discuss Alan's week at UDS. You can listen to recordings of sessions and even watch videos of some sessions.
• We have a command line lurrrrrrrrve from Russel Dickenson who found it on StackOverflow in his hour of need:
  

  ffmpeg -i input_video -vf "transpose=1″ -r 30 -sameq output_video

  It's useful if you have recorded some video in portrait mode and you want to play it in landscape mode.

• We have your feedback, including a frankly bizarre contribution from the Wing Commander.

Comments and suggestions are welcomed to: podcast@ubuntu-uk.org
Leave us some segment ideas on the Etherpad
Join us on IRC in #ubuntu-uk-podcast on Freenode
Leave a voicemail via phone: +44 (0) 203 298 1600, sip: podcast@sip.ubuntu-uk.org and skype: ubuntuukpodcast
Follow our twitter feed http://twitter.com/uupc
Follow us on Identi.ca http://identi.ca/uupc
Find our Facebook Fan Page
Discuss this episode in the Forums

Laura Cowen, Mark Johnson, Alan Pope, and Tony Whitmore are in Studio A for episode 19 of season 4 of the Ubuntu Podcast from the UK LoCo Team! In this week's show:- We chat about someone's new job at Canonical, going to a murder mystery party in costume, upgrading RAM in laptops and getting a new Android phone, and playing with Ruby and xvfb. Can you guess who's who? We also interview James Smith from AMEE who we met at Homecamp 4 and we have the second installment of the second wave of The UUPC Quiz - this time brought to you by Mark. In the news:- Apple release ALAC under Apache… HP announce ARM servers… Canonical and RedHat partner up again… Cabinet Office talks a lot of sense about Open Source… Microsoft contributes to Samba project…?!? Events:- BitCoin conference, Prague, 25-27 Nov Indiana LinuxFest April 13-15, 2012 2012. Indiana Yes, you guessed it (again), FOSDEM will happen in Brussels on 4th - 5th February 2012. We have a Bit About Ubuntu, in which we discuss Alan's week at UDS. You can listen to recordings of sessions and even watch videos of some sessions. We have a command line lurrrrrrrrve from Russel Dickenson who found it on StackOverflow in his hour of need: ffmpeg -i input_video -vf "transpose=1″ -r 30 -sameq output_video It's useful if you have recorded some video in portrait mode and you want to play it in landscape mode. We have your feedback, including a frankly bizarre contribution from the Wing Commander. Comments and suggestions are welcomed to: podcast@ubuntu-uk.org Leave us some segment ideas on the Etherpad Join us on IRC in #ubuntu-uk-podcast on Freenode Leave a voicemail via phone: +44 (0) 203 298 1600, sip: podcast@sip.ubuntu-uk.org and skype: ubuntuukpodcast Follow our twitter feed http://twitter.com/uupc Follow us on Identi.ca http://identi.ca/uupc Find our Facebook Fan Page Discuss this episode in the Forums

09 Nov 2011 9:41pm GMT

I decided to make a website/blog for relinux, because this blog is more about Ubuntu-related news, and not about relinux.

Here is the website address: http://relinuxkit.wordpress.com/. It's just a simple wordpress design, but it will be good enough for relinux.

I've been writing the relinux.h header file for a bit, and it's coming pretty nicely. Also, there will be a new logo for relinux available shortly!

09 Nov 2011 9:28pm GMT

Ahmed Shams and others have put together a fantastic idea! Ubuntu Community Appreciation Day. Ubuntu is not only an operating system, but also a community full of awesome people, who want to make the world a better place.

Sometimes a little thanks is all it takes to make somebody's day, to bring us closer together and show that you care. It's important for us to remember that Ubuntu is put together by people. People who care a lot and put hours and hours of work into this.

From this year on, we want to celebrate and appreciate everybody's hard work on 20th November. What you can do? It's simple: just go and thank somebody. Whichever medium choose to do that, just do it! (The UCADay wiki page lists more ideas how to do it.)

Thanks a bunch for putting this great idea together and thanks to everybody for their support! BIG HUGS!

09 Nov 2011 10:59am GMT

I mentioned at the closing session of UDS last week, that it was remarkable UDS due to the amount of time spent discussing how we build Ubuntu, not just what we will build. As a community, we have blazed many new trails in software development and delivery, and I feel strongly that we are standing at a nexus where we will be able to collect the wisdom of the past seven years of developing an Open Source Community Distro and apply that wisdom in the future in a way that introduces a step function in our adoption curve as we pursue our goal of a mainstream free desktop.

Most of these "how should we build it" discussions circled around building and maintaining development velocity in 12.04 so that we could add new features that users need while maintaining and delivering the quality they also need. Fortunately, we laid some ground work in the 11.10 cycle. Pete Graner led the QA team in 11.10. Along with some new QA staff, they instituted some important practices, like automatically testing the daily ISO each day, and they set up a QA lab for running tests automatically, along with reporting of those test results.

Acceptance Criteria
How we assess and accept code from upsreams within Canonical was an area ripe for discussion. We arrived at UDS with a strong view about how we should be doing this, and we had three discussions about it at UDS. Jason Warner this area of collective effort "Acceptance Criteria". Please note that for 12.04 and the foreseeable future, this applies ONLY to code developed by Canonical, or was call them "Canonical upstreams". There are two main goals of this effort:

• Ensure that landing code from Canonical upstreams does not introduce issues that make the development release too hard to use and develop on, thus slowing down velocity for everyone.
• Encourage Canonical upstreams to fix bugs throughout the cycle, and not to wait until after Feature Freeze to focus all efforts on bug fixing.

As a result, we should see faster development, and a higher quality final product.

Acceptance Criteria means that upstreams have some responsibilities, and Ubuntu has some responsibilities. For upstreams, it boils down to "treat your trunk as sacred". Practically, it requires:

• There is a trunk of code bound for Ubuntu.
• This trunk always builds automatically.
• This trunk has tests that are always passing automatically.
• All branches are properly reviewed for having both good tests and good implementation before merged into trunk.
• Any branch that breaks trunk by causing automated tests to fail or causes trunk to stop building, are immediately reverted.

For Ubuntu Engineering, the responsibilities include:

• Every maintainer in Ubuntu must have a test plan for upstream trunks that are run before uploading to the development release.
• Tests in the test plan that are automated can be run with the help of the QA team.
• Tests in the test plan that are manual can be run with the help of the community team, (and the community QA Lead that is to be hired)
• Refrain from uploading a trunk into Ubuntu if there are serious bugs found in testing that will slow down people using the development release for testing and development.
• Revert uploads that break Ubuntu, as there is no point in having the latest of a trunk in Ubuntu if it's broken and just slowing everyone down.
• Add tests to upstream projects for the Ubuntu test plan if serious bugs do get through that cause a revert.

ISO integration testing
Every day the QA team automatically runs tests on the ISO produced that day, if any. This was set up in 11.10. For 12.04, we will expand on this effort substantially. First, by growing the body of tests run. Secondly, by automatically reporting on the quality of the ISO each day. Finally, by responding to the results of the tests immediately, see the next section.

Daily Quality
We will strive to ensure that we have a new daily ISO each day. If the QA team finds an ISO to be "untestable" or failing critical tests that will hamper development velocity that day, we will respond by trying to fix the issues. For issues that cannot be foreseeably fixed within 3 hours, we will typically back out those changes. After the issue is addressed by being fixed or backed out, we *will spin another ISO*. We will collect metrics on what percentage of days we have a working and testable ISO.

Pre-archive Testing
Of course, catching problems in ISO testing and fixing them everyday is nice, but stopping the problems from reaching Ubuntu in the first place is even better. With that end in mind, Evan Dandrea ran a very interesting session about testing library and other changes before uploading them to the archive for the development release.

This will start out simple. The QA team will be able to install the latest ISO in their test environment, then pull an updated package from a PPA. A tool that I lovingly named "tool 2" will be created that will use rdepends to find packages that both depend on the newly upagraded package and also have tests worth running. Tool 2 will then run those tests and report the results. In this way, issues with libraries and other transitions can be fixed before they get into the development release and slow everyone down.

The next step, which I sincerely hope we get to during 12.04 development is to make tool 1. Tool 1 takes the output of tool 2, and judges if it should copy the newly updated package, or some set of packages, into the release archive. If we get tool 2 set up, then uploads to the development release would first go into the proposed archive for the development release, tested there, and only added to the release archive when found to be "ok" by the tests.

+1 Maintenance Team
Colin Watson is leading an experiment for 12.04 development. He will be leading a small staff of rotating engineers who are focused soley on the stability of the development release. We plan to learn from this effort, and see if we should repeat it, tweak it, or drop it for future versions. In any case, these efforts are meant to enhance, not replace, the generally diffused responsibilities for quality of the ISO and the archive. Colin led a good UDS session on the topic. The priorities defined there being:

1. Deal with ISO smoke test issues, includes install images being buildable
2. Upgrades through development releases work day to day, look at conflict checker
3. All packages in main are installable
4. All packages in main are buildable
5. Component-mismatches / MIRs / etc.
6. Finishing library/NBS transitions through archive (beyond main)
7. All packages in the archive are buildable

Summary
All in all, these are a lot of structural changes to how we approach building Ubuntu and ensuring the quality of it. Here is a table to highlight some of the key changes.

09 Nov 2011 8:17am GMT

I've been following the discussion around the potential switch from Banshee back to Rhythmbox for Precise, and I really don't have all that much to add. Though I did come across an interesting post from an upstream Tomboy developer that deserves some wider attention. He argues that "upstreams would be more than happy to do a lot of stuff for Ubuntu if only Ubuntu actually let them know what they wanted in some sort of predictable fashion."

Ubuntu either doesn't know how important they've become, or they don't care. Developers in upstream apps know that getting exposure in Ubuntu means an incredible influx of new users, which in turn leads to new bug reporters, which finally means new contributors. It's well known that each of these groups is an order of magnitude smaller than the last, so making sure the user group is as big as possible is vital for an application. And because upstream knows this, they are willing to bend over backwards to accommodate Ubuntu's wishes.

He also tells a story about Tomboy nearly being dropped last cycle due to depending on a number of libraries that the desktop team wanted to drop form the CD images. He goes on to suggest that formalizing the procedure around these sorts of things would reduce a lot of confusion and let upstreams know where they stand.

This seems entirely reasonable to me. The Banshee issue aside, it would be great if there was a formal announcement at some set point in the cycle where the targeted development goals for the platform are laid out in one place. If you follow closely this information is already announced, but it is in a trickle of different messages to the devel and desktop lists. The idea would be to compile this information into one clear widely-publicized announcement. It would be early enough in the cycle that upstreams, derivatives, and other stake holders would have time to react. It would also make clear that any discussion before that point is just that, discussion not decisions. The existing Feature Definition Freeze would probably make for a nice fit.

09 Nov 2011 6:33am GMT

Just caught this artwork on deviantArt:

Interesting, isn't it.

09 Nov 2011 3:52am GMT

Some weeks ago Lydia blogged about a German bank giving away 1000 euros for each 1000 associations who can get the most votes. Well, until four days ago we were at postion 320, now we are at 735 and falling. Please, read Lydia's post about how to vote and help KDE e.V., it is just a few clicks.I'll include the directions here for speed. Remember, you'll be sent an email with a link, which you must click, and click a button on that page too. AND you can do this three times! I've done my three votes, have you?

A German bank is giving away 1000 Euro each to the 1000 associations who can get the most votes. Everyone has 3 votes. Please do vote with all 3 for KDE. With just a few clicks you can make a difference!
Here's what you have to do:
1) go to https://verein.ing-diba.de/sonstiges/10115/kde-ev and click "Stimme abgeben"
2) enter your email and the captcha it asks for and then click"absenden"
3) you'll get an email to confirm your vote - click the link in the email
4) you'll get to a website - click "Stimme abgeben"

You can do this 3 times in a row. If KDE is among the top 1000 associations we'll get 1000 Euro.

09 Nov 2011 3:23am GMT

Yesterday I received notice from NYSCATE that the hands-on lab I was giving on November 19th had been canceled due to low enrollment.

This message is regarding your "Introduction to Open Source Applications" session. Up to this point, we were holding on to your session in hopes that enrollment would trip to our cutoff of 3 participants, however, we will need to cancel the session due to low enrollment.

Yes, you read that correctly. There were not three educators interested in learning about Open Source Applications this year. With the same description last year I ended up with eight educators in my class. I am disappointed and now must think about how to raise interest for the session next year. When I look at the courses that survived they are either iDevice oriented or focused on an 'outcome'. I obviously will not have the fortune of teaching about things that match the popularity of an Apple advertised computing device so I think next year I must find a desired outcome and align it with FOSS applications and tools.

The conference is very supportive of Open Source tools such as Moodle so I know there is no issue there. I need to find and tell a story relevant to education that involves Ubuntu and Open Source Applications. Sadly that will have to wait until next year.

09 Nov 2011 3:01am GMT

On Saturday November 12th at 16:00 UTC the Ubuntu Women Project is hosting their second session in their Career Days initiative with a session titled "From Developer to CEO, a Career in Tech" featuring Canonical CEO Jane Silber.

Career Days is the brain child of Cheri Francis who was inspired by her own experiences in tech and studies which continue to show that women lack female role models and exposure to tech career opportunities.

So join us on Saturday, November 12th at 16:00 UTC in #ubuntu-classroom on irc.freenode.net (#ubuntu-classroom-chat for questions).

We will not be accepting questions specifically about Ubuntu, Canonical or other companies she has worked for, this session is strictly about her path and experiences in the tech industry.

These sessions are open to the whole community, you don't need to be a woman to attend or participate.

09 Nov 2011 12:43am GMT

Jono Bacon, with all respect, you are not always so awesome. I wholeheartedly agree with much of what Lionel, the lead developer of Xubuntu, said in his blog when he wrote about doing community survey reports the wrong way.

Any survey report that doesn't do any analysis with the content in any way is useless. Especially if you have large amount of data gathered from very different groups of people, you should do some correlation between different questions, to actually spot possible problems in the community. For example, I'd really like to see some correlations and differences in the answers by Canonical employees and volunteers.

A word of few about collaboration

The survey shows that there is various problems with collaboration between the Canonical teams and the community. While this might not be objectively the biggest problem, it is a multi-layered one, with hard-to-find solutions. Especially if there is no change from the Canonical side of things.

There's a few specific reasons why I think Canonical employees working on Ubuntu should collaborate more with the community.

While 1+1 is not three when you collaborate with other people, it usually does reduce the workload for everybody, since you wouldn't need to do duplicate work and you would be able to brainstorm with other people to get better results with the first try.

Volunteers in derivatives would have much more information on what is going on, and it would be much easier to get things working again, when you could collaborate with the person who (accidentally) broke something you need. Currently it is nearly impossible to get any non-volunteer to help with broken things in Xubuntu, even if the reason for being broke was a direct outcome of any change in Ubuntu, or the core packages.

With derivative developers not having to use most of their time fixing bugs others made appear, they will have more time in getting the derivatives more user-friendly, stable and even more feature-rich. The more interesting and well-working a product is the more people want to use it. This applies to Ubuntu and it's derivatives too, so this would certainly attract more users to Ubuntu, too.

First step forward, but are we going the right way?

I heard there is a new "If you break it, you fix it" -policy coming up. I really hope this works as expected and applies to new versions of packages breaking other packages too. My main concern is that this will not apply to Canonical employees or other core developers, permanently or via exceptions.

Only future will tell.

08 Nov 2011 10:44pm GMT

Jane Silber will be presenting a session titled "From Developer to CEO, a Career in Tech" on November 12 at 16:00 UTC in #ubuntu-classroom and #ubuntu-classroom-chat on freenode.

We are very excited to hear about Jane's journey through the IT world, and as always are grateful for our presenters' participation in this project.

If you're interested in getting involved, please see the Ubuntu Women Career Days wiki page or email Elizabeth Krumbach (lyz@ubuntu.com) or myself (cheri703@ubuntu.com).

These sessions are open to the whole community, you don't need to be a woman to attend or participate.

08 Nov 2011 6:50pm GMT

I will be for the next few weeks writting articles showcasing and recognizing the people who I work with in the community. In these articles I will ask them a few questions as well as tell you just how I was impressed with their work on Ubuntu. I feel that I can accomplish two things with this set of blogs I will be posting. I can help people get the recognition they deserve, and also, bring to light some of the lesser known members of our community. These are going to be the ones who I feel work just as hard but are not in the spotlight as often as other, more prominent members. Though some people I will attempt to interview will be widely known to some, they still may need to be interviewed so everyone knows who they are. I hope to start putting these blogs out sometime in the next couple weeks, hope you all can read them!

08 Nov 2011 5:53pm GMT

A few days late, sure...

Once again, I pity the fool who looks at my notes expecting them to be coherent. They make sense to me, and that's why I took the notes. Here's the highlights:

Andrew Wooldridge - YUI Hidden Gems

I didn't expect to take many notes here, since I'd taken my fair share of dives into the YUI source code (I generally no longer care to read the online docs), but Andrew pointed out a few things I had glanced over and missed the value of. Among them, he mentioned:

• Y.Frame - this is a wrapper for using the IFRAME element. It creates a YUI instance inside the IFRAME, so there's sandboxing, etc. but without the complications that come from IFRAME communication. There are quite a few places that we could use this in Ubuntu One. In particular, I think we could use it for the multi-file upload that we've been wanting to do for a long time.

• Y.DOM.inViewPortRegion - The previous day, I went looking into the ImageLoader source to see how it worked, since the NFL talk mentioned a WidgetFold that only rendered the widget when it came into the viewport, and I was curious how it did it. Even though I had found this hidden gem the day before, it's worth noting its value in all sorts of cases. What I'd like to do is make a synthetic event for Node such that we can hook eventHandlers into "enterViewPortRegion" and "exitViewPortRegion" or something similar.

• Y.on('hover') - How did I miss this? It's a synthetic event that YUI provides, since mouseOver and mouseOut can be a bit of a fun house of edge cases. Quite useful.

• Y.on('clickoutside') - I use this in my little phazr library to close on Overlay or Dialog. It's fantastic.

• Y.Later - A wrapper for setTimeout and setInterval. I made specific notes to play with this in some of the U1 things that I'm working on right now.

Eric ForRealYo - The App Framework

This talk Melted. My. Brain. A common theme that I heard repeatedly was that people tend to implement things in YUI, and right when they're finished, the YUI team announces the exact same thing in YUI. I did this recently with the App Framework.

The App Framework in YUI 3.4 leaves just a bit to be desired, but Eric's talk made it clear in his talk that all those desires will be available in YUI 3.5 (with a promised pr release in December). Eric had mentioned earlier in the week that he kind of looked at the iOS UI framework API when designing the App Framework, and I can see that connection. It's got a pretty good disconnect between data and presentation, which can often be kind of painful if you don't give it some thought. A nice API like the one the YUI team has designed makes it easy to design things correctly without putting too much thought into it.

One of the things I'm looking forward to the most in YUI 3.5 is the addition of support for Handlebars templating. This templating will be directly connected into Y.View, but won't be compulsory, so you can use any template system you'd like, and aren't forced in to Handlerbars.

As it stands now, YUI 3.4 has some of the App Framework stuff, and in particular, it has Model and ModelList, which have events that can be hooked into. To me, that's the best way to start using the App framework. Create widgets that handle events in your Model and ModelList instances. At the very least, that means that I have a clear upgrade path from my app framework to YUI's (so I don't have to maintain code, I can just file a bug and complain... :)

After all of this, it became clear that I've been neglecting the YUI Gallery, both in contributing to it and using it. I need to remedy that.

08 Nov 2011 5:48pm GMT

Launchpad will soon permit you to say your project is not affected by a bug shared with another project - you can delete the spurious bug task. This action can be done from the bug's web page, and using Launchpad API.

You can remove a project from a bug if you are the project maintainer, bug supervisor, or are the person who added the project to the bug. This action can only be performed when the bug affects more than one project - you cannot delete an entire bug. This feature permits you to undo mistakes.

Launchpad beta testers will see the remove action next to the affected project name in the affects table.

The delete() method was added to the bug_task entry in the Launchpad API. There is a example API script, delete_bugtasks.py, that can remove a project from many bugs. There is also a split action to create a separate bug just for the specified project to track separate conversations in bug comments.

Usage: delete_bugtasks.py [options] bug_id:project_name [bug_id:project_name]

Options:
  -h, --help            show this help message and exit
  -v, --verbose
  -q, --quiet
  -f, --force           Delete or split bug tasks that belong to a public bug
  -d, --delete          Delete a spurious project bug task from a bug
  -s, --split           Split a project bug task from an existing bug so that
                        the issue can be tracked separately
  -w WEBSITE, --website=WEBSITE
                        The URI of Launchpad web site.
                        Default: https://api.launchpad.net;
                        Alternates: https://api.staging.launchpad.net,

https://api.qastating.launchpad.net

Previously, you could not remove spurious bug reports about your project. Many were cause by poor bug target management; you could not move a bug between projects and distributions. You can now move bugs between projects and distributions, but thousands of bugs still wrongly claim to affect a project or distribution. This causes clutter on bug pages and searches, and it causes Launchpad performance problems.

This change is a part of a super-feature called Disclosure. To ensure that confidential data is not accidentally disclosed, Launchpad will only permit private bugs to affect a single project. Soon, you may need to remove a project from a bug before marking the bug private.

08 Nov 2011 5:20pm GMT

Launchpad will be entirely offline and Ubuntu's single sign-on service will be read-only for around 15 minutes from 08.30 UTC on the 10th November.

Goes offline: 08.30 UTC 2011-11-10
Expected back: 08.45 UTC 2011-11-10

This is to allow us to make a database upgrade. We're sorry for the disruption that this will cause.

08 Nov 2011 5:16pm GMT