The SHR Project blog

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.

Hi,

There was a security flaw in dropbear (the default SSH server on SHR) configuration that made it listen to all network interfaces (wifi,gprs,usb) instead of making it listen only to usb. This is a problem because the default password is blank,and the SHR distribution runs as root by default.

Notes about the commands:
The command to type are the ones coming just after the root@om-gta02 ~ $
The line that doesn't contain root@om-gta02 ~ $ are the output of the command

Resolution:
The advised way to handle it is to upgrade dropbear,or the entire distribution,or to reinstall To update dropbear the following run the following commands
root@om-gta02 ~ $ opkg update
Downloading http://build.shr-project.org/shr-unstable/ipk//all/Packages.gz
Inflating http://build.shr-project.org/shr-unstable/ipk//all/Packages.gz
Updated list of available packages in /var/lib/opkg/shr-all
Downloading http://build.shr-project.org/shr-unstable/ipk//armv4/Packages.gz
Inflating http://build.shr-project.org/shr-unstable/ipk//armv4/Packages.gz
Updated list of available packages in /var/lib/opkg/shr-armv4
Downloading http://build.shr-project.org/shr-unstable/ipk//armv4t/Packages.gz
Inflating http://build.shr-project.org/shr-unstable/ipk//armv4t/Packages.gz
Updated list of available packages in /var/lib/opkg/shr-armv4t
Downloading http://build.shr-project.org/shr-unstable/ipk//om-gta02/Packages.gz
Inflating http://build.shr-project.org/shr-unstable/ipk//om-gta02/Packages.gz
Updated list of available packages in /var/lib/opkg/
shr-om-gta02 $ opkg upgrade dropbear
Upgrading dropbear on root from 0.51-r1.01 to 0.51-r1.02...
Downloading http://build.shr-project.org/shr-unstable/ipk//armv4t/dropbear_0.51-r1.02_armv4t.ipk Configuring dropbear
System startup links for /etc/init.d/dropbear already exist.
Restarting Dropbear SSH server:
Connection to 192.168.0.202 closed by remote host.
Connection to 192.168.0.202 closed.
Then reboot your phone

Workarounds:
*you can change the default password using the passwd command(just type passwd in the terminal and type your password(note that you won't see * apearing on the screen while typing the password)),that will prevent unauthorized access but dropbear will keep listening on all interfaces To change the password run the following command:
root@om-gta02 ~ $ passwd
Changing password for root
Enter the new password (minimum of 5, maximum of 8 characters)
Please use a combination of upper and lower case letters and numbers.
Enter new password:
Re-enter new password:
Password changed.
*you can make it listen only on the USB interface adding this the following content to the /etc/default/dropbear file:
DROPBEAR_PORT=`ip addr list usb0 | awk 'BEGIN { FS="[ /]+" } /inet / { print $3 }'`:22
Then reboot your phone
Verify that it worked: connect your openmoko to the wifi and verify that you can't ssh into it from the wifi,192.168.1.108 must be replaced by the ip address of your openmoko
$ ssh root@192.168.1.108
ssh: connect to host 192.168.1.108 port 22: Connection refused
In order to find the ip address of your openmoko run the following command on the openmoko: root@om-gta02 ~ $ ip addr list eth0 | awk 'BEGIN { FS="[ /]+" } /inet / { print $3 }'
192.168.1.108

History of the bug solving:
At first we thought that it was because there wasn't something like that in dropbear.inc: SRC_URI_append_openmoko = "file://default"
and that adding the following:
SRC_URI_append_shr = "file://default"
would solve it but it was in the recipe then we thought it was because the default file was in org.openembedded.dev/recipes/dropbear/dropbear/openmoko and not in org.openembedded.dev/recipes/dropbear/dropbear/shr
But it was a veriffication of the SRC_URI variable with bitbkae -i and peek showed that it was in the default file was included in the SRC_URI
Then we thought that someone could have forgotten to bump the PR,we bumped the PR and rebuilt the dropbear package,and then the ipk contained the default file,and upgrading dropbear made the bug disappear
 
Future:
SHR plan to switch to openssh,in order to avoid such problems and to have a better ssh client (dropbear client doesn't support all the features that openssh does such as the key encryption) and server

SHR desperately needs a logo. We have none so far. Mmmh, mmmh, mmmh...

BINGO. A Logo contest: Creative people of the world, SHR lovers, join together and submit proposals. We will have a community poll, deciding on the logo to be used (core devs reserve the right to veto though :-)) Logos need to be under a license that allows us to use them (obviously). We would appreciate if we get the source svg (or whatever file) besides a nice .png as well). Preliminary deadline of the contest is end of September 2009. There will be no montetary prices, but you'll get praise and your design will be seen on millions, ehh, thousands, ehh, well maybe on dozens of phones every day...

If you are not graphically disabled, please consider to create and submit an entry. If you are, tell your graphic designer friend to create and submit an entry. If you don't have artsy friends, you can still pay an advertisement agency to create a logo for us, can't you?

Please submit your entries on our shiny logo contest page.

Hi everyone,

Here's a follow-up about FSOSHRUDCON'09. As Daniel Willman told on his weblog, this was really a great event. We were plenty of eager enthusiasts, all working together in order to go towards a truly free & open phone, based on viable middleware, as well as on usable distributions fit for every use.

There was lots of talks, among which technical as well as organisational pieces, lots of coding, which I hope you'll be able to see the results of soon, and I can, without a doubt, be sure that everybody was happy about the way it went, as it allowed everyone there to meet with people sharing the same intents towards what we're doing right now. We may disagree on some stuff, but in the end, we all know that we want to be able to have a phone usable with a free software stack.

In the next few days we'll put online edited video versions of the talks, and as much written material as possible. For starters, I'll put mine online, and I hope you'll be able to comment and/or mail if you have any question :-)

You'll find this material here.
Meanwhile, just have a look at our ugly faces :-). Other pictures can be found there, thanks to Daniel Willman.



In the end, for all of you who were there, it was a real pleasure to meet you. For all of you who weren't able to make it, I hope we'll see each other in the future as I'm sure there's a bright future ahead for what we do. Please focus guys, and let us keep walking along this path! :-)