Friendly reminder….

Our LoCo Team Reboot IRC meeting will take place this Wednesday (06 Feb 13) at 20:30 local time. I sincerely hope we will have a good active discussion about how we can keep our LoCo active into the future. All ideas and suggestions are welcome. If you are interested in Ubuntu and the Ubuntu Ireland LoCo Team I encourage you to participate in this meeting.

You can contribute as much or as little as you like but please do get involved. I’d also ask you all to spread the news of this reboot meeting as widely as possible in all social media streams. If you know someone who might be interested but who is not subscribed to this mailing list please tell them about the meeting.

Details of the meeting can be found at:

http://loco.ubuntu.com/meetings/ubuntu-ie/532/detail/

Anyone can add an agenda item. If you’d like to add an agenda item just log on to the LoCo Team Portal yourself or reply to this mail and I will add it for you.

For some time I have been concerned about the loading times of my blog. I have spent a fair bit of time debugging and trying to speed it up a little. I think I have now got it loading fairly quickly (a lot better than I had it before – sometimes upto 15 seconds to load a page!).

To aid increasing the loading speed I have:

• Optimised the main header image to be web-friendly (no longer a png, thus reducing file size)

• Turned Off / Deleted excess plugins that are no longer needed

• Switched to less resource hogging plugins where I can

• Removed duplicate image link content

• Reverted to a minimalistic style

I think now I’ll monitor how it goes, I may end up switching host to get better performance (currently my hosting is FREE, so I cannot complain that much really)

Those who know me will not be surprised to learn that I have stayed up until 1:45 AM reading Cory Doctorow's new book, Homeland.

video platform video management video solutionsvideo player

See the video here

The Community Leadership Summit 2013 brings together community leaders, organizers and managers and the projects and organizations that are interested in growing and empowering a strong community. The event pulls together the leading minds in community management, relations and online collaboration to discuss, debate and continue to refine the art of building an effective and capable community.

This year the event takes place on 20th – 21st July 2013 (the weekend before OSCON) in Portland, Oregon and is the fifth anniversary of the event and I am determined to make it bigger, better, and more valuable than ever. Over the previous four events CLS has become the primary annual meeting place for community leadership, and every year we get an absolutely wonderful and diverse attendance spanning technology, education, government, science and more.

At the heart of Community Leadership Summit 2013 is an open unconference-style event in which everyone who attends is welcome to lead and contribute sessions on any topic that is relevant. These sessions are very much discussion sessions: the participants can interact directly, offer thoughts and experience, and share ideas and questions. These unconference sessions are also augmented with a series of presentations from leaders in the field, panel debates and networking opportunities.

Sponsorship

I am currently getting the wheels in motion for the sponsorship for CLS13 and I just wanted to invite any organizations reading this who might be interested in sponsoring the event. CLS is not a particularly expensive event to put on, but I want to expand the usual sponsorship this year to add a little more polish than usual to the event. As such, I am looking for companies or might be interested in supporting the event and getting exposure to community leaders across a range of industries, but with a strong focus on technology.

One of the messages I emphasize in my opening plenary is that the sponsors of the event don’t buy editorial direction or influence (as the event is very focused on being free, open, and attendee-content driven), and as such sponsorship of CLS is very much an affirmation of support of the event for the right reasons. As such, association with CLS as a sponsor has typically reflected very well on those companies who have sponsored in the past. Such companies have included Intel, Microsoft, Black Duck, Oracle, O’Reilly, OpenNMS, and others.

If you are interested in supporting CLS, please drop me an email to jono@jonobacon.org. Thanks!

We’re only 3 days left from the Ubuntu Loco Games =)!, are you already registered?, if not run to do it!, Inscriptions will close in February 8th

• http://pad.ubuntu.com/LocoGames

You don’t need to be the most wild warrior to enter (although that may help), any person can join us, look around for the loco team which you belong to and you’re done, you can have fun with us.

We’ll be playing 3 of the most successful games in the Ubuntu ecosystem: Urban Terror, Battle for Wesnoth and Assaultcube, and you can start practicing right away!

Hope to see you there, PD: Thanks to Joshman for the pretty banner design

tl;drAs of ssh-import-id 3.0, you can now import SSH public keys from both Launchpad and Github using lp:$USER and gh:$USER like this:

$ ssh-import-id lp:kirkland gh:cmars
2013-02-05 17:54:15,638 INFO Authorized key ['4096', 'd3:dd:e4:72:25:18:f3:ea:93:10:1a:5b:9f:bc:ef:5e', 'kirkland@x220', '(RSA)']
2013-02-05 17:54:15,647 INFO Authorized key ['2048', '69:57:f9:b6:11:73:48:ae:11:10:b5:18:26:7c:15:9d', 'kirkland@mac', '(RSA)']
2013-02-05 17:54:22,125 INFO Authorized key ['2048', '84:df:01:9f:da:d3:ef:7d:a0:44:17:ff:ab:30:15:22', 'cmars@github/2114943', '(RSA)']
2013-02-05 17:54:22,134 INFO Authorized key ['2048', 'ab:6a:0c:99:09:49:0b:8f:2a:12:e2:f3:3d:c7:a9:79', 'cmars@github/3263683', '(RSA)']
2013-02-05 17:54:22,135 INFO Authorized [4] new SSH keysThis is now available in Ubuntu Raring 13.04, backported to all other supported Ubuntu releases in this PPA, in the upstream source tarballs, and now installable through pip from pypi!
BackgroundIt's been almost 3 years now since I introduced ssh-import-id here on this blog.  I have a Google Alert setup to watch ssh-import-id and I'm delighted to see that it seems to be quite popular and heavily used!

As a brief reintroduction, ssh-import-id is similar to the ssh-copy-id command.  Whereas ssh-copy-id pushes your public key into a remote ~/.ssh/authorized_keys file, ssh-import-id pulls a public key into the local ~/.ssh/authorized_keys.  Especially in cloud instances, it's a great way to securely, easily, and conveniently retrieve and install your own SSH public key, or perhaps that of a friend or colleague.

