Re: [MeeGo-dev] single sign on framework

[Alberto Mardegan]

On 10/27/2010 06:09 PM, Reijo Korhonen wrote:

Hi,

Does anyone know, how to set signond daemon on?

I tried to simple start it with a command

sudo /usr/bin/signond

but process does not keep alive and /var/log/messages shows some errors


Usually you wouldn't need to start it, it should be activated by D-Bus. The 
reason why it doesn't start is probably logged in either /tmp/signon_trace_file 
or ~/.signon/signon_trace_file (I should check where the log file is kept in MeeGo).


[...]

I am also grateful to have all information, what application use now
Single Sign On Framework and what application are planned to use in
MeeGo.


I guess that currently it's pretty much unused, but ideally all applications 
needing some kind of service authentication should use it.


Ciao,
  Alberto

--
http://blog.mardy.it <-- geek in un lingua international!
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] DVB support on MeeGo

[Ji, Jessica]

No this plan now.

Best Regards 

Jessica.

Intel Asia-Pacific R&D Ltd.[INET] 8821-6598 

-Original Message-
From: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com] On 
Behalf Of vijay singh
Sent: 2010年10月28日 13:43
To: meego-dev@meego.com; meego-ker...@meego.com
Subject: [MeeGo-dev] DVB support on MeeGo

Hello,
I want to know do we have support for DVB under MeeGo 1.0 or planned
MeeGo 1.1 release.

Bye--

___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] DVB support on MeeGo

[Zhang, Zheng]

DVB = digital video broadcast
It need support middle layer support, no relation with MeeGo core
Parser/codec should be there via gstreamer, I remember there is a V4L plugin 
for gstreamer, while V4L support DTV
So It should be ok

-Original Message-
From: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com] On 
Behalf Of Clark, Joel
Sent: Thursday, October 28, 2010 1:56 PM
To: vijay singh; meego-dev@meego.com
Subject: Re: [MeeGo-dev] DVB support on MeeGo

Top Google hit  DVB = Democratic Voice of Burma.


-Original Message-
From: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com] On 
Behalf Of vijay singh
Sent: Wednesday, October 27, 2010 10:43 PM
To: meego-dev@meego.com; meego-ker...@meego.com
Subject: [MeeGo-dev] DVB support on MeeGo

Hello,
I want to know do we have support for DVB under MeeGo 1.0 or planned
MeeGo 1.1 release.

Bye--

___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

[MeeGo-dev] libglx.so for virtualbox

[CSJ]

Hi, all

In Meego wiki:
http://wiki.meego.com/MeeGo_1.0_Netbook_VirtualBox

mentioned Download Libglx.so.gz 
  Replace libglx.so for an X issue, this libglx.so will put glx version to
1.2, instead of 1.4.

is there any source code of this libglx.so?
Or say, where does this libglx.so com from?

Thanks,
CSJ
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] DVB support on MeeGo

[vijay singh]

It is Digital Video Broadcast.

//http://linuxtv.org/wiki/index.php/How_to_install_DVB_device_drivers
//http://linuxtv.org/wiki/index.php/What_is_V4L_or_DVB%3F

On Wed, 2010-10-27 at 23:55 -0600, Clark, Joel wrote:
> Top Google hit  DVB = Democratic Voice of Burma.
> 
> 
> -Original Message-
> From: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com] On 
> Behalf Of vijay singh
> Sent: Wednesday, October 27, 2010 10:43 PM
> To: meego-dev@meego.com; meego-ker...@meego.com
> Subject: [MeeGo-dev] DVB support on MeeGo
> 
> Hello,
> I want to know do we have support for DVB under MeeGo 1.0 or planned
> MeeGo 1.1 release.
> 
> Bye--
> 
> ___
> MeeGo-dev mailing list
> MeeGo-dev@meego.com
> http://lists.meego.com/listinfo/meego-dev


___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] DVB support on MeeGo

[Clark, Joel]

Top Google hit  DVB = Democratic Voice of Burma.


-Original Message-
From: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com] On 
Behalf Of vijay singh
Sent: Wednesday, October 27, 2010 10:43 PM
To: meego-dev@meego.com; meego-ker...@meego.com
Subject: [MeeGo-dev] DVB support on MeeGo

