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 <m...@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 <sebast...@sspaeth.de> > An: "SHR-devel" <shr-de...@lists.shr-project.org>, "SHR-user" <shr- > u...@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-u...@lists.shr-project.org > http://lists.shr-project.org/mailman/listinfo/shr-user > > ------------------------------------------------------------- > > _______________________________________________ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > -- Steven Le Roux Jabber-ID : ste...@jabber.fr 0x39494CCB <ste...@le-roux.info> 2FF7 226B 552E 4709 03F0 6281 72D7 A010 3949 4CCB _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community