And that’s what’s inside it:

That’s a lot of DVDs to watch. Thanks so much! Now I’m in a little quandary* on what to do on the weekend: work on Firefox OS or watch the DVDs? Maybe I can find time for both, the weather is bad enough to stay inside all day :-)

* That’s probably one of the nicest English words I know, so I had to use it here.

Head over to the Firefox OS for Raspberry Pi Manual, which contains all build instructions, download links to a pre-built SD card image and much more information.

But before you start, please note the following limitations of this current release:

• No input devices are supported. No mouse, no keyboard.
• The screen resolution is hardcoded to 1280 x 1024 px.
• The used Firefox/Gecko used is not up-to-date (it’s using revision 801ba75ac563 from 2013-01-03).
• Quite some patches are required to get Gecko building, most of which were developed by Oleg Romashin. Unfortunately, they are not yet part of the official Mozilla source tree, and some of them are quite hacky. Progress to get this work upstream is tracked in bug 731498.All those patches are exported into the meta-b2g layer. A source repository for easier development will be made available soon together with instructions how to contribute to the Gecko development.

So what is all of this useful for at this point? I mainly leave this up to your imagination, but I’m using it as public info screen, displaying the weather forecast, room occupation, the next subway connections and today’s lunch menu. All data comes from publicly available web services or is scraped from Internet pages, all client-side with no web server or anything. Here’s how it looks:

Firefox OS for Raspberry Pi powering an infoscreen

I hope you find Firefox OS for Raspberry Pi as useful and exciting as I do, and please send me your comments, suggestions or (best) patches, to make it even greater!

So that was the idea: build Firefox OS for Raspberry Pi by combining Firefox with a PTXdist-built Linux.

Fast-forward two weeks. Welcome today! After many sleepless nights, a couple switches of the GCC and binutils versions (and full rebuilds of everything), different Linux kernels and some work on Oleg’s patches, I finally got it all working together! In the mean time Oleg posted a Youtube video of Firefox OS running on Raspberry Pi that made it to the homepage of raspberrypi.org. Many people seem to be excited by the idea of running Firefox OS on Raspberry Pi, which is great.

Firefox OS for Raspberry Pi combines two exciting projects, and I’m sure those two will have a great future together.

A lot of work remains to be done, and I’ll post patches and more documentation on how to build all of it in the coming days, but let’s get started with some images (and watch Oleg’s video if you didn’t do so yet!):

Step 0: Prepare your system to use OBS

Instead of duplicating existing documentation, just have a look at the OBS tutorial at the openSUSE wiki. You’ll only need to follow Step One. Basically, this means installing the required packages for OBS and creating a working directory.

If you’re done, switch to your working directory and you can follow the next steps*.

Step 1: Branch (fork) the original package you want to modify

$> osc branch Printing hplip

Step 2: Do a checkout of the branched project

$> osc co home:YOUR_USERNAME:branches:Printing/hplip
$> cd home:YOUR_USERNAME:branches:Printing/hplip

Step 3: Do the required changes to the package (the actual work!)

$> wget http://prdownloads.sourceforge.net/project/hplip/hplip/3.12.6/hplip-3.12.6.tar.gz
$> # verify binary (gpg, md5sum, etc.)
$> osc add hplip-3.12.6.tar.gz
A    hplip-3.12.6.tar.gz
$> osc del hplip-3.12.4.tar.gz
D    hplip-3.12.4.tar.gz
# adjust the spec file as necessary ...


Step 4: Build locally to verify your changes

$> osc build openSUSE_12.1

Instead of openSUSE12.1 you can use any target your might want to test (e.g. openSUSE_Factory etc.). This command is actually pure magic, it pulls all dependencies, installs them into a chroot build environment, and builds the package. Awesome!

You can now even install the resulting RPM package, the above command will tell you where to find it at the end of its output (probably somewhere in /var/tmp/build-root/home/abuild/rpmbuild/RPMS). You actually should do that and verify that everything works as expected.

Step 5: Finish it up

If you’re happy with your changes, and everything works as it should, we can get ready for submission.

First, add a changelog entry:

$> osc vc

will open an editor and allow you to add a changelog entry into the already prepared text template.

Now, check that you added/deleted all files by calling

$> osc status

If everything looks good, commit the package to OBS by using

$> osc commit

You can now go to the OBS web interface and watch your package build, or use

$> osc results

