OpenMoko2007.2

From Openmoko

Revision as of 18:25, 3 August 2007 by Thebohemian (Talk | contribs)

Jump to: navigation, search

As of 2007-07-26 the development of the next version of the OpenMoko distribution has begun.

Goals of the new version are an improved set of PIM applications, improved theming that fixes a lot of the usability problems of the 1st generation design, more formalized UI guidelines and a number of changes in the build system. The latter should introduce more recent software by staying closer in sync with upstream org.openembedded.dev.

An official announcement is expected soon.

(Initially this was named OM-2008 in SVN but renamed shortly after that.)

Contents

How to build

Please note that this is no official guide on how to build OM-2007.2. I am just making my first steps getting this to compile and think it would be a waste of time of I keep problems I found for my own. Additionally it would be good if the new distro gets more exposure and testing so less things will break after the official announcement.

Follow the getting started steps of OpenEmbedded. Use Bitbake from the stable branch from SVN (not the 1.8.6 release - does not work!) and the org.openembedded.dev branch of OE.

Put the following in your local.conf 

BBFILES = "${HOME}/oe/org.openembedded.dev/packages/*/*.bb"

MACHINE = "fic-gta01"
DISTRO = "openmoko"

ENABLE_BINARY_LOCALE_GENERATION = "1"
GLIBC_GENERATE_LOCALES = "en_GB.UTF-8"

Replace "${HOME}/oe" with the path to where your "org.openembeded.dev" folder lives. For the other entries have a look at conf/local.conf.sample about their meaning.

Run bitbake <package name> (e.g. openmoko-devel-image).

Hopefully the MokoMakeFile is soon upgraded to be used for OM-2007.2. Since OpenMoko is not using the overlay any more that makefile should be simpler then. :-)

Build issues

Wrong certificate

You may get something like this while the bitbake recipes are parsed: 

Error validating server certificate for 'https://libw100.svn.sf.net:443':
 - The certificate hostname does not match.
 Certificate information:
  - Hostname: *.svn.sourceforge.net
  - Valid: from Fri, 27 Oct 2006 12:05:58 GMT until Sun, 28 Oct 2007 13:05:58 GMT
  - Issuer: Equifax Secure Certificate Authority, Equifax, US
  - Fingerprint: f2:6c:fe:bb:82:92:30:09:72:dd:1c:b3:e7:56:69:c7:7a:df:67:3e

That is an issue in a bitbake file. One should not use the short-name for sourceforge (sf.net) when certificates are only for exact host names. Accept the certificate and everything is fine for now.

libgsmd FTBFS

Another problem that will most likely arise is that patching libgsmd will fail. You will get an error message that (besides other stuff) contains these lines: 

.
.
.
Applying patch extreplychars.patch
patching file src/gsmd/atcmd.c
Hunk #1 succeeded at 202 (offset -6 lines).
Hunk #2 FAILED at 249.
1 out of 2 hunks FAILED -- rejects in file src/gsmd/atcmd.c
can't find file to patch at input line 27
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|Index: gsm/src/gsmd/vendor_qc.c
|===================================================================
|--- gsm.orig/src/gsmd/vendor_qc.c      2007-06-03 10:46:19.000000000 +0200
|+++ gsm/src/gsmd/vendor_qc.c   2007-06-03 11:45:58.000000000 +0200
--------------------------
.
.
.

I got the built to continue by removing all the patches. For this open packages/gsm/libgsmd_svn.bb and remove all parts of the SRC_URI variable where it says patch=1. Someone with deeper knowledge on gsmd should decide whether those patches are still needed (and especially on the Neo). Since I want to run the image in the emulator only a fully working gsmd is not that important to me.

I expect that the metadata for gsmd will be updated soon to fix the build issues. You should revert your local changes then (mtn revert packages/gsm/libgsmd_svn.bb).

openmoko-libs FTBFS

Some applications have not been fully modified to build with the new libraries of OpenMoko and still need the old-style openmoko-libs package. libmokogsm which is needed for openmoko-libs then fails to build. As a workaround you can remove the not yet ported applications that need openmoko-libs making it unneccessary itself. To do this edit packages/tasks/openmoko-taks.bb and find the following lines: 

.
.
.
 openmoko-terminal \
 matchbox-panel-2 \
 matchbox-panel-2-applets \
 matchbox-applet-inputmanager \
#  openmoko-appmanager \
 matchbox-keyboard \
 matchbox-stroke \
 openmoko-keyboard \
.
.
.

Now put a dash (#) before openmoko-terminal and openmoko-keyboard. You can verify that openmoko-libs is not needed any more by issuing bitbake -g openmoko-devel-image (= creates a dependency graph). There should be no mentioning of openmoko-libs in the file task-depends.dot. Please note that the graphics terminal will be missing now. You can still have terminal access by following the USB Networking guide.

Flashing with MokoMakefile

Since MokoMakefile has not been adjusted to use the new build layout you cannot use it. As a quick hack to make flashing local built image possible again try this:

Find the following lines in the MokoMakefile: 

flash-qemu-local: stamps/qemu stamps/openmoko-devel-image
      ( cd build/qemu && openmoko/flash.sh ../tmp/deploy/images )

And replace them with: 

flash-qemu-local: stamps/qemu
       ( cd build/qemu && openmoko/flash.sh <MY_NEW_BUILD_DIR>/tmp/deploy/images )

Where you should replace <MY_NEW_BUILD_DIR> with the full path to your build directory (the one where conf/local.conf lives in). (This has not been tried yet since my image is still building.) Running the image should work, too. :-)

