Openmoko - User contributions [en]

Talk:Disassembling Neo 1973

2007-10-10T03:07:37Z

Ttz:

Talk:Disassembling Neo 1973

2007-10-10T03:05:07Z

Ttz:

It would be interesting to have a complete set of shots (several views each) of the insides and outsides of the covers, and views from various angles of the phones.

To give ideas of possible hardware add-ons.

Disassembling Neo1973 top cover using the flat-bladed screwdriver instead
- it may be obvious to everyone, but it is probably much easier to use a flat-bladed screwdriver to slide along the side of
the phone to try to open the top cover, instead of what is stated in the "Disassembling..." doc to use the cross-headed screwdriver
coming with the adv kit.

Talk:MokoMakefile

2007-10-04T15:21:26Z

Ttz: /* pango-directfb failed to build due to missing Glib 2.14.x */

== Ubuntu Edgy: Update git-1.4.x to 1.5.x! ==
With old git-1.4.x, fetching uboot does not work: Use 1.5.x:
<pre>
NOTE: package uboot-gta01-1.2.0+svnnow-r4_14da5f7675bbb427c469e3f45006e027b6e21db9_0_1811: task do_fetch: started
fatal: corrupted pack file .git/objects/pack/pack-a146bcbc18f4826d6bf2a7f63be5dd77bbb5b2f5.pack
</pre>

== Fails on a 32bit machine - try again without ccache? ==

<pre>/bin/sh ./libtool --mode=compile ccache gcc -DHAVE_CONFIG_H -I.... -W... -O2 -c -o libbfd.lo build/tmp/work/armv4t-linux/binutils-cross-2.17-r0/binutils-2.17/bfd/libbfd.c
ccache gcc -DHAVE_CONFIG_H -I... -W... -O2 -c /usr/local/oe/build/tmp/work/armv4t-linux/binutils-cross-2.17-r0/binutils-2.17/bfd/libbfd.c -o t shift count >= width of type
make[5]: *** [libbfd.lo] Error 1
</pre>

Any insight here? --[[User:Adam|Adam]] 23:10, 15 May 2007 (CEST)
: Try without ccache (did you get it compiled meanwhile or can we remove this?) --[[User:BernhardKaindl|BernhardKaindl]] 23:05, 19 September 2007 (CEST)

== Building on Fedora Core 6 ==

Install stuff needed for OpenMoko:
# yum install python m4 make wget curl ftp cvs monotone subversion \
tar bzip2 gzip unzip python-psyco ccache perl texinfo texi2html \
diffstat openjade docbook-style-dsssl docbook-style-xsl docbook-dtds \
docbook-utils sed bison bc glibc-devel gcc binutils pcre pcre-devel git \
quilt groff linuxdoc-tools patch compat-gcc-34 lynx netpbm
(notice ''compat-gcc-34'' wich was needed for FC6 (gcc 4 installed), and ''lynx'' which is needed by ''qemu'' (no fallback to ''wget'', ''curl'', or ''links'' at the moment and no check for it, resulting in strange "sleep" errors when trying to build without ''lynx'').

Build it:
$ make setup
$ make openmoko-devel-image
$ unset LD_LIBRARY_PATH
$ make update-makefile && make update && make setup && make openmoko-devel-image

I have also done a
$ unset LD_LIBRARY_PATH; make update-makefile && nice make update && nice make setup && nice make all
(This takes several hours)

Build qemu:
$ make qemu

Run it:
# echo 1024 > /proc/sys/dev/rtc/max-user-freq
$ make run-qemu
This will bring up the OpenMoko :) Use SPACE for AUX and ENTER for POWER.
Not quite the same as holding a Neo1973 in your hands I would guess, but this is the best we can do for now. Thanks!

== Building on Ubuntu Feisty ==

MokoMakefile requires more than 512 MB of RAM + Swap space (around 1GB?).

If you need swap, please '''check that its size under Feisty is not null'''!

