[Community] [Gta04-owner] Report on QtMoko

Sven Dyroff S.Dyroff at phytec.de
Fri Jun 17 14:33:22 CEST 2016

Hello Nikolaus,

> I am already happy if that is
> a strech goal and the initial goal is to get in compile & run again on 
top of Debian
> (like it was some time ago).

Perhaps it's the easiest and fastest way that I did with QtMoko V46 in 
August 2012, although it's the most stupid one. Because so many people 
comlained about failed trials to build QtMoko at that time and finally I 
intended to try it by myself, I did the following:

- Using VM Workstation manager I created a completely new and empty VM.

- I began to follow Radek's readme step by step in the way as I understood 

- After *each* step I took a snapshot from the VM and created a precise 
protocol of these steps and the associated snapshots.

- Like many others on this list before me, at some time I encountered the 
first build error.

- I began to consider if the last steps of Radek's readme that I had 
executed could somehow be understood in another way.

- After identifying such a possibility, I used the VM workstation manager 
in order to remigrate to the appropriate VM snapshot. Then I executed the 
alternative possibility of the step.

- I stepped forward towards the next steps, again precisely protocolling 
them and taking snapshots of the VM, until I encountered the next build 

- I reiterated this procedure as long until I succeeded.

In the end it turned out that the essential key was the sequence in that 
you need to do installations of software packages and updates of these 
software packages. In particular it makes a big difference if you do

  - install A
  - install B
  - update

or if you do

  - install A
  - update
  - install B
  - update

In the end I published the final protocol on this list and indeed other 
guys confirmed that this was working.

But if you do so, please be also aware of some completely unexpected 
Radek shot down almoust all of my explanations, ranted and clamoured that 
he didn't like this and didn't like that what I exposed, and not only 
refused to upload my guidance to his sourceforge account, but even didn't 
reworked his own guidance in order to make it clearer for others than 

Up to now I didn't commemorate this old story, but because in the 
meanwhile it seems to be a severe show stopper that noone exept Radek 
himself manages to get QtMoko compiling and unfortunately I don't find the 
time to do that work again for V57 at the moment, I hereby attach my 
guidance from V46 again in the hope that it might be useful for someone. 
Possible abuses to me are useless, and all others have herewith be 

Best regards


Cross compling from sources

* You need to set up a system with Debian Wheezy, using
  and to get it up-to-date:

apt-get update

* Install Qt with XLib
  This must be done BEFORE installing the emdebian toolchain because 
otherwise you'll get
  version conflicts between Wheezy and Squeeze, resulting in compile 
errors while doing
  the "qtmoko/configure" command.

apt-get build-dep libqt4-dev
apt-get install libqt4-dev libv4l-dev libdbus-1-dev libqt4-sql-sqlite

* Use emdebian toolchain
  Add emdebian apt repos and also sqeeze repos for older packages 
according to

apt-get install emdebian-archive-keyring
echo "deb http://ftp.cz.debian.org/debian/ squeeze main contrib non-free" 
>> /etc/apt/sources.list
echo "deb http://www.emdebian.org/debian wheezy main" >> 
apt-get update

* Install armel cross compiler:

apt-get install g++-4.4-arm-linux-gnueabi

* Install xapt and libraries qtmoko depens on:

apt-get install xapt
xapt -a armel -m libqt4-dev libts-dev libasound2-dev libspeexdsp-dev 
libssl-dev libxtst-dev libbluetooth-dev libdbus-1-dev

* Make link for dbus.h:

cd /usr/arm-linux-gnueabi/include
ln -s dbus-1.0/dbus dbus
cd -

* Install git:

apt-get install git

* Clone current git tree:
  Note: When you fetch from a git repository, you get the entire commit 
  at least for the branch that you asked for. This may include other tags 
that you
  did not ask for explicitly. When you do "git fetch <your-remote>" 
  specifying a branch or tag, git will fetch *all* branches.
  Looks like QtMoko uses submodules that use submodules. Git submodule 
  are still in their infancy, I'd say, so expect some warts. Where the 
  git supports it, I usually use "git submodule init" (initial checkout) 
or "git
  submodule sync" (subsequent checkouts), followed by "git submodule 
  --recursive". Check the documentation.

git clone git://github.com/radekp/qtmoko.git

  Note: Creates a local tracking branch for "master" only!
  (As can be checked with "git branch" within subdirectory "qtmoko".)

* Get a tracking branch for "master_gta04":

cd qtmoko
git checkout master_gta04
git pull

* Initialize and update submodules
  To ensure a consistent state of your directory tree,
  you need to issue all three submodule commands *after* every change of 
branch (checkout).
  When the sync command and init option are not used upon subsequent 
  "git submodule update" can "get stuck" and refuse to proceed because of 
"unknown commits".
  After "git submodule init" and "git submodule update" the 
"qtopiacore/qt"-directory should be populated with Qt sources.
  This directory and few others are git submodules so that we can track 
easily the upstream - you can even see it on github:

git submodule init
git submodule sync
git submodule update

* Create build directory (you can't build from the git directory):

mkdir ../build
cd ../build

* Build it:

../qtmoko/configure -system-qt -device gta04
make install

* Create archive "qtmoko-update.tar.gz", move it to "root at" 
and extract it there to "/opt/qtmoko":



* If you want translations to various languages you need to checkout the 
translations git branch:

git checkout origin/translations -b translations

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.goldelico.com/pipermail/community/attachments/20160617/9b37b91f/attachment.html>

More information about the Community mailing list