Retrieved from "http://wiki.openmoko.org/index.php?title=OpenMoko2007.2&oldid=15935"
Personal tools

As of 2007-07-26 the development of the next version of the OpenMoko distribution has begun.

Goals of the new version are an improved set of PIM applications, improved theming that fixes a lot of the usability problems of the 1st generation design, more formalized UI guidelines and a number of changes in the build system. The latter should introduce more recent software by staying closer in sync with upstream org.openembedded.dev.

An official announcement is expected soon.

(Initially this was named OM-2008 in SVN but renamed shortly after that.)

How to build

Please note that this is no official guide on how to build OM-2007.2. I am just making my first steps getting this to compile and think it would be a waste of time of I keep problems I found for my own. Additionally it would be good if the new distro gets more exposure and testing so less things will break after the official announcement.

Follow the getting started steps of OpenEmbedded. Use Bitbake from the stable branch from SVN (not the 1.8.6 release - does not work!) and the org.openembedded.dev branch of OE.

Put the following in your local.conf 

BBFILES = "${HOME}/oe/org.openembedded.dev/packages/*/*.bb"

MACHINE = "fic-gta01"
DISTRO = "openmoko"

ENABLE_BINARY_LOCALE_GENERATION = "1"
GLIBC_GENERATE_LOCALES = "en_GB.UTF-8"

Replace "${HOME}/oe" with the path to where your "org.openembeded.dev" folder lives. For the other entries have a look at conf/local.conf.sample about their meaning.

Run bitbake <package name> (e.g. openmoko-devel-image).

Hopefully the MokoMakeFile is soon upgraded to be used for OM-2007.2. Since OpenMoko is not using the overlay any more that makefile should be simpler then. :-)

Build issues

Wrong certificate

You may get something like this while the bitbake recipes are parsed: 

Error validating server certificate for 'https://libw100.svn.sf.net:443':
 - The certificate hostname does not match.
 Certificate information:
  - Hostname: *.svn.sourceforge.net
  - Valid: from Fri, 27 Oct 2006 12:05:58 GMT until Sun, 28 Oct 2007 13:05:58 GMT
  - Issuer: Equifax Secure Certificate Authority, Equifax, US
  - Fingerprint: f2:6c:fe:bb:82:92:30:09:72:dd:1c:b3:e7:56:69:c7:7a:df:67:3e

That is an issue in a bitbake file. One should not use the short-name for sourceforge (sf.net) when certificates are only for exact host names. Accept the certificate and everything is fine for now.

libgsmd FTBFS

Another problem that will most likely arise is that patching libgsmd will fail. You will get an error message that (besides other stuff) contains these lines: 

.
.
.
Applying patch extreplychars.patch
patching file src/gsmd/atcmd.c
Hunk #1 succeeded at 202 (offset -6 lines).
Hunk #2 FAILED at 249.
1 out of 2 hunks FAILED -- rejects in file src/gsmd/atcmd.c
can't find file to patch at input line 27
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|Index: gsm/src/gsmd/vendor_qc.c
|===================================================================
|--- gsm.orig/src/gsmd/vendor_qc.c      2007-06-03 10:46:19.000000000 +0200
|+++ gsm/src/gsmd/vendor_qc.c   2007-06-03 11:45:58.000000000 +0200
--------------------------
.
.
.

I got the built to continue by removing all the patches. For this open packages/gsm/libgsmd_svn.bb and remove all parts of the SRC_URI variable where it says patch=1. Someone with deeper knowledge on gsmd should decide whether those patches are still needed (and especially on the Neo). Since I want to run the image in the emulator only a fully working gsmd is not that important to me.

I expect that the metadata for gsmd will be updated soon to fix the build issues. You should revert your local changes then (mtn revert packages/gsm/libgsmd_svn.bb).

openmoko-libs FTBFS

Some applications have not been fully modified to build with the new libraries of OpenMoko and still need the old-style openmoko-libs package. libmokogsm which is needed for openmoko-libs then fails to build. As a workaround you can remove the not yet ported applications that need openmoko-libs making it unneccessary itself. To do this edit packages/tasks/openmoko-taks.bb and find the following lines: 

.
.
.
 openmoko-terminal \
 matchbox-panel-2 \
 matchbox-panel-2-applets \
 matchbox-applet-inputmanager \
#  openmoko-appmanager \
 matchbox-keyboard \
 matchbox-stroke \
 openmoko-keyboard \
.
.
.

Now put a dash (#) before openmoko-terminal and openmoko-keyboard. You can verify that openmoko-libs is not needed any more by issuing bitbake -g openmoko-devel-image (= creates a dependency graph). There should be no mentioning of openmoko-libs in the file task-depends.dot. Please note that the graphics terminal will be missing now. You can still have terminal access by following the USB Networking guide.

Flashing with MokoMakefile

Since MokoMakefile has not been adjusted to use the new build layout you cannot use it. As a quick hack to make flashing local built image possible again try this:

Find the following lines in the MokoMakefile: 

flash-qemu-local: stamps/qemu stamps/openmoko-devel-image
      ( cd build/qemu && openmoko/flash.sh ../tmp/deploy/images )

And replace them with: 

flash-qemu-local: stamps/qemu
       ( cd build/qemu && openmoko/flash.sh <MY_NEW_BUILD_DIR>/tmp/deploy/images )

Where you should replace <MY_NEW_BUILD_DIR> with the full path to your build directory (the one where conf/local.conf lives in). (This has not been tried yet since my image is still building.) Running the image should work, too. :-)