FS#6841 - wpa_supplicant is build without dbus support

Attached to Project: Arch Linux
Opened by Stephan Arts (psyBSD) - Sunday, 08 April 2007, 09:31 GMT
Last edited by Jan de Groot (JGC) - Friday, 14 November 2008, 22:45 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Thomas Bächler (brain0)
Architecture All
Severity Medium
Priority Normal
Reported Version 0.8 Voodoo
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


wpa-supplicant is build without dbus support, due to this it can not easilly be controlled by next-gen network config utilities like airconfig
This task depends upon

Closed by  Jan de Groot (JGC)
Friday, 14 November 2008, 22:45 GMT
Reason for closing:  Fixed
Additional comments about closing:  Fixed in testing for i686. x86_64 will follow shortly.
Comment by Tobias Powalowski (tpowa) - Monday, 09 April 2007, 08:56 GMT
dbus is not in base --> it was not build with dbus support
Comment by Stephan Arts (psyBSD) - Monday, 09 April 2007, 21:42 GMT
Would an additional package in extra, wpa_supplicant-dbus, which conflicts wpa_supplicant in base, be any solution?
Comment by James Rayner (iphitus) - Saturday, 14 April 2007, 14:47 GMT
extra package would be a bit silly, but i don't see any other option.
Comment by James Rayner (iphitus) - Saturday, 15 December 2007, 12:28 GMT
what packages actually use wpa_supplicant with dbus?

Feel free to create a package that provides=() and conflicts=() on the AUR.
Comment by Raphael Kimmig (raf kimmig) - Sunday, 13 January 2008, 00:42 GMT
from /usr/bin/netcfg:

# I don't know how we could determine if wpa_supplicant is ready
sleep 2
Comment by James Rayner (iphitus) - Sunday, 13 January 2008, 23:53 GMT
/usr/bin/netcfg is deprecated. See netcfg2.

We can't add it to the existing package, as it cant depend on dbus, and no packages have been shown to need wpa_supplicant-dbus, so there's no reason to add it to the repos.

Feel free to add to the AUR though. If it gets the votes, then it'll make its way up soon enough.
Comment by Björn Martensen (baze) - Friday, 14 March 2008, 10:35 GMT
  • Field changed: Percent Complete (100% → 0%)
NetworkManager 0.7 will completely depend on wpa_supplicant's dbus capabilities for all wireless acitivies, so this would be really useful, except you want to force everybody to drop networkmanager and use netcfg2 ;)

I built NM0.7 from svn and rebuilt wpa_supplicant with dbus for myself for now, but I couldn't get the permissions right so the system-service doesn't start unless you are root. An official built package is very much appreciated. (or maybe at least some hints how do get such dbus things done the arch way)

-> please provide dbus support for wpa_supplicant. ;)
Comment by Thomas Bächler (brain0) - Monday, 21 July 2008, 21:06 GMT
I thought dbus was a feature added in the 0.6 development branch, but apparently, the 0.5.10 release already contains dbus code. As we need it in core, we would also need dbus in core, which in turn depends on libx11 and so on. I leave the dbus part up to Jan.

Anyway, I am in favor of dbus support in wpa_supplicant, as this is obviously the future of managing wireless connections and dbus is always better than a custom control interface, like the one wpa_supplicant has.
Comment by James Rayner (iphitus) - Friday, 29 August 2008, 03:42 GMT
I'm going to be using this in an upcoming netcfg release, so I'll have a look at how I can deal with the libx11 dep.
Comment by Jan de Groot (JGC) - Friday, 29 August 2008, 08:24 GMT
There's no libx11 dependency on dbus actually. It's dbus-launch inside the dbus package that depends on it. I'll work on splitting dbus into two pieces this weekend: dbus-core and dbus. dbus-core only pulls in expat as extra dependency, dbus will contain the x11 stuff.
Comment by James Rayner (iphitus) - Friday, 29 August 2008, 10:42 GMT
wouldn't it be easier to just set libx11 as optdepends/makedepends -- you'll only end up using dbus launch if you are using X anyway.

Saves splitting another package...
Comment by Thomas Bächler (brain0) - Friday, 29 August 2008, 11:58 GMT
There are people who insist that not only the depends but also the makedepends to packages in core should be in core. I am not one of them though.
Comment by Roman Kyrylych (Romashka) - Friday, 29 August 2008, 18:57 GMT
+1 for what James and Thomas said,
no need to make things complex just because of makedependency that can safely live in extra (we have such packages already).
Comment by Thomas Bächler (brain0) - Tuesday, 14 October 2008, 09:38 GMT
Okay, now that this is done, I will push a new package soon.