The SHR Project blog

Upgrading via opkg upgrade should fix this automatically, Thanks Martin Jansa for putting in a fix.

If that does not work, check this manually:

Older versions of fsodeviced left a stray directory around. Delete the directory
/etc/freesmartphone/conf/openmoko_gta/alsa-default
and make that a symlink to
/etc/freesmartphone/conf/openmoko_gta/alsa-2.6.29

Thanks everyone for finding that out.

Why do we want to do that?
One annoying thing while developing applications for SHR is the time consuming cycle of: hacking - building with OE - installing on the device - testing. The UI itself could be developed natively on the desktop too, but as lots of stuff depends on the actual hardware (eg. phone calls) that does not cover the whole story.

What can we do about that?
Now, we have a solution :-) The other day an interesting application was added to OpenEmbedded (thanks mickeyl): dbus-daemon-proxy. So, what is that? If you start dbus-daemon-proxy on your phone it will proxy all dbus methods and signals from your phone over the network to you desktop. This means you can have the hardware dependent stuff like fsogsmd running on the phone and stuff like phoneuid running on your desktop and it will just work.

So, what do you need to do that?
1) you need a current EFL stack with elementary. Current means you have to build it yourself from Enlightenment SVN. I personally use the get_e.sh script from raster (find it here: get_e.sh). But there are others out there too. NOTE: get_e.sh does not install elementary itself. You have to do that manually after get_e.sh finished installing all the other stuff.

2) you have to install dbus-daemon-proxy on your phone. It is already in the SHR-unstable feed, so if you run SHR-unstable (which is somehow important if you want to develop the SHR phone stack ;), then just opkg install dbus-proxy-daemon.

3) install the SHR phone stack (and all of its dependencies) on your desktop. To make life easy for you I created a script which does that (setup-shr-build-env.sh). It will install all needed stuff to your home directory. If you don't already have LD_LIBRARY_PATH set to contain $HOME/lib you have to add it.

4) stop phoneuid on your phone. Easiest way is to just execute 'killall phoneuid'.

5) start dbus-daemon proxy on your phone. Note: you need one instance for every program connecting to it. I'm using one for phoneuid, one for communication with phoneuid (eg. to start messages app) and one for some debugging tool like d-feet or mdbus2. Create something like the following script to start it on three different ports:

#!/bin/sh
dbus-daemon-proxy --system --port 8080 &
dbus-daemon-proxy --system --port 8081 &
dbus-daemon-proxy --system --port 8082 &

make it executable and start it.

6) start phoneuid on your desktop with the following call:

DBUS_SYSTEM_BUS_ADDRESS=tcp:host=192.168.0.202,port=8080 phoneuid

7) start the messages app with the following call:

DBUS_SYSTEM_BUS_ADDRESS=tcp:host=192.168.0.202,port=8081 phoneui-messages

8) have fun watching your messages pop up on your desktop :-)

Apart from saving a lot of time by not cross-compiling and installing... one big winner is to be able to use some nice gdb GUI to debug the thing.

Petr Vanek reports:

Openmobility conference was held on Saturday April 24th 2010 at the University of Tomas Bata, Zlin, Czech Republic. Initiated by the Czech Openmoko community and organized by group led by Martin Holec (aka Martix), the day long program featured several interesting presentations, for example Open Hardware (OpenMoko, Wikireader...), SHR, Touch Book, Nokia N900, Android, Openstreetmap, QTMoko and more. The conference was also hosting a Freerunner rework party where bass fix, GSM buzz fix and 1024 recamping fix were performed.

QTMoko was presented by it's author Radek Polak. Radek, being a very active and passionate user and maintainer of the successful QT Extended/ GNU Debian based distribution, shared his view and involvement in the project. Greatly enjoying himself to upkeep a distribution that serves his needs, he is happy others are able to use and be happy from his work.

Android and N900 phones were presented by their users who were thrilled by the possibilities of the hardware and by the continuing process of development supported by the strong corporate bodies behind (Google and Nokia). Huge numbers of applications provided by the surrounded community is apparently an important part of the phones' ekosystem and is appreciated by the common users.

SHR Project was presented by one of the project members Martin Jansa (aka JaMa). Clear informative presentation gave comprehensive look into the inside structure of the project, building process, features, community and it's involvement, as well as about history future plans. JaMa, being deeply involved in the building and testing processes was confidently answering questions of several interested visitors of the conference.

Here is what has become very clear after the full day of presentations:

Where corporate driven projects were presented by the end users, barely scratching the surface of the complexity of maintaining a competitive phone system and for whom it was very hard to articulate the reasoning, possibilities or even plans, and where presentation of a beautiful but one and only man show maintenance of discontinued phone stack could be seen, SHR was the only presented distribution project that had both the power and the beauty of living organism with already existing community involvement to the deepest levels all across the system. SHR (who is also suffering the lack of manpower) is at this point the center of the Freerunner's universe and ideally would be the focal point of all developers for (not only) the Neo phones.