to see the results of the build process on the openSUSE servers. Note that building may take some time, depending on the OBS load and obviously your package.

Step 6: Submit the changes to the maintainer

Everything is great? The last step

$> osc sr

sends a “pull request” (in git language) to the package maintainer. You can see the status of this request in the web interface as well.

Now you only need to wait for the maintainer to accept your changes and then: Congratulations, you’ve made your possibly first contribution to openSUSE!

Further reading

OBS tutorial in the openSUSE wiki
Tutorial on how the branch/pull system works in OBS

* Actually, the steps as written here will not result in a working package. The update of hplip required some other changes that I didn’t document here, but I hope the real-life examples will help to make the steps more understandable.

Note: While I only use MSV for XML Schema validation, it can be used for RelaxNG and other schema languages as well.

Get MSV

That’s the easy part: download a binary build from http://java.net/downloads/msv/releases/ and unzip it (you only need the msv.YYYYMMDD.zip).

Validate a XML document

$> cd msv-20090415
$> java -jar msv.jar schema.xsd document.xml
start parsing a grammar.
validating document.xml
the document is valid.


Dump the post-schema-validation infoset (PSVI)

Often it is useful to see which type the XML Schema parser attached to a node in a document. To do this, get the post-schema-validation infoset (PSVI) from the schema validator. With MSV comes a sample application that can be used for this purpose.
$> cd msv-20090415/examples
$> java -cp .:../msv.jar psvi.PSVIDump schema.xsd document.xml


Let’s start with the facts. On the development side, I have been the only person doing coding work on XForms for almost a year now (with great support from Aaron, Alex and Olli, who did all the reviews). Unfortunately, I’m very limited on time and it has not been much work at all (at least by the results; the various platform changes required me to dig much deeper into platform code than I every thought I would, and it took me quite some time to get used those very different areas of code). This makes development extremely slow and puts the focus mainly on “keep the thing working” rather than implementing new features.

On the user’s side, according to the feedback I get via mail and on the mailing list, and according to the download stats, there are still some users of the XForms extension. (The 0.8.8b1 XPI for Firefox 4 has around 300 downloads a month from my site.)

Finally, the environment side. The XForms extension is a binary component that uses many internal interfaces of the Mozilla platform. This makes it, as the past has shown, highly affected by platform changes. It has always been the case that some changes were required on every major platform release (formerly every .x release, e.g. 3.5, 3.6 etc., now every release, e.g. 5, 6, 7).

Since the 3.x-days, three things changed:

1. No more stable APIs. This has been outlined in [1] and implemented with Firefox 4 (Gecko 2.0). This means we cannot rely on any API to stay stable for more than one major release.
2. With the Rapid Release Process [2], the new development model since Firefox 5, a major release is released every 6 weeks and users are auto-updated to that release.
3. Extensions with binary components must be at least recompiled for the new major version, even if no changes to the codebase are necessary. [3]

These three points put together mean that not only a new XForms release every 6 weeks is necessary, but also that a growing number of fixes for platform changes is needed.

You probably see the problem now. One developer that’s short on time has absolutely no chance to do a release every six weeks, and without that the Mozilla XForms extension becomes unusable every six weeks (as said before, users are auto-updated to the new major release).

So, what’s the conclusion? With the current situation, I will not be able to keep up the speed. If no other developers pop up, I don’t see a future for the Mozilla XForms extension. I personally will continue to use it in the project I’m working on (and that will stay on the platform Firefox 3.6 is based on probably), but I will not invest much time into the further development to make it compatible with the latest Firefox release.

Put the other way around, this means: if you are a user of the Mozilla XForms extension and need it to be supported on newer Firefox versions, you might consider joining the development (I will help where ever I can, and I am sure that Aaron, Alex and Olli do the same) or pay someone to do so.

As a final comment, I personally came to the conclusion that XForms as a browser plugin is dead. XForms as technology is still very much relevant, but not for all use cases thought of when initially standardizing XForms 1.0. One of them, replacing the “old” HTML4 forms, will probably never happen. HTML5 and its surrounding technologies make the browser much more powerful in a generic way. This makes it possible to provide a much greater user experience with server-side solutions than it was possible a couple years ago. The web and with it the browser market changed drastically over the last couple years, with more competitors and innovations happening at a much faster pace than ever before. By acknowledging this we can use the new opportunities the HTML5-Cloud-Buzzword-Web brings to provide an even better experience for the users of XForms — unfortunately, the Mozilla XForms extension will not be part of that experience.