Hello,
I want to know do we have support for DVB under MeeGo 1.0 or planned
MeeGo 1.1 release.

Bye--

___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

[MeeGo-dev] DVB support on MeeGo

[vijay singh]

Hello,
I want to know do we have support for DVB under MeeGo 1.0 or planned
MeeGo 1.1 release.

Bye--

___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] meego geoclue gypsy

[Roman Gezikov]

Hi Juha,

  Yes, we have made an example using gypsy/geoclue working. We actually
fixed some bugs in gypsy to get it working. I think the one that doesn't let
you start is bug 30830: https://bugs.freedesktop.org/show_bug.cgi?id=30830.

  We have opened several bug reports and proposed changes
in functionality of gypsy/geoclue (power control, agps), but nothing
happens, unfortunately. So, welcome to club.

Regards,
Roman.

On Wed, Oct 27, 2010 at 4:03 AM,  wrote:

> Hi,
>
> has somebody found a good way to have (GeoClueMaster/GeoClueProvider-)
> Gypsy working with MeeGo?
> E.g. somehow on N900 image, or chroot'd SDK, or image on QEMU? Any tips on
> what has worked are appreciated.
>
> Alternatively if you can see what I'm doing wrong here, any tips much
> appreciated:
> So far I've tried external USB GPS dongle on my 9.10 Ubuntu running
> chroot'd Netbook SDK image from July-10.
> The GPS device (BU-353) does get a fix and I can e.g. 'cat' the NMEA ASCII
> on terminal. I've set the baud rate of the device
> to 4800. However when (manually, autostart does not work for some reason)
> starting the Gypsy daemon and then
> running the simple geoclue gypsy example from
> http://folks.o-hand.com/jku/geoclue-docs/simple-example.html (changing the
> device name though):
>
> ** (gypsy-daemon:5676): DEBUG: Creating client for /dev/ttyUSB0
> ** (gypsy-daemon:5676): DEBUG: Device name: ttyUSB0
> ** (gypsy-daemon:5676): DEBUG: Registered client on
> /org/freedesktop/Gypsy/ttyUSB0
> ** (gypsy-daemon:5676): DEBUG: Starting connection to /dev/ttyUSB0
> ** (gypsy-daemon:5676): DEBUG: GPS channel can connect
> ** (gypsy-daemon:5676): WARNING **: GARMIN: "Private Info Resp" packet data
> not recognized
> ** (gypsy-daemon:5676): WARNING **: Error determining device type for
> /dev/ttyUSB0
>
> And the example program itself remains waiting for position changes (no
> errors occur).
>
> Cheers,
> Juha
> ___
> MeeGo-dev mailing list
> MeeGo-dev@meego.com
> http://lists.meego.com/listinfo/meego-dev
>



-- 
Best regards,
Roman Gezikov.
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] Does Meego well support internationalization/localization?

[Chen, Zhenqiang]

Hi Aleksander, 

>In Tracker we will be using ICU directly to support Chinese Pinyin
>collations. We'll be getting /meegotouch/i18n/lc_collate from gconf and
>pass it directly to libicu. This work is already on-going and will be
>available in the next 2-3 weeks (currently we're assuming en_US.utf8
>locale always in collation).

Thanks for update. 
For some app, locale is temporary changed, not saved to gconf. 

Does tracker have interface to query with a given collation from input? 


>Tracker's FTS, if enabled in meego (which I'm not really sure 
>if it is),
>should already support it. We currently use libicu word-breaking
>algorithm to properly separate words during FTS parsing.

FTS is enabled in MeeGo Tracker. But it uses glib as the default parser.
I will submit a patch to enable libicu as default. 

BTW: For the input of tracker-search-tool, its length (g_utf8_strlen) must >= 3.
But the length of lots lots of Chinese words is 2. 

Can we make it configurable for different languages?  

Thanks!
-Zhenqiang
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] Policy Kit

[Harring, Brian]

Policykit at best would be used for the request to access the area- the actual 
permissions on disk to enforce this (and seperation/proxying of access to the 
content) are outside policykit however.  It's best to think of policykit as the 
dbus equivalent to sudo, basically.

