exocron
This is my blog. There are many like it, but this one is mine.
Open webOS Chronicles, Part 1: Building
Open webOS Chronicles: The Horrors of Building, Installing, and Using Open webOS
Part 1: Building (Desktop and OpenEmbedded)
(Editor’s note: Just so you don’t think this series of posts is nothing but me whining about not being able to build Open webOS, let me tell you this: at this time, I have the emulator image running natively as a second partition on my laptop, and it’s semi-usable. Over the course of this series, I will try to describe every problem I encountered and how I was able to overcome it.)
It all started when I found my old HP TouchPad. Believing it to be bricked, I brought it into work where I thought we might be able to take it apart and JTAG it or otherwise mess around with the insides, only to see a co-worker using it after charging it for a day and a half. Needless to say, I started using it again, and quickly fell in love (again) with the iconic operating system, webOS.
In particular, one of my favorite apps is Flixi, an Exhibition app that lets you split the screen into different layouts and choose a feed for each cell. I don’t know who said it (it very well could have been me), but someone said, “This would be a cool app to run on a projector!” I then realized that, even though the TouchPad does not have TV output, I could possibly run the app on a build of Open webOS.
Thus, my journey of pain had begun.
At the time, my laptop was running the now outdated Ubuntu 13.04. With it’s support period over, I backed up all the data, wiped it clean, and installed Ubuntu 12.04 64-bit, as it’s listed here as one of the supported build platforms.
Once installed, I decided to build the desktop version of Open webOS. (The desktop version runs inside of another linux distribution. The UI, apparently developed with Qt, runs inside of an X window.) I followed the instructions on the README to the letter, and was excited to see the build succeed without errors! But, when I ran Luna, I was greeted with this window:
Okay, I thought to my self, the desktop build is obviously broken. Let’s try the OpenEmbedded one. So I followed the instructions on this page and started the build for the qemu image. This build process is like 2-3 times longer than the desktop one, so I ran it overnight. In the morning, I’m once again excited to see the build complete without errors. But when I go to run it, the guest immediately kernel panics. Great. But then I noticed something about the qemu command: it’s using KVM. So, I removed the KVM option, and then the VM booted! But, once again, I am disappointed by services spewing endless logs of text, and no UI ever appearing.
After a good night’s sleep, I came up with a brilliant idea: Why not try the 32-bit version of Ubuntu? In a perfect world, it shouldn’t matter if you’re building on a 32-bit host OS, or a 64-bit one. But, regardless, I decided to give it a try. So, after spending the day installing Ubuntu (again) and building for the desktop (again), I was pleasantly surprised to see everything render correctly.
A sane person would probably stop here. But I decided that the titlebar and on-screen home button were too much. This had to be all or nothing. I decided that, if I could build the qemu image, I could probably tweak it to run on physical hardware and run it on a second partition on my laptop. So, I cloned the OpenEmbedded repository and started the build, but this time, I got an error:
fatal: reference is not a tree: dea813980f4195503d82b8295f742a4da1df8d93
So, it looks like one of the git submodules is not up to date. Google searching the hash finds two results (well, maybe three now :) ), both referring to the libpalmsocket library. Luckily, replacing the hash with the latest (at the time) master allowed the build to continue, and didn’t seem to have any side-effects on the final product:
$ sed -i 's/dea813980f4195503d82b8295f742a4da1df8d93/9533a7c46f8d35e69112a8c5e671532d059b2e8d/g' meta-webos/recipes-webos/libpalmsocket/libpalmsocket.bb $ sed -i 's/dea813980f4195503d82b8295f742a4da1df8d93/9533a7c46f8d35e69112a8c5e671532d059b2e8d/g' buildhistory/packages/qemux86-webos-linux/libpalmsocket/latest_srcrev
After that, there were no more errors, but once again, when I went to run the image, there was nothing but endless novacomd output.
In the next post, I’ll describe how I got the (not fully working) qemu image running on actual hardware, and how I logged in and started the graphical system. In the meantime, however, I’ll wonder why I didn’t just make a Flixi clone for HTML5.
Archived Comments:
Eric Blade
I, for one, would appreciate hearing about the problems, and the fixes if you have them. We might be able to get them incorporated. There may be some bit-rot there in the Open components, as the IRC #webOS-Ports team is working on a vastly different OE build system, and LG is spending a lot of time busily working on TV webOS...
exocron
Sorry about the long response time, I don’t get around to checking comments ofter because they’re usually all spam. It’s great to hear from someone in the community. It’s been a busy couple of weeks, but I’ll try to get everything else written up soon. I think the biggest things were LunaSysMgr not starting up automatically for whatever reason (I just start it manually now), and not being able to log in as root from the console (I created another user in the root group and su to root). Everything else surfaced from trying to run the QEMU image on physical hardware, ex: I had to replace the kernel, and I had to remove the --connect-ip argument from novacomd, etc. But anyways, I’m rambling; I’ll try to have the problems and fixes up soon.