Ship dbus config and dbus service activation files
RFC 1/1 Ship dbus config and dbus service activation files
Hello.
While playing to get connman 0.1 running I found that we don't ship two files in the wpa-supplicant that come in handy.
/etc/dbus-1/system.d/dbus-wpa_supplicant.conf
That one is really needed. Without it a wpa-supplicant -u barks out about wrong security.
/usr/share/dbus-1/system-services/dbus-wpa_supplicant.service
This one is a nice-to-have. It allows autostart the service with the service activation infrastructure from dbus. If a bus name listed in such a file is called and not available it gets started the way described in this file.
The following patch i nstalls the files correctly for me. Never used FILES_${PN} before so I would like to get some review before.
packages/wpa-supplicant/wpa-supplicant-0.6.inc +8 -1
@@ -59,7 +59,14 @@ do_install () { install -d ${D}${sysconfdir}/wpa_supplicant install -m 755 ${WORKDIR}/ifupdown.sh ${D}${sysconfdir}/wpa_supplicant/ install -m 755 ${WORKDIR}/functions.sh ${D}${sysconfdir}/wpa_supplicant - + + install -d ${D}/${sysconfdir}/dbus-1/system.d + install -m 644 ${S}/dbus-wpa_supplicant.conf ${D}/${sysconfdir}/dbus-1/system.d + install -d ${D}/${datadir}/dbus-1/system-services + install -m 644 ${S}/dbus-wpa_supplicant.service ${D}/${datadir}/dbus-1/system-services + ln -s /etc/wpa_supplicant/ifupdown.sh ${D}${sysconfdir}/network/if-pre-up.d/wpasupplicant ln -s /etc/wpa_supplicant/ifupdown.sh ${D}${sysconfdir}/network/if-post-down.d/wpasupplicant } + +FILES_${PN} += "${datadir}/dbus-1/system-services/*"
packages/wpa-supplicant/wpa-supplicant_0.6.0.bb +1 -1
@@ -1,3 +1,3 @@ require wpa-supplicant-0.6.inc -PR = "r1" +PR = "r2"
packages/wpa-supplicant/wpa-supplicant_0.6.3.bb +1 -1
@@ -1,3 +1,3 @@ require wpa-supplicant-0.6.inc -PR = "r1" +PR = "r2"
Anyone objections?
regards
Stefan Schmidt
Quoted 10 lines · Stefan Schmidt
Hello.
While playing to get connman 0.1 running I found that we don't ship two files in the wpa-supplicant that come in handy.
/etc/dbus-1/system.d/dbus-wpa_supplicant.confThat one is really needed. Without it a wpa-supplicant -u barks out about wrong security.
Quoted 9 lines
/usr/share/dbus-1/system-services/dbus-wpa_supplicant.serviceThis one is a nice-to-have. It allows autostart the service with the service activation infrastructure from dbus. If a bus name listed in such a file is called and not available it gets started the way described in this file.
The following patch i nstalls the files correctly for me. Never used FILES_${PN} before so I would like to get some review before.
Maybe its better to create a package wpasupplicant-dbus. IMO we should try to split packages if we can and the dbus functionallity is clearly separable from wpasupplicant core functions.
Regards,
Thomas
Hello.
Quoted 8 lines · Thomas Kunze
Quoted 3 lines · Stefan Schmidt
The following patch i nstalls the files correctly for me. Never used FILES_${PN} before so I would like to get some review before.
Maybe its better to create a package wpasupplicant-dbus. IMO we should try to split packages if we can and the dbus functionallity is clearly separable from wpasupplicant core functions.
I wouldn't mind. Where would you like to draw the line for such a split? Just the dbus specific files or a wpa-supplicant version without and one with dbus enabled?
If it is only about these two file it may not be worth the effort. I'm open about this though.
regards
Stefan Schmidt
Hello.
Quoted 7 lines · Stefan Schmidt
Quoted 5 lines · Thomas Kunze
Quoted 3 lines · Stefan Schmidt
The following patch i nstalls the files correctly for me. Never used FILES_${PN} before so I would like to get some review before.
Quoted 7 lines
Quoted 3 lines
Maybe its better to create a package wpasupplicant-dbus. IMO we should try to split packages if we can and the dbus functionallity is clearly separable from wpasupplicant core functions.
I wouldn't mind. Where would you like to draw the line for such a split? Just the dbus specific files or a wpa-supplicant version without and one with dbus enabled?
As we have sorted out the dbus depends on libX11 now it would be interesting if people still think that separate version for wpa-supplicant, one with dbus and one without, are still something to aim for?
The two files my patch adds are for sure not the problem here. I think nobody will scream if I commit them.
Personally I would not step to do sucha package split as I don't have a system that does not run dbus. (Which makes me abviously totally biased anyway. :) )
I'm fine on the other hand to test such a patch on the aspect if it still works the way for us as before.
regards
Stefan Schmidt
Am Thursday 11 December 2008 01:16:23 schrieb Thomas Kunze:
Quoted 2 lines
Quoted 2 lines
The following patch i nstalls the files correctly for me. Never used FILES_${PN} before so I would like to get some review before.
Looks good to me.
Quoted 4 lines
Maybe its better to create a package wpasupplicant-dbus. IMO we should try to split packages if we can and the dbus functionallity is clearly separable from wpasupplicant core functions.
Is it? How so? AFAIK there is no facility to have wpa_supplicant dlopen libdbus and only provide the dbus interface on demand.
We can compile it completely without dbus support in a seperate recipe, if that's what you want -- but given the increasing ubiquity of dbus, that doesn't make much sense.
Signature · 1 line
:M:
Quoted 3 lines · Michael 'Mickey' Lauer
We can compile it completely without dbus support in a seperate recipe, if that's what you want -- but given the increasing ubiquity of dbus, that doesn't make much sense.
Which raises a point -- there are still devices out there that don't want the X11 libraries (due to flash space limitations) -- perhaps it is _dbus_ that needs splitting into two separate recipes, one with X and one without?
I think this would mean that everything would change to depend on "virtual/dbus", right? -- and that would be a fairly disruptive change, hence my comments here to see if anyone has strong protests or better ideas.
Mike (mwester)
Am Thursday 11 December 2008 01:55:39 schrieb Mike (mwester):
Quoted 9 lines
Quoted 3 lines · Michael 'Mickey' Lauer
We can compile it completely without dbus support in a seperate recipe, if that's what you want -- but given the increasing ubiquity of dbus, that doesn't make much sense.
Which raises a point -- there are still devices out there that don't want the X11 libraries (due to flash space limitations) -- perhaps it is _dbus_ that needs splitting into two separate recipes, one with X and one without?
I'd rather write a patch that tries to dlopen libX11. dbus needs libX11 only for setting one property on the root window.
Signature · 1 line
:M:
Quoted 5 lines · Michael 'Mickey' Lauer
Am Thursday 11 December 2008 01:55:39 schrieb Mike (mwester):
Quoted 4 lines
Quoted 3 lines · Michael 'Mickey' Lauer
We can compile it completely without dbus support in a seperate recipe, if that's what you want -- but given the increasing ubiquity of dbus, that doesn't make much sense.
Quoted 7 lines
Quoted 4 lines
Which raises a point -- there are still devices out there that don't want the X11 libraries (due to flash space limitations) -- perhaps it is _dbus_ that needs splitting into two separate recipes, one with X and one without?
I'd rather write a patch that tries to dlopen libX11. dbus needs libX11 only for setting one property on the root window.
Well, as I said in another mail, dbus-1 and libdbus-1-3 don't require x11 *at all*, so no patch needs to be written. For people wanting the x11 integration they can install the 'dbus-x11' subpackage. Just like python-tk :)
regards,
Koen
Quoted 7 lines · Mike (mwester)
Quoted 3 lines · Michael 'Mickey' Lauer
We can compile it completely without dbus support in a seperate recipe, if that's what you want -- but given the increasing ubiquity of dbus, that doesn't make much sense.
Which raises a point -- there are still devices out there that don't want the X11 libraries (due to flash space limitations)
http://www.angstrom-distribution.org/repo/?pkgname=dbus-1
http://www.angstrom-distribution.org/repo/?pkgname=libdbus-1-3
Now where do you see it the _packages_ depending on libx11-6? Is dbus going to be the new python where everybody starts screaming about requiring X at runtime, when it's only a buildtime dep to build an *optional* subpackage like python-tk? Please stop with the FUD.
regards,
Koen
Quoted 9 lines · Koen Kooi rudely
On 11-12-08 01:55, Mike (mwester) wrote:
http://www.angstrom-distribution.org/repo/?pkgname=dbus-1
http://www.angstrom-distribution.org/repo/?pkgname=libdbus-1-3Now where do you see it the _packages_ depending on libx11-6? Is dbus going to be the new python where everybody starts screaming about requiring X at runtime, when it's only a buildtime dep to build an *optional* subpackage like python-tk? Please stop with the FUD.
dbus-1 recommends dbus-x11, dbus-x11 depends libx11-6 (and other X libs).
So there you go, opkg install <anything-depending-on-dbus> blows up your flash space by pulling in numerous X libs. No FUD - very real concern.
(But if it's not a concern for Angstrom, then fine -- please ignore
this issue; if I fix it, I'll make sure that it won't change for Angstrom.)
Regards
Mike (mwester)
Quoted 11 lines · Mike (mwester)
Quoted 9 lines · Koen Kooi rudely
On 11-12-08 01:55, Mike (mwester) wrote:
http://www.angstrom-distribution.org/repo/?pkgname=dbus-1
http://www.angstrom-distribution.org/repo/?pkgname=libdbus-1-3Now where do you see it the _packages_ depending on libx11-6? Is dbus going to be the new python where everybody starts screaming about requiring X at runtime, when it's only a buildtime dep to build an *optional* subpackage like python-tk? Please stop with the FUD.
Quoted 6 lines
dbus-1 recommends dbus-x11, dbus-x11 depends libx11-6 (and other X libs).
So there you go, opkg install<anything-depending-on-dbus> blows up your flash space by pulling in numerous X libs. No FUD - very real concern.
(But if it's not a concern for Angstrom, then fine -- please ignore
this issue; if I fix it, I'll make sure that it won't change for Angstrom.)
That rrecommends shouldn't be there specifically for the reasons you mentioned. I don't notice it since I looked up the old package name 'dbus-1' instead of the new one 'dbus', sorry about that.
regards,
Koen
Quoted 3 lines
Regards
Mike (mwester)
Quoted 11 lines · Mike (mwester)
Quoted 9 lines · Koen Kooi rudely
On 11-12-08 01:55, Mike (mwester) wrote:
http://www.angstrom-distribution.org/repo/?pkgname=dbus-1
http://www.angstrom-distribution.org/repo/?pkgname=libdbus-1-3Now where do you see it the _packages_ depending on libx11-6? Is dbus going to be the new python where everybody starts screaming about requiring X at runtime, when it's only a buildtime dep to build an *optional* subpackage like python-tk? Please stop with the FUD.
Quoted 6 lines
dbus-1 recommends dbus-x11, dbus-x11 depends libx11-6 (and other X libs).
So there you go, opkg install<anything-depending-on-dbus> blows up your flash space by pulling in numerous X libs. No FUD - very real concern.
(But if it's not a concern for Angstrom, then fine -- please ignore
this issue; if I fix it, I'll make sure that it won't change for Angstrom.)
Angstrom actually does the right things:
packagees/angstrom/angstrom-x11-base-depends.bb: dbus-x11 \
It will drag in dbus-x11 when people want an image with an xserver in it.
regards,
Koen
Guys..don't get so rude...
Back to the topic:
Quoted 4 lines
Anyone objections?
regards
Stefan Schmidt
Stefan, I think you have enough input to improve connman. This could become a very nice proggy!
Regards
Andrea
Hello.
Quoted 1 line · Andrea Adami
Guys..don't get so rude...
Hehe, that's ok. Getting used to rude email discussion over the years due to various FOSS projects. :)
Quoted 2 lines
Stefan, I think you have enough input to improve connman. This could become a very nice proggy!
I hope so. Will see what else needs fixing over the next weeks will getting it running on the phone.
regards
Stefan Schmidt
Quoted 21 lines · Thomas Kunze
Quoted 20 lines · Stefan Schmidt
Hello.
While playing to get connman 0.1 running I found that we don't ship two files in
the wpa-supplicant that come in handy.
/etc/dbus-1/system.d/dbus-wpa_supplicant.confThat one is really needed. Without it a wpa-supplicant -u barks out about wrong
security.
/usr/share/dbus-1/system-services/dbus-wpa_supplicant.serviceThis one is a nice-to-have. It allows autostart the service with the service
activation infrastructure from dbus. If a bus name listed in such a file is
called and not available it gets started the way described in this file.
Quoted 6 lines
Quoted 3 lines
The following patch i nstalls the files correctly for me. Never used FILES_${PN}
before so I would like to get some review before.Maybe its better to create a package wpasupplicant-dbus. IMO we should try to split packages if we can and the dbus
functionallity is clearly separable from wpasupplicant core functions.
If it gets split (I don't have a strong opinion on that), don't forget to add an RDEPEND_${PN}-dbus = "dbus-1" to make it drag in dbus.
regards,
Koen
Quoted 3 lines
Regards,
Thomas
About connman, last time I built it I noticed it depends on 'resolvconf' which depends on 'bash'.
Is it right?
TIA
Andrea
Quoted 4 lines · Andrea Adami
About connman, last time I built it I noticed it depends on 'resolvconf' which depends on 'bash'.
Is it right?
It's right in so far that resolvconf is full of bashims. It would make more sense to use openresolv (http://roy.marples.name/node/343) to avoid dragging in bash. More to the point, OE's bash doesn't use u-a *and* doesn't register itself with /etc/shells, so resolvconf is broken.
regards,
Koen
Quoted 5 lines
TIA
Andrea
Hello.
Quoted 4 lines · Andrea Adami
About connman, last time I built it I noticed it depends on 'resolvconf' which depends on 'bash'.
Is it right?
I don't remember if it was resolvconf or if it was dhclient, but one of it pulled in bash. This may indeed be worth trying out the alternative Koen pointed out.
This is low prio on my list until I get wpa-supplicant and therfor connman find my device at all and start doing something usefull with it.
regards
Stefan Schmidt
Quoted 12 lines · Stefan Schmidt
Hello.
Quoted 4 lines · Andrea Adami
About connman, last time I built it I noticed it depends on 'resolvconf' which depends on 'bash'.
Is it right?
I don't remember if it was resolvconf or if it was dhclient, but one of it pulled in bash. This may indeed be worth trying out the alternative Koen pointed out.
dhclient certainly used to use a script full of bashisms called when the IP address is discovered. I had fun patching that one for NetworkManager
Graeme
Hello.
Quoted 6 lines · Graeme Gregory
Quoted 5 lines · Stefan Schmidt
Quoted 3 lines · Andrea Adami
About connman, last time I built it I noticed it depends on 'resolvconf' which depends on 'bash'.
Quoted 8 lines
Quoted 6 lines
Quoted 1 line
Is it right?
I don't remember if it was resolvconf or if it was dhclient, but one of it pulled in bash. This may indeed be worth trying out the alternative Koen pointed out.
dhclient certainly used to use a script full of bashisms called when the IP address is discovered. I had fun patching that one for NetworkManager
Interesting. Your fixes are in OE.dev already?
I also got a pointer that maybe udhcp be worth looking into. Would need me to look into a plugin for it. Still this has to wait until I got the basic functions up and running.
regards
Stefan Schmidt
Quoted 15 lines · Stefan Schmidt
Hello.
Quoted 12 lines · Graeme Gregory
Quoted 11 lines · Stefan Schmidt
Quoted 4 lines · Andrea Adami
About connman, last time I built it I noticed it depends on 'resolvconf' which depends on 'bash'.
Is it right?
I don't remember if it was resolvconf or if it was dhclient, but one of it pulled in bash. This may indeed be worth trying out the alternative Koen pointed out.
Quoted 9 lines
Quoted 2 lines
dhclient certainly used to use a script full of bashisms called when the IP address is discovered. I had fun patching that one for NetworkManager
Interesting. Your fixes are in OE.dev already?
I also got a pointer that maybe udhcp be worth looking into. Would need me to look into a plugin for it. Still this has to wait until I got the basic functions up and running.
Yes, I used to use NetworkManager on my zaurus to manage the wifi!
Graeme