The key thing to note about policykit is that you're basically poking it for an 
action- rpc like.  Passing back an fd for example, or allowing an existing 
process to start poking in a directory isn't really viable- asking another 
process to do so on your behalf is more up it's alley.

~brian


From: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com] On 
Behalf Of Clark, Joel
Sent: Wednesday, October 27, 2010 6:57 PM
To: meego-dev@meego.com
Subject: [MeeGo-dev] Policy Kit

Does the Policy Kit in MeeGo provide the capability such that content stored on 
the local storage device (HDD, SSD, or USB Drive) is only readable by the 
applications explicitly granted access by the owning application?

regards
Joel

BMC 7867
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] qemugl build fail

[Yang Rui Rui]

On 10/28/2010 05:26 AM, Dbdwoods wrote:

Ron. I am on a gig right now in. Los. Angeles. So not avialble for a new one. 
Please. Keep in touch. Thanks n. Regards. Dick. Woods

Sent from my iPhone

On Oct 26, 2010, at 3:13 AM, Yang Rui Rui  wrote:


Hi,

qemugl build failed in slackware64 13.0, could someone help?

gcc -Wall -g -O2 -fno-strict-aliasing  -c -o opengl_exec.o /home/dave/git/meego
emulator-qemugl-x86/target-i386/opengl_exec.c -I.. -I. -I../fpu -I/home/dave/gi
/meego-emulator-qemugl-x86/target-i386 -DNEED_CPU_H
In file included from ../fpu/softfloat.h:522,
 from /home/dave/git/meego-emulator-qemugl-x86/target-i386/cpu.
:48,
 from /home/dave/git/meego-emulator-qemugl-x86/target-i386/exec
h:66,
 from /home/dave/git/meego-emulator-qemugl-x86/target-i386/open
l_exec.c:46:
../fpu/softfloat-native.h: In function ‘float32_le_quiet’:
../fpu/softfloat-native.h:238: warning: implicit declaration of function ‘isles
equal’
../fpu/softfloat-native.h: In function ‘float32_lt_quiet’:
../fpu/softfloat-native.h:242: warning: implicit declaration of function ‘isles
’
../fpu/softfloat-native.h: In function ‘float32_unordered’:
../fpu/softfloat-native.h:246: warning: implicit declaration of function ‘isuno
dered’
../fpu/softfloat-native.h: In function ‘float32_is_infinity’:
../fpu/softfloat-native.h:266: warning: implicit declaration of function ‘fpcla
sify’
../fpu/softfloat-native.h:266: error: ‘FP_INFINITE’ undeclared (first use in th
s function)
../fpu/softfloat-native.h:266: error: (Each undeclared identifier is reported o
ly once
../fpu/softfloat-native.h:266: error: for each function it appears in.)
../fpu/softfloat-native.h: In function ‘float32_is_zero’:
../fpu/softfloat-native.h:278: error: ‘FP_ZERO’ undeclared (first use in this f
nction)
../fpu/softfloat-native.h: In function ‘float64_is_infinity’:
../fpu/softfloat-native.h:375: error: ‘FP_INFINITE’ undeclared (first use in th
s function)
../fpu/softfloat-native.h: In function ‘float64_is_zero’:
../fpu/softfloat-native.h:387: error: ‘FP_ZERO’ undeclared (first use in this f
nction)
../fpu/softfloat-native.h: In function ‘floatx80_is_infinity’:
../fpu/softfloat-native.h:479: error: ‘FP_INFINITE’ undeclared (first use in th
s function)
../fpu/softfloat-native.h: In function ‘floatx80_is_zero’:
../fpu/softfloat-native.h:491: error: ‘FP_ZERO’ undeclared (first use in this f
nction)
/home/dave/git/meego-emulator-qemugl-x86/target-i386/opengl_exec.c: In function
‘do_disconnect’:
/home/dave/git/meego-emulator-qemugl-x86/target-i386/opengl_exec.c:1048: warnin
: implicit declaration of function ‘qemu_free’
/home/dave/git/meego-emulator-qemugl-x86/target-i386/opengl_exec.c: In function
‘GetDrawableImage’:
/home/dave/git/meego-emulator-qemugl-x86/target-i386/opengl_exec.c:1119: warnin
: unused variable ‘old_handler’
/home/dave/git/meego-emulator-qemugl-x86/target-i386/opengl_exec.c: In function
‘do_function_call’:
/home/dave/git/meego-emulator-qemugl-x86/target-i386/opengl_exec.c:1341: warnin
: format ‘%08x’ expects type ‘unsigned int’, but argument 3 has type ‘arg_t’
make[1]: *** [opengl_exec.o] Error 1
make: *** [subdir-x86_64-softmmu] Error 2


