[Shr-User] SHR-unstable got a facelift. And you a christmas present....

Sebastian Spaeth Sebastian at SSpaeth.de
Thu Nov 19 16:15:19 CET 2009


[Nov 19 2009, The Internets] It's been psychologically proven that the
longer you wait for your presents, the more happy you will be when you
finally get them. It seems, the SHR team wants to make you REALLY happy
and has let you waiting for quite some time without updates to
shr-unstable...

ENOUGH WAITING. Christmas comes a bit early this year, and a new
SHR-unstable image is out for public consumption. Keep in mind that this
is the first snapshot after quite many major transitions, so don't
complain if things are a bit ..well... unstable in the beginning. We are
working hard to stabilize things. If you depend on your phone, you will
probably not yet want to use this, e.g. right now the ringtones aren't
working (it just vibrates).

We had no resources to provide a nice and working upgrade path, so an
opkg upgrade is very likely to lead to a non-working system. (Really! It
won't work. We know you'll try anyway :). It still won't work). So
download the image (http://build.shr-project.org/shr-unstable), flash it
and start afresh. I am writing this before the new images are out there,
so be a bit patient before you can really grab them.

We will take a branch off current shr-unstable in a couple of weeks
(after the dust has settled a bit) and start a conservative branch that
will allow for more -testing releases and -finally- a stable snapshot.
If others want to volunteer to do that, I'll happy hand over that job
though.

So what has changed, and what to expect:

    * First don't expect any miracles. While stuff has changed under the
hood, you are still owning a fine piece of open. but outdated hardware.
But a path has been laid for future improvements (also performance
wise), so this is the way to go. Also, we have tried to keep the look
and feel as similar as possible in the new phone apps. You will feel
very much at home there. But improvements are much easier now.
    * xorg server rather than glamo kdrive. We switched to using a
proper xorg-server, with a graphics driver that is actively maintained.
There have been some improvements, and developer Weiss thinks that there
are more perf improvements to get.
    * eglibc rather than glibc. Just like Debian did, we switched our
libc library from glibc to eglibc which (apparently) is a bit better
suited  to embedded devices.
    * While the theme contest is still ongoing, we have decided to
install the gry theme by Bernd Pruenster by default, it is faster than
the default theme, which is not designed for obsolete embedded hardware.
The illume theme is still set to "default" or "Illume SHR", so try
stasetting it to *gry* through the top bar wrench (preference settings)
    * The neo theme is also nice and fast. It is not installed by
default, but it is in the feeds. You can easily install in with "opkg
install shr-theme-neo". Another theme to try out is the niebiee theme
which has been designed with speed in mind ("opkg install
shr-theme-niebiee").
    * the python-based frameworkd is being replaced bit by bit with
components written in Vala. The first components that we use are
fsousaged (which replaces ousaged), fsodeviced, and fsonetworkd. Mickey
posted a status update
(http://www.vanille-media.de/site/index.php/2009/11/10/towards-the-end-of-2009/)
on the new fso stuff.
    * phonefsod replaces the ophonekitd phone daemon and and
phoneuid/libphoneui are now responsible for all things GUI with the
phone apps.
    * opimd is included and we have the possibility to save incoming and
outgoing SMS as well as contacts on the SIM card or on the SD card
(using the sqlite backend). New SMS/contacts are now by default saved in
a database on the FreeRunner (SD card or NAND), so be careful before
reflashing! (Someone should probabably give instructions somewhere on
how to change the configuration to use the SIM card as default and how
to transfer data from one backend to another.)
    * We have proceeded with the integration work with openembedded.org
and we are very close to their development branch now, patches will be
submitted to really merge SHR with upstream. This also means that we now
have updated versions of basically every software component in this
image. This migration has unfortunately caused quite some head aches and
build problems...
    * mokonnect was finally able to connect to my WEP WLAN without
crashing the kernel :).
    * We will be providing a possibilitiy to upgrade the kernel to
2.6.31 (including KMS goodness, see
http://www.bitwiz.org.uk/s/how-dri-and-drm-work.html) for adventurous
users some time after this release. We just had to make a cut somewhere
and this did not make it in yet.

What is NOT working:

    * Ringtones are not working yet after the first call (it just
vibrates). There is an issue related to the new fsodeviced and how it
handles alsa sound profiles. We are investigating this issue.
    * 2s Power button press does not shutdown, as the delayed action
thingie seems broken. You'll just get the "shutdown" menu in any case ATM...
    * "Hoversels" in python-elementary seem broken, so you can't switch
profiles from the shr-settings app.
    * The time is off as the timezone remains set to "Europe/London".
    * Number-to-Name resolution is currently broken in the SMS message list.
    * ffalarms crashes when you add an alarm... So don't use your FR as
an alarm clock with this image.

External packages, such as those from opkg.org might be broken due to
the updated components. We do invite external app programmers to submit
their applications for inclusion as a openembedded build recipe and have
them added to the SHR feed, so that apps are just a simple "opkg
install" away.

Finally, although this snapshot has taken quite some time, I think we
should congratulate those people that have worked hard in their spare
time to put it all back together, first and foremost mrmoku, who has
been a great informal lead dev and tireless buildhost guardian. But also
TAsn, dos1, JaMa, Heinervdm, JesusMcCloud, mickeyl, pb (and many others
that I have forgotten now), as well as all those 3rd party application
authors of apps that make the openmoko interesting.


More information about the Shr-User mailing list