Come on in...

Packages needed to create a MeeGo image that boots to a bare X/Wayland screen (with no applications) on a reference device (eg ExoPC). Middleware packages driven by the IVI, Tablet and Handset verticals are in the scope of Core. Reference UXes are not.

Focus is on providing a minimal set of packages to allow a product be built upon. Everything required for compliance and very little more.

"I can build a compliant product from the source released from this area."

Question: How to manage the reference device Hardware Adaptation (HA) without giving special treatment?

Primarily a maintenance project with few native packages.

Tools, build-root and toolchain

Packages needed by developers to compile and create MeeGo images: gcc, spectacle, gdb, make etc.

Note that some tools like mic2 that need to be supported on non-MeeGo platforms (SuSE, Debian, RHEL/Fedora, Ubuntu etc) may be better placed in the 'External Tools' project.

Primarily a maintenance project with few native packages.

Tied tightly to Core release schedules.

Distro : Apps + Surrounds == "MeeGo, the distro"

MeeGo isn't a distro - but for the convenience of the hacking community of users on MeeGo devices it should have one. This area provides packages for apps and upstream libraries required to support them like emacs, vim, python etc. It would be made up from Apps and Surrounds. MeeGo should be the reference to be developing on for MeeGo

Surrounds is primarily a maintenance project with few native packages. Very similar to typical distros.

Apps is primarily a development project with native packages.

Related to Core releases.

SDK

Packages needed to develop Apps for MeeGo.

Primarily a development project with native packages.

Related to Core release schedules.

External Tools and Systems

Packages, documentation and IT information for build and deployment systems/packages used by MeeGo and vendors. Typically intended to run on OSes other than MeeGo. Scope includes OBS, Bugzilla, BOSS, OTS, mic2, REVS, IMG

A mix of maintenance and development packages.

Reference Tablet UX, Handset UX, IVI UX

Packages providing a reference UX layer that can be built on top of the Core. No Core packages can be touched. These projects are intended to be used not just as reference implemenatations but also as reference working models.

Requests and bug-reports to Core from the MeeGo UX project should not be treated any differently to a customer project developing a closed UX.

It would make most sense to develop the UX as an aspect of an integration project.

Primarily a development project with native packages.

They could have an release schedule independent to Core (as a vendor would).

Multiple Hardware Adaptation Projects

Community or openly managed packages needed to adapt or supplement Core to boot and run to the same level as Core on individual devices such as ExoPC, IdeaPad, N9* etc. Working with Core and a suitable CE project would be a good approach that would exercise problems faced by vendors with multiple hardware devices.

A mix of maintenance and development packages.

Integration Projects

Eventually these projects should support MeeGo overall by highlighting and helping to resolve interoperability issues based on different MeeGo releases or form-factors.

Handset Community Edition / CE

Packages from Core, the N9* HA and one (or more) Reference UXes as well as CE-specific packages.

The CE project acts as a 'Reference Vendor' http://mer-l-in.blogspot.com/2011/04/meego-de-that-is-how-you-do-it.html

Tablet Edition

As with the Handset CE but using different HA projects. The ExoPC MeeGo images should be released by this project.

This project too should be contributing to the 'Reference Vendor' concept.

IVI Edition

As with the Tablet Edition but for IVI.

Futures

What else? Well how about some future gazing?

MeeGo Python

A set of packages supported by MeeGo. Device vendors who see the value in QML apps with python as the underlying language may include this in a "Compliant" device under an appropriate "MeeGo" label.

Mini-Glossary

native packages

MeeGo tends to use upstream packages wherever possible; but of course some areas will develop new software - these packages are known as 'native' packages since the code and the packaging are managed at the same time.

MeeGo : Infrastructure

2011-08-03T13:20:00.000+01:00

As mentioned, we want MeeGo projects to use and validate the interfaces and procedures we expect our customers to use. To support this we should provide an operating environment to enable that goal.

An accident of history means the infrastructure we use is already set up in a way that would allow us to replicate some aspects of a vendor's view of MeeGo; we should take advantage of this and as well as clarifying the organisational lines between projects we should strive to replicate the technical interfaces too.

In order to support this new project setup I propose we *don't* change our infrastructure in any significant way.

One key objective (IMO) is to help vendors deliver MeeGo products. This means ensuring that when they deploy systems like OBS, OTS, Bugzilla, BOSS, REVS and others they can get up and running quickly. It also means that they should be able to interoperate smoothly with the MeeGo projects identified above.

We have 2 OBS deployments - we should expand this to include additional systems such as Bugzilla and we should live through the "remote system" issues we expect customers to face.

MeeGo and the hacker community

2011-08-03T13:17:00.001+01:00

We know that : "The MeeGo project provides a Linux-based, open source software platform for the next generation of computing devices." (https://meego.com/about)

So from that I suggest our target customers are pretty obvious: Device manufacturers. Not individual OSS community hackers.

I suggest that we hackers (I consider myself a community hacker as well as a paid MeeGo contributor) should approach MeeGo by recognising that:

MeeGo is not aimed at us -- Sorry but it's not.

Think about it - we don't want it to be aimed at us. We want devices running MeeGo that we can hack. So lets help make it super-attractive to device vendors; then we get to buy their hardware and do what we do best ... hack on it!

Having another Debian/openSuSE/Fedora isn't going to help - if device vendors wanted this then they already exist. MeeGo *has* to be different.

But this doesn't stop us from building cool stuff using MeeGo. Nothing is stopping us from contributing back.

However, by letting MeeGo Core focus on delivering to device vendors we in the hacker community can set up projects like the N900 CE where we have *much* more freedom to construct a real distro. MeeGo Core by itself is not much fun - CE is where the cool stuff happens ;)

MeeGo : Lead by example

2011-08-03T13:14:00.000+01:00

One of MeeGo's biggest failings IMHO is related to its customers.

We expect our customers to work with us and against our systems: OBS, BZ etc - but do we even know how that 'work with us' is supposed to work?

We expect our customers to track bugs in our Bugzilla and link to their private Bugzilla. How exactly?

When a problem is seen in MeeGo we expect a bug report and/or a patch - yet we can't even make that work ourselves; our UX team are granted special rights that customers don't have. Certain patches appear referencing private bug trackers (eg B.O.O bugs) - if Intel can't get this right then our customers have no chance. The only way to solve this problem, and to keep on top of it, is to ensure that significant parts of the MeeGo project act as if they were external customers - still very much a part of the open community but experiencing the social and technical interfaces that we expect customers to use.

I propose we handle this in 2 ways:

CE, UX and Tools to become discretely scheduled MeeGo Projects
Seperate OBS, BZ and REVS infrastructure for Projects and Core
(reviewed in more detail later)
No special handling of any Projects (eg UX)

A more powerful long term solution is to take the opportunity that the Community Edition project offers to fulfill the role of a 'reference vendor' and openly demonstrate how effectively MeeGo can deliver. We should use this to explain, demonstrate - and validate - how real vendors should interact with the MeeGo project at all levels: features, bugs, processes, release management, communication and even infrastructure.

Essentially we should make "How to be a MeeGo Product Builder" a MeeGo Project deliverable.

MeeGo : Evaluating MeeGo

2011-08-03T13:12:00.000+01:00

MeeGo is most likely to enter an organisation via an exhaustive evaluation process.

We need to understand where those performing the evaluation will have come from. Clearly many will have significant experience in the embedded space and there are some good projects in MeeGo supporting these experienced developers in establishing a prototype MeeGo port to their hardware.

What we're missing though is a solution that allows this 'one man hacker' type evaluation to scale into a multi-person team evaluation and demonstrate MeeGo's suitability for an international, multi-team, delivery organisation with hundreds of people.

MeeGo can do this already - for free. So why aren't we shouting about it?

MeeGo: Systems and Processes

2011-08-03T13:10:00.000+01:00

Vendors need much more than lots of source code and a toolchain: they need clarity, consistency, guidance, processes and systems.

Whilst we've looked at clarity at the package level there are a lot more areas where guidance would be welcome; setting up an end-to-end delivery system with various organisational units is a daunting task.

MeeGo has knowledge in this area and can - and should - be delivering more of what device manufacturers (and those in the ecosystem around them) need to prepare themselves to make these MeeGo based products.

Whilst relatively straightforward, probably the most valuable initial delivery would be a consistent set of terminology. This will establish a baseline for communication and improve comprehension of the entities in the MeeGo world and how they relate to previous experiences.

We already provide and suggest some systems: OBS, OTS, BOSS, Bugzilla, IMG, GIT, REVS - the next step is to suggest how these are deployed and configured. This would improve deployment speed and reduce "time to productivity".

Following on from this we can provide information to support sizing estimates for various aspects of the deployment; from build and test systems to training.

Finally we can outline proven approaches to integration; handling code flows from GIT to OBS; bug handling strategies; managing daily and weekly snapshots; MeeGo synchronisation schedules.

This area is likely to be seen as the domain of SIs - however MeeGo will benefit from establishing a reasonably consistent approach across the board; having a 'preferred' deployment/integration solution will reduce variation and hence support costs (both to MeeGo and upstream tools like the OBS); confusion is less likely to arise from mismatched expectations; Vendors and SIs will be able to interoperate more easily;

Proposal:

Support the MINT (MeeGo Integration Tools) project

Deliver a Vendor Manual

MeeGo Core : focus

2011-08-03T13:07:00.000+01:00

MeeGo does deliver a great set of packages which experienced teams can use as an excellent baseline for building product.

What is not needed is yet another general purpose linux distro where each vendor has to interpret the structure and determine for themselves exactly which packages belong where.

Instead we should be clear about what packages the MeeGo project delivers : A tight baseline which can be relied on when delivering a commercial product.

When approaching MeeGo it is not at all clear what is required for compliance and what is part of the sample distribution that vendors are expected to either replace or significantly change.

I suggest MeeGo package areas are clarified and redefined and that interfaces between them (especially reference projects) are made more explicit.

In particular MeeGo should offer a Core which provides a minimal set of packages - enough to build a compliant product. The processes used in Core must obviously be appropriate for MeeGo development - but they *must* also be appropriate for customers too. Around the Core MeeGo will have a number of associated projects forming a well-defined structure around a "bullseye" and not a fuzzy melting pot. These are very much part of the MeeGo project but may only be loosely tied to the release schedule of Core.

Tasks :

rip out what's not neeeded from Core

create UX and Tools projects

create an open MeeGo distro built on these projects

Benefits:

Smaller groups are easier to manage

Permits properly exploring the vendor:MeeGo relationship at the
operational level

Much easier for alternative 'reference' solutions to take root

Restructuring MeeGo : Executive Summary

2011-08-03T12:57:00.000+01:00

Whilst the MeeGo Project has the potential to be incredibly beneficial to the linux device market it can and must do more to fulfill that aspiration.

MeeGo is in danger of becoming "Yet Another Linux Distro". As with any venture; in order to succeed MeeGo must first identify and focus on satisfying its customers.

Identification is not too hard : organisations involved in building devices based on MeeGo.

Satisfying them is harder : these organisations are not your typical linux hackers, nor are they linux-friendly IT teams. They are software product delivery professionals. They care about more than just the source that comes out of MeeGo - they care about managing their build and delivery environments. The last thing these people want is to re-invent the wheel; they are under pressure and need as much help as they can get - automation, QA, progress reporting, minimising overhead and cookie-cutter deployments.

Delivering a repo full of packages is a great start but it's not enough .. not by a long shot.

This is the first in a series of few articles that make some concrete proposals.

(Thanks to the community people who've helped review this : I'll put the text onto the MeeGo wiki for further comment and editing).

MeeGo DE - THAT is how you do it ....

2011-04-27T12:48:00.001+01:00

Over the past several weeks I've been hitting one concept over and over again: "reference".

I'm talking here about the idea of a reference implementation; and I don't mean something so comprehensive that it's almost useless... rather a manageable set of information aimed at easing entry into a project.

I've been accused of being a bit long-winded :) So let me offer a short proposal:

Justify the DE project by extending the "DE Project Vision" to include "Be a reference vendor". Extend the deliverables to include documentation about processes, organisational layout and tool usage. Test, challenge and improve the MeeGo <-> Vendor interface.

I put this to Carsten and Jukka a while ago and they were very positive about it - so if it sounds intriguing then here's my thinking:

MeeGo is (or should be) aimed at vendors. So what is a vendor? Or perhaps, in this context, what aspects of a vendor are we interested in? I think the following three areas are relevant:

The Veneer ("Value Add Layer" if you're marketing a device)
Hardware Adaptation
Contributing Back (A phb may prefer to hear: "Influencing MeeGo's direction")

As a vendor newly arriving at MeeGo I am going to need to work in one or more of these areas - so what do I do? What systems do I need? How do I setup teams, OBS projects? How do they interact with MeeGo? What testing processes should I use? What tools and systems are already available? How do I avoid re-inventing the wheel? How do I link to the core OBS? How do I get a feature included in the core?

Answering these questions correctly is vital if a vendor is to effectively assess the cost of operating in the MeeGo ecosystem; and that assesment should influence their decision to work with MeeGo. Quite simply: the lower we can make barriers to entry, the more vendors will join MeeGo. Not only that; if we can identify and resolve problems with them then that will improve satisfaction. It is also worth remembering that many vendors will be new to working in the open - using the reference project may help to overcome 'shyness' be it cultural or confidentiality based.

This is not just about vendors either. MeeGo as a project has to support the vendor ecosystem - and whilst we do want a diverse community out there, we don't want to support needless variations in process or even terminology. Providing a "suggested way of working" and ensuring that all our tools and processes work with it means that we can minimise the cost of these interactions from MeeGo's point-of-view.

MeeGo also provides interfaces to these vendors - but has no real mechanism for reviewing or testing them (although I'd like to address that in my BoF session at MeeGo 2011). For example

the handling and communication of significant API changes during development;
simple operational communication;
how are vendor products supported *after* a MeeGo release?
how should vendors operate near releases (forks);
I need a change to a MeeGo component : it's not going to be accepted this release; what do I do?

DE operates in all of the layers I mentioned but it's not clear what activity is related to what layers. I'd like to see:

DE provide some clarity around the three roles: particularly a review of the OBS project structure and role-specific processes.
Clear product-oriented and release-managed deliverables in the veneer layer with testing and automation
Documentation of a requirements driven approach to MeeGo core contributions
Documentation of a requirements driven approach to hardware adaptation

Of course the objective of these deliverables is to support new vendors and contributors to DE/MeeGo; not to overburden the contibutors. bearing in mind that

I think the success criteria in this ares would be if any organisation can quickly and easily setup a new initiative to thoroughly evaluate MeeGo for a new product.

There are other areas where we can support vendors by pursuing this model; the use of the MeeGo community OBS mimics the separation between the MeeGo OBS and the vendor's internal OBS. This allow issues dealing with the relationship to MeeGo to be examined openly: what is the recommended link to the core OBS; how are vendors impacted by downtime; what's the best approach to provide a reasonably stable MeeGo base to build the 'veneer layer' on during a sprint whilst still allowing the vendor to be aware of emerging issues in Trunk.

MeeGo also has other system tools: BOSS, REVS, IMG and OTS are freely available and were designed at Nokia using their product building expertise - how can we offer these to the MeeGo vendor ecosystem to once again reduce cost and probably more importantly: time to market. These tools are used in MeeGo core - but they are not documented or discussed (and are probably not relevant to vendors anyway since their business goals are different). Using them in DE allows increased public scrutiny.

So here's another success criteria (for both DE and MeeGo tools): is DE using MeeGo tools to deliver their product? Do the managment reports from REVS provide useful data? Is BOSS automation effective and sufficiently low-overhead? Does OTS work in resource-limited environments?

Finally - you have to ask what the point of the DE project is? I think if it can be held up as an example of "How to work with MeeGo" and has real deliverables beyond supporting an aging device then it provides a tangible benefit to everyone in MeeGo.

A little post-script too : whilst I've focused on DE here this concept applies to a lot of what's done around MeeGo. Opensource succeeds because we stand on the shoulders of midgets - a *lot* of midgets. We should each aim to ensure that when we 'deliver' something to the opensource community we ask "how easy have I made it to let someone else improve on this?"

What now for MeeGo?

2011-02-12T09:59:00.001Z

So Nokia has dramatically reduced commitment to MeeGo and has cited,amongst other thinks, MeeGo's inability to deliver a focussed baselinewith sufficient speed. I happen to agree with this failure (and givenNokia was a significant part of MeeGo's management I don't thinkthere's a blame issue - more a how do we fix it issue)

Assumptions and observations:

MeeGo is intended to provide a viable but focussed baseline upon which vendors can build compliant products; not to be an expansive and 'complete' linux distribution.
MeeGo has limited dedicated resourcs and focusing them on a reduced MeeGo core will improve quality.
MeeGo's main customers are not end-users - they are device vendors : they should be the focus of our core engineering team's design, delivery and QA effort.
MeeGo core does not appreciate the difficulties a vendor has in tracking MeeGo;
A visibly secure development model is important to the perceived integrity of MeeGo - so visibly restricting write access to the core is important.

Proposal:

MeeGo Core is confirmed as not being a linux distribution
An open MeeGo project (openMeeGo?) is created on the community infrastructure to provide a reference MeeGo distribution
Packages not *essential* to the delivery of a compliant MeeGo Core are moved into the community OBS (emacs, vi etc - maybe even the reference UXes) where they are available for use by development teams and end users.
"openMeeGo" acts as a reference vendor and provides a forum for reviewing and improving the processes MeeGo uses to communicate releases
MeeGo community (which includes core developers) has a significantly lower barrier to entry.

MeeGo Community Development: Apps, Surrounds and the Community OBS

2011-01-27T01:19:00.000Z

So... lets say we have some device that run MeeGo; what else canit do? Where are the apps?

Apps - the area formerly known as "Extras"

Borrowing Andrew Flegg (Jaffa)'s mission statement for MeeGo CommunityApps: we need to ensure a vibrant and quality area for community opensource software.

So MeeGo Apps is the community app store and follows on from thesuccesful Maemo Extras.

It allows app developers to build MeeGo compliant (and other) apps anddistribute them to users.

What makes Apps different from a 'random repository' is the communityQA process that is applied; the objective of this QA process is topermit users to trust the apps and to deliver a collection of appsthat a commercial vendor could enable on a shipping device (as Nokiadid with 'Maemo Extras' on the N900).

Clearly then, there needs to be some processes (and automation) todefine how QA checks are carried out and what to do when certainevents occur. We already have a process automation sytem (called BOSS- it's is being developed by Nokia and is essentially an integrationof various OSS libraries) - now we need to decide what processes andcriteria we use to manage and promote apps. Initially I suggest westart with the Maemo Extras process and refine that.

When we talk about process we are also talking about policy. I'vediscussed this below and quite a few of the points apply to Apps.

Now, it's not yet clear what OBS targets Apps should buildagainst. Currently we have:

MeeGo:1.1:Core
MeeGo:1.1:Core:Handset
MeeGo:1.1:Core:IVI
MeeGo:1.1:Core:Netbook

These correspond to the MeeGo Core and then a number of UXes. Howeverthere are plans to consolidate them in the main MeeGo OBS - but howshould the Apps area look? Should a handset user be presented with appswhich were only intended to run on a netbook? OTOH is this anything todo with the repo and build target - should it be determined bymetadata and selectively presented by the download application?

Well, until this is resolved, an app developer simply needs to enableeach target that the app supports to make it available in thatrepository.

I think the discussion up to this point is fairly simple anduncontentious; we can start to address the issues mentioned and just get on with it and start to deliver MeeGo Apps :)

However, as mentioned, the Apps area allows both MeeGo-compliant andMeeGo-extra applications. MeeGo-compliant apps are those which onlyuse libraries in MeeGo core/UX; MeeGo-extra apps have a little extraopen-source goodness sprinkled in... Surrounds.

MeeGo: The Linux Distro

Before I tackle 'Surrounds' lets step back a little:

Since MeeGo was announced around a year ago I've been interested inhow development happens around MeeGo as well as in the centre. Thefollowing is intended to be a discussion document; there are clearlysome large gaps and I expect some of my proposals to be shot down -but I really hope that only happens when better ones are proposed!

In order to address this I think it's important to ask... what is thepoint of MeeGo? Well, IMHO, MeeGo is primarily a modern linux baselineupon which commercial mobile computer products can be delivered.MeeGo's main customers are not end-users - they are device vendors;*they* should be the focus of our core engineering team's design,delivery and QA effort.

So MeeGo clearly has a focused development area with the main OBSsupporting the development and delivery of the MeeGo core systemsoftware and reference UXes.

Of course MeeGo is also capable of being a wonderful and open linuxdistro in its own right. However I personally think that to be asuccess, the MeeGo core needs to focus on the primary goal and allowmore of the "linux distro" side to be managed as a surroundingproject.

Incidentally, in my day job I care a lot about how MeeGo presentsitself to us as a vendor. I think it would be a good thing for MeeGoto have it's own "reference product" built around the core that itoffers to vendors. This would expose issues like:

How does MeeGo communicate significant upcoming changes to it'scustomers?
How do we deal with package naming clashes?
How much of MeeGo is needed for compliance vs the parts that areneeded to make a reference implementation?
With more than one community product: how connected are devices?

So, 'Surrounds' is a proposal that aims to provide a collection ofopen source libraries, tools and applications that support thebuilding of collaborative bazaar-style applications and yes, maybeeven MeeGo distributions.

Whilst I don't think this is an immediate change, I do think it's aninteresting direction for MeeGo to take that may allow more focus onthe core deliverables.

In the meantime lets look at this "extra open-source goodness" Ipromised:

Surrounds

As we know, the open source world is a world of sharing; we regularlystand on the shoulders of our peers and it's considered very bad tasteto just 'bundle' a library into a monolithic application. (Notice howI didn't mention any kind of compliance programme by name - aren't Igood!)

Surrounds provides a collection of libraries and tools that encouragesthis best practice way of working in MeeGo and delivers MeeGo-extraapps. The most obvious area would be for languages like perl, pythonand ruby. These languages have large numbers of useful libs thatclearly are not going to be present in core MeeGo. Of course therewill be many other tools and applications that would also be at homein Surrounds.

Over time, packages may migrate into core MeeGo and equally, some aregoing to be deprecated. Hopefully Surrounds makes both of thoseactions a little easier but we do need to decide how we handledeprecation/promotion of applications/libs between core and Surrounds.

There are many complexities when dealing with a collection of packageslike this:

QA and Releases

The fundamental question is "How is Surrounds QA'ed and released?".

This is a significant undertaking and needs a lot of resource andusers. This alone means that Surrounds should probably start offslowly and ramp up as MeeGo users and developers arrive in largernumbers. The important thing is to prepare for the main issues we'relikely to face.

I propose that Surrounds is actually only populated on an "as needed"basis; tools can be submitted directly but libraries have to be neededby a tool or by an application submitted to the Apps area.

Upgrades and concurrent installations

For example: let's look at a device that has MeeGo 1.2 installed on itand an application "Wowee" built against an imaginary libvisual-1.0which is in the Surrounds-1.2-A stable release of Surrounds.

9 months later many libraries have been updated and developerswant to use the latest versions... it's time to release a newversion of Surrounds-1.2. Sadly libvisual is up to version 1.0awith a minor tweak which would break Wowee; not only that butthe Wowee developer has gone awol (so there's no-one to testit) and no-one's stepped up to update it. Even worse there are50,000 users using Wowee which is working like a dream.

