On Thu, Nov 19, 2009 at 16:44, Tom <t...@stosb.com> wrote: > On Thu, Nov 19, 2009 at 5:36 PM, Tom <t...@stosb.com> wrote: >> >> On Thu, Nov 19, 2009 at 5:15 PM, Sebastian Spaeth <sebast...@sspaeth.de> >> wrote: >>> >>> [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. >>> _______________________________________________ >> >> Congratulations to us :) >> First of all, I really think people should upgrade to this image, but more >> than that, I honestly think we'll fix those issues soon. >> >> One thing Sebastian got wrong: >> * Number-to-Name resolution is currently broken in the SMS message >> list. >> It does work. >> >> Enjoy, and wait, because more presents are coming soon. >> >> -- >> Tom. > > Almost forgot: > * Do not use x11-16 it's broken (and won't be fixed, it's an upstream > issue). > * Selecting in phonelog does not work, upgrade the package. > > > > -- > Tom.
Of course you can still use x11-16 if you want. To deal with phoneuid, just add ELM_ENGINE=x11 before phoneuid invocation in phoneui-wrapper.sh :) -- Sebastian Krzyszkowiak dos _______________________________________________ Shr-devel mailing list Shr-devel@lists.shr-project.org http://lists.shr-project.org/mailman/listinfo/shr-devel
