Re: [E-devel] edbus connman api break.

[The Rasterman]

On Sun, 20 Nov 2011 21:52:31 -0500 Mike Blumenkrantz  said:

> On Mon, 21 Nov 2011 11:35:14 +0900
> Carsten Haitzler (The Rasterman)  wrote:
> 
> > On Sun, 20 Nov 2011 21:03:00 -0200 Gustavo Sverzut Barbieri
> >  said:
> > 
> > > What I tried to mean as well in README is that while libedbus.so is
> > > stable and there is an API for it, everything else in e_dbus/src/lib/
> > > is convenience that is linked to the target service. As it should be.
> > > We just need these things due lack of code generator.
> > 
> > unfortunately as of edbus 1.0 nothing in the README states connman (or any
> > other sub libs) was stable.
> > 
> > > None of e_dbus/src/lib/* are abstraction layers in the sense of Ecore
> > > et al. They are direct 1:1 mapping to the service. They always should
> > > be.
> > 
> > that doesn't matter. it's a library with an api and abi and it hasn't
> > changed major version thus must not break. there isn't something to debate
> > here. these are the rules of writing shared libraries. you don't get to
> > just change them.
> > 
> > > If one wants to create some enetwork that may talk to connman or
> > > networkmanager, then that's fine. Similar to ediskmanager to talk to
> > > hal or udisks. But that's not the case now.
> > 
> > that doesn't change the fact that a shared library must not break api or abi
> > within the same major version. api/abi can be added in minor versions, but
> > nothing can be removed or changed.
> > 
> > > ASAP I'll remove libeconnman.so it will cease to exist. A new library
> > > will be in, then it's not causing problems.
> > > 
> > > So this "it's a release, you ask for it then you complain" is just
> > > *FUD*. Please stop. Don't  flip things upside down.
> > 
> > why the resistance to live up to the responsibilities of a library
> > author/maintainer? the responsibility is to maintain compatibility going
> > forward until a major version bump. if there is no will to do that then
> > either don't release a library. too late. it's released. this is something
> > YOU specifically wanted very much.
> > 
> Can we just figure out a solution to this and stop the arguing over who is
> right or whatever? We supposedly have a release soon, and this appears to be a
> blocker.

i've offered the solutions:

1. remove econnman from edbus entirely (put it into e17).
2. change major version of econnman and put headers into edbus-2 dir and change
econnman.pc to be econnman-2.pc
3. have compat api's and make them work (i've added them - i haven't made them
work).

> I propose that following this 1.1 release, we leave e_dbus and related libs as
> they are, starting a new library to do dbus serialization using eet and
> ecore-con. A code generator can be added on top of this, and that will provide

no - that wouldnt be compatible with dbus. dbus has a specific socket setup
(anonymous sockets on linux normally which ecore_con can do) AND a spefific
wire protocol for encoding data. if we don't deal with that encoding, then it
isn't dbus. :)

> the necessary infrastructure and scalability. The current e_dbus can be like
> embryo, which also will never reach 2.0.
> 
> -- 
> Mike Blumenkrantz
> Zentific: Doctor recommended, mother approved.
> 


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: seoz trunk/web/www/i

[Daniel Juyung Seo]

Welll, this is a facebook question. But what is the main reason you
prefer page not group?
I'm familiar with group not page. And where can I see the list of
pages that I marked 'like'?
I'm trying to be social :)

Daniel Juyung Seo (SeoZ)

On Mon, Nov 21, 2011 at 1:03 PM, Daniel Juyung Seo  wrote:
> Hello, I created Enlightenment Korea page.
> http://www.facebook.com/enlightenment.or.kr
>
> But I can't register enlightenment.kr by mistake :) I registered that
> to my personal username and it's not usable even I changed my personal
> user name to another one.
>
> Anyhow, I have no "Use Facebook as Enlightenment Foundation Libraries"
> menu in  http://www.facebook.com/enlightenment.org.
> Maybe admin only can do that job. Are you registered as an admin?
> If so, please like Enlightenment Korea page.
>
> Thanks.
>
> Daniel Juyung Seo (SeoZ)
>
> On Sun, Nov 20, 2011 at 9:25 AM, Gustavo Sverzut Barbieri
>  wrote:
>> On Sat, Nov 19, 2011 at 12:56 PM, Enlightenment SVN
>>  wrote:
>>> Log:
>>> web: Added South Korean flag image to web for facebook link.
>>>  Copied from trunk/e/data/images/lang-ko_KR.png and scaled donw to 25x17.
>>
>> as said at IRC, but replicated here as it also may apply to France and 
>> Greece:
>>   1 - create a page, not a group
>>   2 - give it a name at http://facebook.com/username, global is:
>> enlightenment.org, brazilian is enlightenment.br, you can choose
>> whatever you wish, but if you can follow it would be great
>>   3 - go to http://www.facebook.com/enlightenment.org and choose at
>> the right-side: "Use Facebook as Enlightenment Foundation Libraries",
>> then go to your new page and like it. Automatically the new page will
>> show at the left-bottom side of EFL page! It's like a friend's circle
>>
>>
>> --
>> Gustavo Sverzut Barbieri
>> http://profusion.mobi embedded systems
>> --
>> MSN: barbi...@gmail.com
>> Skype: gsbarbieri
>> Mobile: +55 (19) 9225-2202
>>
>> --
>> All the data continuously generated in your IT infrastructure
>> contains a definitive record of customers, application performance,
>> security threats, fraudulent activity, and more. Splunk takes this
>> data and makes sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-novd2d
>> ___
>> enlightenment-devel mailing list
>> enlightenment-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>>
>

--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: seoz trunk/web/www/i

[Daniel Juyung Seo]

Hello, I created Enlightenment Korea page.
http://www.facebook.com/enlightenment.or.kr

But I can't register enlightenment.kr by mistake :) I registered that
to my personal username and it's not usable even I changed my personal
user name to another one.

Anyhow, I have no "Use Facebook as Enlightenment Foundation Libraries"
menu in  http://www.facebook.com/enlightenment.org.
Maybe admin only can do that job. Are you registered as an admin?
If so, please like Enlightenment Korea page.

Thanks.

Daniel Juyung Seo (SeoZ)

On Sun, Nov 20, 2011 at 9:25 AM, Gustavo Sverzut Barbieri
 wrote:
> On Sat, Nov 19, 2011 at 12:56 PM, Enlightenment SVN
>  wrote:
>> Log:
>> web: Added South Korean flag image to web for facebook link.
>>  Copied from trunk/e/data/images/lang-ko_KR.png and scaled donw to 25x17.
>
> as said at IRC, but replicated here as it also may apply to France and Greece:
>   1 - create a page, not a group
>   2 - give it a name at http://facebook.com/username, global is:
> enlightenment.org, brazilian is enlightenment.br, you can choose
> whatever you wish, but if you can follow it would be great
>   3 - go to http://www.facebook.com/enlightenment.org and choose at
> the right-side: "Use Facebook as Enlightenment Foundation Libraries",
> then go to your new page and like it. Automatically the new page will
> show at the left-bottom side of EFL page! It's like a friend's circle
>
>
> --
> Gustavo Sverzut Barbieri
> http://profusion.mobi embedded systems
> --
> MSN: barbi...@gmail.com
> Skype: gsbarbieri
> Mobile: +55 (19) 9225-2202
>
> --
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>

--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] edbus connman api break.

[Mike Blumenkrantz]

On Mon, 21 Nov 2011 12:56:01 +1000
David Seikel  wrote:

> On Sun, 20 Nov 2011 21:52:31 -0500 Mike Blumenkrantz
>  wrote:
> 
> > The current e_dbus can be like embryo, which also will never reach
> > 2.0.
> 
> A, poor little embryo will never grow up.  I suppose we should be
> glad to miss out on the terrible twos.
> 
Bad email bot! No trolling in the serious threads! SPANK SPANK SPANK!

-- 
Mike Blumenkrantz
Zentific: Doctor recommended, mother approved.

--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] edbus connman api break.

[David Seikel]

On Sun, 20 Nov 2011 21:52:31 -0500 Mike Blumenkrantz
 wrote:

> The current e_dbus can be like embryo, which also will never reach
> 2.0.

A, poor little embryo will never grow up.  I suppose we should be
glad to miss out on the terrible twos.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] edbus connman api break.

[Mike Blumenkrantz]

On Mon, 21 Nov 2011 11:35:14 +0900
Carsten Haitzler (The Rasterman)  wrote:

> On Sun, 20 Nov 2011 21:03:00 -0200 Gustavo Sverzut Barbieri
>  said:
> 
> > What I tried to mean as well in README is that while libedbus.so is
> > stable and there is an API for it, everything else in e_dbus/src/lib/
> > is convenience that is linked to the target service. As it should be.
> > We just need these things due lack of code generator.
> 
> unfortunately as of edbus 1.0 nothing in the README states connman (or any
> other sub libs) was stable.
> 
> > None of e_dbus/src/lib/* are abstraction layers in the sense of Ecore
> > et al. They are direct 1:1 mapping to the service. They always should
> > be.
> 
> that doesn't matter. it's a library with an api and abi and it hasn't changed
> major version thus must not break. there isn't something to debate here. these
> are the rules of writing shared libraries. you don't get to just change them.
> 
> > If one wants to create some enetwork that may talk to connman or
> > networkmanager, then that's fine. Similar to ediskmanager to talk to
> > hal or udisks. But that's not the case now.
> 
> that doesn't change the fact that a shared library must not break api or abi
> within the same major version. api/abi can be added in minor versions, but
> nothing can be removed or changed.
> 
> > ASAP I'll remove libeconnman.so it will cease to exist. A new library
> > will be in, then it's not causing problems.
> > 
> > So this "it's a release, you ask for it then you complain" is just
> > *FUD*. Please stop. Don't  flip things upside down.
> 
> why the resistance to live up to the responsibilities of a library
> author/maintainer? the responsibility is to maintain compatibility going
> forward until a major version bump. if there is no will to do that then either
> don't release a library. too late. it's released. this is something YOU
> specifically wanted very much.
> 
Can we just figure out a solution to this and stop the arguing over who is
right or whatever? We supposedly have a release soon, and this appears to be a
blocker.

I propose that following this 1.1 release, we leave e_dbus and related libs as
they are, starting a new library to do dbus serialization using eet and
ecore-con. A code generator can be added on top of this, and that will provide
the necessary infrastructure and scalability. The current e_dbus can be like
embryo, which also will never reach 2.0.

-- 
Mike Blumenkrantz
Zentific: Doctor recommended, mother approved.

--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [Patch][Ecore][Win] Changing key name and composer for Shift, Control, Alt

[Kim Shinwoo]

Dear Mr. Vincent, Hello!

I have verified. It works properly.
When I press the left (or right) shift key, it gives Shift_L (or Shift_R).
When I release the left (or right) shift key, it gives Shift_L (or
Shift_R). :)

Sincerely,
Shinwoo Kim.



2011/11/20 Vincent Torri 

>
>
> On Thu, 17 Nov 2011, Kim Shinwoo wrote:
>
> > Dear All, Hello~
> >
> > This is Shinwoo Kim (Previously I have used cnook, kimcinoo@gmail.comfor
> > contribution)
> >
> > The key compose and name have been different with xlib. So I have changed
> > the value of Shift, Control, and Alt.
> > Moreover, the attached patch is able to distinguish between Shift_L and
> > Shift_R as xlib.
> > Please review this and give any feedbacks, Thanks!
>
> the patch was not entirely correct. I think that I have fixed it in svn.
> Could you verify, please ?
>
> Vincent
>
>
> --
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] elm_naviframe_item_promote broken?

[ChunEon Park]

I think auto-generated button does not matter.But when you set the 
content_preserve_on_pop, 
the only content object would be preserved but not elm_naviframe_item 
when you call "elm_naviframe_item_pop". 
You may know the content indicates 
elm_naviframe_item_push(.., content, ...);

-Regards, Hermet-
 
-Original Message-
From: "Leif Middelschulte" 
To: "Enlightenment developer 
list"
Cc: 
Sent: 11-11-21(월) 09:27:46
Subject: Re: [E-devel] elm_naviframe_item_promote broken?
2011/11/20 ChunEon Park :
>
> Hi , Leif.
Hey,
thanks for the quick response.
>
> I added elm_naviframe_item_promote test case in elementary_test.
> But didn't find the same problem.
I think the reason I have this problem is the auto generated
"back"-button, that messes with the page that is "popped".
I don't know what it does with it, but even though "preserve_pages" is
set, the popped page isn't usable anymore and leads to the magic check
fail.
In your elm test code, you manually create a button, that's why I
guess you can't reproduce this.
>
> Please check it again and notice me your usage if you still have that problem
Just try using pages that were popped using the autogenerated
'prev'-button. Doesn't matter whether the preserve option is set or
not.
>
> 
> -Regards, Hermet-
>
> -Original Message-
> From: "Leif Middelschulte"
> To: enlightenment-devel@lists.sourceforge.net
> Cc:
> Sent: 11-11-20(일) 04:40:16
> Subject: [E-devel] elm_naviframe_item_promote broken?
> Hey there,
> when I use elm_naviframe_item_promote on an item created using
> elm_naviframe_item_push, the magic check in the promote function
> fails.
> Sadly I couldn't find anything using this function in trunk to have a
> look at what I might did wrong. The examples in elementary test don't
> use it.
> Could the person who wrote it verify this issue?
> BR,
> Leif
> --
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> --
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
-- 
Leif
--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] edbus connman api break.

[The Rasterman]

On Sun, 20 Nov 2011 16:48:55 -0200 Lucas De Marchi
 said:

> On Sun, Nov 20, 2011 at 2:18 AM, Carsten Haitzler 
> wrote:
> > On Sat, 19 Nov 2011 14:24:46 -0200 Lucas De Marchi
> >  said:
> >
> >> On Sat, Nov 19, 2011 at 7:25 AM, Carsten Haitzler 
> >> wrote:
> >> > while making connman work and improve is good... the edbus connman api
> >> > has been quite heavily broken now.
> >> >
> >> > this is now a blocker for efl 1.1 and we can't release until resolved.
> >> > here is what has happened:
> >> >
> >> > e_connman_service_apn_get() removed
> >> > e_connman_service_apn_set() removed
> >> > e_connman_service_ethernet_netmask_get() removed
> >> > e_connman_service_mnc_get() removed
> >> > e_connman_service_mode_get() removed
> >> > e_connman_service_security_get() api/abi break in parameters passed
> >> > e_connman_service_setup_required_get() removed
> >> >
> >> > we can't release with all these breaks. we are the ones providing an
> >> > advertised stable api to talk to connman. if connman itself breaks api,
> >> > it is our job to do either:
> >>
> >> I think there's not point in saying we implement a stable connman API.
> >> There's no way to check at runtime what is the version of ConnMan and
> >> doing all the work to be compatible with previous api is totally
> >> insane.
> >
> > then bump the major .so version and bump up the pc to be econnman-2.pc and
> > move the headers to e_dbus-2/ instead of e_dbus-1/, make sure all the
> > autofoo does the right thing there in the build tree and make sure everyone
> > knows it. the problem is they kind of don't because its hidden inside a
> > debus-1.x tarball bundle.
> >
> > it's a pretty simple rule. you DON'T BREAK API OR ABI of a library within
> > the same major version.
> 
> My argument is that there's no reason to do this in a library. It's
> just there because there's currently no better way of doing it. The
> application using edbus won't know which version of the library it has
> to link to

there absolutely IS a reason to do it. when you produce a shared library you
have an api and an abi. those are to not break unless you change major version
(because the way linkers work at compile time the symlink to the major version
is resolved and thus the binary is linked to the major version series, not
minor versions). similar rules for compile-time.

the application knows what version edbus is.. it's 1.x.x - that means the
stable api released at the time. pkg-config tells it which version it is too -
down to micro version.

> >> E.g. the case a property changed from plain string to an array of
> >> strings. The natural name of the method for *future* versions cannot
> >> be used.
> >
> > after all the "we must release! release!" now this is not wanting to accept
> > the responsibility of a release, and that is to keep compatibility. it is
> > the
> 
> That is the reason there's a flag saying what is and what isn't stable.

that wasn't there at 1.0 release. too late. it was a stable released api, you
NOW are post-event marking it as unstable and breaking the api. too late. cat
was out of the bag in janruary.

> > responsibility of the library writers to keep that compatibility -
> > regardless what the connman dbus protocol does. the protocol provided a
> > single string before, and now its an array - well my bet is in that array
> > somewhere IS that original string - so for compatibility you make the old
> > api provide the "first string in the array" for example. yes - it's a pain.
> > yes. it's work. yes
> 
> It doesn't work. It compiles, but it doesn't work. Unless you send a
> dbus message with one type of parameters, and on error you send
> another. Ugly!

too bad. that's the cost of having a stable api. and edbus is a stable api.

> > connman dbus protocol changed - but that's not a pain you pass on to your
> > api users WITHOUT a big red blinking sign saying "look - it broke! don't
> > upgrade to this unless you are prepared to do some porting work on your
> > code". if e_dbus
> 
> There is a blinking sign saying: this is unstable, don't upgrade
> unless you agree that this interface can change.

tthey have no choice - because the REST of edbus upgrades and kills
compatibility with it.  as i said already - if you want to have it go keep
breaking on its own - it should not be part of edbus. as long as it is, it
stays and api stays stable until edbus 2.x - the connman api cannot be broken
in edbus during 1.x - it can be extended, but not broken. what connman itself
does is irrelevant. it is the job of edbus to provide a stable api.

> > was 0.x.x - we could pass it off as "hell it's still getting its act
> > together so it has no clue what api to use".
> >
> >> As such the plan is to support the most recent versions packaged by
> >> distros, at least until the ConnMan API becomes more stable. This is
> >> why we added this in E_Connman.h:
> >
> > added... but it wasn't there  on 1.0. 1.0 set up the playfield with an
> > advertisement of stability as 

Re: [E-devel] edbus connman api break.

[The Rasterman]

On Sun, 20 Nov 2011 21:03:00 -0200 Gustavo Sverzut Barbieri
 said:

> What I tried to mean as well in README is that while libedbus.so is
> stable and there is an API for it, everything else in e_dbus/src/lib/
> is convenience that is linked to the target service. As it should be.
> We just need these things due lack of code generator.

unfortunately as of edbus 1.0 nothing in the README states connman (or any
other sub libs) was stable.

> None of e_dbus/src/lib/* are abstraction layers in the sense of Ecore
> et al. They are direct 1:1 mapping to the service. They always should
> be.

that doesn't matter. it's a library with an api and abi and it hasn't changed
major version thus must not break. there isn't something to debate here. these
are the rules of writing shared libraries. you don't get to just change them.

> If one wants to create some enetwork that may talk to connman or
> networkmanager, then that's fine. Similar to ediskmanager to talk to
> hal or udisks. But that's not the case now.

that doesn't change the fact that a shared library must not break api or abi
within the same major version. api/abi can be added in minor versions, but
nothing can be removed or changed.

> ASAP I'll remove libeconnman.so it will cease to exist. A new library
> will be in, then it's not causing problems.
> 
> So this "it's a release, you ask for it then you complain" is just
> *FUD*. Please stop. Don't  flip things upside down.

why the resistance to live up to the responsibilities of a library
author/maintainer? the responsibility is to maintain compatibility going
forward until a major version bump. if there is no will to do that then either
don't release a library. too late. it's released. this is something YOU
specifically wanted very much.

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] edbus connman api break.

[The Rasterman]

On Sun, 20 Nov 2011 16:36:58 -0200 Lucas De Marchi
 said:

> On Sun, Nov 20, 2011 at 2:04 AM, Carsten Haitzler 
> wrote:
> > On Sat, 19 Nov 2011 14:45:13 -0200 Iván Briano (Sachiel)
> >  said:
> >
> >> 2011/11/19 David Seikel :
> >> > Oops.
> >> >
> >> > make[4]: Entering directory
> >> > `/home/dvs1/e17_svn/SVN/trunk/e/src/modules/connman'
> >> >  CC     e_mod_main.lo
> >> >  CC     e_mod_config.lo
> >> > e_mod_main.c: In function ‘_connman_service_security_find’:
> >> > e_mod_main.c:340: warning: passing argument 2 of
> >> >  ‘e_connman_service_security_get’ from incompatible pointer
> >> >  type
> >> > /opt/e17/include/e_dbus-1/E_Connman.h:247: note: expected ‘const
> >> >  char **’ but argument is of type ‘unsigned int *’
> >> > e_mod_main.c:340: error: too many arguments to function
> >> >  ‘e_connman_service_security_get’
> >> > make[4]: *** [e_mod_main.lo] Error 1
> >> >
> >> > Guessing it was this connman thing that broke E.
> >> >
> >>
> >> Bad raster! It's not enough to test that the changes build when
> >> other things depend on that!
> >
> > i fixed it - i forgot to commit it. committed now.
> 
> 
> The way you did, it will work only if you are using connman >= 0.64.
> You say it's better not to break the API/ABI but the application have
> to magically knows what method they can call?

i didn't actually fix the functionality at this point - i just restored totally
removed api's that would cause apps to simply cease to execute at all as they
would have missing symbols. it also allows them to compile still. it's better
than it was.


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: raster trunk/e_dbus/src/lib/connman

[The Rasterman]

On Mon, 21 Nov 2011 07:00:20 +1100 Jochen Schröder  said:

> On 20/11/11 18:12, Carsten Haitzler (The Rasterman) wrote:
> > On Sat, 19 Nov 2011 15:59:43 -0200 Lucas De Marchi
> >   said:
> >
> >> On Sat, Nov 19, 2011 at 7:08 AM, Enlightenment SVN
> >>   wrote:
> >>> Log:
> >>> gustavo - i know you don't like this, but putting back old connman api
> >>>   support.
> >>>
> >>>   1. you broke connman legacy support during feature freeze. this isn't
> >>>   a bug fix. it's a break.
> >>>   2. newer connmans are broken for me - my netwoork basically barely
> >>>   works. i can't make new connections reliably to anywhere outside my
> >>>   lan, and even on my lan  ssh connectiosn justdrop all the time. i'm
> >>>   sticking to a fdowngraded (0.55) connman exactly because of this.
> >>
> >> Not talking about the API break, but just about your issue with newer
> >> versions: could you please run connman with debug info (connman -nd
> >> would be sufficient), and send the log with the description of the
> >> problem to connman mailing list?
> >>
> >> Otherwise the problem might never be fixed.
> >
> > i've spotted 1 thing. later connmans put my card into 130Mb speeds (802.11N
> > land) but 0.55 stays at 802.11g (54Mb)...
> >
> Is this an intel wifi card? There seems to be a driver bug in later 
> kernels (I stumbled across this when upgrading to ubuntu 11.11). I 
> currently work around it by putting

nah. atheros 9*

> options iwlagn 11n_disable=1
> 
> somewhere in /etc/modprobe.d/
> 
> 
> Cheers
> Jochen
> 


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] elm_naviframe_item_promote broken?

[Leif Middelschulte]

2011/11/20 ChunEon Park :
>
> Hi , Leif.
Hey,

thanks for the quick response.
>
> I added elm_naviframe_item_promote test case in elementary_test.
> But didn't find the same problem.
I think the reason I have this problem is the auto generated
"back"-button, that messes with the page that is "popped".
I don't know what it does with it, but even though "preserve_pages" is
set, the popped page isn't usable anymore and leads to the magic check
fail.

In your elm test code, you manually create a button, that's why I
guess you can't reproduce this.
>
> Please check it again and notice me your usage if you still have that problem
Just try using pages that were popped using the autogenerated
'prev'-button. Doesn't matter whether the preserve option is set or
not.
>
> 
> -Regards, Hermet-
>
> -Original Message-
> From: "Leif Middelschulte"
> To: enlightenment-devel@lists.sourceforge.net
> Cc:
> Sent: 11-11-20(일) 04:40:16
> Subject: [E-devel] elm_naviframe_item_promote broken?
> Hey there,
> when I use elm_naviframe_item_promote on an item created using
> elm_naviframe_item_push, the magic check in the promote function
> fails.
> Sadly I couldn't find anything using this function in trunk to have a
> look at what I might did wrong. The examples in elementary test don't
> use it.
> Could the person who wrote it verify this issue?
> BR,
> Leif
> --
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> --
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>



-- 
Leif

--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] edbus connman api break.

[Mike Blumenkrantz]

On Sun, 20 Nov 2011 21:03:00 -0200
Gustavo Sverzut Barbieri  wrote:

> On Sun, Nov 20, 2011 at 4:48 PM, Lucas De Marchi
>  wrote:
> > On Sun, Nov 20, 2011 at 2:18 AM, Carsten Haitzler 
> > wrote:
> >> On Sat, 19 Nov 2011 14:24:46 -0200 Lucas De Marchi
> >>  said:
> >>
> >>> On Sat, Nov 19, 2011 at 7:25 AM, Carsten Haitzler 
> >>> wrote:
> >>> > while making connman work and improve is good... the edbus connman api
> >>> > has been quite heavily broken now.
> >>> >
> >>> > this is now a blocker for efl 1.1 and we can't release until resolved.
> >>> > here is what has happened:
> >>> >
> >>> > e_connman_service_apn_get() removed
> >>> > e_connman_service_apn_set() removed
> >>> > e_connman_service_ethernet_netmask_get() removed
> >>> > e_connman_service_mnc_get() removed
> >>> > e_connman_service_mode_get() removed
> >>> > e_connman_service_security_get() api/abi break in parameters passed
> >>> > e_connman_service_setup_required_get() removed
> >>> >
> >>> > we can't release with all these breaks. we are the ones providing an
> >>> > advertised stable api to talk to connman. if connman itself breaks api,
> >>> > it is our job to do either:
> >>>
> >>> I think there's not point in saying we implement a stable connman API.
> >>> There's no way to check at runtime what is the version of ConnMan and
> >>> doing all the work to be compatible with previous api is totally
> >>> insane.
> >>
> >> then bump the major .so version and bump up the pc to be econnman-2.pc and
> >> move the headers to e_dbus-2/ instead of e_dbus-1/, make sure all the
> >> autofoo does the right thing there in the build tree and make sure
> >> everyone knows it. the problem is they kind of don't because its hidden
> >> inside a debus-1.x tarball bundle.
> >>
> >> it's a pretty simple rule. you DON'T BREAK API OR ABI of a library within
> >> the same major version.
> >
> > My argument is that there's no reason to do this in a library. It's
> > just there because there's currently no better way of doing it. The
> > application using edbus won't know which version of the library it has
> > to link to
> >
> >
> >>
> >>> E.g. the case a property changed from plain string to an array of
> >>> strings. The natural name of the method for *future* versions cannot
> >>> be used.
> >>
> >> after all the "we must release! release!" now this is not wanting to
> >> accept the responsibility of a release, and that is to keep compatibility.
> >> it is the
> >
> > That is the reason there's a flag saying what is and what isn't stable.
> >
> >> responsibility of the library writers to keep that compatibility -
> >> regardless what the connman dbus protocol does. the protocol provided a
> >> single string before, and now its an array - well my bet is in that array
> >> somewhere IS that original string - so for compatibility you make the old
> >> api provide the "first string in the array" for example. yes - it's a
> >> pain. yes. it's work. yes
> >
> > It doesn't work. It compiles, but it doesn't work. Unless you send a
> > dbus message with one type of parameters, and on error you send
> > another. Ugly!
> >
> >
> >> connman dbus protocol changed - but that's not a pain you pass on to your
> >> api users WITHOUT a big red blinking sign saying "look - it broke! don't
> >> upgrade to this unless you are prepared to do some porting work on your
> >> code". if e_dbus
> >
> > There is a blinking sign saying: this is unstable, don't upgrade
> > unless you agree that this interface can change.
> >
> >> was 0.x.x - we could pass it off as "hell it's still getting its act
> >> together so it has no clue what api to use".
> >>
> >>> As such the plan is to support the most recent versions packaged by
> >>> distros, at least until the ConnMan API becomes more stable. This is
> >>> why we added this in E_Connman.h:
> >>
> >> added... but it wasn't there  on 1.0. 1.0 set up the playfield with an
> >> advertisement of stability as long as its 1.x - every time api breaks you
> >> also
> >
> > My argument is:  e_dbus is stable after 1.0 and there's no point in
> > claiming e_dbus/*/ are stable.
> >
> >
> >> drive people away - ESPECIALLY when the api breaks after a 1.x AND even
> >> more when you break it withotut changing major version.
> >>
> >> i'm just saying - that by writing a library with a public and stable api
> >> it is the responsibility of that author to not break api or abi during the
> >> lifetime of that major version. doing so simple breaks the rules and
> >> conventions laid down in unix and linux over decades that let people know
> >> that there was a break. :)
> >>
> >>> #ifndef E_CONNMAN_I_KNOW_THIS_API_IS_SUBJECT_TO_CHANGE
> >>> #error "E_Connman.h is an unstable API linked to upstream connman project"
> >>> #endif
> >>>
> >>>
> >>> However I really hope that at the time this happens we don't need this
> >>> submodule anymore. Gustavo began to work on a tool to generate the C
> >>> bindings (just like there's in, for example, qt and glib) to ease the
>

Re: [E-devel] suid bit for enlightenment_sys

[Gustavo Sverzut Barbieri]

On Sun, Nov 20, 2011 at 7:50 AM, Tomas Cech  wrote:
> Hi,
>
> On Sat, Nov 19, 2011 at 10:31:21PM -0200, Gustavo Sverzut Barbieri wrote:
>>
>> On Sat, Nov 19, 2011 at 10:15 PM, Tomas Cech  wrote:
>>>
>>> Hi,
>>>
>>> as I'm trying to get E17 into openSUSE, I'm trying to tune
>>> sysactions.conf. I'm trying to get rid of suid bit for
>>> /usr/lib64/enlightenment/utils/enlightenment_sys
>>>
>>> All my actions use DBUS messages so suid bit is useless (ok, I haven't
>>> done mount/unmount yet). When I remove suid bit from this binary,
>>> suspend fails and in log I have:
>>>
>>> ERROR: UNABLE TO ASSUME ROOT PRIVILEGES
>>>
>>> Running
>>> /usr/lib64/enlightenment/utils/enlightenment_sys suspend
>>> works fine, so my question is - is really needed check for root
>>> privileges there?
>>>
>>> Thanks.
>>>
>>> Best regards,
>>>
>>> Tomas Cech
>>> Sleep_Walker
>>>
>>>
>>> --
>>> All the data continuously generated in your IT infrastructure
>>> contains a definitive record of customers, application performance,
>>> security threats, fraudulent activity, and more. Splunk takes this
>>> data and makes sense of it. IT sense. And common sense.
>>
>> yes we do. But there is a better way we could do, patches accepted (no
>> time to do it myself):
>>  - have hibernate/suspend/... using upower
>>  - have other actions using proper daemons using dbus + polkit
>> (udisks, timedated...)
>>  - whatever else use polkit's features such as pkexec.
>>
>
> That's probably what I want to have there:
>
> action:   halt      dbus-send --system --dest=org.freedesktop.ConsoleKit
> /org/freedesktop/ConsoleKit/Manager org.freedesktop.ConsoleKit.Manager.Stop
> action:   reboot    dbus-send --system --dest=org.freedesktop.ConsoleKit
> /org/freedesktop/ConsoleKit/Manager
> org.freedesktop.ConsoleKit.Manager.Restart
> action:   suspend   dbus-send --system --dest=org.freedesktop.UPower
> /org/freedesktop/UPower org.freedesktop.UPower.Suspend
> action:   hibernate dbus-send --system --dest=org.freedesktop.UPower
> /org/freedesktop/UPower org.freedesktop.UPower.Hibernate

I was meaning to change E17 to not even call enlightenment_sys for such cases.


> But you have probably in mind something smarter, right? Well this is
> the reason I don't need root privileges, but it won't work without
> passing that check.
>
> It could make sense to at least have configuration option in
> sysactions.conf not to require root privileges.
> Something like:
>
> option: need_root       false
>
>> Would you be able to help us with that?
>
> I'm occupied by family (4 month old baby takes a lot of power and
> time) and work (learning at new position). My time is very limited and
> I'm afraid that even night builds take too much time already.
>
> I know nothing about that and I have never done anything similar so it
> would take a while. It doesn't make sense to start with this when
> workaround is simple and makes sense - it's more like fix from my POV.
> I should rather add more packages to nightly builds.

need_root seems fine, but maybe it should be per-action? What if you
need_root for shutdown but not for suspend? no idea if that may
happen... just wondering


-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202

--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] edbus connman api break.

[Gustavo Sverzut Barbieri]

On Sun, Nov 20, 2011 at 4:48 PM, Lucas De Marchi
 wrote:
> On Sun, Nov 20, 2011 at 2:18 AM, Carsten Haitzler  
> wrote:
>> On Sat, 19 Nov 2011 14:24:46 -0200 Lucas De Marchi
>>  said:
>>
>>> On Sat, Nov 19, 2011 at 7:25 AM, Carsten Haitzler 
>>> wrote:
>>> > while making connman work and improve is good... the edbus connman api has
>>> > been quite heavily broken now.
>>> >
>>> > this is now a blocker for efl 1.1 and we can't release until resolved.
>>> > here is what has happened:
>>> >
>>> > e_connman_service_apn_get() removed
>>> > e_connman_service_apn_set() removed
>>> > e_connman_service_ethernet_netmask_get() removed
>>> > e_connman_service_mnc_get() removed
>>> > e_connman_service_mode_get() removed
>>> > e_connman_service_security_get() api/abi break in parameters passed
>>> > e_connman_service_setup_required_get() removed
>>> >
>>> > we can't release with all these breaks. we are the ones providing an
>>> > advertised stable api to talk to connman. if connman itself breaks api, it
>>> > is our job to do either:
>>>
>>> I think there's not point in saying we implement a stable connman API.
>>> There's no way to check at runtime what is the version of ConnMan and
>>> doing all the work to be compatible with previous api is totally
>>> insane.
>>
>> then bump the major .so version and bump up the pc to be econnman-2.pc and 
>> move
>> the headers to e_dbus-2/ instead of e_dbus-1/, make sure all the autofoo does
>> the right thing there in the build tree and make sure everyone knows it. the
>> problem is they kind of don't because its hidden inside a debus-1.x tarball
>> bundle.
>>
>> it's a pretty simple rule. you DON'T BREAK API OR ABI of a library within the
>> same major version.
>
> My argument is that there's no reason to do this in a library. It's
> just there because there's currently no better way of doing it. The
> application using edbus won't know which version of the library it has
> to link to
>
>
>>
>>> E.g. the case a property changed from plain string to an array of
>>> strings. The natural name of the method for *future* versions cannot
>>> be used.
>>
>> after all the "we must release! release!" now this is not wanting to accept 
>> the
>> responsibility of a release, and that is to keep compatibility. it is the
>
> That is the reason there's a flag saying what is and what isn't stable.
>
>> responsibility of the library writers to keep that compatibility - regardless
>> what the connman dbus protocol does. the protocol provided a single string
>> before, and now its an array - well my bet is in that array somewhere IS that
>> original string - so for compatibility you make the old api provide the 
>> "first
>> string in the array" for example. yes - it's a pain. yes. it's work. yes
>
> It doesn't work. It compiles, but it doesn't work. Unless you send a
> dbus message with one type of parameters, and on error you send
> another. Ugly!
>
>
>> connman dbus protocol changed - but that's not a pain you pass on to your api
>> users WITHOUT a big red blinking sign saying "look - it broke! don't upgrade 
>> to
>> this unless you are prepared to do some porting work on your code". if e_dbus
>
> There is a blinking sign saying: this is unstable, don't upgrade
> unless you agree that this interface can change.
>
>> was 0.x.x - we could pass it off as "hell it's still getting its act together
>> so it has no clue what api to use".
>>
>>> As such the plan is to support the most recent versions packaged by
>>> distros, at least until the ConnMan API becomes more stable. This is
>>> why we added this in E_Connman.h:
>>
>> added... but it wasn't there  on 1.0. 1.0 set up the playfield with an
>> advertisement of stability as long as its 1.x - every time api breaks you 
>> also
>
> My argument is:  e_dbus is stable after 1.0 and there's no point in
> claiming e_dbus/*/ are stable.
>
>
>> drive people away - ESPECIALLY when the api breaks after a 1.x AND even more
>> when you break it withotut changing major version.
>>
>> i'm just saying - that by writing a library with a public and stable api it 
>> is
>> the responsibility of that author to not break api or abi during the lifetime
>> of that major version. doing so simple breaks the rules and conventions laid
>> down in unix and linux over decades that let people know that there was a
>> break. :)
>>
>>> #ifndef E_CONNMAN_I_KNOW_THIS_API_IS_SUBJECT_TO_CHANGE
>>> #error "E_Connman.h is an unstable API linked to upstream connman project"
>>> #endif
>>>
>>>
>>> However I really hope that at the time this happens we don't need this
>>> submodule anymore. Gustavo began to work on a tool to generate the C
>>> bindings (just like there's in, for example, qt and glib) to ease the
>>> use of dbus. Therefore we would not need this part of the lib and the
>>> application could directly use dbus.
>>
>> then maybe copy the existing connman code into e17's connman module and 
>> replace
>> that code when codegen works. we can keep shipping the e_dbus connman

Re: [E-devel] E SVN: raster trunk/e_dbus/src/lib/connman

[Jochen Schröder]

On 20/11/11 18:12, Carsten Haitzler (The Rasterman) wrote:
> On Sat, 19 Nov 2011 15:59:43 -0200 Lucas De Marchi
>   said:
>
>> On Sat, Nov 19, 2011 at 7:08 AM, Enlightenment SVN
>>   wrote:
>>> Log:
>>> gustavo - i know you don't like this, but putting back old connman api
>>>   support.
>>>
>>>   1. you broke connman legacy support during feature freeze. this isn't
>>>   a bug fix. it's a break.
>>>   2. newer connmans are broken for me - my netwoork basically barely
>>>   works. i can't make new connections reliably to anywhere outside my
>>>   lan, and even on my lan  ssh connectiosn justdrop all the time. i'm
>>>   sticking to a fdowngraded (0.55) connman exactly because of this.
>>
>> Not talking about the API break, but just about your issue with newer
>> versions: could you please run connman with debug info (connman -nd
>> would be sufficient), and send the log with the description of the
>> problem to connman mailing list?
>>
>> Otherwise the problem might never be fixed.
>
> i've spotted 1 thing. later connmans put my card into 130Mb speeds (802.11N
> land) but 0.55 stays at 802.11g (54Mb)...
>
Is this an intel wifi card? There seems to be a driver bug in later 
kernels (I stumbled across this when upgrading to ubuntu 11.11). I 
currently work around it by putting

options iwlagn 11n_disable=1

somewhere in /etc/modprobe.d/


Cheers
Jochen

--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] edbus connman api break.

[Lucas De Marchi]

On Sun, Nov 20, 2011 at 2:18 AM, Carsten Haitzler  wrote:
> On Sat, 19 Nov 2011 14:24:46 -0200 Lucas De Marchi
>  said:
>
>> On Sat, Nov 19, 2011 at 7:25 AM, Carsten Haitzler 
>> wrote:
>> > while making connman work and improve is good... the edbus connman api has
>> > been quite heavily broken now.
>> >
>> > this is now a blocker for efl 1.1 and we can't release until resolved.
>> > here is what has happened:
>> >
>> > e_connman_service_apn_get() removed
>> > e_connman_service_apn_set() removed
>> > e_connman_service_ethernet_netmask_get() removed
>> > e_connman_service_mnc_get() removed
>> > e_connman_service_mode_get() removed
>> > e_connman_service_security_get() api/abi break in parameters passed
>> > e_connman_service_setup_required_get() removed
>> >
>> > we can't release with all these breaks. we are the ones providing an
>> > advertised stable api to talk to connman. if connman itself breaks api, it
>> > is our job to do either:
>>
>> I think there's not point in saying we implement a stable connman API.
>> There's no way to check at runtime what is the version of ConnMan and
>> doing all the work to be compatible with previous api is totally
>> insane.
>
> then bump the major .so version and bump up the pc to be econnman-2.pc and 
> move
> the headers to e_dbus-2/ instead of e_dbus-1/, make sure all the autofoo does
> the right thing there in the build tree and make sure everyone knows it. the
> problem is they kind of don't because its hidden inside a debus-1.x tarball
> bundle.
>
> it's a pretty simple rule. you DON'T BREAK API OR ABI of a library within the
> same major version.

My argument is that there's no reason to do this in a library. It's
just there because there's currently no better way of doing it. The
application using edbus won't know which version of the library it has
to link to


>
>> E.g. the case a property changed from plain string to an array of
>> strings. The natural name of the method for *future* versions cannot
>> be used.
>
> after all the "we must release! release!" now this is not wanting to accept 
> the
> responsibility of a release, and that is to keep compatibility. it is the

That is the reason there's a flag saying what is and what isn't stable.

> responsibility of the library writers to keep that compatibility - regardless
> what the connman dbus protocol does. the protocol provided a single string
> before, and now its an array - well my bet is in that array somewhere IS that
> original string - so for compatibility you make the old api provide the "first
> string in the array" for example. yes - it's a pain. yes. it's work. yes

It doesn't work. It compiles, but it doesn't work. Unless you send a
dbus message with one type of parameters, and on error you send
another. Ugly!


> connman dbus protocol changed - but that's not a pain you pass on to your api
> users WITHOUT a big red blinking sign saying "look - it broke! don't upgrade 
> to
> this unless you are prepared to do some porting work on your code". if e_dbus

There is a blinking sign saying: this is unstable, don't upgrade
unless you agree that this interface can change.

> was 0.x.x - we could pass it off as "hell it's still getting its act together
> so it has no clue what api to use".
>
>> As such the plan is to support the most recent versions packaged by
>> distros, at least until the ConnMan API becomes more stable. This is
>> why we added this in E_Connman.h:
>
> added... but it wasn't there  on 1.0. 1.0 set up the playfield with an
> advertisement of stability as long as its 1.x - every time api breaks you also

My argument is:  e_dbus is stable after 1.0 and there's no point in
claiming e_dbus/*/ are stable.


> drive people away - ESPECIALLY when the api breaks after a 1.x AND even more
> when you break it withotut changing major version.
>
> i'm just saying - that by writing a library with a public and stable api it is
> the responsibility of that author to not break api or abi during the lifetime
> of that major version. doing so simple breaks the rules and conventions laid
> down in unix and linux over decades that let people know that there was a
> break. :)
>
>> #ifndef E_CONNMAN_I_KNOW_THIS_API_IS_SUBJECT_TO_CHANGE
>> #error "E_Connman.h is an unstable API linked to upstream connman project"
>> #endif
>>
>>
>> However I really hope that at the time this happens we don't need this
>> submodule anymore. Gustavo began to work on a tool to generate the C
>> bindings (just like there's in, for example, qt and glib) to ease the
>> use of dbus. Therefore we would not need this part of the lib and the
>> application could directly use dbus.
>
> then maybe copy the existing connman code into e17's connman module and 
> replace
> that code when codegen works. we can keep shipping the e_dbus connman forever
> and not change its api or abi. :)

This is the most sane thing I heard and I think it's the only way to
improve connman module in E.

Then I would really like to mark all the connman cal

Re: [E-devel] E SVN: raster trunk/e_dbus/src/lib/connman

[Lucas De Marchi]

On Sun, Nov 20, 2011 at 5:12 AM, Carsten Haitzler  wrote:
> On Sat, 19 Nov 2011 15:59:43 -0200 Lucas De Marchi
>  said:
>
>> On Sat, Nov 19, 2011 at 7:08 AM, Enlightenment SVN
>>  wrote:
>> > Log:
>> > gustavo - i know you don't like this, but putting back old connman api
>> >  support.
>> >
>> >  1. you broke connman legacy support during feature freeze. this isn't
>> >  a bug fix. it's a break.
>> >  2. newer connmans are broken for me - my netwoork basically barely
>> >  works. i can't make new connections reliably to anywhere outside my
>> >  lan, and even on my lan  ssh connectiosn justdrop all the time. i'm
>> >  sticking to a fdowngraded (0.55) connman exactly because of this.
>>
>> Not talking about the API break, but just about your issue with newer
>> versions: could you please run connman with debug info (connman -nd
>> would be sufficient), and send the log with the description of the
>> problem to connman mailing list?
>>
>> Otherwise the problem might never be fixed.
>
> i've spotted 1 thing. later connmans put my card into 130Mb speeds (802.11N
> land) but 0.55 stays at 802.11g (54Mb)...

Please, run connman with "-nd" parameter and send the log.


Lucas De Marchi

--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] edbus connman api break.

[Lucas De Marchi]

On Sun, Nov 20, 2011 at 2:04 AM, Carsten Haitzler  wrote:
> On Sat, 19 Nov 2011 14:45:13 -0200 Iván Briano (Sachiel) 
> said:
>
>> 2011/11/19 David Seikel :
>> > Oops.
>> >
>> > make[4]: Entering directory
>> > `/home/dvs1/e17_svn/SVN/trunk/e/src/modules/connman'
>> >  CC     e_mod_main.lo
>> >  CC     e_mod_config.lo
>> > e_mod_main.c: In function ‘_connman_service_security_find’:
>> > e_mod_main.c:340: warning: passing argument 2 of
>> >  ‘e_connman_service_security_get’ from incompatible pointer
>> >  type
>> > /opt/e17/include/e_dbus-1/E_Connman.h:247: note: expected ‘const
>> >  char **’ but argument is of type ‘unsigned int *’
>> > e_mod_main.c:340: error: too many arguments to function
>> >  ‘e_connman_service_security_get’
>> > make[4]: *** [e_mod_main.lo] Error 1
>> >
>> > Guessing it was this connman thing that broke E.
>> >
>>
>> Bad raster! It's not enough to test that the changes build when
>> other things depend on that!
>
> i fixed it - i forgot to commit it. committed now.


The way you did, it will work only if you are using connman >= 0.64.
You say it's better not to break the API/ABI but the application have
to magically knows what method they can call?


Lucas De Marchi

--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Possible lua excess code?

[David Seikel]

On Mon, 21 Nov 2011 00:17:26 +1000 David Seikel 
wrote:

> On Sun, 20 Nov 2011 01:21:48 +1000 David Seikel 
> wrote:
> 
> > I'm not sure what you where thinking, perhaps that the user
> > could pass in a table to be filled in?  Seems odd.
> > 
> > There's a few of these, I'll just leave a FIXME comment for now, but
> > I'll probably remove the check before the release.
> 
> On a related note, I'm not so sure about this business of reusing
> tables that are passed in as parameters for the results to be
> returned.  I don't think that sort of thing is used anywhere else in
> lua, AND we are returning the result table anyway.
> 
> It's quite nice that things like colour and coords can be passed back
> and forth as a table.  Even better is that excess stuff in these
> tables is ignored if passed in as arguments.  Better still that they
> can be passed in as separate values.
> 
> map:lighting() accepts one set of 3D coords, and two sets of colours.
> 
> map:rotate3d() accepts two sets of 3D coords.
> 
> map:zoom() accepts two sets of 2D coords.
> 
> The problem with these, if using the generic argument scanner I wrote,
> based on the several specialized argument scanners you wrote, is that
> it tries to reuse the table passed in to return results, but A) which
> table?  B) it does a reset of the stack, that causes problems for the
> next scanner call that tries to get the next set of arguments.
> 
> Well, OK, those three don't return any values, so A is moot.  And B is
> moot for those three anyway, since the stack reset is bypassed.  I
> still think it might be a problem for future API additions.
> 
> I still think it would be much cleaner to NOT reuse passed in tables,
> and to not pass values back in optional passed in tables.  This solves
> both problems mentioned in this thread, and makes things cleaner all
> around.
> 
> So that would mean that we remove the bool that tells the argument
> scanner to reuse or create a table, and have the generic "return
> results in a table" function create it's own table.  And remove that
> lua_istable check mentioned in the last email.
> 
> I'll double check if the example is using that sort of thing, then
> make these changes and commit.  You can revert if you disagree.
> 

Just as an example to make my point -

colour_red = {255, 0, 0, 255}
colour_green = {0, 255, 0, 255}

-- some time later

   if (some_bool) then
  some_evas_object:color(colour_red)
   else
  some_evas_object:color(colour_green)

And the scripter wonders why odd things happen to his colours.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: cedric trunk/ecore/src/lib/ecore_file

[David Seikel]

On Sun, 20 Nov 2011 07:14:48 -0800 "Enlightenment SVN"
 wrote:

> Log:
> ecore: use Eina_File for cleaner more portable code.
>   
> 
> Author:   cedric
> Date: 2011-11-20 07:14:48 -0800 (Sun, 20 Nov 2011)
> New Revision: 65451
> Trac: http://trac.enlightenment.org/e/changeset/65451
> 
> Modified:
>   trunk/ecore/src/lib/ecore_file/ecore_file.c
> trunk/ecore/src/lib/ecore_file/ecore_file_private.h 
> 

Dunno, maybe you broke this to?

ecore_file.c: In function ‘ecore_file_mksubdirs’:
ecore_file.c:263: error: ‘DIR’ undeclared (first use in this function)
ecore_file.c:263: error: (Each undeclared identifier is reported only
once 
ecore_file.c:263: error: for each function it appears in.)
ecore_file.c:263: error: ‘dir’ undeclared (first use in this function)
ecore_file.c:284: warning: implicit declaration of function ‘opendir’
ecore_file.c:287: warning: implicit declaration of function ‘dirfd’
ecore_file.c:326: warning: implicit declaration of function ‘closedir’

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: cedric trunk/evas/src/lib/canvas

[David Seikel]

On Sun, 20 Nov 2011 07:17:30 -0800 "Enlightenment SVN"
 wrote:

> Log:
> evas: correct header order.
>   
> 
> Author:   cedric
> Date: 2011-11-20 07:17:29 -0800 (Sun, 20 Nov 2011)
> New Revision: 65452
> Trac: http://trac.enlightenment.org/e/changeset/65452
> 
> Modified:
>   trunk/evas/src/lib/canvas/evas_async_events.c 
> 
> Modified: trunk/evas/src/lib/canvas/evas_async_events.c
> ===
> --- trunk/evas/src/lib/canvas/evas_async_events.c 2011-11-20
> 15:14:48 UTC (rev 65451) +++
> trunk/evas/src/lib/canvas/evas_async_events.c 2011-11-20
> 15:17:29 UTC (rev 65452) @@ -1,6 +1,3 @@ -#include "evas_common.h"
> -#include "evas_private.h"
> -
>  #ifdef BUILD_ASYNC_EVENTS
>  
>  # ifndef _MSC_VER
> @@ -9,6 +6,13 @@
>  # include 
>  # include 
>  
> +#endif
> +
> +#include "evas_common.h"
> +#include "evas_private.h"
> +
> +#ifdef BUILD_ASYNC_EVENTS
> +
>  static int _fd_write = -1;
>  static int _fd_read = -1;
>  
> @@ -159,7 +163,7 @@
>  
> return result;
>  #else
> -   func(target, type, event_info);
> +   func((void*) target, type, event_info);
> return EINA_TRUE;
>  #endif
>  }

Maybe this is why evas is broken?

evas_async_events.c: In function ‘evas_async_events_init’:
evas_async_events.c:48: warning: implicit declaration of function
‘fcntl’ 
evas_async_events.c:48: error: ‘F_SETFL’ undeclared (first use
in this function) 
evas_async_events.c:48: error: (Each undeclared identifier is reported
only once 
evas_async_events.c:48: error: for each function it appears in.) 
evas_async_events.c:48: error: ‘O_NONBLOCK’ undeclared (first use in
this function)


-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: cedric trunk/edje/src/lib

[David Seikel]

On Sun, 20 Nov 2011 06:15:37 -0800 "Enlightenment SVN"
 wrote:

> Log:
> edje: remove warning when building without Ecore_IMF.
>   
> 
> Author:   cedric
> Date: 2011-11-20 06:15:37 -0800 (Sun, 20 Nov 2011)
> New Revision: 65440
> Trac: http://trac.enlightenment.org/e/changeset/65440
> 
> Modified:
>   trunk/edje/src/lib/edje_entry.c 
> 
> Modified: trunk/edje/src/lib/edje_entry.c
> ===
> --- trunk/edje/src/lib/edje_entry.c   2011-11-20 14:11:50 UTC
> (rev 65439) +++ trunk/edje/src/lib/edje_entry.c   2011-11-20
> 14:15:37 UTC (rev 65440) @@ -1508,9 +1508,9 @@
>  _edje_key_up_cb(void *data, Evas *e __UNUSED__, Evas_Object *obj
> __UNUSED__, void *event_info) {
> Edje *ed = data;
> -   Evas_Event_Key_Up *ev = event_info;
> Edje_Real_Part *rp = ed->focused_part;
> Entry *en;
> +
> if (!rp) return;
> en = rp->entry_data;
> if ((!en) || (rp->part->type != EDJE_PART_TYPE_TEXTBLOCK) ||
> @@ -1520,13 +1520,17 @@
>  #ifdef HAVE_ECORE_IMF
> if (en->imf_context)
>   {
> +Evas_Event_Key_Up *ev = event_info;
>  Ecore_IMF_Event_Key_Up ecore_ev;
> +
>  ecore_imf_evas_event_key_up_wrap(ev, &ecore_ev);
>  if (ecore_imf_context_filter_event(en->imf_context,
> ECORE_IMF_EVENT_KEY_UP,
> (Ecore_IMF_Event
> *)&ecore_ev)) return;
>   }
> +#else
> +   (void) event_info;
>  #endif
>  }
>  
> @@ -2057,9 +2061,9 @@
>  ecore_imf_context_input_mode_set(en->imf_context,
>   rp->part->entry_mode ==
> EDJE_ENTRY_EDIT_MODE_PASSWORD ? ECORE_IMF_INPUT_MODE_INVISIBLE :
> ECORE_IMF_INPUT_MODE_FULL); 
> +done:
>  #endif
>   }
> -done:
> en->cursor = (Evas_Textblock_Cursor
> *)evas_object_textblock_cursor_get(rp->object); }
>  

Think you just broke it here.

edje_entry.c: In function ‘_edje_entry_real_part_init’:
edje_entry.c:2064: error: label at end of compound statement


-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Possible lua excess code?

[David Seikel]

On Sun, 20 Nov 2011 01:21:48 +1000 David Seikel 
wrote:

> I'm not sure what you where thinking, perhaps that the user
> could pass in a table to be filled in?  Seems odd.
> 
> There's a few of these, I'll just leave a FIXME comment for now, but
> I'll probably remove the check before the release.

On a related note, I'm not so sure about this business of reusing
tables that are passed in as parameters for the results to be
returned.  I don't think that sort of thing is used anywhere else in
lua, AND we are returning the result table anyway.

It's quite nice that things like colour and coords can be passed back
and forth as a table.  Even better is that excess stuff in these tables
is ignored if passed in as arguments.  Better still that they can be
passed in as separate values.

map:lighting() accepts one set of 3D coords, and two sets of colours.

map:rotate3d() accepts two sets of 3D coords.

map:zoom() accepts two sets of 2D coords.

The problem with these, if using the generic argument scanner I wrote,
based on the several specialized argument scanners you wrote, is that
it tries to reuse the table passed in to return results, but A) which
table?  B) it does a reset of the stack, that causes problems for the
next scanner call that tries to get the next set of arguments.

Well, OK, those three don't return any values, so A is moot.  And B is
moot for those three anyway, since the stack reset is bypassed.  I
still think it might be a problem for future API additions.

I still think it would be much cleaner to NOT reuse passed in tables,
and to not pass values back in optional passed in tables.  This solves
both problems mentioned in this thread, and makes things cleaner all
around.

So that would mean that we remove the bool that tells the argument
scanner to reuse or create a table, and have the generic "return
results in a table" function create it's own table.  And remove that
lua_istable check mentioned in the last email.

I'll double check if the example is using that sort of thing, then make
these changes and commit.  You can revert if you disagree.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] suid bit for enlightenment_sys

[Tomas Cech]

Hi,

On Sat, Nov 19, 2011 at 10:31:21PM -0200, Gustavo Sverzut Barbieri wrote:

On Sat, Nov 19, 2011 at 10:15 PM, Tomas Cech  wrote:

Hi,

as I'm trying to get E17 into openSUSE, I'm trying to tune
sysactions.conf. I'm trying to get rid of suid bit for
/usr/lib64/enlightenment/utils/enlightenment_sys

All my actions use DBUS messages so suid bit is useless (ok, I haven't
done mount/unmount yet). When I remove suid bit from this binary,
suspend fails and in log I have:

ERROR: UNABLE TO ASSUME ROOT PRIVILEGES

Running
/usr/lib64/enlightenment/utils/enlightenment_sys suspend
works fine, so my question is - is really needed check for root
privileges there?

Thanks.

Best regards,

Tomas Cech
Sleep_Walker

--
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.


yes we do. But there is a better way we could do, patches accepted (no
time to do it myself):
  - have hibernate/suspend/... using upower
  - have other actions using proper daemons using dbus + polkit
(udisks, timedated...)
  - whatever else use polkit's features such as pkexec.



That's probably what I want to have there:

action:   halt  dbus-send --system --dest=org.freedesktop.ConsoleKit 
/org/freedesktop/ConsoleKit/Manager org.freedesktop.ConsoleKit.Manager.Stop
action:   rebootdbus-send --system --dest=org.freedesktop.ConsoleKit 
/org/freedesktop/ConsoleKit/Manager org.freedesktop.ConsoleKit.Manager.Restart
action:   suspend   dbus-send --system --dest=org.freedesktop.UPower 
/org/freedesktop/UPower org.freedesktop.UPower.Suspend
action:   hibernate dbus-send --system --dest=org.freedesktop.UPower 
/org/freedesktop/UPower org.freedesktop.UPower.Hibernate

But you have probably in mind something smarter, right? Well this is
the reason I don't need root privileges, but it won't work without
passing that check.

It could make sense to at least have configuration option in
sysactions.conf not to require root privileges.
Something like:

option: need_root   false


Would you be able to help us with that?


I'm occupied by family (4 month old baby takes a lot of power and
time) and work (learning at new position). My time is very limited and
I'm afraid that even night builds take too much time already.

I know nothing about that and I have never done anything similar so it
would take a while. It doesn't make sense to start with this when
workaround is simple and makes sense - it's more like fix from my POV.
I should rather add more packages to nightly builds.


Best regards,

Tomas Cech
Sleep_Walker


pgpnb5ZH695aJ.pgp
Description: PGP signature
--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] E SVN: discomfitor trunk/ecore/src/lib/ecore_con

[Mike Blumenkrantz]

On Sat, 19 Nov 2011 23:11:05 -0800
"Enlightenment SVN"  wrote:

> Log:
> also move magic unset to after all events come back so we don't break
> anyone's event handlers 
> 
> Author:   discomfitor
> Date: 2011-11-19 23:11:05 -0800 (Sat, 19 Nov 2011)
> New Revision: 65426
> Trac: http://trac.enlightenment.org/e/changeset/65426
> 
> Modified:
>   trunk/ecore/src/lib/ecore_con/ecore_con.c 
> 
if anyone notices weird ecore-con behavior after updating, ping me IMMEDIATELY.

-- 
Mike Blumenkrantz
Zentific: Doctor recommended, mother approved.

--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel