Planet Maemo: category "feed:fb2e01f2b05f173de4f8ef523cd2a4d2"

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?"6 0

What now for MeeGo?

Sat, 12 Feb 2011 09:59:00 +0000

So Nokia has dramatically reduced commitment to MeeGo and has cited, amongst other thinks, MeeGo's inability to deliver a focussed baseline with sufficient speed. I happen to agree with this failure (and given Nokia was a significant part of MeeGo's management I don't think there'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.

10 0

MeeGo Community Development: Apps, Surrounds and the Community OBS

Thu, 27 Jan 2011 01:19:00 +0000

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

Apps - the area formerly known as "Extras"

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

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

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

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

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

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

Now, it's not yet clear what OBS targets Apps should build against. 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. However there are plans to consolidate them in the main MeeGo OBS - but how should the Apps area look? Should a handset user be presented with apps which were only intended to run on a netbook? OTOH is this anything to do with the repo and build target - should it be determined by metadata and selectively presented by the download application?

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

I think the discussion up to this point is fairly simple and uncontentious; 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 and MeeGo-extra applications. MeeGo-compliant apps are those which only use libraries in MeeGo core/UX; MeeGo-extra apps have a little extra open-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 in how development happens around MeeGo as well as in the centre. The following is intended to be a discussion document; there are clearly some 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 the point of MeeGo? Well, IMHO, MeeGo is primarily a modern linux baseline upon 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 OBS supporting the development and delivery of the MeeGo core system software and reference UXes.

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

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

How does MeeGo communicate significant upcoming changes to it's customers?
How do we deal with package naming clashes?
How much of MeeGo is needed for compliance vs the parts that are needed 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 of open source libraries, tools and applications that support the building of collaborative bazaar-style applications and yes, maybe even MeeGo distributions.

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

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

Surrounds

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

Surrounds provides a collection of libraries and tools that encourages this best practice way of working in MeeGo and delivers MeeGo-extra apps. The most obvious area would be for languages like perl, python and ruby. These languages have large numbers of useful libs that clearly are not going to be present in core MeeGo. Of course there will be many other tools and applications that would also be at home in Surrounds.

Over time, packages may migrate into core MeeGo and equally, some are going to be deprecated. Hopefully Surrounds makes both of those actions a little easier but we do need to decide how we handle deprecation/promotion of applications/libs between core and Surrounds.

There are many complexities when dealing with a collection of packages like 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 and users. This alone means that Surrounds should probably start off slowly and ramp up as MeeGo users and developers arrive in larger numbers. The important thing is to prepare for the main issues we're likely 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 needed by 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 it and an application "Wowee" built against an imaginary libvisual-1.0 which is in the Surrounds-1.2-A stable release of Surrounds.

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

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

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

This allows apps that use libraries from Surrounds-1.2-A and Surrounds-1.2-B to be installed concurrently even if they use different 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 it would be good to identify in advance. Just ask a maemo developer about the "optification" hack :)

Porting vs Maintaining : A MeeGo partner

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

Some tools and libraries will have comitted maintainers who have time to monitor their packages and fix bugs and security issues in a timely manner.

This is the classic distribution 'maintainer' role.

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

I call this activity 'porting'.

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

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

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

My suggestion for this group of packages is to nominate an upstream or partner distro with a good security record and a wide base of packages. Surrounds releases would closely track this distro (and will likely differ from core MeeGo). Packages taken from this distro would be fast tracked as 'ported' rather than 'maintained' and only minimal packaging changes would be allowed. This would allow Surrounds to leverage the partner-distro's security efforts (and hopefully offer benefits to the partner in return).