define __USER_ISOC99 in softfloat-native.h then building passed, not sure if it 
is a right fix.

Actually I just start to learn meego things, I have two qeustions about qemugl:

a. Does the meego runs ok when dri is not enabled, ie. glxinfo reports  
"GL_RENDERER: Software Rasterizer"? If we just use official qemu-kvm does it 
works? Without opengl part just means low-speed or totally not works?

b. Is there any effort to make qemugl merge into qemu/kvm upsteam?

--- meego-emulator-qemugl-x86.orig/fpu/softfloat-native.h   2010-10-28 
09:58:06.0 +0800
+++ meego-emulator-qemugl-x86/fpu/softfloat-native.h2010-10-28 
09:58:52.16794 +0800
@@ -1,4 +1,5 @@
 /* Native implementation of soft float functions */
+#define __USE_ISOC99
 #include 




--
Thanks
Yang RuiRui
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev



--
To adhere means to yield. To yield means to adhere.
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

[MeeGo-dev] Policy Kit

[Clark, Joel]

Does the Policy Kit in MeeGo provide the capability such that content stored on 
the local storage device (HDD, SSD, or USB Drive) is only readable by the 
applications explicitly granted access by the owning application?

regards
Joel

BMC 7867
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] Meego Image Creation.

[Yang, Yi Y]

Now syslinux is 4.02 in tools repo, I have updated  
http://wiki.meego.com/Image_Creation, please try again, please file a bug if 
any mic2-related issue ( http://wiki.meego.com/Image_Creation#Troubleshooting 
), meego-dev has too messages, they will overwhelm your issue.

From: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com] On 
Behalf Of Ryan Ware
Sent: Wednesday, October 27, 2010 5:45 AM
To: Porwar, Surendra
Cc: meego-dev@meego.com
Subject: Re: [MeeGo-dev] Meego Image Creation.


On Tue, Oct 26, 2010 at 5:03 AM, Porwar, Surendra 
mailto:su...@ti.com>> wrote:
Hi All,

I am using ubuntu 10.04LTS and when I tried installing MIC following the steps 
mentioned in http://wiki.meego.com/Image_Creation

Also in step 2 upon NO_PUBKEY 0BC7BEC479FC1F8A error the first command needs to 
be modified from
gpg --keyserver subkeys.pgp.net --recv 0BC7BEC479FC1F8A
to
gpg --keyserver subkeys.pgp.net -recv-keys 
0BC7BEC479FC1F8A

And I don't think this is an error.  "--recv" works just fine, although yours 
is what's in the documentation.

Ryan

Step 3 under installation steps for ubuntu 9.10,10.04  which is sudo apt-get 
install syslinux=3.85 is failing.

Also on ubuntu 10.04 LTS the default syslinux version is 2:3.63-dfsg-2ubuntu3. 
I tried installing syslinux 4.03 but still while running  sudo apt-get install 
mic2 I get the error:

Mic2: Depends: syslinux(>=2:3.82) but it is 2:3.63-dfsg-2ubuntu3 going to be 
installed

How should I get this working?

Thanks.

Best Regards,
Suren



___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] meego geoclue gypsy

[Juha.Vuolle]

Nevermind, filed a bug (there is also a workaround if you run into this issue):
https://bugs.freedesktop.org/show_bug.cgi?id=31173

-Original Message-
From: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com] On 
Behalf Of ext juha.vuo...@nokia.com
Sent: Wednesday, October 27, 2010 11:04 AM
To: meego-dev@meego.com
Subject: [MeeGo-dev] meego geoclue gypsy

Hi,

