RT @PROINNOVAUCR: El uso de #softwarelibre ahorra 450.000 millones en #Europa http://t.co/Cqqibccc #opensource #freesoftware

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.

RT @freeculture: Announcing the Empowermentors Collective for Women of Color & Queer People of Color in #freeculture and #freesoftwa ...

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?

http://t.co/3Fv4fGEi #musthavesoftware: How to Transfer Software From One Computer to Another #06 #freesoftware #mobilesoftware

Make free science free leverage volunteer computing using #freesoftware http://t.co/ssWGvCLr Talk by @jjmerelo (slides)

#VIDEO #FREESOFTWARE Get UNLIMITED FREE Traffic In Under 2 Minutes http://t.co/TvxTEnpr

#VIDEO #FREESOFTWARE Get UNLIMITED FREE Traffic In Under 2 Minutes http://t.co/1MDGOlHD

#VIDEO #FREESOFTWARE Get UNLIMITED FREE Traffic In Under 2 Minutes http://t.co/PKiwYAxu

#VIDEO #FREESOFTWARE Get UNLIMITED FREE Traffic In Under 2 Minutes http://t.co/KOLv2zxH

RT @PROINNOVAUCR: El uso de #softwarelibre ahorra 450.000 millones en #Europa http://t.co/Cqqibccc #opensource #freesoftware

RT @PROINNOVAUCR: El uso de #softwarelibre ahorra 450.000 millones en #Europa http://t.co/Cqqibccc #opensource #freesoftware

RT @PROINNOVAUCR: El uso de #softwarelibre ahorra 450.000 millones en #Europa http://t.co/Cqqibccc #opensource #freesoftware

El uso de #softwarelibre ahorra 450.000 millones en #Europa http://t.co/Cqqibccc #opensource #freesoftware

RT @maefloresta: Please! Help us to attend #LGM2013 We're really close to our goal! http://t.co/xG9J7DE1 #freeSoftware #animation #2D

RT @larjona99: ClassicShell for #Windows8 http://t.co/iGD6Su1b #freesoftware to the rescue

ClassicShell for #Windows8 http://t.co/iGD6Su1b #freesoftware to the rescue

Please! Help us to attend #LGM2013 We're really close to our goal! http://t.co/xG9J7DE1 #freeSoftware #animation #2D

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