Meeting Minutes

IRC Log of the meeting.

Meeting minutes.

Agenda

20130326 Meeting Agenda

ARM Status

R/master: the -omap flavour was renamed -generic and support for Calxeda SOC was added to it.
The -generic rename, coupled with the deletion of R/omap4 and the removal of the highbank
flavour from master, officialy mark the beginning of arm multiplatform support
in UBUNTU.

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

The above summarizes the remaining work items owned by individuals on
our team for the rest of the 13.04 cycle.

Status: Raring Development Kernel

We have rebased Raring to the latest v3.8.4 upstream stable kernel and
uploaded. We have also began work to provide support for highbank in
Raring. We have also rebased our unstable-3.9 branch to the latest
upstream v3.9-rc4.
Please be aware that Beta Freeze is fast approaching, ie this Thurs Mar
28. We will perform one more upload either today or tomorrow prior to
Beta Freeze. Beta release is then next week on Apr 4 and Kernel Freeze
is the following week on Apr 11. All patches submitted after Kernel
Freeze must adhere to our SRU policy.
Important upcoming dates:

• Thurs Mar 28 – 13.04 Beta Freeze (~2 days)
• Thurs Apr 04 – 13.04 Final Beta Release (~1 week)
• Thurs Apr 11 – Kernel Freeze (~2 weeks)

Status: CVE’s

== 2013-03-26 (weekly) ==
Currently we have 73 CVEs on our radar, with 8 CVEs added and 25 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

Status for the main kernels, until tiday (Feb. 26):

• Hardy – Nothing this cycle
• Lucid – In Prep; (2 commits)
• Oneiric – In Prep; 4 upstream releases; (100 commits)
• Precise – In Prep; 1 upstream releases; (150 commits)
• Quantal – In Prep; 1 upstream releases; (164 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

  We respun the Quantal and Precise kernels yesterday. All derivative
  kernels will need to be respun.

Open Discussion or Questions? Raise your hand to be recognized

No open discussion or questions.

The Ubuntu Developer Advisory Team has been in place for two or three release cycles already and it’s been a fun journey so far. We’ve got in touch with many many new contributors and old contributors as well. If you don’t know what this team does, here’s what our wiki page has to say:

We

• Reach out to new contributors, thank them for their work and get feedback.
• Reach out to people who might be ready to apply for upload rights and help them.
• Reach out to contributors that went inactive and get feedback from them and offer help.

I personally found this very rewarding as I got to talk to many new contributors and see how they feel about Ubuntu Development.

You can help!

If the above sounds interesting to you and you enjoy engaging socially, if you have made a few experiences in Ubuntu Development and want to help out, please talk to me or comment below. It’d be great to have you on board!

Meeting Minutes

IRC Log of the meeting.

Meeting minutes.

Agenda

20130319 Meeting Agenda

ARM Status

R/master: worked on adding support for a new arm soc.
R/omap4: still waiting input if we can drop the omap4 dekstop image.
R/nexus7: debugged an issue about display brightness.

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

The above summarizes the remaining work items owned by individuals on
our team for the rest of the 13.04 cycle.

Status: Raring Development Kernel

We have rebased Raring to the latest v3.8.3 upstream stable kernel and
uploaded. We have also started tracking the v3.9 kernel in an
unstable-3.9 branch. We have rebased that branch to v3.9-rc3 but not
yet uploaded.
Important upcoming dates:

• Raring:
  • Thurs Mar 28 – 13.04 Final Beta Freeze (~1 week)
  • Thurs Apr 04 – 13.04 Final Beta Release (~2 weeks)

Status: CVE’s

== 2013-03-19 (weekly) ==
Currently we have 69 CVEs on our radar, with 21 CVEs added and 6 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

Status for the main kernels, until tiday (Feb. 26):

• Hardy – Nothing this cycle
• Lucid – In Prep; (2 commits)
• Oneiric – In Prep; 4 upstream releases; (100 commits)
• Precise – In Prep; 1 upstream releases; (150 commits)
• Quantal – In Prep; 1 upstream releases; (164 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

  Note: This is the week the last Hardy and Oneiric kernels may be built.

Open Discussion or Questions? Raise your hand to be recognized

No open discussion or questions.

Community has been a big concept for me in 2013. Perhaps it reads as cliche, I’m not cynical! I feel as if I’m struck every day amazing power of community, the ability of individuals to organize, communicate, share and create something better. Continually amazed by the deepness and complexity to the connections between all of us and the spaces (physical or virtual!) we inhabit.

In this line, I’ve been thinking a lot about building more of an online home for myself! Why not start with a blog? A place to share my thoughts, to share what I learn, to share my problems and successes! I’m not sure what I want racarr.me to become, but one step at a time!

I will admit I have put it off for some time, the usual anxiety!

However with the public announcement of Mir, which has been my focus at Canonical for many months, I can’t hold it in any more! Reputedly there is some controversy on the internet over Mir . I have to say though, it’s a piece of software that I am immensely proud to be a part of creating. I think we have solved a lot of hard problems, and generated a lot of interesting thought. I want to share this, so we can all collaborate to find better solutions to the next problems (for Mir or otherwise).

Lately in work I have been working on enabling input for native Mir clients, and am looking forward to writing some posts on the important concepts and features throughout the Mir input stack.

Lately in life I am living in San Francisco and learning to love and share a little more every day.

Who knows what else I will write about? Perhaps the top 100 versions of Scarlet Begonias, perhaps life in San Francisco, perhaps just musings. I’m hoping to find my voice.

Meeting Minutes

IRC Log of the meeting.

Meeting minutes.

Agenda

20130312 Meeting Agenda

ARM Status

R/master: nothing new this week.
R/omap4: verified that pvr-omap4 doesn’t work with our multiplatform 3.8 kernel,
i’m waiting input if we can drop the omap4 dekstop image.
R/nexus7: ported overlayfs from P (lp1076317) – awaiting testing from a
brave soul since my nexus7 is borked ATM (lp1126836).

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

The above summarizes the remaining work items owned by individuals on
our team for the rest of the 13.04 cycle.

Status: Raring Development Kernel

Since our last meeting 2 weeks ago, we have rebased to the latest v3.8.2
upstream stable kernel. We’ve also added Haswell ULT NFC, I2C, SPI, and
SATA RTD3 support, USB3 port power off capability, prime support for
nouveau and radeon, and other misc config updates and bug fixes.
Important upcoming dates:

• Raring:
  • Thurs Mar 21 – 13.04 Final Beta Freeze (~2 weeks)
  • Thurs Mar 28 – 13.04 Final Beta Release (~3 weeks)

Status: CVE’s

== 2013-03-12 (weekly) ==
Currently we have 46 CVEs on our radar, with 10 CVEs added and 1 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

Status for the main kernels, until tiday (Feb. 26):

• Hardy – Nothing this cycle
• Lucid – In Prep; (2 commits)
• Oneiric – In Prep; 4 upstream releases; (68 commits)
• Precise – In Prep; 2 upstream releases; (197 commits)
• Quantal – In Prep; 2 upstream releases; (175 commits)
  Due to a regression, the Quantal kernel and it’s derivatives have been
  respun.
  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

  (bjf> >)
  (bjf> >) Note: The week of March 21 is the week the last Hardy and Oneiric kernels may be built.
  (bjf> >)

Open Discussion or Questions? Raise your hand to be recognized

Welcome back to the Kernel team, kamal!

I just want to echo Tony’s appeal to help three year-old Sam who was diagnosed with high risk neuroblastoma, a particularly aggressive cancer. It has spread from the main tumor into his bones and bone marrow. That makes it a class 4 cancer, the most advanced on the scale. The long term survival rate for high risk neuroblastoma is 40%.

As Tony shares:

The good news is that Sam is responding well to chemotherapy. But Sam’s oncologist at Manchester Children’s Hospital has recommended that Sam receives immunotherapy treatment so that his own body can recognise and attack the neuroblastoma if it returns.

The most successful treatment is not available in the UK because some of the drugs are still being trialled. It costs over £250,000 in the US. Which is why Sam desperately needs your help. Carl and Christine are trying to raise the money to send Sam for treatment in the US.

If you would like to donate to help Sam, that would be brilliant. In the UK you can just text SAMS67 and the amount you’d like to donate (£1, £2 £3 £4 £5 or £10) to 70070. Alternatively you can donate on-line at the Sam Shaw Just Giving page. It’s Sam’s fourth birthday this week, so it would be a great birthday present to give him.

Also be sure to join the appeal’s Facebook page.

Your donation to Sam will have an incredible impact on his life as well as his parents, Christine and Carl, who must be having a hell of a time right now dealing with all of this. Let’s all show them that we care by helping them to cover their son’s treatment.

The Moonshot for Mir & Unity Next

Convergence! Unity Next is what we’re referring to with our migration from Nux to Qt for our shell rendering. Migration might not be the right term, in a way the migration has already begun …as this is what you’re looking at when you see the Ubuntu Touch preview.  And the Ubuntu Touch preview wasn’t written as a demo, it’s intended to continue going through software development and become a product. Finishing up our change to Qt does give us an opportunity to revisit some other things we’ve been working on…like Mir. So our goal is to effectively have Mir be the master of surfaces, input & application info in the system with Unity Next running on top for all form factors…desktop computers, tv’s, tablets & phones.

Any time you’re trying to converge existing solutions into one, you have some choices to make in terms of what to use as a seed. In our case the journey is going to begin with phones as the first key milestone. There are a couple of reasons. You may have noticed in our recent Ubuntu Touch preview the first form factor to appear was the phone. And if you are a long time user of Ubuntu, the there is a subtle difference in the ui you’ve seen recently on the phone & tablet compared to the desktop. So it’s efficient for us as an organization to leverage that which has been the focus of our most recent effort in the UI stack evolution.  Also, due to the screen real-estate area, the phone presents itself as a virtual subset of the desktop requirements. So we feel that beginning with a focus on the phone will to get to a productizable code base on the phone is the best way to quickly harden what we have & provide the vehicle to convergence.

Approaching it from the phone angle means we’ll be able to harden a subset what’s needed for full convergence & deliver an actual product to use along the way…rather than trying to do everything in one shot. And that’s beneficial in terms of getting “road milage” on the code and making any tweaks especially for “look and feel” topics. It does mean that along the way we’ll need to keep an eye on building in some flexibility to accommodate our desktop….but the good news there, we’ve been delivering Unity for desktop for a while now, so most interested parties are aware of what the desktop needs to deliver.

Devil’s in the blueprints

As you can imagine, there’s plenty to do for full convergence. We’ve captured much of what we think needs to occur in https://blueprints.launchpad.net/ubuntu/+spec/client-1303-mir-phone-iteration-0 & we’ve begun to flesh out work for Unity Next as well here https://blueprints.launchpad.net/ubuntu/+spec/client-1303-unity-ui-iteration-0. If you take a look at the blueprint https://blueprints.launchpad.net/ubuntu/+spec/client-1303-mir-converged you’ll see a see a diagram dependency in the middle of the page…The thinking goes like so…”what do you need for a converged solution?”…”you need a productizable phone base”…”what do you need for a producatizable phone?”…”you need a first integration”. Unity Next has a similar blueprint & diagram https://blueprints.launchpad.net/ubuntu/+spec/client-1303-unity-ui-converged

And so, our milestones effectively match this line of thought.  Its like a 3 stage rocket for Mir & Unity Next… First target is integration of Unity Next & Mir  (we’ll be discussing this at the upcoming UDS)….second is actually creating our Ubuntu for Phone with Unity Next + Mir sometime in 4Q13. Lastly we should hit full convergence in 2Q 2014. And if you poke around you may notice that there is high priority on phone with low priority on convergence, but there’s no confusion convergence is the ultimate target. This is just an artifact planning reality, the nearest required steps are the highest priority…as we deliver the phone, convergence will take its place.

If you’d like to join us on the journey. Look for the Mir session and the Unity Next session in our upcoming virtual UDS http://uds.ubuntu.com/ & you can always find us on #ubuntu-unity

Some time ago, Canonical started internal discussions about our convergence strategy, clearly spelling out the distant target of shaping and developing a single computing platform and operating system that is able to power the cloud, classic desktop machines, laptops, TV sets, phones and tablets (fridges anyone?). More to this, we stated that we want a single mobile device, a bundle of portable computing power together with the respective operating system, that seamlessly adapts to different form-factors and use-cases. Or to put it a little more catchy:

Your phone is your TV, is your desktop, is your … you name it.

And yes, we were aiming for the moon. We worked hard to draft a system that would allow us to reach the moon, while at the same time catering towards our other central goal of providing a beautiful and lean user experience. It became apparent in conversations and discussions that one of the cornerstones of the future system we were designing will be the graphics stack, including the Unity shell. After much discussions about existing solutions (X & Weston), and how we could leverage them, we took a step back and distilled down our (technical) requirements for a future graphics stack:

• Tailored towards an EGL/GL(ES) world.
• Minimal assumptions regarding the underlying driver model.
• Ability to leverage existing drivers implementing the Android driver model.
• Ability to leverage existing hardware compositors.
• Efficient, in terms of memory-, CPU- and GPU-consumption/usage.
• Tightly integrated with the Unity shell, fulfilling the shell’s requirements while at the same time not dictating any sort of semantics up the stack.
• An efficient and secure input subsystem supporting demanding mobile use-cases.
• Fully tested from the ground up.
• Adaptable to future requirements.

With these priorities in mind, we revisited and carefully evaluated existing solutions again and found that neither of them satisfies our requirements. In particular, X and its driver model is way too complicated and feature-laden, resulting in a less efficient system and a driver model that is unlikely to be widely supported on mobile platforms. In the case of Weston, the lack of a clearly defined driver model as well as the lack of a rigorous development process in terms of testing driven by a set of well-defined requirements gave us doubts whether it would help us to reach the “moon”. We looked further and found Google’s SurfaceFlinger, a standalone compositor that fulfilled some but not all of our requirements. It benefits from its consistent driver model that is widely adopted and supported within the industry and it fulfills a clear set of requirements. It’s rock-solid and stable, but we did not think that it would empower us to fulfill our mission of a tightly integrated user experience that scales across form-factors. However, SurfaceFlinger was chosen as our initial solution for getting started with the overall Ubuntu Touch project, planning to replace SurfaceFlinger with Mir as soon as possible.

In summary, our evaluation of existing solutions led us to the conclusion that neither of them fits our requirements and that adjusting/adapting them would require substantial efforts, too. For this, we decided to go for our own solution, catering directly towards our goals and our vision, effectively saying: Yes, we are going to do our own display server.

The project was born and we decided to name it Mir (as in the space station), as it would be our outpost that finally enables us to reach our goal of arriving at the moon, providing a seamless and beautiful user experience spanning multiple form-factors. The team set off to work on Mir while large parts of Canonical started working on the Ubuntu Touch project (relying on SurfaceFlinger). A lot of knowledge and experience was and is transferred from the Ubuntu Touch project to the Mir team, with the work on the phone and tablet revealing more and more technical requirements and subtleties that heavily influenced the Mir architecture and implementation. Thus, one of the earliest technical decisions that has been taken by the team concerned the protocol that applications rely upon to communicate to Mir. We evaluated Wayland and compared it to the SurfaceFlinger approach, realizing that neither of them fits our needs. Wayland is a very promising and sensible attempt at standardizing the way that applications talk to a display server, however, it exposes privileged sections like the shell integration that we planned to handle differently, both for security reasons and as we wanted to decouple the way the shell works on top of the display server from the application-facing protocol. In the end, we decided to implement Mir’s core in a protocol-agnostic way, considering the communication protocol a very important part of the overall story, but not the driving one. We have chosen Google’s protocol buffers as our data and interface description language (DDL & IDL) and implemented a lean RPC layer that abstract away transport-specific details (relying on an ordinary socket by default). It is well tested and the protobuf IDL and DDL provide us with forward- as well as backward-versioning capabilities. However, the communication component of the overall system is adaptable and can be adjusted to account for future requirements and developments.

A final word on timelines: At the time of this writing, we are preparing to deploy the next version of the Unity shell tightly integrated with Mir in the not-too-distant future on the phone and the tablet. However, regarding the desktop use-case: We have integrated X, leveraging the prior XWayland work, to run on top of Mir (XMir) and started initial porting efforts for toolkits with a focus on Qt5. With our X-integration in place, you can run Mir on your desktop machine if your system runs a GPU that supports the free driver stack. For the closed-source desktop drivers: We are in active conversations with GPU vendors to enable Mir on those drivers/GPUs, too. [Updated] More to this, we are working together with NVIDIA towards a more unified driver model sitting on top of EGL.

As we are moving along with the development of Mir, we will work on integrating existing toolkits with the new display stack to allow application developers a seamless transition between different form-factors and prevent them from the burden of supporting multiple different display servers. As noted before, Qt5 is our first target here, with GTK3 and XUL being in the pipeline. To support legacy X applications that cannot be adjusted to work against Mir, we will provide a translation-layer that leverages the existing XMir implementation and allows legacy X apps to use Mir transparently.

And that’s pretty much it. Thanks for reading. I hope I could give you some insight into the history of Mir, its motivation and its trajectory. If you want to dive even further into the Mir world, head over to wiki.ubuntu.com/MirSpec. A lot of work has already been done, but more of it lies ahead of us. So if you are curious, have questions, want to help us or simply want to get to know the team, join the Mir sessions at the upcoming virtual UDS. You might also want to read Olli’s description of the bigger picture, including our overall convergence strategy for Unity.

To the moon,

Thomas

These ancient entries were taken from my old Advogato diary, written in my early twenties, a year after I joined the development team of Conectiva Linux. I’m copying them for historic purposes, with the content untouched. It’s curious to look back and have such details of what was going on at the time, things that feel good, and things that feel awkward such as the “Dear Diary, …” style of writing, and the amount of exclamations!!

6 Feb 2002

Wow!! It has been a long time since my last diary entry.

I’ve left Linuxconf development team coordination in favor of the Conectiva Linux port to the S390 platform coordination (ok, I’m mostly coordinating myself now . Most of the work is done. I have developed an acceptable installer (in Python!) and most of the packages are ported. We had some problems with IBM OCO modules (ick!), but we are already workarounding them (we gave up on some of our kernel patches, and I patched insmod to recognize OCO modules). Anyway, more information about this later (if I don’t disappear for another year.. …

In the process of porting Conectiva Linux to S390 and PPC (Harald Welve started the PPC port, and I’m keeping it up to date and working on missing stuff) we are learning some lessons. We are trying to use those lessons to build a defacto package building system using the Python language. Unfortunately, we don’t have enough people here to develop it quickly, so we are trying a more realistic and evolutive approach this time. The first part of it is almost done. While devloping it, I’ve studied a little bit about process groups and extended python with a missing killpg() system call. I’ve also discovered that when python spawns a new thread, it blocks all signals. With this information in mind, I have also extended it with a new execv() syscall, that besides doing the usual work, unblocks every signal before the real call to execv(). I hope this project becomes real someday.

I’ve also been playing with Python optimization lately. There’s a big opportunity for somebody wanting to study and implement some concepts there. I’ve read some documentation about Stack Machine Optimization and made some tries (basically, optimizations around the inner loop and the Big Switch, stack caching, and other flavors of this joy). Today I found a paper from Skip Montanaro documenting some of the tries I’ve made (reading it first would save me a lot of time, but this knowledge will be useful anyway). You should have a look at his paper if you have any interest in the topic. Oh, don’t forget to get yourself a copy of Lemburg’s pybench to have a general idea of what you’re doing (don’t trust too much on it, it’s just a benchmark). I’ve written Skip a mail to discuss a little bit about what could be integrated into the interpreter. Let’s see where we get.

Oh… I must not forget to update the people I’ve certified in the past to reflect what they’ve been doing.

27 Jan 2001

I’ve just tested the patch floppy_cs on kernel 2.2.17 and it works just fine!!! I had no problems applying it. Now my Libretto 50CT has a floppy drive. Maybe Conectiva Linux can ship with this patch. The only drawback is that floppy support must be modular.

In the few last days, I’ve implemented support for Inputgrid into gnome-linuxconf. It allows one to define sensitive areas into a drawing area. Gurus are already working with it.

I’ve also created two new commands for Linuxconf’s gui protocol: Splash and Hidesplash. Linuxconf will send them while it is starting, and the graphic frontend is suposed to show a nice splash screen. Support in gnome-linuxconf has also been implemented with an image designed by Everaldo (thanks!!!).

Btw, yesterday I’ve fixed a bug in Python’s bsddb module. It was handling DB_RECNO databases with string keys. As the documentation says, these databases must use, in key’s “data” field, a pointer to a memory location holding a recno_t type.

My parents have arrived yesterday!! They’ll stay here until monday and then will go to Minas Gerais, visiting Raul and Lulude.

22 Jan 2001

Yesterday I’ve implemented a message signing module for Mailman. Darian (aka dmalloc), from openprojects.net has asked if I could do such module to use on lists.openprojects.net. (I said yes… . I’m going to ask the people here at Conectiva if they want to use this module in some of our lists.

Pybot has a few new features: CTCP handling/sending, timer module, unhandled messages hook, and something else I probably forgot.

About Linuxconf, I have spent the last days fixing a few simple bugs introduced in 1.24r2 and in the last modules developed by Conectiva. I hope to release a Linuxconf update to Conectiva 6.0 tomorrow.

gnome-linuxconf has won a home with screenshots and everything else at http://distro.conectiva.com/projetos/45. I’ve also published it at freshmeat and put files to download at SourceForge.

Oh, good news I forgot to tell: for those of you that are using wxxt-linuxconf, Jack (Jacques Gelinas) has implemented the Treemenu icons into this frontend as well.

16 Jan 2001

Today I’ve fixed a bug in the Pythonmod module of Linuxconf. Linuxconf has a default handler for the SIGCHLD signal that controls all of its child termination. This method has a few disadvantages. Before calling any external processes without using default Linuxconf methods, you must block this handler, otherwise Linuxconf will get on your way. Because of this, If a Pythonmod module tried to fork external processes, they were failing. Now Pythonmod is setting the SIGCHLD signal to SIG_DFL (POSIX doesn’t allow us to SIG_IGN it) before calling python code, and after returning from a few Linuxconf API functions that set the handler back. When the python code returns, popen_initsignal() is called, putting the Linuxconf handler back in place.

On the gnome-linuxconf side, I’ve implemented the drawing context command Defpen. Now we have colored lines and primitives!! (ok… not that good…

I’ve also spent a few hours in the last two days backing up and restoring data in my colocated machine. Now my personal emails are back online and the server has an updated kernel. I hope it doesn’t bother me for a long time.

Unfortunately, the server stuff didn’t let me work on Pybot, but I had time to implement dynamically loading, unloading and reloading of modules, before I started on the server. This will help a lot in the development, since I don’t have to reboot the bot everytime something is wrong. Anyway, now that the server is ok (I hope so), I’m planning to spend some of my spare time on the bot (yes, I still have some… .

11 Jan 2001

Today I’ve added the ability of using icons while in the Treemenu mode of Linuxconf. I have just changed some functions to pass the icon name around until it got into the treemenu module and then sent it to the GUI front-end. A little hack on gnome-linuxconf did the work at the front-end side. Following this line of improvements, I’m planning to add a splash screen or something like that soon. Icons would also be welcome in the web interface.

Besides that, I’m also playing with a Python IRC bot. It’s not meant to be a war or a channel control bot. I’m planning to implement useful modules to help making IRC even more useful as an information media (no it won’t be just another infobot clone). The core and a few modules are ready. I’ll post more information later… for now, I’ll just tell that it is a multi-channel, multi-server bot, and that I’m trying to make its commands with natural language (eg. forward messages from #blah on servername to #bloh on servername).

Happy birthday Diogo!!

16 Aug 2000

Created advogato account.

Meeting Minutes

IRC Log of the meeting.

Meeting minutes.

Agenda

20130226 Meeting Agenda

ARM Status

R/master: upstream landed a patch for the ipv6 stack alignment problem – waiting
for it to enter linux-next or stable before picking it up.
Trying to make the binary pvr omap4 module to work with the
upstream kernel (but so far no success).

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

The above summarizes the remaining work items owned by individuals on
our team for the rest of the cycle.

Status: Raring Development Kernel

We have recently uploaded the 3.8.0-7.16 Raring kernel. This upload
contains a fix for CVE-2013-1763 and config updates following a full
v3.8 config review.
Important upcoming dates:

• Raring:
  • Thurs Mar 07 – 13.04 Feature Freeze (~1 week)
  • Thurs Mar 21 – 13.04 Beta Freeze (~3 weeks)
  • Thurs Mar 28 – 13.04 Beta Release (~4 weeks)

Status: CVE’s

== 2013-02-26 (weekly) ==
Currently we have 36 CVEs on our radar, with 6 CVEs added and 5 CVEs 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

Status for the main kernels, until tiday (Feb. 26):

• Hardy – Nothing this cycle
• Lucid – In Prep; (2 commits)
• Oneiric – In Prep; 4 upstream releases; (68 commits)
• Precise – In Prep; 2 upstream releases; (197 commits)
• Quantal – In Prep; 2 upstream releases; (175 commits)

  Due to an high priority CVE, all the stable kernels are being respined this week.
  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

  Note: The week of March 28 is the week the last Hardy and Oneiric kernels may be built.

Open Discussion or Questions? Raise your hand to be recognized

No open discussions.

Ubuntu Phone OS integrates with Orange and Deutsche Telekom in GSMA OneAPI initiative

Mobile World Congress kicks off today and we’re gearing up to show off Ubuntu running on multiple devices. We’ll be demonstrating phones, tablets and desktops at the stand, have Ubuntu developers flashing spare hardware, as well as be showing integration and interoperability with Orange and Deutsche Telekom through the GSMA’s One API initiative.

GSMA’s OneAPI initiative aims to provide application programming interfaces (APIs) that enable applications to exploit mobile network capabilities, such as messaging, authentication, payments and location-finding with a cross-operator reach. For example, a payment network API could be used to add an in-app purchase directly to the user’s mobile phone bill.

Ubuntu is the first smartphone operating system to be able to demonstrate integration and interoperability with a carrier’s authentication and billing systems. Working with Deutsche Telekom and Orange, we’ll show how a single API can be used to instantly log users in with their operator identity and seamlessly link that with Ubuntu One, Ubuntu’s identity and payments services, and provide carrier billing options upon purchase of music and eventually, apps.

This is a massive step forward for the industry as the GSMA and partners such as Canonical, are spearheading an initiative to standardise access to operator facilities via network APIs across all operators. The initiative will benefit operators, developers and consumers:

• It puts operators in a position to forge stronger relationships with their customers.
• For developers, OneAPI reduces the time and effort needed to create applications for and content that is portable across mobile operators, increasing reach and ultimately enhancing the consumer experience.
• For consumers, it makes it really quick and easy to make application purchases directly from their phone. It’s also more secure because it’s not necessary to input credit card details for each purchase.

Also at Mobile World Congress:

• Mark Shuttleworth, founder of Ubuntu, will participate in a keynote panel discussion alongside Mozilla and Tizen on Tuesday 26th Feb at 18.00 at the MWC Conference Auditorium and broadcast live on Mobile World Live
• We’ll be taking part in the App Developer Day on Tuesday 26th Feb. Stuart Langridge, technical architect at Canonical will be presenting the Ubuntu phone, SDK, HTML5 and native apps as well as discussing app development for Ubuntu on phones and tablets. We’ll also have engineers available at the event to flash spare handsets with Touch Developer Preview of Ubuntu. This will take place from 9.00-9.30 and 11.40-11.55, and 13.30-14.00 in Hall 8.0, Theatre A.
• The GSMA Seminar on “Unlocking Value with Network APIs” will run on Thursday 28th from 9am to 10.30 am in Room CC1.1. Canonical’s Stuart Langridge will present and demo the Ubuntu Phone during the session. We’ll also be demonstrating Ubuntu’s OneAPI solution at the GSMA stand daily.
• Look out for Ubuntu engineers who will flash spare hardware with developer images for phone and tablet throughout the show close to the Ubuntu stand.

Meeting Minutes

IRC Log of the meeting.

Meeting minutes.

Agenda

20130219 Meeting Agenda

ARM Status

nothing new to report this week

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

The above summarizes the remaining work items owned by individuals on
our team for the rest of the 13.04 cycle.

Status: Raring Development Kernel

We have rebased the Raring kernel to the final upstream v3.8 release and
uploaded. We also made a few misc config changes and added some i915
fixes.
Important upcoming dates:

• Raring:
  • Thurs Mar 07 – 13.04 Feature Freeze
  • Thurs Mar 21 – 13.04 Beta Freeze
  • Thurs Mar 28 – 13.04 Beta Release

Status: CVE’s

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

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

• 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

Due to an high priority CVE, all the stable kernels are being respined this week.
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

  Note: The week of March 28 is the week the last Hardy and Oneiric kernels will be built.

Open Discussion or Questions? Raise your hand to be recognized

No open discussions.

Dell announced today an updated XPS 13, preloaded with Ubuntu, which has a full high-definition 1080p display. It will be available for sale in the USA  and Canada, but as part of this update Dell will also be making it available in parts of Europe, the Middle East and Africa.

As we reported in November, the Dell XPS 13 is a high-end ultramobile laptop, offering developers a complete client-to-cloud experience. It is the result of Dell’s bold Sputnik initiative which embraced the community and received terrific response from developers around the world.  With Ubuntu 12.04 LTS preloaded, the machine is perfect for developers and anyone who wants high speed, brilliant graphics and smart design.

If you’re keen to get your hands on a new Dell XPS 13 Developer Edition with Ubuntu pre-loaded, check-out our web page for more details and links:

  http://www.ubuntu.com/partners/dell/dellxps

We’ll post more links allowing you to buy in additional countries as soon as we can.

Inside Canonical, we have projects going on and testers testing them all over the world. This means transferring daily builds of projects that can be gigabytes in size, to people who might not have a great deal of bandwidth.

We had been using rsync to do this, using a previous daily build as a seed so that rsync only transferred data when it found a diff. However, that still meant transferring a lot of data, as rsync’s capability of calculating a delta between ISOs could be better. Still, it did have a speedup of 25-30%.

Zsync is a project that does it better. The deltas are significantly smaller for our use cases, and it goes over http which means we don’t have to set up shell access for users.

We tested both rsync and zsync against two of our projects that get a lot of activity, and have large ISOs to transfer to testers. Here’s the results of the delta size that each tool transferred.

Target ISO Size for Project X: 1976.3mb

Age of seed ISO: 7 days
rsync transfer : 1486.7mb
zsync transfer : 531mb

Age of seed ISO: 2 days
rsync transfer : 1479.9mb
zsync transfer : 375.9mb

Target ISO size for Project Y: 1104mb

Age of seed ISO: 7 days
rsync transfer : 758mb
zsync transfer : 66.1mb

So for our use case, zsync seemed the obvious choice. There were a couple of barriers to using it though.

Our image archives are HTTPS and protected by OpenID authentication. The zsync client does neither of these things, as it has its own internal HTTP client. The project itself has not seen any activity since 2010, so the chances of a new version using libcurl getting released are pretty much zero.

There were a couple of projects attempting to update zsync, at various stages of completion, but they were either incomplete for our needs (i.e. missing authentication methods) or at the early stages of development.

So, we spun our own solution.

Zsync-curl is a fork of the zsync client that uses libcurl. To solve our OpenID problem, it allows you to set arbritary cookies, so we have a script that authenticates against our OpenID provider, and sets the authenticated session cookie when calling our libcurl backed zsync binary.

The zsync-curl packages install a new zsync_curl binary which sits alongside zsync and zsyncmake from the official zsync distribution.

All of our benchmarks show this will save a significant amount of data transfer, so we’re looking forward to getting it out to our testers around the world and seeing how much it saves in real world usage.

Meeting Minutes

IRC Log of the meeting.

Meeting minutes.

Agenda

20130212 Meeting Agenda

ARM Status

R/master: still working on last week’s “BUG: scheduling while atomic” bug in
the ipv6 stack – nothing new to report.

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

Status: Raring Development Kernel

We have rebased the Raring kernel to the latest v3.8-rc7 upstream
kernel and uploaded. Perf has also been re-enabled with the latest
upload.
Important upcoming dates:

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

Status: CVE’s

Currently we have 29 CVEs on our radar, with 1 CVE added and 3 CVEs 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 12):

• Hardy – Nothing in this cycle
• Lucid – In Testing; 1 CVE; (2 commits)
• Oneiric – In Verification; 3 CVEs; 4 upstream stable release(s); (154 commits)
• Precise – In Verification; 0 CVEs; 2 upstream stable release(s); (222 commits)
• Quantal – In Verification; 0 CVEs; 2 upstream stable release(s); (375 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.

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.

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.

Welcome to Canonical Voices. This is your first post. Edit or delete it, then start blogging!

Part of my duties as a Hardware Certification Engineer is to develop and maintain our test and bug reports. Previously these have been Python scripts containing lots of inline HTML (yuck :/), which I’m ashamed to admit it because I didn’t know any better when I initially wrote them. I’m currently in the middle of refactoring (hopefully not ref**ktoring) the scripts to take advantage of a new API that’s available for querying data from the Certification website and have decided to use Jinja (precisely Jinja2) as the template engine.

So I have a list of systems which may be in different locations and I want to sort them by location. Initially I did this in the Python code which gathered the data, using a simple .sort(key = lambda obj: obj.datacentre). Then the template code used the sorted list and all was well. Later on when reading the Jinja template documentation I discovered a way to sort a list in the template itself. I considered this to be a cleaner, more transparent way to modify the list (somebody looking at the template asking ‘why does it come out in this order’ has the answer right in front of them). So I gave it a try by changing

for hw in {%reported_hardware %}

to

{% for hw in reported_hardware|sort(attribute='datacentre') %}

and was unfortunately confronted with a traceback from the template engine:

Traceback (most recent call last):
...
AttributeError: Hardware instance has no attribute '__getitem__'

This looks like it’s saying that the ‘Hardware’ object (which I’ll introduce in a second) isn’t the type that the template engine was expecting.

Initially I defined the Hardware object like this:

class Hardware:

def __init__(self..., datacentre):
...
self.datacentre = datacentre

My first attempt to fix this involved making datacentre a property:

@property

return self._datacentre


But this didn’t seem to do the trick. Eventually I read in the Python documentation about the property built in working only on new-style classes and this set off the lightbulb

class Hardware(object):

This seemed to be the magic ingredient, and the sort in the template engine started working. I also realised that making datacentre a property wasn’t really necessary, so reverted that change.

Update: I found out that this whole problem is avoided by using Python3.x because all classes there are new-style classes. So the advice above only applies if you’re stuck with Python2.x

Last week I wrote about my first impressions on working with QML vs Android as I tried to translate a SimpleTodo application.

This week, I managed to find a few more spare hours to finish it. Not only that, but I have been able to go beyond what I had for Android. Specially on the UI part, QML makes it really simple to build in transitions and animations. I also found that defining States for the application had simplified the complexity of the program.

I don’t think that today there are official menus published for Ubuntu qml components, so I have implemented my own menu “a la” Ubuntu for phones. Here is a small video of the app:

or you can access the link here: http://www.youtube.com/watch?v=T-gDv-vDMhg

Overall, I highly recommend everyone to play with QML. Here are two very useful links if you are new to it:

• QML Elements
• Qt Quick intro

And of course, lets not forget the awesome developer.ubuntu.com pages!

The original Half-Life and Counter-Strike games were quietly released for Linux and Mac OS X last week, and as the maintainer of SteamLink, a repackaging of Half-Life: Uplink for Steam, I went out to see if the mod's files could be installed on these platforms.

Turns out there is a bug in Steam for these platforms, where it tries to launch the Windows version of Half-Life for GoldSrc mods from within Steam. However, Half-Life can be manually launched and pointed at the mod.

I have released a new version of SteamLink as a zip file. If you would like to run Half-Life: Uplink on Linux or OS X, simply download and extract the zip, and run the installer shell script. It will determine the Half-Life installation directory, install the mod, and give you a symlink to a script to launch it.