has somebody found a good way to have (GeoClueMaster/GeoClueProvider-) Gypsy 
working with MeeGo?
E.g. somehow on N900 image, or chroot'd SDK, or image on QEMU? Any tips on what 
has worked are appreciated.

Alternatively if you can see what I'm doing wrong here, any tips much 
appreciated:
So far I've tried external USB GPS dongle on my 9.10 Ubuntu running chroot'd 
Netbook SDK image from July-10. 
The GPS device (BU-353) does get a fix and I can e.g. 'cat' the NMEA ASCII on 
terminal. I've set the baud rate of the device
to 4800. However when (manually, autostart does not work for some reason) 
starting the Gypsy daemon and then
running the simple geoclue gypsy example from 
http://folks.o-hand.com/jku/geoclue-docs/simple-example.html (changing the 
device name though):

** (gypsy-daemon:5676): DEBUG: Creating client for /dev/ttyUSB0
** (gypsy-daemon:5676): DEBUG: Device name: ttyUSB0
** (gypsy-daemon:5676): DEBUG: Registered client on 
/org/freedesktop/Gypsy/ttyUSB0
** (gypsy-daemon:5676): DEBUG: Starting connection to /dev/ttyUSB0
** (gypsy-daemon:5676): DEBUG: GPS channel can connect
** (gypsy-daemon:5676): WARNING **: GARMIN: "Private Info Resp" packet data not 
recognized
** (gypsy-daemon:5676): WARNING **: Error determining device type for 
/dev/ttyUSB0

And the example program itself remains waiting for position changes (no errors 
occur).

Cheers,
Juha
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

[MeeGo-dev] single sign on framework

[Reijo Korhonen]

Hi,

Does anyone know, how to set signond daemon on?

I tried to simple start it with a command

sudo /usr/bin/signond

but process does not keep alive and /var/log/messages shows some errors

Oct 27 10:22:55 meego-desktop klogd: [ 8299.604614] Pid: 706, comm:
signond Not tainted 2.6.35.3-6.2-netbook #1
NC10   /NC10

Same problem can be found, when running signond tests.

I use netbook for testing.

I am also grateful to have all information, what application use now
Single Sign On Framework and what application are planned to use in
MeeGo.


BR, Reijo Korhonen
MCTS team


___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] ARMv7 hardfp port of MeeGo discussion

[Thiago Macieira]

On Wednesday, 27 de October de 2010 09:51:44 sakari.pou...@nokia.com wrote:
> My take on this as a Nokia MeeGo architect is that we need hardfp. That is
> where the market is going: Harmattan and linaro are already in that train.
> IMO, we should start building softfp and hardfp for a 6 months grace
> period. Once 1.2 is out we should drop softfp.

I've received a new report from our Technology Management people this morning. 
The recommendation, in summary, is to use:

1) single-precision floating point (float, not double)
2) ARM's RunFast mode (i.e., not fully IEEE754 compliant)
3) hardfp argument passing
4) disable use of short vector mode

On the Cortex-A8, single precision FP with RunFast mode executes on the 
pipelined Neon core (even if you don't use Neon instructions), which results 
in single-cycle operations for multiply-accumulate. Anything else will execute 
in the VFPlite core, which is not pipelined and will impose delays due to lack 
of pipelining and branch misprediction.

Some applications need IEEE754 compliancy, so turning this back on should be 
possible. But the OS should start apps in RunFast mode by default.

I'm not sure I understand what the "short vector mode" is. If the compiler is 
generating such a code, it needs to stop. I've passed this recommendation to 
the Linaro toolchain team already.

I'm not sure how things change if the processor doesn't have Neon (like the 
Tegra II).

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Senior Product Manager - Nokia, Qt Development Frameworks
  PGP/GPG: 0x6EF45358; fingerprint:
  E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358


signature.asc
Description: This is a digitally signed message part.
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] About Final Meego1.1 Release

[Quim Gil]

On Wed, 2010-10-27 at 14:31 +0200, ext Rohit Baravkar wrote:
> Hi,
> As per release engineering plan, final Meego 1.1 was planned to
> release between 25th to 27th of October.
> Is there any change in plan? When the source packages for final Meego
> 1.1 will be accessible in Meego source repo?