When I initially wrote it, it was really just a simple shell script wrapper around wget, with some error checking, that would pull public keys over an SSL connection from Launchpad.net.  All of my network friends and colleagues had active, authenticated accounts at Launchpad.net, and everyone had to upload their public GPG keys and public SSH keys to Launchpad in order to get any work done.  This was really easy, since all keys are available as flat text at a very predictable URL pattern: https://launchpad.net/~%s/+sshkeys.

I have always wanted ssh-import-id to be able to pull keys from servers other than Launchpad.  The tool has long supported defining a $URL in your environment or in /etc/ssh/ssh_import_id at the system level.  There just aren't really any other good, authenticated SSH public key servers.
GithubA few days ago, my friend and Gazzang colleague Casey Marshall noticed that Github had actually recently added support to their API which exposes public SSH keys!  This was just awesome :-)  It would take a bit of effort to support, though, as the output format differs between Launchpad (raw text) and Github (JSON).

So this past Saturday on a beautiful evening in Austin, TX (when neither of us should really have been hacking), we both independently initiated our own implementation adding support for Github keys in ssh-import-id :-)  A bit of duplicated effort?  Yeah, oh well...  But we both took a similar approach: let's port this puppy from shell to Python so that we can take advantage of JSON parsing (our alternative was awk!).
PythonMy approach was pretty elementary...  I basically implemented a line-by-line, function-by-function port from Shell to Python, since I knew, from a regression standpoint, this would be stable, solid code.  But Casey is undoubtedly the better programmer between the two of us :-)  He took a much more Pythonic approach, implementing each of the protocol handlers as sub commands.

Once we caught up with one another online around midnight Saturday night, we realized that we really duplicating efforts.  So we decided to team up on the problem!  Casey had a much more elegant design, complete with a setup.py and uploadable to pypi.python.org.  Meanwhile, I have maintained the source code and the package in Ubuntu for nearly 3 years and I understood the complex set of legacy compatibility I needed to preserve, as well as several years worth of gotchas and bugs-fixed.  So I took Casey's implementation, whole hog, and went to work on a bunch of little things to get it whipped into shape for upload to Ubuntu.
PortabilityGiven that Github is now supported in addition to Launchpad, there may actually be some interest in the tool beyond Ubuntu.  Non-Ubuntu users can now install ssh-import-id directly from pypi.python.org!

$ sudo pip install ssh-import-id
Downloading/unpacking ssh-import-id
Running setup.py egg_info for package ssh-import-id

Requirement already satisfied (use --upgrade to upgrade): argparse in /usr/lib/python2.7 (from ssh-import-id)
Downloading/unpacking Requests >=1.1.0 (from ssh-import-id)
Running setup.py egg_info for package Requests

Installing collected packages: ssh-import-id, Requests
Running setup.py install for ssh-import-id

changing mode of /usr/local/bin/ssh-import-id-lp to 775
changing mode of /usr/local/bin/ssh-import-id to 775
changing mode of /usr/local/bin/ssh-import-id-gh to 775
Running setup.py install for Requests

Successfully installed ssh-import-id Requests
Cleaning up...

Please report bugs as you find them here!  And please use StackExchange for questions!  Enjoy ;-)

:-Dustin

NOTICE: To whom it may concern, the ubuntu quality team is seeking those with a desire to help ubuntu to contribute to the quality and testing efforts. With a little time and a willingness to learn, you too can unlock the tester within you!

Interested? Please inquire below!

If that text didn't get you, I hope the picture did. Seriously though, if you are here reading this page, I want to offer you an opportunity to help out. We as a team have expanded our activities and projects this cycle and we want to extend an offer for you to come along and learn with us. We're exploring automated testing with autopilot and autopkg, manual testing of images, and the virtues of testing in a regular cadence.

But we can't do it alone, nor do we wish to! We'd love to hear from you. Please have a look at our getting involved page (but do excuse the theme dust!) and get in touch. I offered a challenge to this community in the past, and I was blown away by the emails that flooded my inbox. Send me an email, tell me your interests, and ask me how you can help. Let me help get you started. Flood my inbox again1. Let's make ubuntu better, together!

1. If anyone is counting, I believe the record is ~100 emails in one 24 hour period :-p

So, when I’m not busy working on Ubuntu, or on LXC, or on Edubuntu, or … I also spend some of my spare time preparing the upcoming NorthSec 2013 security contest which will be held from Friday the 5th of April to Sunday the 7th of April at ETS in downtown Montreal.

NorthSec can be seen as the successor of HackUS 2010 and HackUS 2011 which both were held where I currently live, in Sherbrooke, QC. This year, we’re moving to Montreal, in the hope of attracting more people, especially from other Canadian provinces and from abroad.

I’m personally mostly involved with the internal infrastructure side of things, building the Ubuntu based infrastructure required to simulate the hundreds of servers and services used for the contest. All of that while making sure everything is rock solid and copes extremely well under pressure (considering what our contestants tend to throw at us).

I also usually get involved with some of the tracks, mostly the networking one, trying to think of really twisted setups ranging from taking over an active IPv6 network to hijacking IPs by messing with a badly configured BGP router (taken from past editions).

Outside of our twisted network challenges, we have quite a few more things to offer, here’s the current list of tracks for this year:

• Trivias (they seem easy but people are known to have wasted hours on them)
• Web (sql injection, xss anyone?)
• Binaries (because we know you love those)
• Networking (my track of choice)
• Reverse Java

And if anyone manages to finish everything, don’t worry, we’ll come up with more.
As far as I know, we never had a single team get bored in the past two editions

So if you’re interested in computer security, want to try to prove how good you are at finding security flaws and exploiting them or just want to see what that thing is all about, well you should consider a trip to Montreal in early April.
All the details you need are at: http://www.nsec.io/en

If you are a company interested in helping us with sponsorship, I hear that we’re always looking for more sponsors. So if that’s something you can help with, feel free to contact me directly at: stgraber at nsec dot io

Today I got email that ‘xf86-video-armsoc’ landed in Ubuntu 13.04 ‘raring’. I also sent ‘linux-chromebook’ into archive.

Next step would be ‘vboot-utils’ which are now in NEW queue in Debian. Once it lands I will sync it into Ubuntu so we can sign kernels. What else needs to go into archive? Maybe OpenGLES driver. I have 0.45 packaged but need to fix showing the license.

What with support of older Ubuntu releases? I do not care about them and have a feeling that those who run them on their Chromebooks does not care as well (no one checked UCM profiles which were for verification).

So if you want to have good working Ubuntu on your Samsung ARM Chromebook then update to 13.04 or take care of backporting updates or ‘talk to the hand’.

All rights reserved © Marcin Juszkiewicz
Chromebook support lands in 13.04 was originally posted on Marcin Juszkiewicz website

Meeting Minutes

IRC Log of the meeting.

Meeting minutes.

Agenda

20130205 Meeting Agenda

ARM Status

R/master: work continues on the arm multiplatform kernel – right now i’m
tracking down a “BUG: scheduling while atomic” (actually an alignment problem -
how conform
http://paste.ubuntu.com/1613275/) that only happens on omap4, seems to be ipv6
related and seems to be triggered by our articulated kernel configuration.

Release Metrics and Incoming Bugs

Release metrics and incoming bug data can be reviewed at the following link:

• http://people.canonical.com/~kernel/reports/kt-meeting.txt

Milestone Targeted Work Items

We were able to clean up quite a few work items last week and are now
well below the trend line for our overall burn down chart. Thanks to
everyone who closed out items.

   apw    hardware-r-kernel-config-review    6 work items          hardware-r-delta-review    3 work items       ppisati    hardware-r-kernel-config-review    1 work item          hardware-r-kernel-version-and-flavors    2 work items          hardware-r-delta-review    1 work item       rtg    hardware-r-delta-review    1 work item       smb    hardware-r-kernel-misc    2 work items   

Status: Raring Development Kernel

We have rebased the Raring kernel to the latest v3.8-rc6 upstream
kernel and uploaded. We’ve also pulled our first set of patches for arm
multiplatform support \o/.
Also just a small reminder, the 12.04.2 point release is nearing. If
anyone has free cycles and is able to test, please do so.
Important upcoming dates:

• Raring:
  • Mon Feb 18 – 13.04 Month 4 Milestone (~2 weeks)
• Precise:
  • Thu Feb 14 – 12.04.2 Release (~1 week)

Status: CVE’s

Currently we have 32 CVEs on our radar, with 3 CVEs added and 4 CVE retired this week.
See the CVE matrix for the current list:

• http://people.canonical.com/~kernel/cve/pkg/ALL-linux.html

  Overall the backlog has decreased slightly this week:

• http://people.canonical.com/~kernel/status/cve-metrics.txt

• http://people.canonical.com/~kernel/cve/pkg/CVE-linux.txt

Status: Stable, Security, and Bugfix Kernel Updates – Quantal/Precise/Oneiric/Lucid/Hardy

Here is the status for the main kernels, until today (February 05):

• Hardy – Nothing in this cycle
• Lucid – Nothing in this cycle
• Oneiric – In Preparation; 3 CVEs; 4 upstream stable release(s); (154 commits)
• Precise – In Preparation; 0 CVEs; 2 upstream stable release(s); (222 commits)
• Quantal – In Preparation; 0 CVEs; 2 upstream stable release(s); (368 commits)
  Current opened tracking bugs details:

• http://people.canonical.com/~kernel/reports/kernel-sru-workflow.html

  For SRUs, SRU report is a good source of information:

• http://people.canonical.com/~kernel/reports/sru-report.html

  Future stable cadence cycles:

• https://wiki.ubuntu.com/RaringRingtail/ReleaseInterlock

Open Discussion or Questions? Raise your hand to be recognized

No open discussions.

I just found out about Ajenti, a system management Web UI (released as free open source software under the GPLv3 license), it may be useful to manage desktops and small server setups, as opposed to other projects like Zentyal which do a lot more.

I’ve asked if it’s compatible with Ubuntu 12.04 LTS (which would mean also compatible with Trisquel 6).

Why is this interesting? There are tons of web interfaces out there and vendors of NAS hardware all implement a variation of this. A few years ago when I came across the Franklin Street Statement on Freedom and Network Services I decided that if I was to advocate the use of autonomous, self-hostined/managed services, I should try to Eat my own dog food whenever I could. With this in mind, I kept my eyes open for projects that would not only publish their source code under free open source licenses but also would be easy to implement at home, with consumer hardware, in typical DIY manner – just a bit shy of the current cloud this and cloud that madness.

I’ve been using OpenMediaVault for a couple of small NAS projects, and I love it. It’s based off Debian so I am in familiar territory, I wish this was part of Debian already, I prefer adding such web UIs to existing vanilla installs instead of using a dedicated/modified/derived distribution. I also like its plugins, specially the OpenVPN one, which even generates archives with files and instructions when creating a new access. But aren’t plugins much like packages, optional funcitonality which you should be able to add/remove without bvreaking the system? The main difference is when you have pluggins in such a web UI, such plugins aren’t of Debian-package quality, and introduce yet another layer of software you need to keep an eye on for updates, upgrades, security, etc. Oh, and yet another bug tracker, forum, blog, etc. to follow if you are to get involved.

I’ve always wondered why web UIs like those on OpenWRT or DD-WRT / Tomato are not part of all GNU/Linux distributions, as a separate package. A lot of commercial providers come up with their own too, it all seems like a huge duplication of effort when someone comes up with yet-another-web-ui. Having a common project or interface guidelines would make it easier to use 100% free software on such devices, while having an easy-to-use web interface.

When I researched alternative firmware to use with my DNS-323 Dlink NAS device, I came across Alt-F, yet another one! This motivated me into researching how to install a full distribution on it – eventually Debian was it. It’s very interesting that one can install Debian on several NAS-like devices or specialized hardware, but then you loose the access to a nice (though always different) web interface provided by the vendor.

In many ways it seems sysadmin work and infrastructure management can be done with 100% free software, but what good is it when you have to depend on proprietary interfaces or middleware? I think projects like OpenMediaVault and Ajenti go in the right direction.

What are your favorite Web UI implementations of every-day infrastructure administration tasks?

This post is part of the Unity daily release process blog post suite.

After a week to let people ask questions about the daily release process, I guess it's time to catch up and conclude this serie with a FAQ and some thoughts for the future.

FAQ

The FAQ is divided in multiple sequences depending on your role in the development of ubuntu, with the hope that you will be able to find what you are looking for quicker this way. If you have any question that isn't addressed below, please ping didrocks on IRC freenode (#ubuntu-unity) and I'll complete this page.

Upstream developers What's needed to be done when proposing a branch or reviewing?

As discussed in this part, when proposing a branch or reviewing a peer's work, multiple rules have been established. The developers needs to:

• Design needs to acknowledge the change if there is any visual change involved
• Both the developer, reviewer and the integration team ensure that ubuntu processes are followed (UI Freeze/Feature Freeze for instance). If exceptions are required, they check before approving for merging that they are acknowledged by different parts. The integration team can help smooth to have this happened, but the requests should emerge from developers.
• Relevant bugs are attached to the merge proposal. This is useful for tracking what changed and for generating the changelog as we'll see in the next part
• Review of new/modified tests (for existence)
• They ensure that it builds and unit tests are passing automated
• Another important one, especially when you refactor, is to ensure that integration tests are still passing
• Review of the change itself by another peer contributor
• If the change seems important enough to have a bug report linked, ensure that the merge request is linked to a bug report (and you will get all the praise in debian/changelog as well!)
• If packaging changes are needed, ping the integration team so that they acknowledge them and ensure the packaging changes are part of the merge proposal.

When you approve a change, do not forget to check that there is a commit message in launchpad provided and to set the global status to "approved".

When do changes need to land in a coherent piece?

Some changes can happen and touch various components (even across different stacks). To avoid loosing a daily release because only half of transition landed in some upstream projects (and so, tests will fail because they catch this issues, isn't it? ;)), it's asked to ensure that all transitions are merged by 00 UTC. Then, you can start approving again transition starting from 06 UTC. We can try to make this window shorter in the future, but let's see first how this work in practice. For any big transition, please coordinate with the ubuntu-unity team team so that they can give a hand.

I have a change involving packaging modifications

As told in a previous section, just ask for the ubuntu-unity team to do some review or assisting in doing those changes.

I want to build the package locally myself

If you have done some packaging changes, or added a C symbol, you maybe want to ensure that it's building fine. Quite simple, just go into your branch directory and run $ bzr bd (from the bzr-builddeb package). This will build your package on your machine using the same flags and checks than on the builders. No need to autoreconf if you are using autotools, everything is handled for you. You will get warned as well if some installed files are missing.

I need to break an API/ABI

The first question is: "are you sure?". Remember that API changes are a PITA for all third parties, in particular if your API is public. Retro-compatibility is key. And yes, your dbus interface should be considered as part of your API!

If you still want to do that, ensure that you bump your soname if the ABI is broken, then, multiple packaging changes are needed. Consequently, ensure to ping your lovely ubuntu-unity team to request assistance. The transition should happen (if no retrocompatibility is provided) within the previously mentionned timeframe to have everything landing in coherence.

You also need to ensure that for all components build-depending on the API you changed, you bumped the associated build dependency version in debian/control.

To what version should I bump the build dependency version?

Let's say you added an API to package A. B is depending on A and you want to start using this new awesome API. What version should be used in debian/control to ensure I'm building against the new A?

This is quite easy, the build-dependencies in debian/control should look like: A >= 6.0daily13.03.01 (eventually ended by -0ubuntuX). Strip the end -0ubuntuX and append then bzr<rev_where_you_added_the_api_in_trunk>. For instance, let's imagine you added the API in rev 42 in trunk, so the build-dep will change from:

A >= 6.0daily13.03.01

to:

A >= 6.0daily13.03.01bzr42

This is to ensure the upstream merger will be able to take it.

If no "daily" string is provided in the dependency you add, please check with the ubuntu-unity team.

I'm exposing a new C symbols in my library, it seems that some packaging changes are needed…

Debian packages have a debian/<packagename>.symbols file which lists all exposed symbols from your library (we only do that for C libraries as C++ does mangle the name per architecture). When you try to build the package containing a new symbol, you will see something like:

--- debian/libdee-1.0-4.symbols (libdee-1.0-4_1.0.14-0ubuntu2_amd64)

+++ dpkg-gensymbolsvPEBau 2013-02-05 09:43:28.529715528 +0100

-4,6 +4,7

dee_analyzer_collate_cmp@Base 0.5.22-1ubuntu1

dee_analyzer_collate_cmp_func@Base 0.5.22-1ubuntu1

dee_analyzer_collate_key@Base 0.5.22-1ubuntu1

+ dee_analyzer_get_type@Base 1.0.14-0ubuntu2

dee_analyzer_new@Base 0.5.22-1ubuntu1

dee_analyzer_tokenize@Base 0.5.22-1ubuntu1

dee_client_get_type@Base 1.0.0

The diff shows that debian/libdee-1.0-4.symbols doesn't list the exposed dee_analyzer_get_type new symbol. You see a version number next to it, corresponding to the current package version. The issue is that you don't know what will be the package version in the future when the next daily release will happen (even if you can infer), what to put then?

The answer is easier than you might think. As explained in the corresponding section, the daily release bot will know what version is needed, so you just need to give a hint that the new symbol is there for the upstream merger to pass.

For than, just include the symbol, with 0replaceme[1] as the version for the branch you will propose as a merge request. You will thus set in your symbols file:

dee_analyzer_collate_cmp@Base 0.5.22-1ubuntu1

dee_analyzer_collate_cmp_func@Base 0.5.22-1ubuntu1

dee_analyzer_collate_key@Base 0.5.22-1ubuntu1

dee_analyzer_get_type@Base 0replaceme

dee_analyzer_new@Base 0.5.22-1ubuntu1

dee_analyzer_tokenize@Base 0.5.22-1ubuntu1

dee_client_get_type@Base 1.0.0

The dee_analyzer_get_type@Base 0replaceme line will be replace with the exact version we release in the next daily release.

My name deserves to be in the changelog!

I'm sure you want the world to know what great modifications you have introduced. To get this praise (and blame ;)), we strongly advise you to link your change to a bug. This can be done in multiple ways, like link bugs to a merge proposal before it's approved (you link a branch to the bug report in launchpad), or use "bzr commit --fixes lp:XXXX" so that automatically links it for you when proposing the merge for reviewing, or put in a commit message something like "this fixes bug…". This will avoid the changelog to have only empty content.

I invite you to read "Why not including all commits in debian/changelog?" from this section to understand why we don't include everything, but only bug reports title in the changelog.

Ubuntu Maintainers I want to upload a change to a package under daily release process

Multiple possibilities there.

The change itself can wait next daily release

If it's an upstream change, we strongly advise you to follow the same procedure and rules than the upstream developers, meaning, proposing a merge request and so on… bzr lp-propose and bzr branch lp:<source_package_name> are regularly and automatically adjusted as part of the daily release process to point to the right branches so that you can find them easily. Vcs-Bzr in debian/control should point to the right location as well.

Then, just refer to the upstream merging guidelines above. Once approved, this change will be in the next daily release (if tests pass).

An urgent change is needed

If the change needs to be done right away, but can wait for a full testing round (~2 hours), you can:

• Propose your merge request
• Ping someone from the ubuntu-unity team who will ensure the branch is reviewing in priority and rerun a daily release manually including your change. That way, your change will get the same quality reviews and tests checking than anything else entering the distro.

It's really urgent

You can upload right away your change then, the next daily will be blocked for that component though (and only for that component) until your change reaches upstream. So please, be a good citizen and avoid more churn in proposing your change back to the upstream repo (including changelog), pinging the ubuntu-unity team preferably.

I'm making a change, should I provide anything in debian/changelog?

Not really, as mentioned earlier, if you link to a bug or mention in a commit message a bug number in your branch before proposing for review, this will be taken into account and debian/changelog will be populated automatically with your name as part of the next daily release. You can still provide it manually and the daily release will ensure there is no duplication if it was already mentionned.

If you provide it manually, just: dch -i and ensure you have UNRELEASED for an unreleased version to ubuntu (without direct upload).

ubuntu-unity team

Note that in all following commands, if -r <release> is not provided, "head" is assumed. Also, ensure you have your credentials working and be connected to the VPN (the QA team is responsible for providing those jenkins credentials).

Where is the jenkins start page?

There it is.

Forcing a stack publication

After reviewing and ensuring that we can release a stack (see section about manual publication causes, like packaging changes to review or upstream stack failing/in manual mode). Then run:

$ cu2d-run -P <stack_name> -r <release>

example for indicators, head release:

$ cu2d-run -P indicators

Remember that the master "head" job is not rerun, so it will stay in its current state (unstable/yellow). The publish job should though goes from unstable/yellow to green if everything went well.

Rerun a full stack daily release, rebuilding everything

$ cu2d-run -R <stack_name> -r <release>

Rerun a partial stack daily release, rebuilding only some components

$ cu2d-run -R <stack_name> -r <release> <components>

/!\ this will keep the state and take into account (failure to build state for instance) and the binaries packages for the other components which were part of this daily release, but not rebuilt.

for instance, keeping dee and libunity, but rebuilding compiz and unity from the unity, head release stack:

$ cu2d-run -R unity compiz unity

The integration tests will still take everything we have (so including dee and libunity) at the latest stack with the new trunk content for compiz and unity when we relaunched this command.

Rerun integration tests, but taking all ubuntu-unity ppa's content (like transition needing publication of the indicator and unity stacks):

$ cu2d-run -R <stack_name> -r <release> --check-with-whole-ppa

This command doesn't rebuild anything, just run the "check" step, but with the whole ppa content (basically doing a dist-upgrading instead of selecting only desired components from this stack). This is handy when for instance a transition involved the indicator and unity stack. So the indicator integration tests failed (we don't have the latest unity stack built yet). Unity built and tests pass. To be able to release the indicator stack as well as the unity stack, we need the indicator stack to publish, for that, we relaunch only the indicator tests, but with the whole ppa content, meaning last Unity.

In that case, the publish for the indicators will be manual (you will need to force the publication) and as well, you should ensure that you will publish the unity stack at the same time as well to have everything in coherence copied to the -proposed pocket. More information on the stack dependency in this section.

Adding/removing components to a stack

The stack files are living in jenkins/etc/. This yaml file structure should be straightforward. Note that the tuple component: branch_location is optional (it will be set to lp:component if not provided). So add/change what you need in those file.

Be aware that all running jobs are stopped for this stack.

$ cu2d-update-stack -U <path_to_stack_file>

This will reset/reconfigure as well all branches, add -S if you don't have access to them (but ensure someone will configure them still at least once)

Different level of failures acceptance.

We do accept some integration tests failing (no unit tests should fail though as ran as part of package building). The different level of those triggers are defined in a file like jenkins/etc/autopilot.rc. Those are different level of failures, regressions, skipped and removed tests per stack. The real file depends on stackname and are found in $jenkins/cu2d/<stack_name>.autopilotrc as described in the -check template.

Monitoring upstream uploads and merges

Remember to regularly look at the -changes mailing list to pick if a manual upload has been done and port the changes back (if not proposed by the ubuntu developer making the upload) to the upstream branch. The component which had a manual upload is ignored for daily release until this backport is done, meaning that no new commits will be published until then (you can see the prepare job for that component will turn unstable).

Also, ensure as you are watching all upstream merges to follow our acceptance criterias that the "latestsnapshot" branches generated automatically by the daily release process has been merged successfully by the upstream merger.

Boostrapping a new component for daily release

A lot of information is available on this wiki page.

Conclusion

Phew! This was a long serie of blog post. I hoped that you appreciated to have a deeper look of what daily release means, how this work, and also that the remaining questions have been answered by the above FAQ. I've just ported all those information on the https://wiki.ubuntu.com/DailyRelease.

Of course, this is not the end of the road, I have my personal Santa Claus wishlist like UTAH being more stable (this is under work), the daily image provisionning with success more often than now, refactorisation work taking integration tests into account, less Xorg crashes when completing those tests… This is currently adding a little bit of overhead as of course, any of this will reject the whole test suite and thus the whole stack. We prefer to always be on the safe side and not accepting something in an unknown state!

Also, on the upstream stack and daily release process as well, there are rooms for improvments, like having less upstream integration tests failing (despite awesome progress already there), I wish I can soon turn that down to 3% of accepted failure at most for unity instead of the current 7% one. Dedicated integrations tests for indicators would be awesome as well (stealing the unity ones for now and only running those involving indicators, but of course, not everything is covered). Having also some oif, webapps and wecreds integration tests is one of my main priority, and we are working with the various upstream developers to get this done ASAP so that we have a better safety net than today. On the daily release process itself, maybe freezing all trunks in a go would be a nice improvement, more tests for the system itself as well is under work and my personal goal to reach 100% test coverage for the scripts before making any additional changes. Finally, some thoughts for later but a dashboard would enable to have a higher view than just using jenkins directly for reporting, to get a quicker view on all stack statuses.

Of course, I'm sure that we'll experience some bumpy roads with this daily release process through the cycle, but I'm confident we'll overcome them and I am really enthousiast about our first releases and how smoothly they went until now (we didn't break the distro… yet :p[2]. I'm sure this is a huge change for everyone and I want again give a big thank you to everyone involved into that effort, from the distro people to upstream and diverse contributors on the QA team. Changing to such a model isn't easy, it's not only having yet another process, but it's really a change of mindset in the way we deliver new features and components to Ubuntu. This might be frightening, but I guess it's the only way we have to ensure a systematic delivery, continuous and increasing quality while getting well a really short feedback loop to be able to react promptly to the changes we are introducing to our audience. I'm confident we are already collecting all the fruits of this effort and going to expand this more and more in the future.

For all those reasons, thanks again to all parties involved and let's have our daily shot of Unity!

I couldn't finish without a special thanks to Alan Pope for being a patient first reader, and fixing tediously various typos that I introduced into the first draft of those blog posts.

Notes

[1] "0replacemepleasepleaseplease" or anything else appended to 0replaceme is accepted as well if you feel adventurous

[2] fingers crossed, touching wood and all voodoo magic required

Since I upgraded to Firefox 18, I’ve had blurry fonts on some sites, including Twitter and YouTube. Today I looked a bit into the problem, and found a solution in the Firefox Support forum.

In about:config, edit keys in the following way:

1. Set layers.acceleration.force-enabled to true
2. Set layers.acceleration.disabled to false

Thanks for juanbaez for the tip!

If you don’t want to edit your configuration, I read that this is fixed in Firefox 19 as well. Downgrading to Firefox 17 reportedly works as well.

Year ago we had Linaro Connect right after FOSDEM so I decided to skip and walk to Golden Gate instead. But this year there were no conflicts!

Months before we had discussion on SzLUUG mailing list about who goes for FOSDEM. There were about 9 people wanting and we ended with five. So on Friday morning friends arrived near my house, I jumped into car, we grabbed 4th one (Tomek was in London at that time) and went to Berlin Schönefeld airport for 07:00 Easyjet flight.

And we missed it… 5-10 minutes late we were ;( 75€ per person and 10 hours later he took off from SXF airport.

But that 10h was not wasted. Berlin has very nice Technical Museum with many trains, cars, planes and other exhibitions. And they had Trabant 601 as well:

Then trip to shops (Saturn, Media Markt) in search for HTC Desire X case (Magda) and LG Nexus 4 (me). Avoid Saturn — they do not handle credit card payments at Alexanderplatz so I had to walk to the ATM. Two S-Bahns later we passed security check and went to the gate early enough to fly.

BRU airport… I think that (with exception of SXF/TXL) it is my most visited airport as it was my 5th FOSDEM and there was UDS-M around as well. But this time we took a bus instead of a train. 14€ ticket works for 72 hours so cover all trips perfectly. Few hours later we were joking that this multi country journey was exhausting as we were in Berlin, Brussels, went though Geneve (bus stop) to Luxembourg (square) and passed near London (restaurant) ;D

Hotel, drop stuff, connect chargers, went for beer event. Crowdy as usual it was. But I managed to meet some friends (but also missed lot of them) and grabbed few beers. Good spent time. Too bad that I was so tired that went back to hotel just right after midnight.

Saturday

Breakfast in St. Nicolas hotel maybe is not the best but provides enough energy to survive a day. Met several guys there, Philip gave me Kindle Paperwhite which I bought few days before (with delivery to his house to lower price) and his famous Belgium/Holland/Luxembourg guidebook. I also got Beagle pendrive from Koen.

Then overcrowded bus 71 and FOSDEM! I told Bartek where things are (but at that time I had no idea of K building) and we split. In AW building I met friends manning OpenEmbedded stand just right in front of building entry.

Circuitco had Beaglebone stand right to it:

That robot was great example what you can do with enough signals available to drive all those motors. And what you can do with 3D printers ;D

I do not know is it due to crisis or something but AW building had just half of a space for stands used…

Then I went for talks:

• “Embedded distro shootout: buildroot vs. Debian” — wasted time. Long discussion about Emdebian + short info that Buildroot works in other way. Could be nice talk if done in other way.
• “Porting Fedora to 64-bit ARM systems” — talk done by Jon Masters and his clone. As usual first “what the hell is 64-bit ARM” and then how Fedora bootstraps itself. Nice talk, got some new stuff. Have to dig for Cavium SDK.
• “Porting OpenJDK to AArch64″ — interesting it was. Two speakers, lot of technical details.
• “ARMv8, ARM’s new architecture including 64-bit” by Andrew Wafaa. Mostly to catch speaker in easy way ;D
• “Bootstrapping Debian-based distributions for new architectures” – I was lazy to go somewhere else but it was good talk.
• “Bootstrapping the Debian/Ubuntu arm64 ports” by Wookey. Kind of recycled talk from Barcelona but I like his presentations. Also first one without “what the hell is armv8″ introduction.

I also had nice discussion with Jolla guys about their system/device and would I like to test it once they will have something ready for complains. Played a bit with Firefox OS on their reference developer platform and on Nexus S and was not impressed — for example it looked like they have to learn about DPI…

Then I met OE crew and few other guys and when finally noticed that it is time to go to the hotel and drop gear there. Once arrived it was a bit to late to go somewhere and search for some event so I joined SzLUUG team and we went for a meal, chocolates and then some drinking with Kerneliusz (SzLUUG mascotte):

Sunday

Breakfast, packing gear and go for a bus which was less crowded than day before (but we are a bit late as well). As we had to leave after 14:00 I managed only two talks:

• “systemd, Two Years Later” — some Ubuntu trolling and project status. Nice talk.
• “Porting applications to 64-Bit ARM Architecture” by Riku Voipio (main AArch64 porter at Linaro). Good discussion in a room, some nice hints and suggestions. Read his recent blog post about ARMv8 porting

Then walk, tram, bus and security check. This time I did not have to take developer boards from backpack as I gave them away during event. We arrived in Berlin and (due to Michał’s fosdem flu) I drove us back home.

Summary

It was great event as usual. But distance between K building and rest was too big for sessions which are one after another. I dropped some entries from my calendar just because it would be H->K->H->K switching.

Android application for schedule was ok. Would be nice to make a bigger effort and update it to cover K building as well and add a way to see what is going on in each building/room to reduce time before sessions.

Funny part

On Saturday I realized that for some reason I may remind Jon Masters… That’s due to hardware I had with me:

• two developer boards
• two phones
• two tablets
• 3 USB chargers
• 4 microUSB cables

The good thing is that they were not of same type (except some cables) :D

Related content:

1. UDS-Q
2. Going for FOSDEM
3. FOSDEM X
4. UDS-O
5. Dublin: Ubuntu sprint and more

All rights reserved © Marcin Juszkiewicz
FOSDEM 2013 was originally posted on Marcin Juszkiewicz website

We would like to welcome some new faces to the forum moderation team:

codemaniac
ikt
varunendra
QIII

Thank you all for giving your time to help keep the forum the pleasant place it is

The death of Gnome Panel

Gnome Panel (or more properly, gnome-panel) is the main dock that you would see in the Gnome 2 series desktop, and in the Gnome Fallback session (also called Gnome “Classic” in many distributions) in Gnome 3.

To provide the typical desktop experience, it’s also accompanied by Nautilus and Metacity along with a few other libraries (hence forth, gnome-panel’s friends). Gnome Panel and friends have recently been deprecated so that developers have more time to focus on Gnome Shell, the new default shell for Gnome that has a vastly simplified (and better) technology stack. Last November, Vincent Untz announced that he would stop maintaining Gnome Panel and friends beyond the 3.6 release, which means the death for it unless anyone else takes it up.

Then What

I’ve been an avid user of the Gnome 2.x series and also Gnome Fallback in the 3.x series. I’ve gotten rather good at supporting it too. We include it by default in Edubuntu, and even have an option in the installer to make it the default for installations over Unity. It provides a low-footprint, fast and simple desktop experience with very reasonable usability, while being very configurable and lockdownable. (my spell check says that’s not a word, but I don’t care).

I’ve been considering whether we should switch to having Xfce or LXDE as an alternative to Unity, but after discussing it with other Edubuntu contributors, it became clear that if I wanted to do that, I’d have to be willing to maintain it for Edubuntu by myself. In Edubuntu we’ve been pretty good at having at least 2 people being interested in any side-project we pick up and I like to keep it that way if we can. It means that if someone gets a bit busy, there’s someone who can pick up the slack for a little while. Also, Xfce and LXDE had big holes in usability, especially when it came to things like having multiple displays and running on laptops. I decided to put that project on the backburner a little since Ubuntu 13.04 will still be using Gnome 3.6, which meant that we’d have the Fallback session for one more release anyway.

The Inevitable Fork

Ikey Doherty forked off Gnome Panel to create a new environment called Consort. Metacity is forked to become Consortium. The website where the Consort desktop environment used to live seems gone now, but here’s a link to some screenshots from Google+.

This caused a bit of a stir, Vincent Untz posted a good chronology of what lead up to it and why he believes that a fork is a bad idea when the Gnome project has effectively put the upstream code up for adoption.

I’ve been interested in the Consort family since it could potentially be something that we could use in Edubuntu once the upstream gnome-panel is no longer in the archives. Also, while Gnome Shell, KDE Plasma Desktop and Unity are great and have come incredibly far in terms of stability and performance, it’s just not always for me. I want to be able to use it for myself in virtual machines, older machines and some other special cases (most notably, on LTSP).

Josselin Mouette, maintainer of Gnome in Debian, approached Ikey after some requests have been made for it in Debian. If you’ve read the post and the IRC logs linked, then you’ll probably agree that it could’ve gone a lot better. I’m not on the SolusOS IRC channel so only saw the conversation after the fact, but I was disappointing since it would need to go into Debian if I’d want to support it in Edubuntu. I think both Josselin and Ikey could’ve handled it better, but humans are just that and emotions and misunderstandings happen.

And so I Bite

I was chewing a bit on Josselin’s comment on how the former maintainer “maintainer decided to give the key to anyone who wanted to” and it’s been several weeks since Vincent invited people to take over maintainership. I decided that I’d at least be willing to do the absolute minimum just to keep the project releasable every six months so that it can be included in distributions, maintain its online presence pages, bug tracker status and keep up with component changes in the stack. So I e-mailed Vincent and explained what I’m willing to do. I had very little resistance, Vincent sent an email out to other people who are steakholders in the gnome-panel project and after a week, there were no objections. So here I am, brand new maintainer of the Gnome Fallback session and its components!

This means that the project is, at least for now, alive again. It’s not going to be part of the official Gnome 3.8 release (I still have to figure out exactly what that means), but there will be a 3.8 release of Gnome Panel and friends as tarballs and for people who maintain it in distributions, things will continue to work exactly as it did before.

Short-term Goals

• My complete primary goal for this at the moment is to ensure that gnome-panel, metacity, etc is releasable alongside the Gnome 3.8 release. This basically means making sure it builds, including any patches that we can and releasing.

Medium-term Goals

• Do something about the long buglist. The Gnome bug tracker has an ugly long list of gnome-panel bugs (939 at my last count). I want to eliminate all the stale Gnome 2.x gnome-panel bugs of which a very large amount of them are no longer relevant (at least on first glance). Then I’d like to do some regular posts to the mailing list and blog about a few prominent bugs every now and again and try to fix them and get people involved.

• Porting Metacity to GTK3. So here’s a bit of really good news. Josselin is also involved with this and one of his mid-term goals is to port metacity to gtk3. It’s something that I know would have to happen, but I don’t have the skills to do that (yet) and I’m glad that he has took this up. Josselin’s mid-term goals also include possibly adding support for the new notification  system (if necessary) and adding support for the new Gnome global menu.

• Create a nice project page with goals and to-do list, who’s envolved and what they’re doing and encourage more people to get involved. The current page is rather outdated so it would be nice to fix it. For now that mostly involved bringing the Gnome Panel Gnome Wiki page up to date.

Long-term Goals

• My pet peeve…  intelligent launcher icons. Windows 7, Mac OS X, KDE, Unity and Gnome Shell have docks that work very similarly in many ways. You click on a launcher and those same launcher entries are recycled as your window list. Gnome Panel is a bit old fashioned in this regard. Many people use 3rd party panels and launchers just to get around this. I have thought for a long time that this should be fixed in Gnome Panel and long-term, it’s something that I’d like to see happen.

• Make the stack as downstream-friendly as possible. Regarding Ikey and Consort, I don’t actually think it was a completely horrible idea at the time. We live in a free world where we use free software and anyone is allowed to do whatever they want and fork whenever they want, and while that doesn’t necessarilly mean it’s a good idea, it also doesn’t mean that we need to get all hissy about it. I’d actually be very interested in working with people who want to fork and find out why they want to fork and try to reel them in closer to upstream. In the case of Consort, I think it would be most beneficial for both projects and all their users if Consort was a branch of Gnome Fallback, rather than a fork. Both projects use Git, FFS. I’ll reach out and try to minimize duplication of effort while not blocking anyone on experimenting with new features or implementing distro-specific changes.

• More metacity features. Metacity’s compositing features have come quite a long way, there are still a few bugs that need to be sorted out, but more than that, there are many window manager features that users have become accustomed to in pretty much all the other environments. Ikey has indicated previously that he wants to do this for consortium. It’s one of the reaons I’ll be super-nice to him because I’d really prefer that he submit as much of that upstream as possible.

• Make everything worth configurable and lockdownable. There are some settings that I get requests from from the users I support so often that it’s just getting boring. The Gnome 2.x series proved to work well in educational and corporate environments. I say we should play on that strength and make it even more  so, while sticking 100% with the Gnome Human Interface Guidelines, of course.

Very Long-term Goals

Well, the fact is, Gnome Fallback will die. There’s a new project called Gnome Legacy, it implements a Gnome 2.x-like experience in Gnome 3. As time goes by, older machines become more powerful and the missing pieces will be implemented and eventually there would be no more good reason for anyone to want to run what we now know as Gnome Fallback. I think it could still have a good 3-5 years or maybe even more in it. Who knows, by then Gnome 4 might even be in development and all of this will be ancient history.

So, my very quick “Eek, I’m now maintainer of Gnome Panel!” post has become quite lengthy post, if you have any questions, I’ll respond to it in the comments.

As many of you know, I’ve been spending some time hacking on a Lisp variant that’s fully hosted in Python. If you want to read more about it, check out the slides I prepared for Boston Python’s meetup — in particular, pay attention to the “magic REPL”.

I’ve been pondering what to do next, and the natural instinct is for me to take a step back, and properly implement a few things I’ve forgotten. Namely: Macros. Yes. Macros. It’s a Lisp without Macros.

I’ve hit a few stumbling blocks in it’s implementation, and it’s been holding me up. I’m mostly concerned with how Hy should treat quoted forms, in particular I’m concerned about loosing the distinction between a vector and a list, since both convert into Python lists.

There is of course the option to encode Lists as:

`(list foo bar baz)

but that seems wrong.

I’ve also got some concerns about “derefing” values in a quoted form — I think this is just going to result in a lot of special casing for Macros.

More to come soon.

Welcome to the Ubuntu Weekly Newsletter. This is issue #302 for the week January 28 – February 3, 2013, and the full version is available here.

In this issue we cover:

• Smart Scopes
• Announcing Ubuntu User Days Feb 9-10th
• Ubuntu Stats
• Ubuntu Ohio Holds Educational Session
• The World’s Largest Barcamp is in Myanmar
• Ubuntu App Developer Blog: Develop locally, run remotely
• Jonathan Carter: Ubuntu Developer Summit for 13.04 (Raring)
• Ubuntu Classroom: Ubuntu Developer Week: Days 1-3
• Ubuntu Women: Ubuntu Women Full Circle Follow Up with Laura Czajkowski
• Alan Bell: Ubuntu Smart Scopes
• Ubuntu Classroom: Interested in helping with Quality? Several sessions next week!
• Victor Tuson Palau: [Ubuntu QML] SimpleToDo.. done!
• Charles Profitt: Friendly Needs You!
• In The Press
• In The Blogosphere
• Other Articles of Interest
• Featured Audio and Video
• Weekly Ubuntu Development Team Meetings
• Upcoming Meetings and Events
• Updates and Security for 8.04, 10.04, 11.10, 12.04 and 12.10
• And much more!

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

• Elizabeth Krumbach
• Jasna Bencic
• Jim Connett
• And many others

If you have a story idea for the Weekly Newsletter, join the Ubuntu News Team mailing list and submit it. Ideas can also be added to the wiki!

Except where otherwise noted, content in this issue is licensed under a Creative Commons Attribution 3.0 License BY SA Creative Commons License

It looks like after a 7-0 vote by the Fedora Engineering Steering Comittee, MariaDB will replace MySQL in F19.

No word from the Monty Program crew yet, but congrats to them, especially Colin Charles, and the Fedora community, especially Jaroslav Reznik and Honza Horak.

We are having community moderator elections for the year 2013 in order to accommodate the growing community at Ask Ubuntu. The elected moderators from this year’s election will complement the current moderators, as is the policy with Stack Exchange network of sites.

Ask Ubuntu had some tremendous growth in the year 2012 and the stats only prove that:

• Over 50,000 questions,
• 60,000 more users and
• more than tripling the daily traffic to 217k visits/day.

If you are one of those nice blokes (like the current set of moderators ) and is willing to help make Ask Ubuntu an even better place, please do consider nominating yourself for the upcoming moderator elections. The nomination phase runs for the next 7 days followed by the voting on the nominees. Do note that the nominees are required to have at least 300 reputation. Anyone with over 150 reputation will be part of the electorate and can vote on the nominees during the election phase.

People interested in discussing the election or any of the nominations, please consider joining the chat room for Ask Ubuntu elections.

Or, we can always use some help with answering the questions. Here’s a good place to start.