[https://bugs.launchpad.net/ubuntu/+bug/105490 Bug #105490] describes the current issue and offers a workaround (23 Jul 07).

== Fails trying to build bluez-utils ==
on Gentoo Linux, it fails compiling bluez-utils (I've tried also "make clean-package-bluez-utils" before the following command)

do a "make build-package-libusb; make clean-package-bluez-utils" and it should continue (the bluez-utils .bb is missing the libusb dependency)

== openSUSE 10.1 and 10.2 workarounds ==

ltrace package fails to build with error:
<pre>
...
checking for pid_t... yes
checking for getopt... yes
checking for getopt_long... yes
checking gelf.h usability... no
checking gelf.h presence... no
checking for gelf.h... no
configure: error: ***** gelf.h not found *****
FATAL: oe_runconf failed
</pre>

'''FIX: '''
edit ''/home/moko/build/tmp/work/armv4t-linux/ltrace-0.4-r0/ltrace-0.4/configure.ac''
at line 44: remove the following block:
<pre>
for path in /usr/include/elfutils /usr/local/include/elfutils \
/usr/include/libelf /usr/local/include/libelf; do
if test -f ${path}/gelf.h; then
CPPFLAGS="$CPPFLAGS -I ${path}"
fi
done
</pre>
( it adds /usr/include/elfutils to path, which causes cross-compile badness error )

=== QEMU build fails to compile USB code ===
<pre>
/usr/include/linux/usbdevice_fs.h:116: error: variable or field `__user' declared void
/usr/include/linux/usbdevice_fs.h:116: error: syntax error before '*' token
/home/moko/openmoko/trunk/src/host/qemu-neo1973/usb-linux.c: In function `usb_host_handle_control':
/home/moko/openmoko/trunk/src/host/qemu-neo1973/usb-linux.c:103: error: invalid application of `sizeof' to incomplete type `usbdevfs_ctrltran
sfer'
/home/moko/openmoko/trunk/src/host/qemu-neo1973/usb-linux.c: In function `usb_host_handle_data':
/home/moko/openmoko/trunk/src/host/qemu-neo1973/usb-linux.c:120: error: storage size of 'bt' isn't known
/home/moko/openmoko/trunk/src/host/qemu-neo1973/usb-linux.c:132: error: invalid application of `sizeof' to incomplete type `usbdevfs_bulktran
sfer'
/home/moko/openmoko/trunk/src/host/qemu-neo1973/usb-linux.c:120: warning: unused variable `bt'
/home/moko/openmoko/trunk/src/host/qemu-neo1973/usb-linux.c: In function `usb_host_device_open':
/home/moko/openmoko/trunk/src/host/qemu-neo1973/usb-linux.c:199: error: storage size of 'ctrl' isn't known
/home/moko/openmoko/trunk/src/host/qemu-neo1973/usb-linux.c:202: error: invalid application of `sizeof' to incomplete type `usbdevfs_ioctl'
/home/moko/openmoko/trunk/src/host/qemu-neo1973/usb-linux.c:199: warning: unused variable `ctrl'
make[2]: *** [usb-linux.o] Error 1
</pre>

'''FIX: '''
edit ''/home/moko/openmoko/trunk/src/host/qemu-neo1973/usb-linux.c''
at line 29 add the following (before ''#include <linux/usbdevice_fs.h>'')
<pre>
#include <linux/compiler.h>
</pre>
hint: there is a copy of the file in ''/home/moko/build/tmp/work/i686-linux/qemu-native-0.9.0+cvs20070613-r5/qemu/usb-linux.c''

''see: http://osdir.com/ml/emulators.kvm.devel/2007-01/msg00101.html''

== Cannot satisfy fstests ==
<pre>
make openmoko-devel-image
...
| Collected errors:
| ERROR: Cannot satisfy the following dependencies for task-openmoko-debug:
| fstests
NOTE: Task failed: /no-backup/Moko/build/tmp/work/fic-gta01-linux/openmoko-devel-image-1.0-r0/temp/log.do_rootfs.25036
NOTE: package openmoko-devel-image-1.0-r0: task do_rootfs: failed
ERROR: TaskFailed event exception, aborting
</pre>
Failed on debian etch 2007-07-20
Solution from mailing list post from hardskinone, report of an irc chat
<pre>
I got help in IRC channel. I do following steps
* remove fstest from oe/packages/tasks/task-openmoko.bb ,
* increase PR field by one
* make openmoko-devel-image
</pre>

== conflicting types for 'futimens' ==

if you encounter the following error:

| In file included from utimecmp.c:40:
| utimens.h:2: error: conflicting types for 'futimens'
| /usr/include/sys/stat.h:370: error: previous declaration of 'futimens' was here

a patch is needed because your glibc is too new. grab & enable the patch as follows

cd openembedded/packages/coreutils
mv coreutils_5.3.0.bb coreutils_5.3.0.orig
wget http://www.openembedded.org/repo/org.openembedded.dev/packages/coreutils/coreutils_5.3.0.bb
cd -
cd openembedded/packages/coreutils/coreutils-5.3.0
wget http://www.openembedded.org/repo/org.openembedded.dev/packages/coreutils/coreutils-5.3.0/futimens.patch
cd -

== Workaround for problems compiling mtd-utils ==

Change the line on <code>openembedded/packages/mtd/mtd-utils_1.0.0+git.bb</code> which reads:

SRC_URI = "git://git.infradead.org/mtd-utils.git;protocol=git;tag=master \

to:

SRC_URI = "git://git.infradead.org/mtd-utils.git;protocol=git;tag=a6fa706fe9e7696b4b2045edf9698c3bac07e3e3 \

which forces the recipe to use an older revision (the one which worked last time I built the image on my computer).

Be sure to remember to undo the change later, or else you will not get any new changes to that package. --[[User:CesarB|CesarB]] 04:48, 25 July 2007 (CEST)

Note: these patches should be updated - the lzo patch is included in the current version, so backing off to the previous version and repatching seems silly. I was able to make it through this part of the build by applying the remaining patches manually. --[[User:Mellon|Ted Lemon]] 15:44, 29 July 2007 (CDT)

== Monotone segfaulting on Ubuntu Feisty Fawn/PPC ==
If you are running Ubuntu Feisty Fawn on a PowerPC computer you will experience problems running monotone. To fix this issue you need to install monotone as well as the libboost packages from Gutsy. The easiest way to accomplish this is to add the gutsy repositories to your sources.list
and change the preferences to look like this:

Package: *
Pin: release a=feisty
Pin-Priority: 700

Package: *
Pin: release a=gutsy
Pin-Priority: -100

Package: libc6 libc6-dev tzdata util-linux libgcc1 libstdc++6 monotone
Pin: release a=gutsy
Pin-Priority: 800

Package: libboost-*
Pin: release a=gutsy
Pin-Priority: 800

After doing this install monotone in this way:
apt-get -t gutsy install monotone.
That should install monotone 0.35 with updated (and working) boost libraries.

== Fails on ncurses install in Fedora 7 with a "tic -x" message ==
Adjust the following command to your system, then run it:
export LD_LIBRARY_PATH=/home/moko/build/tmp/work/x86_64-linux/ncurses-native-5.4-r8/ncurses-5.4/lib
Then start make again and it should pick up where it left off.

You can get a list of potential paths to use with the following command from you main moko directory:
find . | grep libncurses

The basic problem is that it is linking against your main system libraries instead of the OpenEmbedded ones.

There's probably a cleaner way of handling this - please update this entry if you know it.

This has been fixed in Openembedded, see [http://bugs.openembedded.org/show_bug.cgi?id=2554 Openembedded Bug #2554] for further details.

== uboot-gta01 fails to build ==
Changes in the GIT of U-Boot make the OpenMoko patches unapplyable. For the use of Revision ''cc3023b9f95d7ac959a764471a65001062aecf41'' and everything will be fine for now.

== Perl fails to build ==
After following every bit of advice I can find to 'make clean' and nuke the perl build directories, every build comes up with:

| make[1]: Entering directory `/src/openmoko/build/tmp/work/i686-linux/perl-native-5.8.7-r3/perl-5.8.7'
| make[1]: *** No rule to make target `<command-line>', needed by `miniperlmain.o'. Stop.
| make[1]: Leaving directory `/src/openmoko/build/tmp/work/i686-linux/perl-native-5.8.7-r3/perl-5.8.7'
| FATAL: oe_runmake failed
NOTE: Task failed: /src/openmoko/build/tmp/work/i686-linux/perl-native-5.8.7-r3/temp/log.do_compile.19531
NOTE: package perl-native-5.8.7-r3: task do_compile: failed

Solution turned out to be editing
/src/openmoko/build/tmp/work/i686-linux/perl-native-5.8.7-r3/perl-5.8.7/makedepend.SH and at line 169 change the regexp to eat references to "<command.line>" to catch what was leaking through.

== Gettext fails to build ==
Gettext's build is broken unless you have emacs installed. Crazy though it seems. You will see an error like:

<pre>

| WARNING: Warnings can be ignored. :-)
| if test "no" != no; then \
| set x; \
| list='po-mode.el po-compat.el'; for p in $list; do \
| if test -f "$p"; then d=; else d="./"; fi; \
| set x "$@" "$d$p"; shift; \
| done; \
| shift; \
| EMACS="no" /bin/bash ../../config/elisp-comp "$@" || exit 1; \
| if test "no" != no; then \
| set x; \
| list='po-mode.el po-compat.el'; for p in $list; do \
| if test -f "$p"; then d=; else d="./"; fi; \
| set x "$@" "$d$p"; shift; \
| done; \
| shift; \
| EMACS="no" /bin/bash ../../config/elisp-comp "$@" || exit 1; \
| else : ; fi
| mv: cannot move `elc-temp' to `elc-stamp': No such file or directory
| make[5]: Leaving directory `/home/raster/moko/build/tmp/work/i686-linux/gettext-native-0.14.1-r5/gettext-0.14.1/gettext-tools/misc'
| make[5]: *** [elc-stamp] Error 1
| make[5]: Leaving directory `/home/raster/moko/build/tmp/work/i686-linux/gettext-native-0.14.1-r5/gettext-0.14.1/gettext-tools/misc'
| make[4]: *** [po-mode.elc] Error 2
| make[4]: *** Waiting for unfinished jobs....
| make[4]: Leaving directory `/home/raster/moko/build/tmp/work/i686-linux/gettext-native-0.14.1-r5/gettext-0.14.1/gettext-tools/misc'
| make[3]: *** [all-recursive] Error 1
| make[3]: Leaving directory `/home/raster/moko/build/tmp/work/i686-linux/gettext-native-0.14.1-r5/gettext-0.14.1/gettext-tools'
| make[2]: *** [all] Error 2
| make[2]: Leaving directory `/home/raster/moko/build/tmp/work/i686-linux/gettext-native-0.14.1-r5/gettext-0.14.1/gettext-tools'
| make[1]: *** [all-recursive] Error 1
| make[1]: Leaving directory `/home/raster/moko/build/tmp/work/i686-linux/gettext-native-0.14.1-r5/gettext-0.14.1'
| FATAL: oe_runmake failed

</pre>

The solution is simple - install emacs (example below for debian/ubuntu) and try again:

<pre>

sudo apt-get install emacs
make clean-package-gettext-native-0.14.1-r5
make openmoko-devel-image

</pre>

== Fails compiling binutils-cross on Gentoo/AMD64 and openSUSE/x86_64 ==

make setup works fine, but when running make openmoko-devel-image it fails with the following:

<pre>
| make[4]: Entering directory `build/tmp/work/armv4t-angstrom-linux-gnueabi/binutils-cross-2.18-r0/binutils-2.18/build.x86_64-linux.arm-angstrom-linux-gnueabi/libiberty/testsuite'
| make[4]: Nothing to be done for `install'.
| make[4]: Leaving directory `build/tmp/work/armv4t-angstrom-linux-gnueabi/binutils-cross-2.18-r0/binutils-2.18/build.x86_64-linux.arm-angstrom-linux-gnueabi/libiberty/testsuite'
| make[3]: Leaving directory `build/tmp/work/armv4t-angstrom-linux-gnueabi/binutils-cross-2.18-r0/binutils-2.18/build.x86_64-linux.arm-angstrom-linux-gnueabi/libiberty'
| make[2]: Nothing to be done for `install-target'.
| make[2]: Leaving directory `build/tmp/work/armv4t-angstrom-linux-gnueabi/binutils-cross-2.18-r0/binutils-2.18/build.x86_64-linux.arm-angstrom-linux-gnueabi'
| make[1]: Leaving directory `build/tmp/work/armv4t-angstrom-linux-gnueabi/binutils-cross-2.18-r0/binutils-2.18/build.x86_64-linux.arm-angstrom-linux-gnueabi'
| rmdir: build/tmp/cross//home/techiem2/Moko/build/tmp/cross/lib/gcc-lib: No such file or directory
| rmdir: build/tmp/cross//home/techiem2/Moko/build/tmp/cross/lib: No such file or directory
| rmdir: build/tmp/cross//home/techiem2/Moko/build/tmp/cross: No such file or directory
| mv: cannot stat `build/tmp/cross/lib/libiberty.a': No such file or directory
NOTE: Task failed: build/tmp/work/armv4t-angstrom-linux-gnueabi/binutils-cross-2.18-r0/temp/log.do_stage.9730
NOTE: package binutils-cross-2.18-r0: task do_populate_staging: failed
ERROR: TaskFailed event exception, aborting
NOTE: package binutils-cross-2.18: failed
ERROR: Build of openembedded/packages/binutils/binutils-cross_2.18.bb do_populate_staging failed
ERROR: Task 1641 (openembedded/packages/binutils/binutils-cross_2.18.bb, do_populate_staging) failed
NOTE: Tasks Summary: Attempted 107 tasks of which 107 didn't need to be rerun and 1 failed.
ERROR: 'openembedded/packages/binutils/binutils-cross_2.18.bb' failed
make: *** [openmoko-devel-image] Error 1
</pre>

The final reason why the build cannot continue is:
mv: cannot stat `/home/techiem2/Moko/build/tmp/cross/lib/libiberty.a': No such file or directory

Likely, Gentoo/AMD64 uses lib64 instead of lib as the library directory for x86_64 libraries. It's l likey that may (or all?) AMD64 distributions do for their 64-bit binaries. At least on openSUSE-x86_64, the same happens.

At least on openSUSE-10.3 the missing libiberty.a was inatalled to build/tmp/cross/lib64/libiberty.a, which is clearly wrong.

After seeing this, I assumed that openmoko/openembedded was clearly not tested with lib64 build hosts and since that would mean that even if I'd fix that error, many others could follow, and as I was not interested to fix the lib64 bugs but rather wanted to see something running first, I decided to make openmoko/openembedded think that it was running on a normal 32-bit non-lib64 machine.

There are several ways to do that:
* You install an IA32-Linux somewhere and use that for building:
** Do a native install and dual-boot the IA32-linux (That's for dummies which do not know the other tricks)
** Install IA32-Linux in a virtual machine (Quite some setup and has some overhead too)
* you can install a 32-bit development system in to a chroot jail and compile there (also quite some setup and inconvinience)
* Or you can install a 32-bit development system on the 64-bit host (suppored on openSUSE, should be possible with Gentoo/AMD64 too)

I decided to go for the last option - to install a 32-bit development environment and use that:

=== Build cross-binutils, cross-gcc and QEMU using -m32 on 64-bit hosts ===

Here are my notes from openSUSE-10.3, no idea how gentoo names these things:

Install the following packages for the 32-bit C/C++ compiler target option -m32 to work and to compile what is needed

gcc-32bit libgcc-32bit glibc-devel-32bit libstdc++-devel-32bit ncurses-devel-32bit zlib-devel-32bit gtk2-devel-32bit

The current openSUSE 10.3 had no libopenssl-devel-32bit, so I had to install this 32-bit rpm:

libopenssl-devel

For MokoMakefile to not fail on compiling qemu-user, you need gcc33, I used:

wget http://download.opensuse.org/repositories/devel:/tools:/gcc/openSUSE_Factory/i586/cpp33-3.3.3-41.3.i586.rpm
wget http://download.opensuse.org/repositories/devel:/tools:/gcc/openSUSE_Factory/i586/gcc33-3.3.3-41.3.i586.rpm
rpm -Uhv cpp33.rpm gcc33.rpm

Note these are the 32-bit cpp33 and gcc33 rpms as the 64-bit gcc33 rpms for openSUSE do not support the 32-bit target.

Then I used
linux32
In order to build moko with the personality of the system set to i686 (uname -m changes to i686):
cd ~/moko
linux32 su - $USERNAME

And set up gcc scripts which force the compilation of 32-bit binaries:

mkdir bin;cd bin
echo '/usr/bin/${0##*/} -m32 "$@"' >gcc
echo '/usr/bin/${0##*/} -m elf_i386 "$@"' >ld
echo '/usr/bin/${0##*/} --32 "$@"' >gas
sed -i '1i#!/bin/sh' gcc gas ld
chmod 755 gcc gas ld
ln -s gcc cc
ln -s gcc c++
ln -s gcc g++
ln -s gas as
echo PATH=\""$PWD":\$PATH\" >.setup-gcc-m32
cd -

Then set the path and test it:

source bin/.setup-gcc-m32
type gcc

It would be of course much better to fix the binutils build, maybe it's the only build which is broken because binutils may
be a special package, going into the directory where it compiled and grepping for lib64 could help to find the bug.

== More package requirements ==

On my system (Kubuntu 6.10) build failed with message "ERROR: QEMU requires SDL or Cocoa for graphical output" because package <tt>libsdl-image1.2-dev</tt> was missing. Use <tt>apt-get install libsdl-image1.2-dev</tt> to install. Additionally I had to install packages <tt>cvs</tt> and <tt>diffstat</tt>. I was also asked to install Psyco JIT Compiler (package <tt>python-psyco</tt>) to increase performance. Nevertheless <tt>make flash-qemu-local</tt> took some hours, but now I finally can get an impression of the phone that I am looking for! -- [[User:Nichtich|Nichtich]] 00:26, 20 September 2007 (CEST)

== pango-directfb failed to build due to missing Glib 2.14.x ==

The latest(as of Sept. 25, 2007) build started to fail with the following error:

| checking for GLIB... no
| configure: error:
| *** Glib 2.14.0 or better is required. The latest version of
| *** Glib is always available from ftp://ftp.gtk.org/.
| FATAL: oe_runconf failed
NOTE: Task failed:
/media/sdc1/moko/build/tmp/work/armv4t-angstrom-linux-gnueabi/\
pango-directfb-1.18.1-r0/temp/log.do_configure.19927
NOTE: package pango-directfb-1.18.1-r0: task do_configure: failed
ERROR: TaskFailed event exception, aborting
NOTE: package pango-directfb-1.18.1: failed
ERROR: Build of /media/sdc1/moko/openembedded/packages/pango/\
pango-directfb_1.18.1.bb do_configure failed

The Glib included in the build tree seems to be only 2.12.12, so looks like something
is broken in term of dependency.

This had happened on both of Fedora 7 and Debian Etch. I am running the latest
MokoMakefile with OM-2007.2. The funny thing is that the build had worked only
couple nights ago. Any idea? I will update anything I find here and also on my blog(see my user profile).
[[User:ttz|ttz]] Wed Sep 26 12:17:33 CDT 2007

pango-directfb had been removed from OE for now due to the report of it breaking builds like OpenMoko.

[[User:ttz|ttz]] Thu Oct 4 10:20:12 CDT 2007

== uicmoc4 failes to compile ==

this is solved by installing libz-dev

Talk:MokoMakefile

2007-09-26T17:21:59Z

Ttz:

User:Ttz

2007-09-26T17:20:47Z

Ttz:

Updates and more could be found at my blog:

http://tomsville.blogspot.com/

Openmoko Local Groups: North Texas

2007-09-23T05:52:22Z

Ttz:

Welcome to the North Texas openmoko page!

This group is for anyone in the DFW and surrounding areas. Hopefully we'll be able to organize an event for when a few of us get the neos. Local LUGs will probably be interested too, update here as it happens.

{|border=1
!Name
!Skills
!Level of Interest
!Location
!Other
|-
|[[User:jaebird|Jae Stutzman]]
|C++, C# (mono)
|neo1973 SH1 in my hands
|Greenville
|freedom is coming
|-
|Erik Hix
|C#, ninja
|curious
|Rockwall
|[http://www.lostfrog.org/ Who took my frog?]
|-
|[[User:sagacis|Mark Arvidson]]
|C++, mad bo staff
|[[P1_Owners|neo1973 SH1 on the way]]
|Richardson
|*refresh* still in CA *refresh* still in CA *sigh*
|-
|Michael Carter
|C#, C++
|Waiting for Phase 2
|Greenville
|Ready Tomorrow
|-
|Jeff Rush
|C++, Python
|neo1973 SH1 arrived 7/27!
|Richardson
|Will be making tutorial screencasts
|-
|Edward Lineberry
|J2ME, C, rhyme
|neo1973 SH1 in my hands
|Dallas
|Will be be watching tutorial screencasts
|-
|[[User:Dmitri|Dmitri]]
|Translation
|Waiting for Phase 2
|Dallas
|
|-
|Ricky
|C, Python, Ruby, GTK
|App testing, dev for personal use
|Fort Worth
|Want more experience developing for embedded systems. Need a North Texas email list
|-
|[[User:Willtrout|Matt Willtrout]]
|Some c, c++
|Personal use, embedded systems, experience, porting
|E Collin Co
|Ordered, waiting for shipping.:-SS
|-
|[[User:ttz|Tom]]
|kernel,c,java,ruby/rails
|Development. Waiting for my SH1
|Plano
|I created a Google group to serve as our first communication channel, feel free to join in, http://groups.google.com/group/openmoko-dfwug
|-
|}

See [[Talk:OpenMoko_Local_Groups:_North_Texas|discussion]]

[[Category:Community]]