No changes in the plan. You can follow the meego.com release publishing
status at
http://wiki.meego.com/Community_Office/Marketing/Meego.com_1.1_update

--
Quim

___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] ARMv7 hardfp port of MeeGo discussion

[sakari.poussa]

On 26/10/10 10:18 PM, "ext Quim Gil"  wrote:

> On Mon, 2010-10-25 at 23:52 +0200, ext Thiago Macieira wrote:
>> This is why I was wondering why we're not using hardfp *now* for 1.1.0.
>> fp 
>> We shouldn't be breaking binary compatibility.
>> 
>> We shouldn't be softp either.
> 
> Just reminding the obvious, but as for today there is no major MeeGo
> products in the market, no AppUp for MeeGo, no Ovi for MeeGo, no Extras
> for MeeGo. Even the MeeGo SDK itself is in its first iterations.
> 
> I see Arjan's point made from an architecture consistency point of view
> - but from a marketing point of view 1.2 and following releases will be
> a lot more used and scrutinized than 1.1.x releases. If this soft-hard
> break is unavoidable then it seems that now it will create a lot less
> hassle than in 6 months or later.

My take on this as a Nokia MeeGo architect is that we need hardfp. That is
where the market is going: Harmattan and linaro are already in that train.
IMO, we should start building softfp and hardfp for a 6 months grace period.
Once 1.2 is out we should drop softfp.

-sakari


> 
> --
> Quim
> 
> 
> 
> ___
> MeeGo-dev mailing list
> MeeGo-dev@meego.com
> http://lists.meego.com/listinfo/meego-dev

___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] ARMv7 hardfp port of MeeGo discussion

[Eero Tamminen]

Hi,

ext Jeremiah Foster wrote:

On Oct 27, 2010, at 07:07, mailto:jarmo.k...@nokia.com>> 
mailto:jarmo.k...@nokia.com>> wrote:

1.1 schedule for hardfp would be *very* challenging since we are still working 
in order to get hardfp toolchain working. After that testing (incl. performance 
testing) can be start.


What are the issues in getting a working MeeGo hardfp toolchain?



From: Arjan van de Ven [ar...@linux.intel.com]
Sent: Tuesday, October 26, 2010 10:24 PM
On 10/26/2010 12:18 PM, Quim Gil wrote:
On Mon, 2010-10-25 at 23:52 +0200, ext Thiago Macieira wrote:
This is why I was wondering why we're not using hardfp *now* for 1.1.0.

We shouldn't be breaking binary compatibility.

We shouldn't be softp either.
Just reminding the obvious, but as for today there is no major MeeGo
products in the market, no AppUp for MeeGo, no Ovi for MeeGo, no Extras
for MeeGo. Even the MeeGo SDK itself is in its first iterations.

which will change once we release 1.1.

I fully argee with Quim here, we have to act on this now, when the installed 
base does not exist.

It does seem an advantage to act now in order to impose the least amount of 
disruption possible on the installed user base.

Can we sketch out a roadmap? It seems evident that a MeeGo 1.1 hardfloat is 
difficult.


According to this (first Google hit):
  http://wiki.meego.com/Release_Engineering/Plans/1.1

1.1 is going to be released now?



How difficult will a 1.2 be? And if the toolchain is prepared for building a 
hardfloat 1.2,
then we should build in parallel, as if this was a separate port, correct?
(This is in fact what Debian does, their ARM hardfloat is essentially a 
separate port.)

If this path is the appropriate path


I don't see any point in softfp once hardfp is working fine (see below).



then we might need a target end of life of
the softfloat ARM port, how do we identify that?


Needs identifying what are the toolchain issues and what SW will
be impacted[1].

-> 1.1 release notes should at least state that there's a partial
   ABI break coming and for 99% of apps re-compile is enough?


[1] Only things generating assembly instructions directly[2] need
changes for hardfp, and only if the generated code is calling
floating point functions directly.

[2] See e.g. Debian's TODO for full list of impacted SW:
http://wiki.debian.org/ArmHardFloatTodo



I see Arjan's point made from an architecture consistency point of view
- but from a marketing point of view 1.2 and following releases will be
a lot more used and scrutinized than 1.1.x releases. If this soft-hard
break is unavoidable then it seems that now it will create a lot less
hassle than in 6 months or later.