PS: There is much discussion going on in the community right now about
add-on compatibility, including ideas like porting binary addons to
js-ctypes or using the Addon SDK (JetPack). Both options are not really
applicable to XForms, as it is probably unique in the way how deep it
integrates with the platform. Even if they were, a lot of engineering effort would be necessary to utilize those technologies. [4], [5]

[1] http://groups.google.com/group/mozilla.dev.platform/browse_thread/thread/18f49e75338e4ce0/f42915417230e621?pli=1
[2] https://wiki.mozilla.org/RapidRelease
[3] “We have and we will break add-on API compatibility with every release, certainly binary add-on compat. We will be adding major new features or doing serious re-architecuring with every release.” — Asa Dotzler at http://weblogs.mozillazine.org/gerv/archives/2011/07/firefox_version_numbers_cognitive_disson.html
[4] http://xulforge.com/blog/2011/07/version-numbers-add-on-breakage/
[5] http://adblockplus.org/blog/binary-xpcom-components-are-dead-js-ctypes-is-the-way-to-go
This is a cross-post from the mozilla.dev.tech.xforms news group, please follow up there for the further discussion.

On openSUSE, this means you can install the VirtualBox package using Yast (or zypper, or whatever you’d like to use) and then open VirtualBox, go to File > Preferences > Extensions, click the top “Add package” button, select the downloaded file and you’re done.

Well, almost done. After you add a USB device filter to your VM and boot it, you’ll notice that all entries in the Devices > USB menu are grayed out.

Reason for this is a permission problem. Usually, VirtualBox installs a udev rule that gives all users in the vboxusers group permission to access all USB files. openSUSE chose to disable this udev rule by default for security reasons without visible notice to the users.
So, to cut a long story short, open /etc/udev/rules.d/60-vboxdrv.rules, and replace the lines that are commented out with the ones below (these are almost like the commented-out lines, but replace NAME with SYMLINK+):

KERNEL=="vboxdrv", NAME="vboxdrv", OWNER="root", GROUP="root", MODE="0600"
#these two lines give access permission to vboxusers to properly work with usb nodes, this could be security risk (bnc#664520) !!
SUBSYSTEM=="usb_device", ATTR{devnum}=="?*", ATTR{busnum}=="?*",SYMLINK+="vboxusb/$attr{busnum}/$attr{devnum}", GROUP="vboxusers"
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ATTR{devnum}=="?*", ATTR{busnum}=="?*",SYMLINK+="vboxusb/$attr{busnum}/$attr{devnum}", GROUP="vboxusers"

Now reboot and you should have all USB devices available (at least if you’re in the vboxusers group, check this with the id command in a terminal window).

And while you’re at it, please ignore forum posts that modify usbfs or anything like that, newer VirtualBox versions don’t need these things any more.

If you only have a 10-vboxdrv.rules file, then you most likely installed VirtualBox not from the openSUSE repositories, but from the VirtualBox download site. Remove this version first and install the openSUSE version if you want to use this guide (and save you from recompiling the kernel module with every update).

(Post updated on 2011-08-15 to incorporate some user comments. Thanks guys!)

But actually there is a way to get it all work together nicely and it’s not hard at all:

1. Enable PulseAudio (#> is a root console)

   #> setup-pulseaudio --enable

2. Install the missing PulseAudio mixer (without it it’s like sitting in a car without driving wheel)

   #> zypper install pavucontrol

3. Reboot (just to make sure …)
4. Start pavucontrol. You’ll see your sound devices (e.g. the sound card and your headset), the per-application volume controls as soon as an application uses an input or output and everything else you dreamed of.

Now you can start Skype and do a test call, and you’ll be able to use pavucontrol to route its output and input to the right device (e.g. to your headset).

Enjoy!

PS: It seems that there has been some progress on KDE4 integration with PulseAudio, and I hope in openSUSE 11.4 everything will work out of the box.

http://philipp.wagner.name/mozilla-xforms/xforms-0.8.8b1.xpi

It requires at least Firefox 4 Beta 8 and works on Windows (x86) and Linux (x86 and x86_64).

Please test this version with your forms and report any problems you find! It helps us to deliver a great version of the extension for Firefox 4!

An (incomplete) list of changes is available.

Looking forward to your feedback!