With the recent successful merge with the direct OpenEmbedded branch, future building possibilities were safeguarded, moving us a great leap forward and providing an easily build-able system with many active developers, allowing participation at any time - welcomed and greatly appreciated community involvement is accepted with sincere thoughts for more opened future, not with superficial hopes of greater sales and higher Nasdaq ratings.

SHR at the Openmobility was evidently an icing on the cake and a confirmation that the movement for freeing the phone is still alive. Thank you Jama for the long trip from Prague and hope to see you here again next year!

I just pushed an update to the shr-testing repository. How to upgrade and what has changed?

--------------------------------------------------------------
Make big upgrades work
--------------------------------------------------------------
This upgrade will unfortunately require manual attention. Why? opkg downloads all upgrades to /tmp (which is in RAM), so for big upgrades your RAM will be full even before it starts upgrading.

There are 2 solutions for this:

1. Only install one package at a time, calling opkg multiple time. This is quite easy and described here: http://trac.shr-project.org/trac/wiki/opkg#Installonepackageatatime
2. Create a swap file that allows to swap out the downloads on the SD card. I recommend this anyway: http://trac.shr-project.org/trac/wiki/swap#Createaswapfile. If you are afraid that your SD card will die soon because of this, I don't think so and they are cheap anyway, so if you need to buy a new one every 2 years, what the heck.
   

--------------------------------------------------------------
Remove SHR-TODAY
--------------------------------------------------------------
Before starting the upgrade do "opkg remove -force-depends shr-today". Opkg *should* be removing this automatically, however according to some reports opkg failed to do so (due to opkg stupidness), and keeping shr-today seems to cause weird lockups. So get rid of it in advance.
UPDATE: JaMa told me that besides removing the package, killing the actual running process would also be useful. He is right. Kill the correct python process with "kill `pgrep shr-today`" as well.
--------------------------------------------------------------
Safety tipp: screen session
--------------------------------------------------------------
- Do run this upgrade (as in every upgrade) in a screen session. My FR display froze during the upgrade (access through ssh still worked)
- It's a big upgrade unfortunately which takes some time. All Enlightenment stuff seems to have been bumped.

--------------------------------------------------------------
What is new:
--------------------------------------------------------------
- Plenty of changes to the shr phone apps...
- Dimming is now done with a  dim phase rather than the simple on/off. Timeouts can be set for the Idle and Idle_dim timeouts. To make these changes persistent, modify the values in /etc/frameworkd.conf
- python-based shr-today is no more. It is now rewritten in C and integrated into the shr UI. It's reportedly faster than the old lock screen.

Bugs that I have seen:
- The new idle screen does not show the signal strength for me
- During the opkg upgrade process my phone suspended and this aborted the upgrading.... Annoying, I know. I now tap on the screen while updating which is pretty silly but.... Of course, what you should be doing is to automatically request the CPU resource while running updates using this technique: http://trac.shr-project.org/trac/wiki/opkg#Preventsuspendwhileupgrading

To sum it up: if you see mysterious screen hangs, you have still shr-today installed and/or running.

[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 (lite or full), flash it and start afresh. I am writing this before the new images are out there, so be a bit patient before really grabbing it.

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 setting 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 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 how-dri-and-drm-work) 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. UPDATE: FIXED NOW SEE BELOW
  
• 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". UPDATE: FIXED NOW SEE BELOW
  
• Number-to-Name resolution is currently broken in the SMS message list. UPDATE: FIXED NOW
  
• 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.

UPDATE: Some of the issues are resolved already with a simple opkg upgrade (e.g. ringtones should work now). An upgrade of fsodeviced might require a reboot though.... But some upgrades from the initial image will require manual intervention. This is what I found so far:

• opkg remove -force-depends apm apmd
  opkg install task-fso2-compliance
  This will install the correct power management stuff and makes things feel speedier here. Try it and check if the animation of shr-today is nicer again.
• opkg remove -force-depends atd
  opkg install atd-over-fso
  This will probably make your ffalarms work again.
  
• opkg install tzdata tzdata-europe (or whatever package you want)
• Personally, I would also "opkg remove -force-depends avahi-daemon avahi-autoipd" to get rid of avahi.
  

Those fixes will automatically go into new images as we fix them...

After the huge success of the previous contest (SHR Logo Contest, http://wiki.shr-project.org/trac/wiki/LogoContest ) we decided to let the community help with the themes as well.
We discovered many talented community members (in the meanwhile we already started using the logo in several places, and Slyon started using it in his amazingly beautiful shr-today theme), that can probably make an amazing theme for SHR.
ATM we work with a default ugly theme and with a couple of community generated themes (gry/niebiee/more...) but each one of them has it's own flaws and none of them was made "in the spirit of our new logo".

We'd really like to see great contributions like we saw in the last contest, and like before your submission/vote will probably shape the new face of SHR.

You have to make themes for elementary and e-wm/illume but adding gtk+ and icon sets will give you a bonus, as it's more likely that people will vote for a theme that makes SHR consistent, than for a partial theme.

Guidelines:

1. The theme should be finger friendly (if the theme you create affects sizing and behavior, like for instance gtk+ themes)
2. The theme should look good :)
3. The theme should be consistent.
4. The theme should not break usability.
5. The theme should not be slow.

NOTICE: many themes previously created for the moko were designed for X11-16bit engine, though since raster said X11-16 is broken and should not be used, you do *not* have to make your theme look nice with that, although that's a bonus.

Like in the logo contest, the submissions will be gathered in the contest's wiki page.
When adding a new submission please provide the following details:
Name of the theme, name of the creator, license (or state you let us choose the license for you), a link to the theme, pictures of the theme and maybe a short description.
Please make sure you leave enough space between your entry and the others, so voters won't get confused.

That's about it, go ahead. We will accept submissions until: 30/11/09 at 19:00pm UTC.
If you have any questions feel free to contact me.

Useful links:
The SHR theme repositories (for templates and examples): http://git.shr-project.org/git/?p=shr-themes.git;a=tree;h=refs/heads/master;hb=master
The contest's wiki page: http://wiki.shr-project.org/trac/wiki/ThemeContest

Have fun.

Hello everyone,

First of all, I want to say we were amazed by the number and quality of the submissions, we really didn't expect so many entries.
As you probably noticed, we decided to let people choose their favorite 3 (or more), this was only because choosing just one from so many great logos is nearly impossible.

We really want to thank all the participants (voters and especially the logo artists) for helping us make SHR better, and we hope to see this kind of participation in future contests as well.

Without further ado, here are the results:
There was a total of 269 voters and over 60 submissions, but unfortunately we can only have one logo.
The winning logo is: 4, by alphalog design-studio (http://wiki.shr-project.org/trac/raw-attachment/wiki/LogoContest/alphalog-shr-3.png)

We are really anxious to start using this logo in SHR all there's left is receiving the SVG from alphalog (http://alphalog.de).

As for the rest of the contestants: Again, thanks a lot. Actually because we liked some of the entries so much, we'll try to use some of them for making boot splashes or maybe incorporate them in other
parts of SHR.

Thanks a lot, we had fun, if you submitted a logo and want to know how many votes you got, please email TAsn (not everyone would like their "score" published).

P.S, stay in touch, as we might start some more contests soon. 

Hello.
In order to normalize numbers in SHR we use a library called libphone-utils.
This library needs to know the Phone prefixes of the user's country in order to work correctly.
ATM each user sets up his prefixes manually using a config file in /etc/phone_utils.conf (or probably using shr-settings)
We want to make it automatic. Though in order to do that, we need to know, what are your settings? What's working well for you?

So please, add to the following wiki page your country and your settings so we'll be able to use them for automatic settings.

Wiki page: http://wiki.openmoko.org/wiki/Phone_Prefixes

Thanks in advance, the SHR team.

Hello everyone.

The logo contest is over, no more submissions are allowed, and the voting phase has started.
You are more than welcomed to vote for your favorite logo at:
http://www.doodle.com/if9mwpmen4btbxu4

You can find more info at the wiki page: http://wiki.shr-project.org/trac/wiki/LogoContest

You can vote to as many logos as you like, so you don't have to choose your absolute favorite, you are welcomed to choose your top 3.

Voting will end at 19:00 12.10.2009 GMT, Have fun and good luck.

As you may have noticed, recently we sent a lot of mails concerning the looks of SHR.
Most of the users don't care about what's running under the hood, though the majority do care about how it looks/behaves.

Therefore we decided to ask the users about all of our graphical and UI design choices before we actually do them,
as this distro is made for YOU.

So what's on the topic:

1. A new SHR logo - we already started the logo contest (for more info: http://wiki.shr-project.org/trac/wiki/LogoContest)
2. A new SHR theme - we already sent a mail about that, though in short, we need a new theme for illume and a default background image, wiki page: http://wiki.shr-project.org/trac/wiki/Illume%20Theme
3. A new phone UI - will be explained in a moment.

As for 1 and 2, things are going ok, we need more user involvement as those will be default soon, but we are getting there and we already have some nice suggestions.

As for the new Phone UI:
This is the most important topic, as this is not only about "looks" it's also about "feel" or usability. We want YOU to help us determine the features and look & feel of the entire phone UI.
Of course we have our own suggestions (which will be presented in a moment), so even if you don't have a suggestion of your own, we'd like to
see what you have to say about our current sketches.

Link to the phoneui page: http://wiki.shr-project.org/trac/wiki/phoneui

These are our design suggestions, please tell us what you think should be done in order to improve them, or just suggest your own, please don't remove parts of the wiki,
and keep the order sane if you add your own suggestions.