Tue, 21 Nov 2006
Maemo Glossary
As a result of a conversation on IRC a couple of days ago about the connection between the Nokia 770/Maemo and The Flintstones I decided to start a Maemo Glossary in the wiki to preserve such esoterica for future generations.
Posted at: 23:45 | category: /maemo | Comments ()
Catalan to English translation
The other day I discovered an impressive online Catalan to English translation service. At first I didn't know my source document was written in Catalan but a helpful soul on #mamemo helped me out on that score. Some Google-ing revealed a couple of online translation services for Catalan but Translendium was by far the most impressive.
The source page I was translating had information on Nokia 770 reverse engineering and was an interesting find. The resulting translation makes clear when the translation is ambiguous or where there is no appropriate translation known. It managed to turn "Primer hem de extreure les parts de la imatge" into "First we have to extract the parts from the image" which I thought was impressive. Of course translation doesn't always help, such as when one ends up with "costs an egg and half" and one doesn't know how much an egg costs. But from the helpful soul on IRC I learned this is equivalent to the English idiom of "costs an arm and a leg". i.e. Expensive!
If you are interested in learning more check out the detailed Nokia 770 reverse engineering document.
Posted at: 01:05 | category: /maemo | Comments ()
Wed, 08 Nov 2006
Treo 180 Speaker Fix-Up
The other night I finally got around to fixing my Treo 180 so I can actually use it as a phone again. (Certain readers may find that surprising. :-) ) Thanks to this Treo 180 speaker fix guide the operation went mostly smoothly.
I should really have used thinner hookup wire but I just used what I had on hand so it's not the most pretty fix in the world. But at least it works. It really was a bad design flaw that should never have made it past QA.
Cheap, hackable Linux smartphone due soon?
On the subject of cell phones, can I have one of these, please. :-) Interesting seeing the "mad props" given to Nokia. Time will tell what this new entrant (assuming it appears as forecast) will mean to existing FLOSS/Linux-based players such as Nolkia's Maemo and the Palm-related Access platform.
Posted at: 01:00 | category: /maemo | Comments ()
Sat, 30 Sep 2006
Bluetooth-based Social Engineering
An article about an advertising sign that uses detection of Bluetooth devices as a way to determine what it should display reminded me of a thought I had during my time in US airports.
For laughs I ran this simple Python script on my Nokia 770 while sitting in various airports:
#!/usr/bin/python
import bluetooth
for i in bluetooth.discover_devices():
print bluetooth.lookup_name(i)
Anyway, in addition to the occasional obscene device name it struck me that device names offer a form of information leakage. (I'm sure that's not an original thought.) I did wonder how much you could get away with from learning someone's name ("Joe Smith's AZ890 Cell") and recognizing the model of phone: "Hey, Joe, Joe Smith, is that you? Wow, long time no see...". So, are generic device names (Bluetooth-accessible or otherwise) simply security-by-obscurity or a vital form of defense against dangerous social engineering? </dum-da-dah!>
Posted at: 11:55 | category: /maemo | Comments ()
Maemo Browser Tab Grab Bag #2
Continuing the series here's some of the open tabs related to Maemo and Nokia 770 projects in some way:
Linux Automation Tools
For the controllee side of Maemote on Mac OS X the choice of the initial automation tool to support is fairly obvious—AppleScript. Unfortunately in Linux-land the choice isn't so obvious, so here's a few related tools I've noticed recently, it remains to be seen what is most widely supported:
- dogtail—"an automation framework for GNOME and other applications that use ATK or otherwise support accessibility via AT-SPI", "written in Python" and "AT (assistive technology)".
- PyUNO OpenOffice.org example.
- S-Flux—cross-platform graphical automation tool.
- Atomato—a currently DBUS-based scripting and automation tool for GNOME (early stages).
- McClient—A project from late last year to write a Nokia 770-based control system for MPD and Muine.
Mac OS X Automation and AppleScript notes
As the current Maemote version uses AppleScript on Mac OS X I needed a few pieces of information:
For a basic forward/backward action suitable for slides and so forth I needed the correct arrow key values to pass to the System Events handler:
orkey code 123 -- Left key code 124 -- Right key code 125 -- Down key code 126 -- Up
keystroke (ASCII character 28) -- Left keystroke (ASCII character 29) -- Right keystroke (ASCII character 30) -- Up keystroke (ASCII character 31) -- Down
Although dated, this Scripting the Unscriptable in Mac OS X article may be helpful also. (See also.)
For future reference this Mac OS X home automation tool might be useful.
Hachoir
When I was playing around with creating ar format files in Python I was thinking about reading or investigating binary file formats using Python. Soon after I discovered Hachoir "a library written in Python which allows to see and edit a binary file (or any binary stream) field per field". I didn't look too far into the library but it seems worth further investigation should the need arise—and, yes, it does have ar file format read support. :-)
Convert video for Nokia 770 viewing
An online tool to convert video into a format suitable for viewing on the Nokia 770—I haven't used it yet but if I ever get around to getting that bigger RS-MMC card (in capacity, not physical size, obviously...) it might be useful. The 770 video conversion software used is also available off-web too.
Other stuff
stdeb - Python to Debian source package conversion utility (still requires Debian packaging tools to be installed though).
Posted at: 11:25 | category: /maemo | Comments ()
Sat, 16 Sep 2006
Announce: Maemote — turn your Nokia 770 into a Bluetooth remote
Finally after weeks of veiled allusions today I can announce the "got-to-have-a-release-to-accompany-my-linux.conf.au-proposal" release of Maemote--the Nokia 770 Bluetooth remote application.
Now you can easily control specific functions of your desktop or laptop from your Nokia 770 with Maemote--the Bluetooth remote.
Features
- Use Maemote on your Nokia 770 to control applications on your desktop or laptop (Mac OS X only currently--but the intention is to make it multi-platform).
- Connects using Bluetooth.
- The potential to control your music player, movie player, presentation software, terminal, home automation and more!
- Customisable commands and interface--use the touch screen or hardware buttons to send commands. Create task-specific (e.g. entertain, presentation) interfaces and command sets.
Downloads
Other
Maemote is currently a "technology preview"--it has many rough or non-existant edges--but I hope you'll find it useful in some form and maybe try hacking on some command actions for it.
Thanks
A big thanks to aCiDBaSe on #maemo for being the first to take the time and be brave enough to test the release. :-)
And, of course, a big thank you to you-know-who for supporting me. :-)
What's in a name?
Oh, and by the way, if you could tell me whether or not Maemote is an hideously offensive word in Tagalog or some other language I'd be interested to know...
This release brought to you by bdist_maemo
The Maemo package for Maemote was created with bdist_maemo. If you're wanting to package a Python (or other language?) application for Maemo/Nokia 770 check it out.</pimping>
Posted at: 10:35 | category: /maemo | Comments ()
Fri, 15 Sep 2006
Announce: bdist_maemo disutils package released
Hmmm, where did that come from? Somehow the Python ar file creation script and the mkdeb shell scripts turned into a distribution packaging command bdist_maemo for distutils. The command produces .deb files suitable for installation with the Nokia 770/Maemo Application Installer.
The command is a pure-Python implementation and requires no external tools (i.e. no ar, tar, gzip, perl, debhelper or dpkg-dev installation is needed). It includes a generic .deb package file class which could be used for generic .deb file creation but I've only tested it with the Nokia 770 Application Installer.
It's a first cut that "works for me" and is under-documented but does include an example Python script and example_setup.py packaging script. After unzipping bdist-maemo-0.1.0.zip run python example_setup.py bdist_maemo. If it works for you (or not) I'd appreciate you letting me know.
I've opened a ticket in the Maemo Bugzilla for adding bdist_maemo to the pymaemo distribution as the result of a request on IRC #maemo.
Posted at: 08:50 | category: /maemo | Comments ()
Wed, 13 Sep 2006
Create ar files from Python
Heh, you knew this was going to happen, didn't you..? :-)
Okay, so maybe I did end up writing a small Python module to create ar (archive) format files.
Posted at: 03:25 | category: /maemo | Comments ()
Mon, 11 Sep 2006
Packaging Python Maemo applications on a non-Debian platform (Part Two)
Continued from part one...
bdist_deb or not
After deciding to try a different approach I wondered if there was a Python distutils command for packaging a Debian .deb package. Turns out someone wrote a patch for a bdist_deb command but the bdist_deb patch is still sitting in the SourceForge patch tracker.
Unfortunately I soon discovered the bdist_deb command still requires the other Debian packaging scripts to be installed! :-( (I've since noticed the patch includes a "pythonic" version of dh_make that appears to only rely on one of the standard tools so potentially it could be modified slightly.)
Due to the dependency on the standard scripts--already given up on--this looked like another dead end.
What's in a .deb anyway?
By this time I was starting to think it might be quicker to reinvent the wheel so I decided to look into what made up a .deb package. Wikipedia has a summary on the implementation of .deb packages:
deb file is implemented as an ar archive. Canonical contents of this archive are 3 files:
- debian-binary - deb format version number
- control.tar.gz - all package metainformation
- data.tar.gz - the actual installable files
Hmmm... that's starting to look straight-forward. Along the way I discovered some other useful descriptions of the file format and contents of individual files:
- deb -- Debian binary package format (man page)
- Creating Debian Packages
- dpkgdeb -- Debian package archive (.deb) manipulation tool (man page)
- Debian Binary Package Building HOWTO
The internals of this Debian binary package format are described in the deb(5) manual page. Because this internal format is subject to change (between major releases of Debian), always use dpkg-deb(8) for manipulating .deb files.This means any utility that doesn't use the official tools is "bad" but by this stage I don't care--I just want to make an install package for the Nokia 770!
Show me some code!
After getting a general overview of the file format and content I decided I'd write a couple of simple shell scripts to make my install package. (I considered a Python script but have bigger plans for that, more on that later.) It turns out you can create an installable package with little more than mkdir, ar, tar, gzip and a text editor.
Without further ado, the first of the tools in the mkdeb toolkit, mkdeb-init.sh:
#!/bin/sh
#
# Create directory structure to be used for a .deb file
#
TARGET_DIR=$1
echo Creating ${TARGET_DIR}...
mkdir ${TARGET_DIR}
mkdir ${TARGET_DIR}/control
mkdir ${TARGET_DIR}/data
echo "2.0" > ${TARGET_DIR}/debian-binary
touch ${TARGET_DIR}/control/control
echo Done.
This will produce a directory tree along with a couple of pre-created files, like so:$ mkdeb-init.sh my-test-package Creating my-test-package... Done.
$ ls -R my-test-package ./my-test-package: control data debian-binary ./my-test-package/control: control ./my-test-package/data:
You need to edit <dir>/control/control--for the OS2006 Application Installer this seems to be sufficient:
Package: [name] Version: [version] Section: user/other Priority: optional Architecture: all Maintainer: [email] Depends: python2.4, python2.4-hildon, python2.4-gtk2 Description: [short description] [indented long description]
Next, you need to copy your code into the final installation destination of your code in the <dir>/data/ directory. For example, if you have a script foo to be installed in /usr/bin/ on the Nokia 770 then you need to put it here:
(You could obviously use a Python setup.py script to do this for you like the Python Maemo tutorial suggests.)<dir>/data/usr/bin/foo
By now you should have everything in place so you can now use the second half of the mkdeb toolkit, mkdeb-pack.sh:
#!/bin/sh
#
# Pack a directory structure into a .deb file
#
TARGET_DIR=$1
OUTPUT_FILEPATH=${TARGET_DIR}/$2
FILEPATH_CONTROL_TGZ=${TARGET_DIR}/control.tar.gz
FILEPATH_DATA_TGZ=${TARGET_DIR}/data.tar.gz
FILEPATH_DEBIAN_BINARY=${TARGET_DIR}/debian-binary
DIRPATH_CONTROL=${TARGET_DIR}/control
DIRPATH_DATA=${TARGET_DIR}/data
echo Using ${TARGET_DIR} to create ${OUTPUT_FILEPATH}...
tar czvf ${FILEPATH_CONTROL_TGZ} -C ${DIRPATH_CONTROL} --exclude=*~ .
tar czvf ${FILEPATH_DATA_TGZ} -C ${DIRPATH_DATA} .
ar -r ${OUTPUT_FILEPATH} ${FILEPATH_DEBIAN_BINARY} ${FILEPATH_CONTROL_TGZ} ${FILEPATH_DATA_TGZ}
echo Done.
$ mkdeb-pack.sh my-test-package my-test-package_0.1.0-1.deb Using my-test-package to create my-test-package/my-test-package_0.1.0-1.deb... ./ ./control ./ ./usr/ ./usr/bin/ ./usr/bin/foo Done.
You've almost got a usable installer--in fact if you have no executables it should work okay but you're going to run into some ownership and permissions problems in the package's current form.
Post-install Permission and Ownership fixes
In theory it's possible to set the correct ownership and permission when the files are tared but the version of tar on Mac OS X doesn't support the options. (If we use the Python tarfile library we can set them also--I'm looking at that option for the future.)
We'll need to re-pack our .deb but we can solve the permissions/ownership issue by creating a <dir>/control/postinst shell script. The script can be as simple as this (assuming the exec bit was previously set):
#!/bin/sh chgrp users /usr/bin/foo chown user /usr/bin/foo
Now, if you re-run the mkdeb-pack.sh script you should be good to go with a fresh Nokia 770-installable Python application.
The future
The most obvious enhancement is to turn all of this into a Python distutils bdist_ command extension and not rely on any external tools. This is almost do-able at present but I haven't found an ar archive format creation library for Python. The ar archive file format looks fairly straight-forward so it shouldn't be too much of a problem.
Anyway, all this is Works For Me, so I'd be interested to hear if it's useful for anyone else. Feel free to contact me at follower@rancidbacon.com.
Posted at: 02:25 | category: /maemo | Comments ()
Sun, 10 Sep 2006
Packaging Python Maemo applications on a non-Debian platform
Over the past few days I've been working on packaging my application to be a "real" installable Nokia 770 application. After working through the basic desktop integration side of things it was time to create the installable package. The packaging process as described in the tutorial appeared to be relatively straight-forward, if a little tedious...
Alas--as often seems to be the case for me--apparently I was trying to do something just a little bit different from the norm and the documented approach did not work. The main sticking point seemed to be I was running the packaging process on a non-Debian box--specifically Mac OS X.
dh_make
First up I attempted to use the dh_make script to generate the required template files. Although the script is written in Perl unfortunately I couldn't even get a usage message to display--I got multiple lines of error messages instead:
So, the moral of that story for script writers is: if you're only asked for a usage message please don't do a whole lot of processing before you (don't) display it. :-)$ ./dh_make --help awk: invalid -v option Can't match key XXXX in map passwd.byname. Reason: Request arguments bad ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1) ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1) Unable to find 822-date program in /usr/bin!
From reading the source I discovered you could set environment variables to supply the username and email address it was attempting to find which fixed a couple of the errors. In addition, rather than integrating the downloaded but non-installed 822-date script I just chucked in a hardcoded value for the date. I then changed the hardcoded dh_make install location and by also changing two cp -a to a cp -pR I got it to do enough to generate the required control and rules files.
As a side note: the dh_make script is in the dh-make package. (Note: the change from underscore ('_') to dash ('-') in the name which I think contributes to the bad Google-juice for the script name.) It also wasn't immediately obvious to me but at the bottom of the just linked Debian package page is a link to the actual dh_make / dh-make source tar ball.
debhelper, dpkg-dev, fakeroot and friends
I'll spare you the full story but needless to say--after downloading the required packages debhelper, dpkg-dev and the like--when I ran the required tool I wasn't over-awed by my extreme success:
And so on, and so forth. While I admit I didn't have all the scripts installed (i.e. I was trying to point the scripts to the uninstalled locations), by this time it was seeming like a whole lot of effort to get anywhere for what wasn't that complicated an operation. So, I did a -d and hit the next bump:$ dpkg-buildpackage.sh -rfakeroot dpkg-buildpackage.sh: source package is test-package dpkg-buildpackage.sh: source version is 1.0.0-1 dpkg-buildpackage.sh: source maintainer is fullname <a@b.com> dpkg-architecture: warning: Unknown gcc system type powerpc-apple-darwin8, falling back to default (native compilation) dpkg-architecture: warning: Specified GNU system type powerpc-darwin does not match gcc system type powerpc-apple-darwin8. dpkg-architecture: warning: Unknown gcc system type powerpc-apple-darwin8, falling back to default (native compilation) dpkg-architecture: warning: Specified GNU system type powerpc-darwin does not match gcc system type powerpc-apple-darwin8. dpkg-buildpackage.sh: host architecture is darwin-powerpc /var/lib/dpkg/status: No such file or directory dpkg-buildpackage.sh: Build dependencies/conflicts unsatisfied; aborting. dpkg-buildpackage.sh: (Use -d flag to override.)
And indeed it wasn't. (Found, that is.)... dpkg-buildpackage.sh: host architecture is darwin-powerpc fakeroot debian/rules clean dpkg-buildpackage.sh: line 175: fakeroot: command not found
Turns out fakeroot is a not-entirely trivial piece of code apparently not currently available on OS X--although it seems someone has at least tried porting fakeroot to Mac OS X. By this stage I had no real interest in trying the fakeroot port (I'm only packaging a Python script for pete's sake!) so I decided I needed to find another approach.
Apparently I'm not the only person to get frustrated by Debian packaging tools--but the thread in question does cover some interesting material. (Also, here's Ubuntu's take on Debian packaging.)
bdist_deb or not
Need some sleep so this is to be continued... (But, you know, thought I'd release early and often...)
Rest assured--while this is a bit of a rant I do have a constructive purpose and solution in hand and I'm only documenting things so thoroughly to provide Google-bait to hopefully help prevent someone else from spending the same time discovering the same things. :-)
Update: Part two
Posted at: 01:25 | category: /maemo | Comments ()