My interest in the future of MeeGo is quite intense, both professionally and personally. Today the CEO of my employer wrote his thoughts into his blog. It was quite interesting read, and hopefully gives new hope for those in doubt.
Planet maemo: category "feed:0c0feabdde04fabb6474d5d8a3e5c362"
On 64-bit platform and willing to try the new fremantle SDK? Look no further, following the previous release, now here are the debs for scratchbox as needed by fremantle.
As last time, the debs are, again, available with apt, just add:
deb http://www.ipi.fi/~pablo/maemo5-sdk_amd64 /to your sources.list and apt-get yourself out!
Following yesterday's vdso32 hack. The same colleague now built amd64 packages for maemo4 scratchbox.
Also with debian repo; just add
deb http://www.ipi.fi/~pablo/sbox_amd64 /to your apt sources.
Scratchbox needs vdso disabled, which can be done run-time with 32-bit kernels. With 64-bit kernels, however, this is not possible... until now. A colleague of mine wrote a (hacky) kernel module to do exactly that, it seeks the vdso-flag and writes 0 to it. I helped him with dkms/deb packaging, and now it's available for download.
Note that this does not help with any other annoyances with sbox on 64-bit system, but at least it is something.
Blobby Volley 2 is a nice volley ball game in the spirit of clbuttic arcade volleyball. However, the default AIs are beatable by jumping in certain point, definitely too easy. Found some AIs over at esnips, and for convenience packaged them for maemo. .install file available as usual. Just install the package, start the game, go to options and select some AI.
Warning: these AIs aren't easy to beat.
After playing around with cairo, I came up with an idea and base for a leetle system monitor for the hildon home. After some twiddling and finishing, it now works somehow and installs nicely. Thanks to hns and his post on ITT for getting me over the last hurdles to get the transparency working. The new project is dubbed mh-home-sysmon and currently supports only showing cpu load and memory usage. Warning: this is the very first release and may break things and most likely will drain your battery. Please report any bugs you find to maemo-hackers ticket system, wishes welcome too (select enhancement as ticket type). Installation easiest by using the .install link.
Here's the mandatory screenshot:
Been a while since I've blogged nor done anything maemo related. Well, for a change I whipped up a new version of osso-statusbar-cpu. I hadn't built it for chinook previously (although the code would have allowed that) and it was still looking like it belonged to OS2007. I whipped up a new base icon for it (based on the battery icon stretched to bigger square).
I'm not too happy how it turned out, but having approximately zero capabilities in graphics, I decided to let it slip as is. Here's a sneak peek of what it looks like:
.
The .install file is available as usual.
As someone somewhere pointed out a long ago, the osso-xterm/vte show bold black as black, not as "bright black". I finally fixed this and new vte is now in repos for mistral, bora and chinook. Currently there's no way to pull this via UI (and OS2008 wouldn't allow it anyway) so if you want it, you need to use some apt-magic.
Obligatory updated screen shot:
I've been running hardy (the upcoming ubuntu LTS release) for a while now. After a kernel update, I noticed I couldn't build any packages anymore due to configure failing when checking if built binaries could be run. A bit of log reading, the error seemed to be: "mmap: permission denied", hmm.
The configure test there should be fairly trivial, but just to be sure, I made a little test program and compiled it. The compiler works just fine but the produced binary gave the same mmap-error, so it seemed the arm emulation was broken. After stracing the binary a bit, I saw that it tried to do mmap(..., 4096, ...), which failed.
The error appeared after a kernel upgrade, so I tried to find something related to mmap in /proc, and find did give me /proc/sys/vm/mmap_min_addr, which had 65536 in it. Running sudo sh -c 'echo 4096 > /proc/sys/vm/mmap_min_addr' was my first instinct and it did indeed fix the problem -- any larger value and the problem resurfaced.
So, if you're running ubuntu hardy (or linux 2.6.24(?)), you might hit this problem; and lowering the mmap_min_addr should help.
By popular request, mh-shot-tool now remembers the last selected method (save to disk vs. flickr) and the last save path. Also, an activity indicator was added for image saving/compression, uploading is still missing one though.
Keep your ideas coming, they just might get implemented. 
A small update for the lucky ones: mh-shot-tool is available for chinook. Just click on the install link.
Despite the fact that the maemo sdk “installer script” is the “preferred” way of installing scratchbox and the roostraps, I have never used it. I prefer to have my dpkg aware of the scratchbox. What I do instead, is grab the scratchbox packages with apt and download the rootstraps manually. These instructions are for debian/ubuntu — on other distros/platforms you’re on your own, sorry.
Most of “my” applications are now chinook ready, at least in the svn. However, I prefer to keep them compatible with mistral and bora, so I need to do little quirks. Let’s investigate osso-xterm’s modifications for example.
What was previously known as hildon-libs, is now hildon-1, so we need to tell configure.ac about this. Before the change, I had:
PKG_CHECK_MODULES(HILDON, hildon-libs >= 0.12.0) AC_SUBST(HILDON_CFLAGS) AC_SUBST(HILDON_LIBS)
Now, as we need to also check for hildon-1, and due to the fact that we need to know it in source as the include paths have changed, it goes like this:
PKG_CHECK_MODULES(HILDON, hildon-1 >= 0.9.9, \
AC_DEFINE(HILDON, 1, [Version of hildon libraries]), \
[AC_DEFINE(HILDON, 0, [Version of hildon libraries]) \
PKG_CHECK_MODULES(HILDON_LIBS, hildon-libs >= 0.12.0)])
AC_SUBST(HILDON_CFLAGS)
AC_SUBST(HILDON_LIBS)
In code, I do the following:
#ifdef HAVE_CONFIG_H # include <config.h> #endif #if HILDON == 1 # include <hildon/hildon-window.h> #else # include <hildon-widgets/hildon-window.h> #endif
There are also some real changes, but with this I get to compile stuff and get warnings/errors for the other stuff that has changed. Those I’ve, again, separated with #if HILDON == 1.
For projects that don’t use autotools, I use this kind of stuff:
mh_shot_tool_CFLAGS += $(shell if pkg-config hildon-1 --exists; then \
pkg-config hildon-1 --cflags; echo -DHILDON=1; \
elif pkg-config hildon-libs --exists; then \
pkg-config hildon-libs --cflags; echo -DHILDON=0; \
else pkg-config gtk+-2.0 --cflags; fi)
Edit: thanks to Loïc for pointing out, the AC_SUBSTs aren’t actually needed, PKG_CHECK_MODULES already does that. You may omit them and it will still work.