based on the discussion here... the technology is at least several
months away.

>

There is work underway already. Already ~80% of the main Debian archive
is being built against the hardfloat port.
https://wiki.linaro.org/Linaro-arm-hardfloat

and breaking compatibility in an upgrade is even worse than breaking it
n a new release...
 really.

Clearly MeeGo ought to be following your advice. But I think that
you may be persuaded if we take into account;

1. There is a significant set of optimizations in the hardfloat ARM port [0.]
2. ARM softfloat will be less relevant once a hardfloat is present


Not just less relevant, but irrelevant.  Softfp already implies
HW having VFP.

Only point of "softfp" is function call ABI compatibility with
non-VFP "soft" (= fp emulation) software, but as "soft" would be
a *huge* performance penalty on VFP capable HW, it think it actually
a good thing that it's not supported...  That way nobody does it
accidentally. :-)



3. Much of the ARM Linux community is already moving in this direction

0. http://www.powerdeveloper.org/forums/viewtopic.php?t=1821

We need to address those concerns by talking bout this openly.
According to best experts this will take some time, so unfortunatelly
it seems that we will have 2 ARM architecture builds towards 1.2,
and we can only make final judgement when we know that hardfp
will work as intended.

This seems like a logical path forward. Yes there will be some difficulty,
but this seems the only way to ensure that ARM devices are performant as soon 
as possible.



- Eero

___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] About Final Meego1.1 Release

[Andre Klapper]

On Wed, 2010-10-27 at 18:01 +0530, Rohit Baravkar wrote:
> As per release engineering plan, final Meego 1.1 was planned to
> release between 25th to 27th of October.
> Is there any change in plan?

Not that I know, but keep in mind that there are timezones...

> When the source packages for final Meego 1.1 will be accessible in
> Meego source repo?

After 1.1 has been released. Patience. :)

andre
-- 
Andre Klapper (maemo.org Bugmaster)

___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] ARMv7 hardfp port of MeeGo discussion (Was: Re: new draft of MeeGo compliance specification)

[Ian Lawrence]

Hi

> As I said in earlier thread, this is my fault. I should have undesrtood the 
> signifigance
> and start that work early enough in MeeGo so we would have had change to get 
> it
> into 1.1 already. My only defence is that this is pretty new stuff, and for 
> the record,
> I am not ARM expert at all ..

I think this was a quote from somewhere

'In this game maybe it's good we make a few early mistakes, as this
relieves us of the pressure of trying to maintain an undefeated
record'

It is nice to see that the qualities which attracted me to the Maemo
project - owning up to making mistakes, correcting them and moving on
with our lives - are being carried over to these lists

Regards


-- 
http://ianlawrence.info
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

[MeeGo-dev] About Final Meego1.1 Release

[Rohit Baravkar]

Hi,
As per release engineering plan, final Meego 1.1 was planned to release
between 25th to 27th of October.
Is there any change in plan? When the source packages for final Meego 1.1
will be accessible in Meego source repo?

Thanks & Regards,
Rohit
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

[MeeGo-dev] is there letter-spacing support in css for meego

[chinmayi.s-k]

hi,
i need to use the letter-spacing variable in css for my text.I havent seen it 
being used .
wanted to know if that support exists for meego theming
regards,
chinmayi.s.k
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

[MeeGo-dev] Does Meego well support internationalization/localization?

[Aleksander Morgado]

Hi Zhenqiang,
 
>   - are there any libraries available helping easily 
>implement Chinese localization features like 
>Chinese search, sort using Chinese Pinyin?

1 Sort
Current Meego content framework does not support Chinese Pinyin
sort.

But if your order is the same as ICU, it is easy to implement it
in app. 

For handset applications based on libmeegotouch:
MLocale supports two kind of Chinese sortings.
zh_CN at collation=pinyin sorts Chinese according to the pinyin
phonetics, 
zh_CN at collation=stroke sorts Chinese according to the stroke
count of the characters.

In Tracker we will be using ICU directly to support Chinese Pinyin
collations. We'll be getting /meegotouch/i18n/lc_collate from gconf and
pass it directly to libicu. This work is already on-going and will be
available in the next 2-3 weeks (currently we're assuming en_US.utf8
locale always in collation).


