[maemo-developers] Survey about Maemo porting problems

[From: tz]

> * What application/software did you want to port to Maemo?

socat, kismet, sox (latest), x11vnc, minicom

> * What did you try to port it based on? (Ubuntu/Debian source package,
> tar.gz, svn, ..etc.)

Debian packages, Ubuntu if available

Remember the whole maemo extras system absoultely REQUIRES a deb package

Debian lenny (or whatever the current version is) seems to be a few
steps ahead or otherwise out of sync with scratchbox.

> * What was the show-stopper(s) that made you give up on trying to port
> this application to Maemo?

dpkg/dhelper/etc above 5 required.  Something wrong in pkgconfig hard
to diagnose

Cross compiling hopelessly broken (does the gcc produce i386
executables?  No, well use --host, and by the way the debian system
will patch/restore/undo any attempts at getting around a broken
config).

Something in /usr/include or /usr/lib didn't match or wasn't the right
version or in the expected place.

> * If you know, what would be the fixes to be made, for these
> show-stoppers if they were to be fixed in the Maemo platform?

Update the package building to debian latest (if it is backward
compatible).  dpkg-buildpackage should work in all modes on all
current debian debs that don't have some specific cross-compiling
problem.

Jam the build environment to do something about the stupid "can I run
executables" test, perhaps upstream into the gnu buildtools horror
show.  (./configure is evil.  It doesn't work as is, so many people
put extra tests which only work in narrower circumstances but are
hopelessly broken when cross compiling or with obsolete systems).

Put together an on-tablet build environment (ext2 SD card image?) for
those things which cannot be fixed to cross compile cleanly (without a
few hundred man-years), and an arm-native host parallel to the current
autobuilder for uncrossable builds.  I successfully did this for my
Sharp Zaurus - it was painfully slow, but it was faster than trying to
fix all the configure horrors.  And many already have full desktops.
An "official" native build environment would help.

Within this it has already been suggested to (allow?) replacing the
busybox with the actual tools in some fashion.  Minimally busybox
needs some things turned on - I'd fatten it as much as possible.

In addition, some of the sdk/tools need to be included or available.
wireless-tools, bluez-utils-test,  bzip2, zip/unzip.  Either that or
fully open and/or fix wlanconfd and the rest so that the tools aren't
necessary.  I can't find ANY code that will return a list of available
access points in either C or Python (some obscure dbus incantation is
necessary, but the examples all crash at the moment).  They just put a
few things and don't really document it and create an API for
bluetooth and wireless, and then get all bothered when it becomes
NECESSARY to install the real CLI tools to get something working at
all, much less in a reasonable manner.   Sending "rfcomm %d %s" to the
system command is a lot cleaner and less buggy than the two dozen
lines of dbus stuff required to do something which may or may not do
the same thing.  I don't think they are going to fix the APIs to make
everything in wireless-tools or bluez-utils-test available in some
other easy manner (with cli examples showing how to do the equivalent
of each of the cli tools using the "official API).

/usr/include/linux is BROKEN!!.  (there is a bugzilla report on this).
 Socat has a test based on this, which if it exists is assumed to at
least let you compile a program which includes one of the files (for
ext2 support), so it says "/usr/include/linux/e2fsXXX exists" so turns
an option on, but that blows up the compile.  Ubuntu includes
/usr/src/linux-kernel-headers for a reason.  the SDK should do the
same.

------------------------

And a more general suggestion.  Up-port and sync a COMPLETE maemo -
osso - hildon setup as close to the Tablet version that runs on TOP of
the  UBUNTU DESKTOP.  It is very close, but there are still things
missing.  For example, the wlanconfd is only accessible via the dbus,
but doesn't exist there.  If I'm trying to develop things, it would be
easier in the ubuntu native environment, but with taskbar and
statusbar and the rest of the hildon specific things, and so the osso
notifications and controls would work and the rest.  That would help
diagnosing and developing.  Having to run sapwood and xephyr, and I
forget how many other things (which aren't in a one-click-to-start
package anywhere) gets tedious.  A one-click start/run would help a
great deal, but not having to turn on anything would be better.