Patchwork [1/5] connman: Upgrade to version 0.75

Enable ofono plugin.
Adopt some logic in meta-oe on connman plugin runtime dependency.
Remove the fix-shutdown-ap-disconnect.patch since the original logic no longer exists.
Add Upstream-Status information for patches.

Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
---
 .../connman-0.65/fix-shutdown-ap-disconnect.patch  |   42 --------------------
 .../add_xuser_dbus_permission.patch                |    2 +
 .../connman/{connman-0.65 => connman-0.75}/connman |    0
 .../{connman-0.65 => connman-0.75}/dbusperms.patch |    2 +
 meta/recipes-connectivity/connman/connman.inc      |   16 ++++++-
 .../connman/{connman_0.65.bb => connman_0.75.bb}   |    8 ++--
 6 files changed, 21 insertions(+), 49 deletions(-)
 delete mode 100644 meta/recipes-connectivity/connman/connman-0.65/fix-shutdown-ap-disconnect.patch
 rename meta/recipes-connectivity/connman/{connman-0.65 => connman-0.75}/add_xuser_dbus_permission.patch (94%)
 rename meta/recipes-connectivity/connman/{connman-0.65 => connman-0.75}/connman (100%)
 rename meta/recipes-connectivity/connman/{connman-0.65 => connman-0.75}/dbusperms.patch (91%)
 rename meta/recipes-connectivity/connman/{connman_0.65.bb => connman_0.75.bb} (74%)

On Tue, 2011-06-21 at 16:08 +0800, Dongxiao Xu wrote:
> -DEPENDS  = "libgdbus dbus glib-2.0 hal iptables"
> -RDEPENDS_${PN} = "wpa-supplicant resolvconf"
> +DEPENDS  = "libgdbus dbus glib-2.0 hal iptables ofono wpa-supplicant resolvconf bluez4"

What does the dependency stack for ofono look like?  If it's non-trivial
then I am not sure it is a good idea to add ofono to DEPENDS
unconditionally.

Ditto bluez4, I don't think that should be in there unless
DISTRO_FEATURES requested it.

p.

Op 21 jun 2011, om 11:12 heeft Phil Blundell het volgende geschreven:

> On Tue, 2011-06-21 at 16:08 +0800, Dongxiao Xu wrote:
>> -DEPENDS  = "libgdbus dbus glib-2.0 hal iptables"
>> -RDEPENDS_${PN} = "wpa-supplicant resolvconf"
>> +DEPENDS  = "libgdbus dbus glib-2.0 hal iptables ofono wpa-supplicant resolvconf bluez4"
> 
> What does the dependency stack for ofono look like?  If it's non-trivial
> then I am not sure it is a good idea to add ofono to DEPENDS
> unconditionally.

dbus, glib-2.0 and udev, so that's not too bad. Only udev is "new", but connman already requires it since it dumped hal eons ago.

So the line should actually look like this:

>> DEPENDS  = "libgdbus dbus glib-2.0 udev iptables ofono wpa-supplicant resolvconf bluez4"

On Tue, Jun 21, 2011 at 11:12, Phil Blundell <pb@pbcl.net> wrote:
> On Tue, 2011-06-21 at 16:08 +0800, Dongxiao Xu wrote:
>> -DEPENDS  = "libgdbus dbus glib-2.0 hal iptables"
>> -RDEPENDS_${PN} = "wpa-supplicant resolvconf"
>> +DEPENDS  = "libgdbus dbus glib-2.0 hal iptables ofono wpa-supplicant resolvconf bluez4"
>
> What does the dependency stack for ofono look like?  If it's non-trivial
> then I am not sure it is a good idea to add ofono to DEPENDS
> unconditionally.

Although Koen showed that the dependcies were quite trivial, I'd
prefer to not build ofono if it is possible.

> Ditto bluez4, I don't think that should be in there unless
> DISTRO_FEATURES requested it.

Yes, I certainly agree with you on bluez4. If we don't have bluetooth
enabled for our machine/distro, I definitely prefere to not build it.

To me it's not only about the risk that we increase the rootfs, but
also about build-times. Even if we have quite fast machines today, it
is a waste of CPU cycles to build lots of SW that aren't going to be
used...

Adding a dependency etc is easily done in a bbappen-file, which makes
the reversed desire quite easy. I'm not sure if there is an easy way
of removing item from e.g. DEPENDS and EXTRA_OECONF etc.

Regards,
Anders

Op 21 jun 2011, om 11:34 heeft Anders Darander het volgende geschreven:

> On Tue, Jun 21, 2011 at 11:12, Phil Blundell <pb@pbcl.net> wrote:
>> On Tue, 2011-06-21 at 16:08 +0800, Dongxiao Xu wrote:
>>> -DEPENDS  = "libgdbus dbus glib-2.0 hal iptables"
>>> -RDEPENDS_${PN} = "wpa-supplicant resolvconf"
>>> +DEPENDS  = "libgdbus dbus glib-2.0 hal iptables ofono wpa-supplicant resolvconf bluez4"
>> 
>> What does the dependency stack for ofono look like?  If it's non-trivial
>> then I am not sure it is a good idea to add ofono to DEPENDS
>> unconditionally.
> 
> Although Koen showed that the dependcies were quite trivial, I'd
> prefer to not build ofono if it is possible.
> 
>> Ditto bluez4, I don't think that should be in there unless
>> DISTRO_FEATURES requested it.
> 
> Yes, I certainly agree with you on bluez4. If we don't have bluetooth
> enabled for our machine/distro, I definitely prefere to not build it.
> 
> To me it's not only about the risk that we increase the rootfs, but
> also about build-times. Even if we have quite fast machines today, it
> is a waste of CPU cycles to build lots of SW that aren't going to be
> used...
> 
> Adding a dependency etc is easily done in a bbappen-file, which makes
> the reversed desire quite easy. I'm not sure if there is an easy way
> of removing item from e.g. DEPENDS and EXTRA_OECONF etc.

I'd trade extra build time over not having to use bbappends anytime. Especially where upstream has proper plugin support like connman.

On Tue, Jun 21, 2011 at 11:54, Koen Kooi <koen@dominion.thruhere.net> wrote:
>
> Op 21 jun 2011, om 11:34 heeft Anders Darander het volgende geschreven:
>
>> On Tue, Jun 21, 2011 at 11:12, Phil Blundell <pb@pbcl.net> wrote:
>>> On Tue, 2011-06-21 at 16:08 +0800, Dongxiao Xu wrote:
>>>> -DEPENDS  = "libgdbus dbus glib-2.0 hal iptables"
>>>> -RDEPENDS_${PN} = "wpa-supplicant resolvconf"
>>>> +DEPENDS  = "libgdbus dbus glib-2.0 hal iptables ofono wpa-supplicant resolvconf bluez4"
>>>
>>> What does the dependency stack for ofono look like?  If it's non-trivial
>>> then I am not sure it is a good idea to add ofono to DEPENDS
>>> unconditionally.
>>
>> Although Koen showed that the dependcies were quite trivial, I'd
>> prefer to not build ofono if it is possible.
>>
>>> Ditto bluez4, I don't think that should be in there unless
>>> DISTRO_FEATURES requested it.
>>
>> Yes, I certainly agree with you on bluez4. If we don't have bluetooth
>> enabled for our machine/distro, I definitely prefere to not build it.
>>
>> To me it's not only about the risk that we increase the rootfs, but
>> also about build-times. Even if we have quite fast machines today, it
>> is a waste of CPU cycles to build lots of SW that aren't going to be
>> used...
>>
>> Adding a dependency etc is easily done in a bbappen-file, which makes
>> the reversed desire quite easy. I'm not sure if there is an easy way
>> of removing item from e.g. DEPENDS and EXTRA_OECONF etc.
>
> I'd trade extra build time over not having to use bbappends anytime. Especially where upstream has proper plugin support like connman.

In cases like connman (with proper plugin-support, and a good
packaging), yes, then it is only about build time. And sure, in some
cases I completely agree with you.

However, occasionally when building a really tiny image adding a small
package could result in a complete build of X and lots of other stuff.
In such cases it's not always that funny. (Sorry, it was a long time
ago on .dev that this happened, so I don't remember what package it
was). Apart from these kind of situations, it's normally not a big
problem, unless you're in a development stage where you need frequent
clean rebuilds...

(Another drawback, although it is really only on the first build, is
that building lots of unnecessary packages increases the risk of
build/fetch problems.)

Currently I can't access cgit.openembedded.org (probably the local
network), so I can't check it. But isn't e.g. bluetooth found
somewhere in either DISTRO_FEATURES or MACHINE_FEATURES? If so, bluez4
and configure options should probably be set conditionally.

/Anders