2 Search
(1) Big efforts are required to support search bases on Chinese
"word". 
e.g. which text files have word "搜索"?  

For CJK languages, there is no ' ' to separate words in a
sentence, some word segmentation libraries are required. 

Tracker's FTS, if enabled in meego (which I'm not really sure if it is),
should already support it. We currently use libicu word-breaking
algorithm to properly separate words during FTS parsing.


(3) If you want to search Chinese with Pinyin, application
should translate Chinese to Pinyin and save the maps.

This is currently not supported in Tracker when doing FTS queries. This
is, we do not convert all Chinese text to Pinyin during FTS
automatically. But, if not using FTS and looking for exact matches of
property values, it could probably work just if the proper pinyin
collation is enabled (didn't test that anyway).

If applications are the ones inserting both Chinese and Pinyin strings
in full-text-indexed properties in tracker, FTS searches should just
work properly right now.

Cheers,

-- 
Aleksander

___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] ARMv7 hardfp port of MeeGo discussion

[Jeremiah Foster]

On Oct 27, 2010, at 07:07,   wrote:
> 
> 1.1 schedule for hardfp would be *very* challenging since we are still 
> working in order to get hardfp toolchain working. After that testing (incl. 
> performance testing) can be start. 
> 
>>> From: Arjan van de Ven [ar...@linux.intel.com]
>>> Sent: Tuesday, October 26, 2010 10:24 PM
>> On 10/26/2010 12:18 PM, Quim Gil wrote:
>> On Mon, 2010-10-25 at 23:52 +0200, ext Thiago Macieira wrote:
>>> This is why I was wondering why we're not using hardfp *now* for 1.1.0.
>>> 
>>> We shouldn't be breaking binary compatibility.
>>> 
>>> We shouldn't be softp either.
>>> Just reminding the obvious, but as for today there is no major MeeGo
>>> products in the market, no AppUp for MeeGo, no Ovi for MeeGo, no Extras
>>> for MeeGo. Even the MeeGo SDK itself is in its first iterations.
>>> 
>> which will change once we release 1.1.
> 
> I fully argee with Quim here, we have to act on this now, when the installed 
> base does not exist.

It does seem an advantage to act now in order to impose the least amount of 
disruption possible on the installed user base. 

Can we sketch out a roadmap? It seems evident that a MeeGo 1.1 hardfloat is 
difficult. How difficult will a 1.2 be? And if the toolchain is prepared for 
building a hardfloat 1.2, then we should build in parallel, as if this was a 
separate port, correct? (This is in fact what Debian does, their ARM hardfloat 
is essentially a separate port.) 

If this path is the appropriate path then we might need a target end of life of 
the softfloat ARM port, how do we identify that?

>>> I see Arjan's point made from an architecture consistency point of view
>>> - but from a marketing point of view 1.2 and following releases will be
>>> a lot more used and scrutinized than 1.1.x releases. If this soft-hard
>>> break is unavoidable then it seems that now it will create a lot less
>>> hassle than in 6 months or later.
>> 
>> based on the discussion here... the technology is at least several
>> months away.

There is work underway already. Already ~80% of the main Debian archive is 
being built against the hardfloat port.
https://wiki.linaro.org/Linaro-arm-hardfloat
>> 
>> and breaking compatibility in an upgrade is even worse than breaking it
>> n a new release...
>>  really.

Clearly MeeGo ought to be following your advice. But I think that you may be 
persuaded if we take into account;

1. There is a significant set of optimizations in the hardfloat ARM port [0.]
2. ARM softfloat will be less relevant once a hardfloat is present
3. Much of the ARM Linux community is already moving in this direction

0. http://www.powerdeveloper.org/forums/viewtopic.php?t=1821

> We need to address those concerns by talking bout this openly.
> According to best experts this will take some time, so unfortunatelly
> it seems that we will have 2 ARM architecture builds towards 1.2, 
> and we can only make final judgement when we know that hardfp
> will work as intended.

This seems like a logical path forward. Yes there will be some difficulty, but 
this seems the only way to ensure that ARM devices are performant as soon as 
possible. 

Jeremiah

___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev