Re: [MeeGo-dev] BME (Battery Management Entity) on MeeGo

2011-02-09 Thread Rémi Denis-Courmont
On Saturday 29 January 2011 19:19:19 ext Arjan van de Ven, you wrote:
> On 1/28/2011 5:54 PM, Lego Ming wrote:
> > Hi all,
> > 
> > We want to study the Battery Management Mechanism on MeeGo Handset.
> > 
> > Like:
> > 
> > The voltage threshold corresponding to different battery level. (for
> > example, display 2 level if current voltage is 3.85v)
> > 
> > The low battery management - Low battery to disable DATA connection /
> > Low battery to forbid CALL / ...
> 
> if you forbid me, as end user, to make a call when I'm on my last bit of
> battery, I will be very upset (because I'm in the pooring rain and was
> trying to call my girlfriend to come pick me up and take me home). If
> you forbid me, as end user, to make a data connection I will be equally
> upset because I might have been trying to send an email to achieve the
> same.

That is only one side of the problem... Ultimately, the device is going to hit 
the physical limits of the battery at some point. And most users expect the 
device to do so by shutting down gracefully.

You would probably be even more upset if the device let you make that phone 
call only to find out afterward that:

* Your MMC filesystem is corrupted, and your data non recoverable, because the 
phone did not have enough energy to flush.

* Your SIM stopped working. Yes, this *can* happen if the SIM interface is 
powered down in a "wrong" way.

* Your battery cannot be recharged anymore.

Somehow, I have to believe that Android also has some kind of safety measures 
against the potential consequences of full battery drain. Maybe in some cases, 
the safety is taken to an excessive level. But in general, I don't that kind 
of stuff as "anti-features": Those measures are there to protect the integrity 
of the device against unintended damage, in other words, protect the user from 
him-/herself. It's not like DRM, which protects third parties from the user.

-- 
Rémi Denis-Courmont
Nokia Devices R&D, Maemo Software, Helsinki
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev


Re: [MeeGo-dev] BME (Battery Management Entity) on MeeGo

2011-02-09 Thread Lego Ming
Hi Marius,

Yes. I agree with you and Arjan as well.

I didn't take the UX design into account when I sent this question :-<, but
more from technical feasibility view...

Now as pointed by Arjan and you, it's not a good design concept to forbid
some normal operations.

But the follow perform should be suitable:

 - If you don't have 50% of battery or are plugged in, we don't allow
  you to update the OS.

Again the question is how to get the battery status: what's the battery's
health status, what's the percentage of current voltage...

B.R.

On Wed, Feb 9, 2011 at 3:38 PM, Marius Vollmer wrote:

> ext Arjan van de Ven  writes:
>
> > On a more serious note though, forbidding the user to do things he'd
> > want to do is a bad design concept ;-=)
>
> Yes, I agree wholeheartedly.  I have, unfortunately, mostly given up the
> fight against the moronic requests for these anti-features, but maybe I
> can find some motivation again.
>
>
> There is a line between being helpful by reminding the user that
> something unexpectedly bad might happen when he goes forward, and
> outright preventing him or her from going forward.
>
> There are a number of examples in the package manager:
>
>  - If you don't have 50% of battery or are plugged in, we don't allow
>   you to update the OS.
>
>  - If you don't have 20% of battery or are plugged in, we don't allow
>   you to install 3rd party applications.
>
>  - If you are on a cellular connection, we don't allow you to download a
>   OS update beyond a certain size.
>
>  - If there is a newer version of the store client, you must install it
>   before being able to use the store.  (You can't even use the store
>   via its web site in this case since the browser redirects to the
>   store client).
>
> I see this anti-feature creep mostly as a disease that has befallen our
> product managers.  They turn into control-freak zombies.  I hope I am
> overreacting.
>
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev


Re: [MeeGo-dev] BME (Battery Management Entity) on MeeGo

2011-02-09 Thread Timo Härkönen
On Wed, 2011-02-09 at 09:38 +0200, Marius Vollmer wrote:
> ext Arjan van de Ven  writes:
> 
> > On a more serious note though, forbidding the user to do things he'd
> > want to do is a bad design concept ;-=)
> 
> Yes, I agree wholeheartedly.  I have, unfortunately, mostly given up the
> fight against the moronic requests for these anti-features, but maybe I
> can find some motivation again.
> 
> 
> There is a line between being helpful by reminding the user that
> something unexpectedly bad might happen when he goes forward, and
> outright preventing him or her from going forward.
> 
> There are a number of examples in the package manager:
> 
>  - If you don't have 50% of battery or are plugged in, we don't allow
>you to update the OS.
> 
>  - If you don't have 20% of battery or are plugged in, we don't allow
>you to install 3rd party applications.
> 
>  - If you are on a cellular connection, we don't allow you to download a
>OS update beyond a certain size.
> 

Why on earth? I'd would expect to be able to do so since I'm paying for
flat rate data. A simple warning should be enough if downloading large
amounts of data is needed.

>  - If there is a newer version of the store client, you must install it
>before being able to use the store.  (You can't even use the store
>via its web site in this case since the browser redirects to the
>store client).
> 
> I see this anti-feature creep mostly as a disease that has befallen our
> product managers.  They turn into control-freak zombies.  I hope I am
> overreacting.

You are not

-Timo

> ___
> 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] BME (Battery Management Entity) on MeeGo

2011-02-09 Thread Marius Vollmer
ext Lego Ming  writes:

> Now as pointed by Arjan and you, it's not a good design concept to forbid some
> normal operations.
>
> But the follow perform should be suitable:
>
>  - If you don't have 50% of battery or are plugged in, we don't allow
>   you to update the OS.

Yeah, this is maybe the least harmful.  OS updates don't happen every
day, can be postponed to a time when you are ready for them[0], and
consequences can be really bad if they are interrupted.

[0] Unless someone decides to force a OS update on you and the whole
device stops working until you have installed it, of course. :)
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev


Re: [MeeGo-dev] BME (Battery Management Entity) on MeeGo

2011-02-09 Thread Marius Vollmer
ext Rémi Denis-Courmont  writes:

> But in general, I don't that kind of stuff as "anti-features": Those
> measures are there to protect the integrity of the device against
> unintended damage, in other words, protect the user from
> him-/herself.

Yes, this is important, but it should happen at a low level, invisible
to the user.

The user knows: "The phone doesn't run with an empty battery since it
needs electricity".  That the battery isn't really totally empty when
the device shuts down for intricate reasons having to do with how SIM
cards are broken on a low level is of no concern to the user.  "The
whole thing is off because the battery is empty."

But here we are talking about gratuitous UX decisions: We decide what
the remaining battery can be used for.  You can send an SMS, but you
can't call.  You can play music, but you can't install an application.
Effectively, we decide that it is more important to play 10 more minutes
of music than it is to call someone for 30 seconds.  These kind of
decisions must be left to the user.  

We _can_ make the decision that it is more important to shut down the
device cleanly than it is to hold the call for 2 more seconds.  Because
it really is.  But the rest is just gratuitous.
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev


Re: [MeeGo-dev] BME (Battery Management Entity) on MeeGo

2011-02-09 Thread Marius Vollmer
ext Timo Härkönen  writes:

>>  - If you are on a cellular connection, we don't allow you to download a
>>OS update beyond a certain size.
>
> Why on earth?

I can only guess.  Maybe because the operator's network can't handle
anything big?  :-)
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev


Re: [MeeGo-dev] ConnMan-0.61.1 MeeGo Integration Notification

2011-02-09 Thread Antti Kaijanmäki
On Wed, 2011-02-09 at 13:45 +0800, Xu, Martin wrote:
> ConnMan-0.61.1 has been released at upstream, so we’d like to catch up
> upstream release and kick off ConnMan Release @ MeeGo.

You probably mean ConnMan-0.69 for the trunk, right? Or is this about
providing update to 1.1 where we currently have connman-0.60.7-4.1 ?

-- 
Antti Kaijanmäki
Software Architect
Team Manager
m. +358 41 440 4187
linkedin.com/in/anttikaijanmaki
www.nomovok.com

Nomovok Ltd.
Keilasatama 3
FI-02150 Espoo
Finland

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


Re: [MeeGo-dev] ConnMan-0.61.1 MeeGo Integration Notification

2011-02-09 Thread Clark, Joel
The version numbering here does not make sense.  You list the changes in 0.68 
and 0.69 and then say we are moving to 0.61.1.  Is this a typo?

From: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com] On 
Behalf Of Xu, Martin
Sent: Tuesday, February 08, 2011 9:45 PM
To: meego-dev@meego.com; Awad, Majid; Ortiz, Samuel
Cc: Zheng, Jeff
Subject: [MeeGo-dev] ConnMan-0.61.1 MeeGo Integration Notification


ConnMan-0.61.1 has been released at upstream, so we’d like to catch up upstream 
release and kick off ConnMan Release @ MeeGo.



Merge Window: 2011-2-9 -- 2011-2-15
We will have about 1 week buffer before the package in.
In the buffer, we will do some test to make sure the quality.

And if your work on MeeGo depend on it, you also can modify your codes. Thank!



ConnMan MeeGo RPM package:
https://build.meego.com/package/binaries?package=connman&project=devel%3Aconnectivity&repository=Trunk_Testing

ver 0.69:
Fix issue with not handling DNS proxy failures gracefully.
Fix issue with double free in statistics handling.
Fix issue with early tethering bridge creation.
Add support for tethering property per technology.
Add support for initial WiFi tethering feature.
Add support for using PACrunner as proxy driver.
Add support for WPS as part of the security property.
Please note:
the service security  property is no longer a string but an array of strings. 
For WiFi  services, one of the string will contain the actual security protocol 
(none, wep, psk or  ieee80211x) that used to be the security property string.  
The rest of the strings carry additional security properties (only  "wps" is 
supported for now, for WPS enabled WiFi APs). Also, the boolean WPS property 
has been removed.

ver 0.68:
Fix issue with wrong name of PolicyKit configuration file.
Fix issue with inconsistency of WiFi scan states.
Fix issue with missing auto-reconnect and oFono.
Add support for vpnc based private networks.
Add support for WiFi Protected Setup handling.
Remove legacy WiFi plugin.

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


Re: [MeeGo-dev] ConnMan-0.61.1 MeeGo Integration Notification

2011-02-09 Thread Samuel Ortiz
Yes, this is a typo. Martin meant 0.69.1

Cheers,
Samuel.

On Wed, Feb 09, 2011 at 04:02:58AM -0700, Clark, Joel wrote:
> The version numbering here does not make sense.  You list the changes in 0.68 
> and 0.69 and then say we are moving to 0.61.1.  Is this a typo?
> 
> From: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com] On 
> Behalf Of Xu, Martin
> Sent: Tuesday, February 08, 2011 9:45 PM
> To: meego-dev@meego.com; Awad, Majid; Ortiz, Samuel
> Cc: Zheng, Jeff
> Subject: [MeeGo-dev] ConnMan-0.61.1 MeeGo Integration Notification
> 
> 
> ConnMan-0.61.1 has been released at upstream, so we’d like to catch up 
> upstream release and kick off ConnMan Release @ MeeGo.
> 
> 
> 
> Merge Window: 2011-2-9 -- 2011-2-15
> We will have about 1 week buffer before the package in.
> In the buffer, we will do some test to make sure the quality.
> 
> And if your work on MeeGo depend on it, you also can modify your codes. Thank!
> 
> 
> 
> ConnMan MeeGo RPM package:
> https://build.meego.com/package/binaries?package=connman&project=devel%3Aconnectivity&repository=Trunk_Testing
> 
> ver 0.69:
> Fix issue with not handling DNS proxy failures gracefully.
> Fix issue with double free in statistics handling.
> Fix issue with early tethering bridge creation.
> Add support for tethering property per technology.
> Add support for initial WiFi tethering feature.
> Add support for using PACrunner as proxy driver.
> Add support for WPS as part of the security property.
> Please note:
> the service security  property is no longer a string but an array of strings. 
> For WiFi  services, one of the string will contain the actual security 
> protocol (none, wep, psk or  ieee80211x) that used to be the security 
> property string.  The rest of the strings carry additional security 
> properties (only  "wps" is supported for now, for WPS enabled WiFi APs). 
> Also, the boolean WPS property has been removed.
> 
> ver 0.68:
> Fix issue with wrong name of PolicyKit configuration file.
> Fix issue with inconsistency of WiFi scan states.
> Fix issue with missing auto-reconnect and oFono.
> Add support for vpnc based private networks.
> Add support for WiFi Protected Setup handling.
> Remove legacy WiFi plugin.
> 
> Quality:

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