For obvious reasons I propose openSuse as the partner distro. (For the record 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 I wrote in a bit of rant (forgive me Shane). Some apply to Surrounds and Apps, some to the OBS in general

Licenses: OSI only licenses? GPL3 (considering the "promotion to core" target).
People: What's the process for absent devs? If someone says "hey, lbt, let me upload a new version of that library Shane uploaded" ... do I just let her? What if there's a security issue in it? What if you've not been seen in 3 months? Do maintainers need to demonstrate reliability to handle timely updates?
Legal : Do we accept mp3 players? libdecss? What about porn? What about apps with a rather rude splash screen? Any patent issues? (Don't forget the system physically lives in the "land of the free" so is subject to state seizure by the RIAA).
Commercial: I've had commercial organisations enquire about using the community OBS. I've had them ask to sponsor it. How do we deal with this? My first reaction is "no commercial work"... but why not?
Quality: Do we insist on a valid bugtracker being identified for all Surrounds packages? Must it proxy via a bmc#?
Packages scope: Where's the ITP?
Can we rebuild MeeGo with some different compiler flags (think non-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 stop doing what they're doing?
Non-MeeGo targets? When Smeegol becomes Sogmeel will we allow it to 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 we need more help. In part this whole post is a way to structure what we'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 the top level namespace to allow us to support additional distros such as Fremantle and hopefully others.

One common use for structure is to provide a QA route. Packages go from some sub-project in a developer's home: area to a 'Team' area and then into a Testing area. Each transition is subject to policy and quality checks. Defining these workflows and structures correctly will make 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 thorough testing to take place before releasing either to Surrounds or Apps

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

PPAs

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

Certainly these PPAs offer developers a huge amount of freedom. They can start by uploading and building a package in a "home" directory (which can have a structure underneath it for multiple projects). This will allow them to build against any of the main targets; any group/community projects or even any other community member home projects. Oh, and they can use each others code as a baseline too. Once built the packages are automatically published to a repo on the 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 complete set of repositories (1 per subproject). No painful QA processes for them and no 'fragmentation' for the MeeGo community. But equally these repo(s) will needed to be manually added to a device in order for it to appear in any apt-get/zypper/yum etc. Oh, and the Apps downloader team really should pay attention here.

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

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 is fine - 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 incur the 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 my desktop. It has an AMD phenom chip and an ATI card - both well supported in the opensource world. It's time to build a community MeeGo :)

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

Surrounds

What projects are needed in the Surrounds area? Certainly some unstable->testing->stable cycle makes sense; but this is not likely to be 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 and to 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 into these 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

10 0

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

Wed, 16 Jun 2010 14:18:00 +0000

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 Council39 0

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

Sun, 16 May 2010 11:38:00 +0000

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.20 0

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

Sun, 16 May 2010 10:28:00 +0000

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.

The community testers then approve your code.

(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:

21 0

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

Fri, 07 May 2010 18:20:00 +0000

...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.22 0

N900 and Mozilla on the BBC

Tue, 22 Dec 2009 12:30:00 +0000

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...19 1

Android... is it Linux ?

Fri, 06 Nov 2009 23:51:00 +0000

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.30 1

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

Tue, 27 Oct 2009 12:51:00 +0000

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.

33 0

Maemo Security - Lockdown or Liberation?

Mon, 12 Oct 2009 18:54:00 +0000

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!22 0

Important Summit Announcement

Tue, 06 Oct 2009 23:22:00 +0000

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 ;)8 0

Want to PUSH... need a kickstart?

Mon, 21 Sep 2009 09:54:00 +0000

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....)15 0

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

Fri, 04 Sep 2009 16:56:00 +0000

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.12 0

GrandCentral for Mer... connecting the components

Fri, 04 Sep 2009 15:00:00 +0000

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.10 0

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

Thu, 03 Sep 2009 10:00:00 +0000

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 for upcoming releases. The roadmaps will be developed with input from this community, 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 to find 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 them had 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 a locked filing cabinet stuck in a disused lavatory with a sign on the door 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!16 0

Accelerating OBS .... !scratchbox

Tue, 01 Sep 2009 09:29:00 +0000

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.10 0

$ make distro

Sat, 29 Aug 2009 11:19:00 +0000

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.2 0

Planet Maemo: category "feed:fb2e01f2b05f173de4f8ef523cd2a4d2"

Restructure MeeGo : By Installments

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

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

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?