Looking at the large number of apps in Maemo Extras I thinkproblems like this will arise and are beyond the resources ofthe community to handle at this point.

A technical solution may be that when Surrounds-1.2-A is installed itgoes into /opt/surrounds/1.2-A/... and any apps use the appropriatepath to find their dependencies.

This allows apps that use libraries from Surrounds-1.2-A andSurrounds-1.2-B to be installed concurrently even if they usedifferent versions.

I'm not sure how Surrounds-1.2 handles upgrades from MeeGo 1.2 to 1.3.

The message however is that there are many issues like this that itwould be good to identify in advance. Just ask a maemo developer aboutthe "optification" hack :)

Porting vs Maintaining : A MeeGo partner

When it comes to populating Surrounds we need to look to the largerlinux ecosystem.

Some tools and libraries will have comitted maintainers who have timeto monitor their packages and fix bugs and security issues in a timelymanner.

This is the classic distribution 'maintainer'role.

Some libraries won't. Developers will simply need a particular libraryand 'grab' a source rpm that looks like it's good-enough. They throwit at the OBS and a few minutes later have an installable package fortheir application. This is what happens in Maemo Extras.

I call this activity 'porting'.

The problem arises when another developer does the same thing afew weeks later with a slightly different version of thepackage. This may cause the original app to fail.

Equally, none of those developers want to commit to maintainingthe library. So when a security issue arises, no-one is readyto update the package.

I'm actually a little concerned about prolific porting - and sadlythis is the bit that gets the fame and glory : "look how many packageshe's ported". The truth is that this doesn't bode well for MeeGo inthe long run.

My suggestion for this group of packages is to nominate an upstream orpartner distro with a good security record and a wide base ofpackages. Surrounds releases would closely track this distro (and willlikely differ from core MeeGo). Packages taken from this distro wouldbe fast tracked as 'ported' rather than 'maintained' and only minimalpackaging changes would be allowed. This would allow Surrounds toleverage the partner-distro's security efforts (and hopefully offerbenefits to the partner in return).

For obvious reasons I propose openSuse as the partner distro. (For therecord I'm a Debian guy - but lets be sensible here!)

For equally obvious reasons this is a political minefield :)

Some random policy questions:

There are a lot of policy considerations for the community; some Iwrote in a bit of rant (forgive me Shane). Some apply to Surrounds andApps, some to the OBS in general

Licenses: OSI only licenses? GPL3 (considering the "promotionto core" target).
People: What's the process for absent devs? If someone says"hey, lbt, let me upload a new version of that library Shaneuploaded" ... do I just let her? What if there's a securityissue in it? What if you've not been seen in 3 months? Domaintainers need to demonstrate reliability to handle timelyupdates?
Legal : Do we accept mp3 players? libdecss? What about porn?What about apps with a rather rude splash screen? Any patentissues? (Don't forget the system physically lives in the"land of the free" so is subject to state seizure by theRIAA).
Commercial: I've had commercial organisations enquire about usingthe community OBS. I've had them ask to sponsor it. How do we dealwith this? My first reaction is "no commercial work"... but why not?
Quality: Do we insist on a valid bugtracker being identifiedfor all Surrounds packages? Must it proxy via a bmc#?
Packages scope: Where's the ITP?
Can we rebuild MeeGo with some different compiler flags (thinknon-ssse3 ... yay ... I can run MeeGo on my AMD desktop at last!)
Do we sign any of the community repos? What does that mean?
Acceptable Use Policy : at what point do we ask users to stopdoing what they're doing?
Non-MeeGo targets? When Smeegol becomes Sogmeel will we allow itto be a target?

Again the message is "there's a lot to think about".

The Community OBS

We have a MeeGo Community OBS already; and it builds apps for MeeGo.

It is currently managed by Niels Breet (X-fade) and I (lbt) - but weneed more help. In part this whole post is a way to structure whatwe'd like to achieve and to make it easier to identify tasks.

Structure

So what project structure do we need? We've not assumed MeeGo at thetop level namespace to allow us to support additional distros such asFremantle and hopefully others.

One common use for structure is to provide a QA route. Packages gofrom some sub-project in a developer's home: area to a 'Team' area andthen into a Testing area. Each transition is subject to policy andquality checks. Defining these workflows and structures correctly willmake life easier.

Team Areas

It makes sense for teams to have collaboration for things like KDE,Gnome, Python, LibreOffice, Emacs etc. This would allow more thoroughtesting to take place before releasing either to Surrounds or Apps

However, what's needed to form a team? Can anyone just step up andclaim Team:KDE or should we ask for some relationship with upstream?Do we just want to assess a proposal? Who does the assesment? Do weannounce this and give time for the community to raise objections orconsiderations?

PPAs

The general policy for *home* projects is "OSI, nothing illegal anddon't take the piss". We may (or may not) need a more formal one :)

Certainly these PPAs offer developers a huge amount of freedom. Theycan start by uploading and building a package in a "home" directory(which can have a structure underneath it for multiple projects). Thiswill allow them to build against any of the main targets; anygroup/community projects or even any other community member homeprojects. Oh, and they can use each others code as a baselinetoo. Once built the packages are automatically published to a repo onthe community downloads server.

AFAIUI this is a lot like the Ubuntu PPA solution (hence the heading).

At that point developers can stop if they want. They have a completeset of repositories (1 per subproject). No painful QA processes forthem and no 'fragmentation' for the MeeGo community. But equally theserepo(s) will needed to be manually added to a device in order for itto appear in any apt-get/zypper/yum etc. Oh, and the Apps downloaderteam really should pay attention here.

A huge benefit here is that to for a user to get at a developmentversion of an application they use a specific repository, not amishmash of randomly unstable packages (like the Maemo Extras-develarea).

MeeGo Targets

What MeeGo targets do we support?

MeeGo 1.0? Really? Does anyone use that?

MeeGo 1.1 and above make sense. But what architectures? As released isfine - but what if there are community rebuilds of non-ssse3?

Also, when MeeGo releases distro updates, do we just rebuild all apps?What happens to QA at this point?

MeeGo Snapshots

One area to look at is how often we import MeeGo snapshots - and incurthe rebuild cost for any projects targetting them.

MeeGo Rebuilds

Frankly I'm a bit fed up that after a year I can't run MeeGo on mydesktop. It has an AMD phenom chip and an ATI card - both wellsupported in the opensource world. It's time to build a communityMeeGo :)

Do we need a community version targetting the DublinBook? What aboutthe O2 Joggler? Are there any policy issues here? Can anyone ask forthis - there's potentially a lot of resource tied up doing this kindof rebuild.

Surrounds

What projects are needed in the Surrounds area? Certainly someunstable->testing->stable cycle makes sense; but this is not likely tobe finalised until the workflow is understood.

Fremantle

The Fremantle migration. Mmmm. Well it might happen at some point :)

Actions and Ideas

Establish a task-force/group to coordinate and deliver activity andto act as a communications hub.
Design and implement OBS project structures and targets for Surrounds,Apps, Teams and (suggestions for) home areas
Design and communicate process/policy for putting packages intothese projects and migrating them
How do packages move from Community OBS into MeeGo core
Implement and automate stuff
Structure and enrich the outstanding issues outlined above
Design project structures
Work up a proposal which sees MeeGo split into Core and Distro
Copy this list into a Wiki so it's actually useful

Are Intel subverting MeeGo.com?

2010-08-11T20:14:00.003+01:00

Well... there's a "challenging" blog title :)

Please read on and allow me to explain.

Intro

So what's making me risk offending one of the powerhouses behind MeeGo?

First off, let me say that I think the answer is "No"; but I do think there's a problem and it should be solved.

So having hopefully gotten your attention; what's the problem? Well, quelle surprise, it's that inconvenient "openness" again.

MeeGo is an open distribution; I don't think that's really in doubt. However there have been many discussions on what makes something open and I'd like to add another: "Inclusiveness".

For the record : In the remainder of this post I've included issues that I've seen raised that I may not personally support.

Issue

The question is ... who gets to use the builds that are produced at meego.com? Well, technically "anyone", but practically "only people who've bought recent Intel hardware".

Why? Because the MeeGo.com builds are optimised for the Intel Atom processor; not a generic x86.

So what's the impact of this?

Pros: Less CPU usage for some functions (3D and audio codecs AFAIUI get +20% performance on certain tasks)

.... that's it

Cons. Well machines with a non-Atom CPU running MeeGo netbook edition may boot up but often fail to run. Additionally non Atom machines can't easily develop for MeeGo (eg the image building app uses ssse3 instructions inside somewhere.)

Impact

If a developer wanders over to look at MeeGo and sees that she needs to buy an Atom netbook to run it then: "Oh, I need special HW to run it? Ubuntu just runs on my laptop. Bye MeeGo, hello Ubuntu."

Making it hard to use MeeGo is *not* inclusive.

Details

The way MeeGo is built any binary could contain SSSE3 instructions; however which ones actually do depends on the optimisation flags used, the compiler version and the source code and and a change in any of them can add or remove instructions.

Essentially it's "random" - or at least not humanly determinable if a given application will suddenly choke on non-Atom hardware.

In irc Thiago scanned the Qt binaries to try and find any SSSE3 instructions. When he ran a quick and dirty analysis he couldn't find any SSSE3 instruction in QtCore and QtWebKit; and found a total of 4 SSSE3 instructions on QtGui - that's many 10s or 100s of Mb of binary code and only a handful of instructions.

So given the entirety of Qt uses *4* instructions there was a challenge to the "performance benefit" it offers by using these options "across the board".

Postition

Given MeeGo.com is supposed to be open and to minimise barrier to entry this exclusion seems wrong.

MeeGo is managed by the Linux Foundation and I was under the impression that we had a Linux Foundation managed build service at build.meego.com; so why are we building for exclusivity and not inclusivity?

Fairness

My understanding of the business model is that Nokia and other vendors would have an internal OBS to allow them to tailor and optimise MeeGo for their commercial product

MeeGo's model is that Intel, Nokia and others (as vendors) have their own internal build service (OBS) to optimise for a commercial product so why does Intel get to optimise for Atom on the MeeGo.com build service?

Why do we optimise for only Atom machines on the MeeGo.com builder? Why isn't that done on build.meego.intel.com? Is Intel essentially using MeeGo.com to make "the Intel MeeGo" not "the community MeeGo"?

Obviously, as a fallback the community OBS is a potential place for this generic build but that was *not* the point. We have often been told that MeeGo *is* the community.

Counters

One point has been of the "cost" of the shared infrastructure and Intel employees having said that Intel should not be burdened with the cost of supporting other arch/platforms/builds.

There's some validity to this - and I don't think the community would object in the slightest to seeing optimisations for Atom made available *as well* as a generic build.

One question is: Is MeeGo an open and inclusive distro? Who dictates the commercial aspects of the "shared resources" and who gets to dictate what is and is not on the agenda.

One argument has been "Intel contributed the hardware and they want it optimised for their platform"; However that's not a community platform; that's a vendor specific build platform.

And are we seriously saying that a vendor producing a version of MeeGo for a non-Intel based x86 device is going to have a problem rebuilding with appropriate gcc flags?

Proposal

Add a 'generic x86' target to the MeeGo.com build architectures. This will form the basis for more inclusive MeeGo variants.

Allow the builder to create targetted binaries for some hardware; this is going to become a requirement as more hardware appears.

As we know: 'optimized for Atom' sells and attracts developers to the platform and a set of development hardware, etc..

But surely we can be "optimized for Atom" without excluding non-Atom users.

This means anyone with a non-Atom device could at least start MeeGo on eg an AMD desktop. As Arjan says: "I and several of my coworkers run MeeGo to develop MeeGo" "it's still very much intended to be a quite complete *client* PC linux"

http://lists.meego.com/pipermail/meego-dev/2010-April/001318.html
http://lists.meego.com/pipermail/meego-dev/2010-April/001392.html

Works for everyone

Well, isn't that the job of MeeGo.com?

MeeGo.com is supposed to be open and to minimise barrier to entry - lets help it do that

Conclusion

The point is that MeeGo should be doing a generic i586 build

Not Intel, MeeGo

Open Letter / Proposal to allow Maemo on the MeeGo Community OBS

2010-06-16T14:18:00.000+01:00

This is an open letter to the whole MeeGo community and on behalf of the Maemo development community. The purpose of this letter is to ask the MeeGo community for their permission to bring Maemo build targets (currently Fremantle eventually Harmattan, Diablo, Chinook?) to the MeeGo Community OBS and to ask the Maemo development community for their support in this project.

*Please discuss on meego-community mailing list*

I would like to emphasise that this is a Maemo Community initiative and is not being pushed by Nokia.

At this point we are not aware of any similar initiatives related to the Moblin community but we would fully support any that arise.

The Maemo community has built up around Nokia devices which, in many ways, are amongst the most open devices available in their class. There is a passion for openness in the Maemo community and we know that the future for this family of devices lies with MeeGo.

Many of us are looking forward to MeeGo and are keen to transition as smoothly as possible.

However our devices are not fully open and developing for them has dependencies on vendor proprietary binaries which would need to be available on the build service. This would mean putting closed binaries on the MeeGo OBS and having a part of the MeeGo Community OBS functionality being 'restricted' to Maemo developers.

Naturally we recognise and respect that MeeGo is an open source project and there may be ideological issues in allowing closed binaries into the ecosystem (even though they're just for build/linking). We also recognise the risk of "opening the door" to closed binaries and suggest that this arrangement could be agreed as a one-time "grandfathering in" (http://en.wikipedia.org/wiki/Grandfather_clause) situation for the Maemo community.

However we also feel that the benefits of supporting a smooth transition for the vibrant Maemo development community would be worthwhile both for MeeGo and Maemo:

developers would be able to use the OBS' natural ability to target Fremantle, Harmattan and MeeGo from a single location. This would bring more developers and their applications to MeeGo sooner.
many of the same people in the Maemo and MeeGo community teams look after the Maemo Autobuilder and the MeeGo application OBS. Our limited volunteer time would be used more effectively on a single platform instance.
resources earmarked for Maemo could be added to the MeeGo estate and would naturally be used at peak efficiency as Maemo demand decreases and MeeGo demand rises.
new Maemo community Quality Assurance processes would evolve around the shared OBS and could assist the development of MeeGo QA processes.

and perhaps most important of all:

users of existing devices could expect a significantly longer maintainable life from products built on a consolidated build service and could look forward to their applications being available on MeeGo as soon as devices become available.

The maemo.org buildservice already has a 'proof of concept' instance of the OBS which allows the Fremantle target to co-exist with a MeeGo target and we already intend to use this as a basis for the MeeGo community OBS.

The proposed solution *must* allow MeeGo community users to use the MeeGo Community OBS without any reference to Nokia closed binaries; this facet of the service should be entirely optional.

Equally the legal issues around the closed binaries require an EULA related to demonstrated possession of a relevant device. This can be handled in a similar manner to the Maemo Autobuilder service; ie registration of a serial# to a developer account.

The proposal therefore is:

To provide the closed binaries as a build-target repository (probably DoD for those who know and care) on the community OBS.
To grant ACL based access to this repository based on acceptance of an EULA
To *not* require any such EULA for 'MeeGo-only' accounts on the service

I've run this by Tero Kejo in Nokia and he's very supportive of the idea.

From:

David Greaves / lbt
   Community Member and build systems guy.
Niels Breet / X-Fade
   maemo.org webmaster and autobuild owner
Carsten Munk / Stskeeps
   maemo.org distmaster
Andrew Flegg / Jaffa
   on behalf of the Maemo Community Council

I like crashes like that...

2010-05-23T22:54:00.000+01:00

So I'm ssh'ed into my kerberos kdc server and at the same time I'm playing with nfsv4 and I clearly push the boundary somewhere and my NFS server has a kernel BUG and goes wibbly... ctrl-alt-sysreq S-U-B wibbly...

Now the kerberos kdc is a VM on the nfs server; which also holds the home directory for my desktop. So my desktop hangs hard.... toast.

I wander over to the nfs server and shut it down as best I can and reboot it.

It comes back... and as it does my desktop wanders into life, my ssh session to the VM is still active; nothing happened.

I like crashes like that :)

Kerberos and ssh

2010-05-22T22:00:00.000+01:00

So you're setting up Kerberos and you've got a ticket with kinit

the target has a host/@REALM

but ssh fails with:

debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context

Well the first thing to realise is that you're probably not using gssapi-keyex, you're probably using gssapi-with-mic (see http://www.ietf.org/rfc/rfc4462.txt if you want to know more).

Running:

/usr/bin/sshd -D -ddd -e

may give

debug2: input_userauth_request: try method gssapi-with-mic
debug3: mm_request_send entering: type 38
debug3: mm_request_receive_expect entering: type 39
debug3: mm_request_receive entering
debug3: monitor_read: checking request 38
debug1: Unspecified GSS failure.  Minor code may provide more information
Key table entry not found

The problem I has was a typical one in kerberos setups... DNS and name resolution has to work.
In this case a simple entry in the hosts file with a non-fqdn and there are very few clues.

So maybe you'll google some of that and it'll help... :)

OBS and Fremantle ... huge success :) and HELP!!!!

2010-05-16T11:38:00.000+01:00

As you may know I recently volunteered to setup a community OBS in my "spare time" (hah, right!). This is a progress report because I've reached a significant milestone... the following 193 applications have been built from 'Extras' most on both ARM and X86:

accdisplay, acl, actman, adblock-plus-1.0, adflashblock-css, alienblaster, anarchism, attitude, attr, audiofile, avahi, battery-eye, belltower, blubbels, bluetooth-dun, bluezwitch, brainparty-data, burgerspace, catorise, clutter, clutter-gtk, copernicium, crimson, currencyconverter, datetoday-home-widget, dbus-python, de-lite, dialcentral, doom-wad-shareware, easy-deb-chroot, easypark, ejpi, fapn, feedingit, feedparser, flac, flatzebra, fm-boost, fmradio, freecell4maemo, fschedule, fuse, gboggle, glibmm2.4, glogarchive, gnome-python, gonvert, goocanvas, gpe-icons, gpodder-icon-theme, greekiradio, gst-plugins-good0.10-flv, gst-plugins-good0.10-mkv, gst-plugins-good0.10-ogg, gst0.10-python, gstreamer0.10-ffmpeg, gtk+extra2, gweled, headphoned, healthcheck, hex-a-hop, host, irssi, jamaendo, json-glib, kernel-power-settings, libart-lgpl, libcap, libdaemon, libevent, libffi, libgnomecanvas, libgnomeprint, libgtkhtml2, libliqbase, libmad, libmicrofeed, libmodplug, libraw-lite, librsvg, libsidplay, libsigc++-2.0, libsoup2.26-1, libxinerama, liqflow, lirc, lybniz, lzma, lzo2, madbomber, maemo-optify, mafw-lastfm, mancala, mastory, masudoku, mauku, mclock, meanwhile, mediabox, microfeed, microfeed-providers-unstable, microfeed-utils, milkyway-wallpaper, mirror, mplayer, mspede, mutagen, mygpoclient, n900-fmrx-enabler, n900fly, nako, ncalc, nmap, notify-python, omweather, openvpn, openvpn-applet, panucci, pedometerhomewidget, pexpect, polipo, poppler, proximityd, pycairo, pycurl, pygame, pygobject, pygtk, pygtkeditor, pyinotify, pymaemo-optify, pypianobar, pyrecipe, python-central, python-dbus, python-evolution, python-facebook, python-gdata, python-gtkhtml2, python-imaging, python-location, python-numeric, python-support, python-twitter, python-xml, python-ystockquote, qtsixa, quickbrownfox, quicknote, recaller, reflect, rfk, rmz-helsinki-wallpaper, rmz-senaatintori-wallpaper, rootsh, rsync, sdl-net1.2, sdl-ttf2.0, sdlgfx, sdlpango, sense, sgt-puzzles, shortcutd, sip4, sleeper, solarwolf, sopwith, sqlite, ssh-status, stockthis, storageusage, supertux-stable, systeminfowidget, tar, tennix, thai-ttf, tickstill, tor, touchsearch, tsocks, uqm-3do-data, uqm-data, uremote, ussd-common, ussd-widget, vim, vor, vultures, wget, witter, worldtv99, xkblayouts-rx51-ru, zoutube

There are a lot that don't build but I think we're at the point where I need help from some experts and it's time to open the beta service up to early adopters. You can see what I've done to setup Fremantle on the OBS.

As I said HELP
I now need to fix build issues like:

installing hildon-update-category-database
/usr/bin/hildon-update-category-database: I don't have write permission on /usr/share/mime.
Try rerunning me as root.
dpkg: error processing hildon-update-category-database (--install):
 subprocess post-installation script returned error exit status 1
Errors were encountered while processing:
 hildon-update-category-database
exit ...

which blocks a large number of applications

and package specific ones like this in libogg:

automake: configure.in: installing `./mkinstalldirs'
Makefile.am:3: require version 1.6, but have 1.4-p6
include/ogg/Makefile.am:6: invalid variable `nodist_ogginclude_HEADERS'
autoreconf: automake failed with exit status: 1
make: *** [configure-stamp] Error 1
dpkg-buildpackage: failure: debian/rules build gave error exit status 2

I can fix almost all of them myself but that's not the point - we need a team to make this work. Please get in touch and help.

Community Building for Maemo and MeeGo - What does the OBS Do?

2010-05-16T10:28:00.000+01:00

In a closed environment you use what's in the SDK and you get your own little space; talking to others is discouraged and sharing and re-use outside the blessed area is frowned upon. This dictatorial style has the advantage of making life easier for the vendor. In an open world we have more interactions... and as students of networks know: increased connectivity brings increased complexity as well as increased benefits. So this is an initial proposal for the organisation of OBS build projects and packages to support a QA process into an app-store / Extras or garage-like environment. I'll introduce some basic OBS concepts and then describe how this might work. I would like this to raise awareness of some potential complexities that we may face and get some thoughts on how to deal with them. ...... Oh, and this is about both Maemo and MeeGo.

First an OBS Intro

It's a build system (fully local) and a build service (like the autobuilder).
You put source into it and say "use this repository" and it spits binary packages out.
It builds a minimal and "clean" SDK using the repository you told it to use
It has packages - a package corresponds to a tarball and a spec/dsc
It has projects - a project is like a directory with packages
Packages are 'published' into a corresponding repository (which can be shared with others)
The published repositories can also be used by devices to download binary packages.

There is a lot more to it; scheduling, dependency based building, multiple architecture support, home projects, package signing...

The 'trick' then, is to set up a structure of projects that we can use to support the publishing and sharing activities that we need.

So What are our Goals?
We want:

to allow freedom for developers to develop;
to provide a great build service and SDK
to work with the core distro as much as possible
to provide excellent quality assured applications for our "app store";
and for MeeGo, to extend the core distro with a community supported area for libraries and packages that are depended upon by more than one application.

First thing we get: Individual Homes and PPAs
You'll start by uploading and building a package in your "home" directory (which can have a structure underneath it for multiple projects). This will allow you to build against any of the main distros; any group/community projects or even any other community member home projects. Oh, and they can use your code as a baseline too. Once built your code is automatically published to a repo on the
community downloads server.

This is a lot like the Ubuntu PPA solution.

At that point you can stop if you want. You have a complete set of repositories (1/subproject). No painful QA processes. No 'fragmentation'. But equally your repo(s) will needed to be manually added to a device in order for it to appear in any apt-get/zypper/yum etc.

A huge benefit here is that to get at a development version of an application you use a specific repository, not a mishmash of randomly unstable packages like Extras-devel.

For the pros: Community QA'ed Repository - Extras
If you'd like your application to appear in the Extras repo which is pre-installed on devices then you can submit to the QA process.

First you register for the package name, then submit your code to the distro promoter; there it is QA checked, copied to Extras:Testing, built, QA'ed again and becomes available in the Testing repository.

<here be dragons> The community testers then approve your code. </dragons>

(I know that's a contentious point - and I don't have an answer. I do however have confidence that we can solve the problem through collaboration and co-operation.)

Once approved the code is copied to the Extras:Stable repository for publication.

Conclusion

Much of this text is online at:
http://wiki.maemo.org/OpenSuse_Build_Service
(I really hate it when things get locked up in blog posts and forums)

How can you help?

Some tasks needed to get the OBS running:

OBS Installation - a detailed guide on how the system was setup.
Application QA Process on the OBS - a proposal
Setting up Fremantle - WIP - post to follow
Fixing the Fremantle SDK - mmmm
Setting up cross-building - started, not imported yet
An OBS Autobuilder queue - not started
Reporting - not started

Also see:

It was the Dawn of the 3rd Age...

2010-05-07T18:20:00.003+01:00

...and not only is the Shadow War over but it looks like we will have a community OBS thanks to the team formerly known as maemo.org infrastructure :)

I'm really excited as I see this as a way for the Maemo and Moblin development communities to transition smoothly into a MeeGo future; we should eventually be able to offer an easy way to build applications for Fremantle, Harmattan, MeeGo and future device OSes too.

So what's happened?

A while ago the RWG proposal was begun and we've been pushing it ever since. Tero, Mike, Neils and others have been working on the CAT proposal as well as the RWG. We got together on irc and had a chat about the scope and how to proceed.

Last week the TSG agreed we need something (kinda!) - so we decided that we'd go ahead and do it.

We now (thanks to Tero & Nokia?) have a test machine behind a firewall and I've setup an OBS (more than you ever wanted to know... but you said to work in the open, right?) to prototype how we'd deploy it for community use. This has a link to the MeeGo OBS and successfully builds MeeGo packages.

Where are we going?

I don't know yet; but here's what I'm proposing (my ideas tempered with some input from others):

Initially we should offer a MeeGo OBS and a Maemo OBS. There are corporate issues around this and whilst my personal aim is a single build system able to build debs and rpms against any M[aemG]*o distro, that isn't the first step.

The MeeGo OBS will probably offer home directories and a way to build against the MeeGo weekly snapshots. We may be able to offer a 'live' feed if some OBS bugs are resolved and we have the build resources.

The Maemo OBS will provide an alternative to the autobuilder for Fremantle and, eventually, for Harmattan. This makes sense as our longer term future with MeeGo is clearly the OBS.

One thing I dread is having to go to each device vendor's build system to make build my app for their community app store; so maybe off into the future we'll even provide a neutral place where we can support multiple vendors: a single build system that can build community MeeGo apps for devices from any vendor that participate.

Another area of interest to me is something I call "Surrounds" (yes, Quim, I know... it needs work). This isn't my idea... lots of software products and distros have it. It's that chaotic area around a product where 'outsiders' or community people contribute their "unsupported" bits and pieces. Actually this deserves a post on its own. Anyhow, I think the OBS will make managing this a lot easier for the community.

There is still a lot to do...

We've asked a few community devs to join (and please come and talk to us if you feel you can help - bear in mind that we need documentation and build system process experience more than development skills).

A big task is the setup of an OBS build system for Fremantle. I managed to get this 80% done a while ago so that work needs digging up and finishing off. Once that's done we will need a lot of help validating all the Extras apps.

Yet more work is required on my cross-compilation system used by the OBS. That was deployed for Mer and we need to redeploy it for Fremantle too.

There is work on reporting systems and QA automation systems going on that we can re-use which will help in transforming the autobuilder promotion type processes and figuring out what is and isn't needed in the OBS world.

Speaking of which ... do we take this opportunity to tweak the Extras promotion policy?
I think we need something like the Devel->Testing->Stable process for Maemo apps - but maybe we should be working with the CAT guys to figure this one out?

Finally please don't ask me when you'll get to use it, we don't have a schedule yet :(

However, do feel free to ask me what we're working on or what we've done or what you can help with.

N900 and Mozilla on the BBC

2009-12-22T12:30:00.000Z

Here's the BBC Technology story it's good that the N900 is being seen as an open system at this level.

snippets:

The browser, codenamed Fennec, will initially be available for Nokia's N900 phone, followed by other handsets.

and

Apple is very restrictive. It doesn't allow other browsers.

which is all promoting the core values the community loves about Maemo...

Android... is it Linux ?

2009-11-06T23:51:00.000Z

This i just something that I saw on LWN (from Harald Welte) and felt needed a little more visibility here at maemo.

The presentation shows how Google has simply thrown 5-10 years of Linux userspace evolution into the trashcan and re-implemented it partially for no reason. Things like hard-coded device lists/permissions in object code rather than config files, the lack of support for hot-plugging devices (udev), the lack of kernel headers. A libc that throws away System V IPC that every unix/Linux software developer takes for granted. The lack of complete POSIX threads. I could continue this list, but hey, you should read those slides. now!

The slides

As usual the commentary at LWN raises some interesting counters.

Ovi Maps... Really? Is this the best we can do?

2009-10-27T12:51:00.000Z

I got caught in a nasty traffic jam tonight just a few miles from home.

There was a road that I've never been down - windy country lanes, right general direction...

I grin and whip out my N900 and give it to my wife to navigate us - just the ticket?

No.

An hour later we've been lost several times, argued and are generally very annoyed and unhappy. My wife thinks that *I* think she's stupid 'cos she can't use a map application. She hates that. I hate that.

The maps UI sucks. It is unusable to a novice. The GPS seems to update randomly every 10 mins or so. It blocks the screen with messages. It tries to connect to GPRS when there's no signal (and clearly no need). Mostly it just completely fails to meet its purpose.

As we hit a road we recognised I realised that I was so pissed off with this experience that if I were a consumer who'd paid retail for this device I would want my money back - and as someone who has breathed Maemo for almost a year now, that makes me very, very sad.

Maemo Security - Lockdown or Liberation?

2009-10-12T18:54:00.000+01:00

At the Maemo2009 Summit Nokia shared a great deal of information about the security mechanisms that would be available and/or mandated in upcoming platforms.

The concepts outlined include well established favourites in the OSS world (like privilege management) as well as some that are rather less well regarded - such as relatives of the Trusted Computing Platform and DRM.

Inevitably there will be a significant amount of interest and concern about how this affects the open nature of the Maemo platform.

I'd like to highlight that there is a specific boot-path designed in to allow a community kernel to be booted with, as far as I could tell, no loss of functionality other than access to DRM content. That's amazingly positive.

For what it's worth I will say that I was massively sceptical as soon as I saw "Trusted Computing" and "DRM"; however after listening and thinking about it I came to the conclusion that this solution could be a huge benefit to the OSS community. Certainly Nokia can abuse it - but that's not the point. The point is do we - and should we - trust them.

We certainly need more security. Right now when I download an application from Extras-Devel it can do anything to my device; on an N800 that's not so bad - on an N900 that can incur significant cost and could conceivably (and almost trivially) be used to perpetrate fraud. I'd like to be able to say "no, scrabble game, you can't access my contacts data or make phonecalls - what on earth do you need to do that for?" An open security infrastructure would make me feel a whole lot more comfortable.

As a starting point to a rational response I think a sensible thing to do is to brainstorm the key questions we need to ask Nokia in order to gather the data needed to come to a conclusion.

The presentation was a great start - as was Elena's offer to continue the discussion on the mailing lists and respond to our queries and concerns (Thanks Elena).

So,I have started a Maemo Security page on the wiki which I hope can capture community questions (and, eventually I hope, Nokia's answers) about these issues.

The first questions are draft (I just landed and I'm tired!) to get people thinking. Certainly I want to re-watch Elena's presentation video several times before going much further.

I suggest we initially add questions to the Maemo Security discussion page and and once they've been refined and consolidated, we'll add them onto the main page.Obviously discussion needs to happen on talk, email and irc too.

I'll wrap up with a plea - please don't over-react - jumping to conclusions and misleading the rest of the OSS community before we know the facts can only hurt what has so far been the most amazingly open phone device I could have dreamt of!

PS The Summit was brilliant!

Important Summit Announcement

2009-10-06T23:22:00.001+01:00

Well, it's important if you arrive for the Summit on Thursday and want to meet up for a beer (or, if Copenhagen was anything to go by... an ice-cream) in the evening.

More details here:
http://wiki.maemo.org/Maemo_Summit_2009/Schedule

Meet up at 19:00 (so after early registration closes).

There will be free beer available

if someone offers to buy it ;)

Want to PUSH... need a kickstart?

2009-09-21T09:54:00.000+01:00

So one problem with the PUSH is that it's a bit tough for us software nerds to get into the real world. What would be cool is a nice easy "apt-get install HARDWARE" ... interested? read on...

A few years ago I bought a couple of these boards for about £25.

They provide:

5 digital input channels
8 digital output channels
2 analogue inputs
2 analogue outputs (8 bit resolution)

You can also have up to 4 of these plugged in via a usb hub.

So, I thought... how hard can it be... and actually it is quite easy. The source is on sourceforge and I'm packaging it so you can pull libvelleman from garage, plug in a board and PUSH :)

As you can see the test program implements K.I.T.T. for you...

So now all we need is someone with an N900 to help me test it...

(Warning: Don't get your hopes up - it appears that the N900 can't (yet?) act as a normal USB host; so no plugging in printers....)

The Summit: Git/Gitorious - Untracked talks: consider adding them...

2009-09-04T16:56:00.000+01:00

I proposed a talk at the summit on DVCS and git and it has not been accepted (or rejected) by the talk selection group. This isn't a complaint :) . . . . . however I do worry that it might worth pushing ... what do you think? (Breaking news... sounds like there has been an acceptance - also it may make sense to do a BOF session after any presentations). I still would appreciate feedback - what' important to you?

This message is just to solicit opinions and hopefully will validate their decision. If it causes a rethink then that's fine too.

Heh - I could do without the extra work involved!!

I personally thing think that as a development community with git on garage and gitorious.org we should be making efforts to understand how best to use DVCS processes to collaborate.

Maybe it's just me but I see a lot of devs who are new to DVCS and very few community guidelines on how to use DVCS. Qt uses it but, as we've recently been discussing, it could be going better.

Frankly I don't care which 'good practice' I use - I can go out and find lots of them. But it strikes me that as a community we should at least say "hey, quite a few of us are using this approach - if you don't have any strong preferences then you can use it too"

So why now?

Well, real soon now (I hope) we're going to have 3 different versions to support.

Fremantle
Diablo
Mer

They'll each have different capabilities and some apps just won't care - they'll support Fremantle or Diablo and ignore the others. That's fine.
(Although being open-source you might find patches being sent in to add support for another flavour - how will you cope? Wouldn't you like some help in doing the boring stuff?)

Other apps will decide to embrace that diversity from the start.

So how do we (you) manage the build-variations (ie debian/* may well vary for each of them. Maybe ./configure too)? Do we use branches? How?

Now how do we manage adding features and back-porting simple bug fixes to the stable release whilst you work on that big new feature set.

How are contributions and teams handled?

It sounds horrendous - and it can be!

But actually this is all fairly simple stuff with DVCS once you have it explained and once you grok it - but it's bloody hard to figure out from scratch and it's also very unlikely that you'll arrive at the same solution as another team.

Which means if you're a member of multiple teams you might find they each have different approaches - "whoo hoo!" - not!

So anyway... I thought a talk would be a good idea.

Now at the time no-one had volunteered so I did - some of you may have noticed my name at the bottom of:
http://www.kernel.org/pub/software/scm/git/docs/git.html
(yes, I'm proud of that contribution)

Now you may think that qualifies me to offer this talk - you'd be wrong ;)

I was hanging around the kernel lists at the time, got interested and acted as an 'editor' pulling together words of wisdom. Since then I've used git a little but it wasn't until we started to need it in Mer that I reviewed the state-of-play and tried to pull in other people's good ideas - so that's what I'd use as a base.

However we also have Johan Sørensen who wrote Gitorious.org - I think having him speak on using git and gitorious would be an opportunity that we shouldn't miss.

Equally there must be developers in Nokia/Trolltech who could say "we know this stuff and this is how we think you might want to do it."

So... speak now...

PS If anyone fancies collaborating and doing a multi-person presentation then I'm up for it.

GrandCentral for Mer... connecting the components

2009-09-04T15:00:00.001+01:00

First, I'm sorry but this isn't an N900 post :) instead I've been looking at one of the areas that's holding back Mer. It's fairly simple conceptually: just handling interaction between various parts of the system; and by this I mean things like screen dimming; what happens when you press the power key; shutting down when the battery is low; waking up for an alarm... Things that should just work. Well, I think I have a potential solution. (Oh, and some of you may be interested... I also found out how far eclipse has come in the UML modelling space too!)

Currently this is handled by powerlaunch; it is really not a bad bit of code and does most of its job well.

Sadly it really sucks at being configurable!

Here's a snippet:

 global_key_press_power = timer_set _key_power_long $powerkey_longdelay; timer_set _key_power_medium $powerkey_mediumdelay; set powerkey_short 1; call _key_press_power_short
global_key_release_power = timer_cancel _key_power_long; timer_cancel _key_power_medium; if $powerkey_short _key_release_power_short key_release_power_long

I don't know what it does and the only way I'd be happy changing it would be after extensive research. Frankly it scares me!

Here's what I was thinking we'd do for a 'configuration' syntax in Mer:

 # describe some action
def on_wifi_up():
  notify "The wifi is up"
  os.system("mail me@gmail.com -S 'wifi is up'")

connect(wifi, "Connection.up", on_wifi_up)

connect(camera, "Camera.active", takePhotoAfter10Secs)
connect(camera, "Camera.turn",   media.play, "/home/lbt/sounds/camera_click.wav")
connect(powerButton, "Button.longPress", powermenu.show_menu)

This uses a python signal library (like Qt or libsigc++) and provides a set of component objects that emit nice signals like "Connection.up".

The benefits of this approach:

simple syntax is nice and readable
interpreted so can easily be edited
python understood by many so can be easily extended
re-uses some powerlaunch code (eg powered)

Of course there are drawbacks:

it's not a config file - it's code (but considering we want to configure functional behaviour then any config syntax needs to be a language... so use a decent one)
python is quite large (but it's now in memory and .so are available)
it's another re-write :( (it only took a few days and I'm using powerlaunch as a prototype for config rules - if I can understand them!!)

So anyway, as I said, I found eclipse Modelling edition...

This says (well, I hope it says):

There is a system and a user dispatcher
They're based on a common Dispatcher
Which contains components (such as Headphone, Menu etc) that can

send signals (eg when the camera on the N800 is turned)
take requests (dim the screen)
provide state information (a headphone is connected)
be accesed on D-Bus

The Dispatcher creates Connections which

listen() for Components to emit signals (also listening on D-Bus)
run Scriptlets which might

run arbitary code
make requests to components
emit signals that (other) Connections can listen() for

Scriptlets are part of the Dispatcher

Oh, and the good news is that it's up and running... I'll put the code on gitorious RSN.

Do you take contributions? or is it "Beware of the Leopard"

2009-09-03T10:00:00.025+01:00

Open source is about opening things up... right?
Well, yes.
But I think there's more to it than that.

Think about the kernel and how that works. A wide open mailing list (and source repository) with people getting on with it. Fedora? Ubuntu? The same. SGI's XFS filesystem; in fact any number of projects out there.

But what does that even mean? "Getting on with it?"

To me it means discussions, proposals, code, designs, bugs. If you care you can watch; you can even attempt to join in. You can certainly learn about what's happening and why.

So here's the question...

Where's the 'Contribute to Maemo' on maemo.org?

Fremantle is coming out - but it just appears on the download servers. There's no opportunity for the community to contribute. Where are the mailing list archives or the commit logs so I can find who committed that change, when and why?

Opensource means you can't be shy; open doesn't mean "behind closed doors"; it doesn't mean "you get it when we're done".

Open means "this is what we're doing". And "we" includes the community.

I hope we're doing it the right way in Mer.

irc is our main collaboration area and that's open and logged. Not terribly useful as an archive though. We have the chatter mailing list which gives a pretty good summary of key events.

What we do to activate incoming developers to make it easy for them to contribute? Well, we've adopted gitorious as our DVCS and I think the process and UI there makes that a good call. I've also put some effort into describing our 'internal' build processes and what we (ultimately) expect DVCS contributions to look like.
Carsten has setup a neat little tracker of outstanding tasks so potential contributors can pick up things to work on.

We have some design statements on the wiki and we know that 'track Fremantle and predict Harmattan' are our tenets.

I wondered what Android does?
Hmm : http://source.android.com/roadmap

The Android Open Source Project will publish roadmaps forupcoming releases. The roadmaps will be developed with input from thiscommunity, Project Leads, and the Open Handset Alliance

Sounds good.. and the code is up there.

What about contributions?
Well... say no more! A random click got me that gem.

Nokia and Maemo5 .... well, to be frank it looks a lot more like Microsoft.

And that's not that harsh :)

Microsoft provide (I'm told) excellent documentation for developing OSS on their platform.

For Maemo there is some really good developer documentation (seriously - I think this is not shouted about enough); there's superb support for creating OSS on Maemo platforms; and that's absolutely crucial.

Contributing to Maemo... not so much.

Yes, the source is there for the released maemo packages; and there are random directories like this or this (first one is circa 2005, 2nd April 2008)... browse around, we found some useful stuff in there!
As Carsten said "god knows how i found that first time". There are garage projects too (impossible tofind the right ones though), recently we noticed some appearing on gitorious or git.maemo.org or svn....

However I'm not really aware of anything other than bugzilla for communicating with the development teams; and I don't think that's something the community generally finds to be a 'shining example' :)

We recently added a note by way of an apology for Mer's lack of "apt-get source" but I think Maemo deserves it too:

`...You hadn't exactly gone out of your way to call attention to themhad you? I mean like actually telling anyone or anything.'
`But the plans were on display...'
`On display? I eventually had to go down to the cellar to find them.'
`That's the display department.'
`With a torch.'
`Ah, well the lights had probably gone.'
`So had the stairs.'
`But look you found the notice didn't you?'
`Yes,' said Arthur, `yes I did. It was on display in the bottom of alocked filing cabinet stuck in a disused lavatory with a sign on thedoor saying "Beware of The Leopard".'

I really don't think it's doom and gloom though - Qt has opened up a lot since Nokia took over. The development has moved out into the open and there's a process to contribute. Gitorious is being sponsored by Nokia/Qt and I hope the maemo-af team are leading the way.

I really hope that when Harmattan arrives the basement is light and airy; very, very noisy and the leopard has relocated to the lobby!

Accelerating OBS .... !scratchbox

2009-09-01T09:29:00.002+01:00

So I've been working on accelerating the Open Build Service recently.

It's a great build environment for Mer and we love it. It uses qemu to emulate arm architectures and provides a pristine chroot build environment using native packages. This approach of using distribution tools rather than a toolchain provides a more consistent build system.

The problem is that this approach is slow.

Following the 80/20 rule, the OBS engineers (thanks Martin, Jan Simon) identified the applications that represented the greatest load on the build system:

bash
bzip2
dpkg
gzip
m4
make
perl

And of course:

So the intention was to accelerate these binaries in the emulator by using host machine code, not emulated code.

The emulator uses binfmt_misc to call qemu for foriegn binaries when it hits them so simply replacing the binaries with host binaries should work.

Well; almost.

The host binaries need their shared libraries; and they live in the same place as the emulated shared libraries... which may be used by non-replaced code. Hmmm.

(Before going any further, lets establish a naming convention: target is the architecture of the chroot and eventual target; host is the architecture of the underlying CPU. Typically for us target is armel, host is x86.)

The approach to solving this problem is to minimise changes from a pure arm build environment. This is achieved by installing both arm and x86 packages; to avoid collisions the x86 packages are installed into /lib-x86 (in the chroot) and of course, shared libraries will fall into /lib-x86/[usr/]lib and not overwrite the target .so files.
The final step is to move selected binaries in /bin and /usr/bin out of the way and replace them with symlinks to the i586 binaries in /lib-x86/[usr/]bin

Most x86 packages are unmodified; any paths they use will relate to the main / directory and the config/data files installed by the target package will be used. (This works in general although the eagle-eyed will spot issues with things like XS modules for perl - not a major problem for a simple build environment though).

Some packages are modified to minimise build times - eg to avoid 64 bit builds; others are modified (eg dpkg) to set the target architecture as a default.

Obviously the host binaries need to link to shared libraries which are not in the normal LDPATH. We don't want to have to rely on environment variables etc so 2 steps are used:

modify ldlinux.so to look in /lib-x86/lib etc
modify the rpath value in the ELF header of each replaced binary

This is done by creating a static build of patchelf and modifying the binaries as they are installed.

Finally a modified package has all postinst scripts removed and replaced with something like:

prefix=/lib-x86
$prefix/usr/bin/patchelf --set-rpath $prefix/lib $prefix/usr/bin/make
mv /usr/bin/make /usr/bin/make-orig-x86lib
ln -s $prefix/usr/bin/make /usr/bin/make

Note that some libraries have an rpath and need to be treated with patchelf too.

One final problem arises with fakeroot: it modifies the LD_LIBRARY_PATH to look for libfakeroot-XXX.so This is handled by editing the fakeroot script to append the /lib-x86/ paths in the same way the multi-arch paths are added.

All in all this is actually a very clean solution:

the modified binary uses the exact same source as the one it replace
the installation principles mimic biarch (and will, we hope use biarch when it's ready)
only the specific binary executable is replaced - data and scripts come from the target package
it can easily be switched on or off for a specific binary
enabling it on the OBS is done in the enclosing project, not the package

Next steps, making it work on the OBS and then ... building a cross-gcc.

$ make distro

2009-08-29T11:19:00.003+01:00

That's what the OBS does for us.

The openSuse builder provides Mer with an incredibly powerful tool for building packages.

It gives us:

over 150 build cores !!
powerful monitoring and control tools - web and cli
total access - it's all GPL
proven capability - openSUSE and SLE are built using it
distribution neutrality

OBS is a GPL, distro-neutral build system; it works by creating a totally empty virtual machine (or chroot), bootstrapping a minimal version of a distribution and then driving the distro's own build tools to pull in the build dependencies from the official distribution repository. Finally it calls the native tools (eg dpkg-buildpackage) to build the package

Think of it as a wrapper around the distribution's standard build tools which provides queue management and a good web interface.

What's good about that then?

No wheels being re-invented - it uses the 'standard' tools
Quality control - packages must specify exactly what they depend on to build; and a build installs clean packages and builds from clean source
Management wrappers - more about this later

And it does this around multiple base distributions inclding Debian/Ubuntu/Redhat/Centos/Moblin and of course SUSE and openSUSE.
Just try building a Redhat package on the Debian build system - or vice versa.

What makes it particularly interesting for Mer is that it also does this with multiple architectures including ARM.

So what Mer essentially does is to feed it a large number (~200) standard debian format source packages and wait for it to spit out .deb files in an sources.list compatible repository.

Doing this correctly means it needs to analyse build dependencies and, make-like, consider the freshness of those dependencies to determine if a rebuild is required. So if a change is needed in libhildonfm2 then all the packages that depend on it will be rebuilt - nice.

If you'd like to read a bit more about how Mer uses it then start on the Mer Build pages.

Come on in...

Restructure MeeGo : By Installments

MeeGo :Restructured

Development and Maintainance Projects.

Core

Tools, build-root and toolchain

Distro : Apps + Surrounds == "MeeGo, the distro"

SDK

External Tools and Systems

Reference Tablet UX, Handset UX, IVI UX

Multiple Hardware Adaptation Projects

Integration Projects

Handset Community Edition / CE

Tablet Edition

IVI Edition

Futures

MeeGo Python

Mini-Glossary

native packages

MeeGo : Infrastructure

MeeGo and the hacker community

MeeGo : Lead by example

MeeGo : Evaluating MeeGo

MeeGo: Systems and Processes

MeeGo Core : focus

Restructuring MeeGo : Executive Summary

MeeGo DE - *THAT* is how you do it ....

What now for MeeGo?

Assumptions and observations:

Proposal:

MeeGo Community Development: Apps, Surrounds and the Community OBS

Apps - the area formerly known as "Extras"

MeeGo: The Linux Distro

Surrounds

QA and Releases

Upgrades and concurrent installations

Porting vs Maintaining : A MeeGo partner

Some random policy questions:

The Community OBS

Structure

Team Areas

PPAs

MeeGo Targets

MeeGo Snapshots

MeeGo Rebuilds

Surrounds

Fremantle

Actions and Ideas

Are Intel subverting MeeGo.com?

Intro

Issue

Impact

Details

Postition

Fairness

Counters

Proposal

Works for everyone

Conclusion

Open Letter / Proposal to allow Maemo on the MeeGo Community OBS

I like crashes like that...

Kerberos and ssh

OBS and Fremantle ... huge success :) and HELP!!!!

Community Building for Maemo and MeeGo - What does the OBS *Do*?

It was the Dawn of the 3rd Age...

N900 and Mozilla on the BBC

Android... is it Linux ?

Ovi Maps... Really? Is this the best we can do?

Maemo Security - Lockdown or Liberation?

Important Summit Announcement

Want to PUSH... need a kickstart?

The Summit: Git/Gitorious - Untracked talks: consider adding them...

GrandCentral for Mer... connecting the components

Do you take contributions? or is it "Beware of the Leopard"

Accelerating OBS .... !scratchbox

$ make distro

MeeGo DE - THAT is how you do it ....

Community Building for Maemo and MeeGo - What does the OBS Do?