-- 
Intel Open Source Technology Centre
http://oss.intel.com/
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev


Re: [MeeGo-dev] BME (Battery Management Entity) on MeeGo

2011-02-09 Thread Rémi Denis-Courmont
On Saturday 29 January 2011 10:42:28 ext Carsten Munk, you wrote:
> 2011/1/29 Lego Ming :
> > Hi all,
> > We want to study the Battery Management Mechanism on MeeGo Handset.
> 
> The battery management mechanism on MeeGo handset is up to the
> individual hardware adaptation. You're likely to have to implement
> that yourself depending on your hardware.

Shouldn't the values be readable with the standard power_supply device class 
in Linux sysfs at least?

-- 
Rémi Denis-Courmont
Nokia Devices R&D, Maemo Software, Helsinki
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev


Re: [MeeGo-dev] BME (Battery Management Entity) on MeeGo

2011-02-09 Thread Carsten Munk
2011/2/9 Rémi Denis-Courmont :
> On Saturday 29 January 2011 10:42:28 ext Carsten Munk, you wrote:
>> 2011/1/29 Lego Ming :
>> > Hi all,
>> > We want to study the Battery Management Mechanism on MeeGo Handset.
>>
>> The battery management mechanism on MeeGo handset is up to the
>> individual hardware adaptation. You're likely to have to implement
>> that yourself depending on your hardware.
>
> Shouldn't the values be readable with the standard power_supply device class
> in Linux sysfs at least?

In practice, contextkit values is what should matter to apps and give
the most flexibility, I believe..

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


Re: [MeeGo-dev] BME (Battery Management Entity) on MeeGo

2011-02-09 Thread Marius Vollmer
ext Carsten Munk  writes:

> 2011/2/9 Rémi Denis-Courmont :
>> On Saturday 29 January 2011 10:42:28 ext Carsten Munk, you wrote:
>>> 2011/1/29 Lego Ming :
>>> > Hi all,
>>> > We want to study the Battery Management Mechanism on MeeGo Handset.
>>>
>>> The battery management mechanism on MeeGo handset is up to the
>>> individual hardware adaptation. You're likely to have to implement
>>> that yourself depending on your hardware.
>>
>> Shouldn't the values be readable with the standard power_supply device class
>> in Linux sysfs at least?
>
> In practice, contextkit values is what should matter to apps and give
> the most flexibility, I believe..

There is also the upcoming QSystemBatteryInfo in QtMobility 1.2:

https://qtmetrics.europe.nokia.com/qtmobility/mainline/qsystembatteryinfo.html
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev


Re: [MeeGo-dev] BME (Battery Management Entity) on MeeGo

2011-02-09 Thread Rémi Denis-Courmont
On Wednesday 09 February 2011 13:33:31 ext Carsten Munk, you wrote:
> 2011/2/9 Rémi Denis-Courmont :
> > On Saturday 29 January 2011 10:42:28 ext Carsten Munk, you wrote:
> >> 2011/1/29 Lego Ming :
> >> > Hi all,
> >> > We want to study the Battery Management Mechanism on MeeGo Handset.
> >> 
> >> The battery management mechanism on MeeGo handset is up to the
> >> individual hardware adaptation. You're likely to have to implement
> >> that yourself depending on your hardware.
> > 
> > Shouldn't the values be readable with the standard power_supply device
> > class in Linux sysfs at least?
> 
> In practice, contextkit values is what should matter to apps and give
> the most flexibility, I believe..

That's the discussion whether apps should/could get the value from sysfs, 
(lib)udev, ContextKit, QtMobility, FreeDesktop D-Bus PowerManager, and/or the 
proprietary BME message queue protocol. And that was not my point.

MeeGo is not just a standardized developer API. It's an operating system and 
an implementation of that API. I am questioning not how the value should be 
read, but where the value should come from. Unless there is a reason why 
reimplementing the API back-end with every MeeGo products is unavoidable, this 
stuff should be commoditized.

I mean, we already have the Linux kernel as our HAL with all the per-hardware 
drivers.

-- 
Rémi Denis-Courmont
Nokia Devices R&D, Maemo Software, Helsinki
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev


Re: [MeeGo-dev] Problem in setting up OBS

2011-02-09 Thread Yun-Seok Jang
Hi John,

 john pratss  11/02/08 오후 4:04 >>>
>Hi All,
>
>I am trying to set up the OBS with drop 1.1 latest using 
>http://wiki.meego.com/User:Stskeeps/10_easy_steps_to_a_local_OBS. 
>

Didn't try this.

>I am unable to connect to the web interface for my locally set OBS ( 
>http://IP/ --> 500 - Internal Server Error) and as well as to repository 
>>(http://IP:82/  --> 404 - Not Found).
>But I am able to access the API interface using http://IP:81/.

Please check if you uncomment some lines in 3.2 from 
/usr/share/doc/packages/obs-api/README.SETUP  file.
and of course,  $rclighttpd start  to restart lighttpd.
You could ask OBS question to OBS mailing list.
Hope this would solve your problem.

Best regards,
YS Jang



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


Re: [MeeGo-dev] How do you make libqtwebkit-devel-2.1.0 for armv7l?

2011-02-09 Thread Eero Tamminen

Hi,

ext fathi.bou...@nokia.com wrote:

What build options are you using?


CXXFLAGS='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions 
-fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security  
-fmessage-length=0 -march=armv7-a -mtune=cortex-a8 -mlittle-endian  -mfpu=vfpv3 
-mfloat-abi=softfp -D__SOFTFP__'


Why softfp?


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


Re: [MeeGo-dev] How do you make libqtwebkit-devel-2.1.0 for armv7l?

2011-02-09 Thread Carsten Munk
2011/2/9 Eero Tamminen :
> Hi,
>
> ext fathi.bou...@nokia.com wrote:
>>>
>>> What build options are you using?
>>
>> CXXFLAGS='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
>> -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security
>>  -fmessage-length=0 -march=armv7-a -mtune=cortex-a8 -mlittle-endian
>>  -mfpu=vfpv3 -mfloat-abi=softfp -D__SOFTFP__'
>
> Why softfp?
Because MeeGo ARM is currently softfp, but is changing to
mfloat-abi=hard for 1.2 as per TSG decision. Port exists in
devel:hardfp:prep:Trunk:Testing and devel:hardfp:prep:Trunk and
already boots to Handset UX.

/Carsten

>
>
>        - Eero
> ___
> 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] BME (Battery Management Entity) on MeeGo

2011-02-09 Thread Arjan van de Ven

On 2/9/2011 3:30 AM, Rémi Denis-Courmont wrote:

On Saturday 29 January 2011 10:42:28 ext Carsten Munk, you wrote:

2011/1/29 Lego Ming:

Hi all,
We want to study the Battery Management Mechanism on MeeGo Handset.

The battery management mechanism on MeeGo handset is up to the
individual hardware adaptation. You're likely to have to implement
that yourself depending on your hardware.

Shouldn't the values be readable with the standard power_supply device class
in Linux sysfs at least?


absolutely

and the layer on top of that is upower which provides a dbus interface 
to this information.


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


Re: [MeeGo-dev] ConnMan-0.61.1 MeeGo Integration Notification

2011-02-09 Thread feng wang
hi all,

Sorry, it seems not available from the original link:
https://build.meego.com/package/binaries?package=connman&project=devel%3Aconnectivity&repository=Trunk_Testing

Regards,

  Shawn

On Wed, Feb 9, 2011 at 7:22 PM, Samuel Ortiz  wrote:
> Yes, this is a typo. Martin meant 0.69.1
>
> Cheers,
> Samuel.
>
> On Wed, Feb 09, 2011 at 04:02:58AM -0700, Clark, Joel wrote:
>> The version numbering here does not make sense.  You list the changes in 
>> 0.68 and 0.69 and then say we are moving to 0.61.1.  Is this a typo?
>>
>> From: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com] On 
>> Behalf Of Xu, Martin
>> Sent: Tuesday, February 08, 2011 9:45 PM
>> To: meego-dev@meego.com; Awad, Majid; Ortiz, Samuel
>> Cc: Zheng, Jeff
>> Subject: [MeeGo-dev] ConnMan-0.61.1 MeeGo Integration Notification
>>
>>
>> ConnMan-0.61.1 has been released at upstream, so we’d like to catch up 
>> upstream release and kick off ConnMan Release @ MeeGo.
>>
>>
>>
>> Merge Window: 2011-2-9 -- 2011-2-15
>> We will have about 1 week buffer before the package in.
>> In the buffer, we will do some test to make sure the quality.
>>
>> And if your work on MeeGo depend on it, you also can modify your codes. 
>> Thank!
>>
>>
>>
>> ConnMan MeeGo RPM package:
>> https://build.meego.com/package/binaries?package=connman&project=devel%3Aconnectivity&repository=Trunk_Testing
>>
>> ver 0.69:
>>     Fix issue with not handling DNS proxy failures gracefully.
>>     Fix issue with double free in statistics handling.
>>     Fix issue with early tethering bridge creation.
>>     Add support for tethering property per technology.
>>     Add support for initial WiFi tethering feature.
>>     Add support for using PACrunner as proxy driver.
>> Add support for WPS as part of the security property.
>> Please note:
>> the service security  property is no longer a string but an array of 
>> strings. For WiFi  services, one of the string will contain the actual 
>> security protocol (none, wep, psk or  ieee80211x) that used to be the 
>> security property string.  The rest of the strings carry additional security 
>> properties (only  "wps" is supported for now, for WPS enabled WiFi APs). 
>> Also, the boolean WPS property has been removed.
>>
>> ver 0.68:
>>     Fix issue with wrong name of PolicyKit configuration file.
>>     Fix issue with inconsistency of WiFi scan states.
>>     Fix issue with missing auto-reconnect and oFono.
>>     Add support for vpnc based private networks.
>>     Add support for WiFi Protected Setup handling.
>>     Remove legacy WiFi plugin.
>>
>> Quality:
>
>> ___
>> MeeGo-dev mailing list
>> MeeGo-dev@meego.com
>> http://lists.meego.com/listinfo/meego-dev
>
>
> --
> Intel Open Source Technology Centre
> http://oss.intel.com/
> ___
> MeeGo-dev mailing list
> MeeGo-dev@meego.com
> http://lists.meego.com/listinfo/meego-dev
>



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


Re: [MeeGo-dev] ConnMan-0.61.1 MeeGo Integration Notification

2011-02-09 Thread Zheng, Jeff
You need an account. Or you can get it from 
http://download.meego.com/live/devel:/connectivity/Trunk_Testing/i586/

Bests
Jeff

> -Original Message-
> From: feng wang [mailto:taurus...@gmail.com]
> Sent: Thursday, February 10, 2011 11:15 AM
> To: Samuel Ortiz
> Cc: Clark, Joel; meego-dev@meego.com; Ortiz, Samuel; Awad, Majid; Zheng,
> Jeff
> Subject: Re: [MeeGo-dev] ConnMan-0.61.1 MeeGo Integration Notification
> 
> hi all,
> 
> Sorry, it seems not available from the original link:
> https://build.meego.com/package/binaries?package=connman&project=devel
> %3Aconnectivity&repository=Trunk_Testing
> 
> Regards,
> 
>   Shawn
> 
> On Wed, Feb 9, 2011 at 7:22 PM, Samuel Ortiz 
> wrote:
> > Yes, this is a typo. Martin meant 0.69.1
> >
> > Cheers,
> > Samuel.
> >
> > On Wed, Feb 09, 2011 at 04:02:58AM -0700, Clark, Joel wrote:
> >> The version numbering here does not make sense.  You list the changes in
> 0.68 and 0.69 and then say we are moving to 0.61.1.  Is this a typo?
> >>
> >> From: meego-dev-boun...@meego.com
> [mailto:meego-dev-boun...@meego.com] On Behalf Of Xu, Martin
> >> Sent: Tuesday, February 08, 2011 9:45 PM
> >> To: meego-dev@meego.com; Awad, Majid; Ortiz, Samuel
> >> Cc: Zheng, Jeff
> >> Subject: [MeeGo-dev] ConnMan-0.61.1 MeeGo Integration Notification
> >>
> >>
> >> ConnMan-0.61.1 has been released at upstream, so we'd like to catch up
> upstream release and kick off ConnMan Release @ MeeGo.
> >>
> >>
> >>
> >> Merge Window: 2011-2-9 -- 2011-2-15
> >> We will have about 1 week buffer before the package in.
> >> In the buffer, we will do some test to make sure the quality.
> >>
> >> And if your work on MeeGo depend on it, you also can modify your codes.
> Thank!
> >>
> >>
> >>
> >> ConnMan MeeGo RPM package:
> >>
> https://build.meego.com/package/binaries?package=connman&project=devel
> %3Aconnectivity&repository=Trunk_Testing
> >>
> >> ver 0.69:
> >>     Fix issue with not handling DNS proxy failures gracefully.
> >>     Fix issue with double free in statistics handling.
> >>     Fix issue with early tethering bridge creation.
> >>     Add support for tethering property per technology.
> >>     Add support for initial WiFi tethering feature.
> >>     Add support for using PACrunner as proxy driver.
> >> Add support for WPS as part of the security property.
> >> Please note:
> >> the service security  property is no longer a string but an array of 
> >> strings.
> For WiFi  services, one of the string will contain the actual security 
> protocol
> (none, wep, psk or  ieee80211x) that used to be the security property
> string.  The rest of the strings carry additional security properties
> (only  "wps" is supported for now, for WPS enabled WiFi APs). Also, the
> boolean WPS property has been removed.
> >>
> >> ver 0.68:
> >>     Fix issue with wrong name of PolicyKit configuration file.
> >>     Fix issue with inconsistency of WiFi scan states.
> >>     Fix issue with missing auto-reconnect and oFono.
> >>     Add support for vpnc based private networks.
> >>     Add support for WiFi Protected Setup handling.
> >>     Remove legacy WiFi plugin.
> >>
> >> Quality:
> >
> >> ___
> >> MeeGo-dev mailing list
> >> MeeGo-dev@meego.com
> >> http://lists.meego.com/listinfo/meego-dev
> >
> >
> > --
> > Intel Open Source Technology Centre
> > http://oss.intel.com/
> > ___
> > MeeGo-dev mailing list
> > MeeGo-dev@meego.com
> > http://lists.meego.com/listinfo/meego-dev
> >
> 
> 
> 
> --
> Wang Feng. Shawn
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev