Re: [QtMoko] amd64 compilation trouble

2011-05-20 Thread giacomo 'giotti' mariani

On 05/16/2011 15:43, giacomo 'giotti' mariani wrote:

Hi Ed

Hi Giacomo,

There might be something wrong with the libraries,
can you check with:
ldd /opt/toolchains/arm920t-eabi/bin/arm-linux-gnueabi-gcc-4.3

Kind regards,
Ed

here the output of ldd follows:
jack@nb2-mariani:~$ ldd 
/opt/toolchains/arm920t-eabi/bin/arm-linux-gnueabi-gcc-4.3

linux-gate.so.1 =  (0xf77bb000)
libc.so.6 = /lib32/libc.so.6 (0xf763f000)
/lib/ld-linux.so.2 (0xf77bc000)

It looks good to me, but I'm not a guru at all.


Thank you very much
 Giacomo


Hello everyone,
I don't know how, but after upgrading to 11.04 the problem 
disappeared.


Regards
Giacomo

--
##
giacomo 'giotti' mariani
gpg --keyserver pool.sks-keyservers.net --recv-key 0x99bfa859
O  ASCII ribbon campaign: stop HTML mail
www.asciiribbon.org
##


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: Aurora

2011-05-20 Thread Michael 'Mickey' Lauer
Am Freitag, den 20.05.2011, 19:57 +0200 schrieb Enrico Zini:
 On Mon, May 16, 2011 at 06:02:58PM +0200, Michael 'Mickey' Lauer wrote:
 
  SUPPORTED DEVICES
  
  We decided to only support the Palm Pre devices (Pre/Pre Plus/Pre 2) for
  the first to-be-released version of Aurora. More
  supported devices will join after the 0.1 release. This decision has
  been forced by the fact that we are only very few people
  working both on FSO and Aurora (and also on OpenEmbedded). Later on, we
  expect to see the OpenEZX family of devices,
  the Openmoko devices, the Nokia N900, and possibly also a bunch of HTC
  smartphones supported.
 
 Thank you for the announcement, it sounds nice. This bit made me wonder,
 though: why must each different platform require a separate effort? Is
 there something in FSO which works differently on different kinds of
 phones?

Yes, unfortunately... but that's due to the nature of being
a middleware. Middleware is an abstraction layer on top of the
hardware which shields the applications from the underlying
differences. That means while FSO provides always the same
interface to the applications, the hard and daunting task
is to cope with the device specifics and make them disappear.

FSO has to deal with varying kernel-level interfaces, such
as to audio routing, GSM modem, accelerometers, LEDs, buttons,
peripheral control... to name just a few.

Although we have seen a welcome level of standardization
via kernel class devices in the past years, there are still
too many home-grown vendor solutions and interfaces developed
out of the kernel tree. All those we (FSO) have to adapt
to provide a unified experience to the application level.

Cheers,

-- 
:M:


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: Aurora

2011-05-20 Thread Michael 'Mickey' Lauer
 Although we have seen a welcome level of standardization
 via kernel class devices in the past years, there are still
 too many home-grown vendor solutions and interfaces developed
 out of the kernel tree. All those we (FSO) have to adapt
 to provide a unified experience to the application level.

And to expand on that... some of those device specifics
have to be reverse engineered. As a scaring prime example:
In September 2009, we launched the 'FSO on Palm Pre' challenge,
trying to get a GSM voice call running within one month.

Boy, how did we fail :)

It took us (or rather 'Morphis, our hero') the better part of 
12 months to get a proof of concept done. Even today, almost 20 months
after we started working on the Pre, we don't have full coverage,
e.g. we just started to work on SMS, and GPS is also still lacking.

Our friends over @ HTC-Linux can sing many songs on that as well.
And our friends from OpenEZX can tell a story as well... it has
been 6 years now since the A780 has been introduced with Linux 2.4.
Guess what, it's still not fully supported in kernel 2.6, i.e.
no ALSA, no GPRS, no GPS.

-- 
:M:


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: [QtMoko] faenqomod updated

2011-05-20 Thread Joif
Hi!
This [ยน] is a little update of FaenqoMod, changelog:
- added two icons for the addressbook; 
- new layout for the home screen with a BIG clock (:
- new layout for the titlebar with the great return of the clock close to
the battery icon;
Screenshots at http://db.tt/vG5D0yZ
I am grateful if Radek can make the deb (:

Regards
Joif

[1] https://www.dropbox.com/s/2dnc2ld9pthmahn/faenqomod.tar.gz

--
View this message in context: 
http://openmoko-public-mailinglists.1958.n2.nabble.com/QtMoko-faenqomod-updated-tp6090693p6387833.html
Sent from the Openmoko Community mailing list archive at Nabble.com.

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: Aurora

2011-05-20 Thread Neil Jerram
Hi Simon,

Many thanks for your explanations of Aurora.  I think I understand
now, at least as regards what you are trying to do, and why.  I have
just one further comment below.

On 17 May 2011 06:57, Simon Busch morp...@gravedo.de wrote:

 Aurora is not about fragmentation. Zhone was already there before SHR
 and Aurora will continue Zhone. We will take aurora as our new reference
 application as it is quite simple and let us integrate new features very
 fast.

One question, then, is how will Aurora be different from Zhone?
Having worked a bit with Zhone myself, I'd say that

- on the one hand, its code seems pretty accessible and easy to experiment with

- but on the other hand, it feels relatively hard to add completely
new features into the UI (possibly because of my own familiarity with
the Edje/embryo stuff).

Is that roughly your feeling too?  If it is, how will you make Aurora better?

Regards,
   Neil

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community