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

Fri Nov 20 14:16:54 CET 2009

Congrats for the great work !

I just wonder, there is still a lot of work or is there any other
reason to not integrate paroli ?

On Thu, Nov 19, 2009 at 5:01 PM, Thomas Zimmermann <ml at vdm-design.de> wrote:
>
> ----------  Weitergeleitete Nachricht  ----------
>
> Betreff: [Shr-User] SHR-unstable got a facelift. And you a christmas
> present....
> Datum: Donnerstag 19 November 2009
> Von: Sebastian Spaeth <Sebastian at sspaeth.de>
> An: "SHR-devel" <shr-devel at lists.shr-project.org>, "SHR-user" <shr-
> user at lists.shr-project.org>
>
> [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.
> _______________________________________________
> Shr-User mailing list
> Shr-User at lists.shr-project.org
> http://lists.shr-project.org/mailman/listinfo/shr-user
>
> -------------------------------------------------------------
>
> _______________________________________________
> Openmoko community mailing list
> community at lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>

-- 
Steven Le Roux
Jabber-ID : Steven at jabber.fr
0x39494CCB <steven at le-roux.info>
2FF7 226B 552E 4709 03F0  6281 72D7 A010 3949 4CCB