http://permalink.gmane.org/gmane.comp.freedesktop.dbus hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.freedesktop.dbus/14731 <pre>BAVOUX Jean-Baptiste schreef op do 24-05-2012 om 12:27 [+0200]: pygtk is not maintained and not compatible with current Gnome. To build dbus-python you only need glib, dbus and pkg-config as far as I can see, and Python _______________________________________________ dbus mailing list dbus-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW&lt; at &gt;public.gmane.org http://lists.freedesktop.org/mailman/listinfo/dbus </pre> tjoen 2012-05-24T16:42:28 http://permalink.gmane.org/gmane.comp.freedesktop.dbus/14730 <pre>I need python-dbus on windows. So I started a cmake port over there: https://github.com/choeger/dbus-python-cmake Currently it does only build &amp; test on linux. I'll get to build &amp; test on windows now. Installing should be trivial. For testing on windows I first need to either get a bash or to port the testsuite to cmake/pure python. Dunno how long this will take. Please let me know, what you think and feel free to merge if you think my work is useful. </pre> Christoph Höger 2012-05-24T11:37:41 http://permalink.gmane.org/gmane.comp.freedesktop.dbus/14729 <pre> Hello I am trying to use dbus-python on Windows ( in order to port a linux python dbus application ) Can someone help me ? Is there a binary release ? Or do I need to recompile some code? ( I've installed pygtk, downloaded dbus-python-1.1.0, but I think I need to compile _dbus_bindings and _dbus_glib_bindings, how can I do that wuth mingw, ) Thanks JB _______________________________________________ dbus mailing list dbus-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW&lt; at &gt;public.gmane.org http://lists.freedesktop.org/mailman/listinfo/dbus </pre> BAVOUX Jean-Baptiste 2012-05-24T10:27:32 http://permalink.gmane.org/gmane.comp.freedesktop.dbus/14728 <pre> Recent Ubuntu versions use a patched version of D-Bus which interacts with Upstart. It seems that upstream versions of D-Bus will not work there: Upstart assumes that a patched version of D-Bus is in use. Either use the Ubuntu-provided binaries (you can get development headers with "apt-get install libdbus-1-dev"), or compile the Ubuntu version of dbus from source ("apt-get source dbus" and build it with dpkg-buildpackage or similar), or use a distribution which doesn't require special D-Bus patches (Debian, Fedora, Mandriva, Gentoo, etc.). In general there's not much point in compiling all the dependencies for something like VLC yourself - particularly true for core system libraries like dbus. The purpose of a distribution is to provide you with versions of various packages which are known to work well together. Use the distribution's packages where possible, and only compile newer versions yourself if the versions provided by the distribution are too old, the versions provided by the distribution have b</pre> Simon McVittie 2012-05-22T17:26:03 http://permalink.gmane.org/gmane.comp.freedesktop.dbus/14727 <pre>i am trying to compile vlc, everything from source, i need the dbus package, after i success install dbus-1.4.20, i reboot, the ubuntu crash, what shall i do please help_______________________________________________ dbus mailing list dbus-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW&lt; at &gt;public.gmane.org http://lists.freedesktop.org/mailman/listinfo/dbus </pre> Lee Wei han 2012-05-22T17:04:50 http://permalink.gmane.org/gmane.comp.freedesktop.dbus/14726 <pre>(Please ask the mailing list rather than asking individual contributors. If you ask me personally, only I can help you, and if I'm too busy, you won't get an answer; if you ask the mailing list, anyone on the list can help you.) On 22/05/12 11:38, Vinoth V wrote: That's possible. That's possible. I'd do this as an asynchronous method call sent by the "server" to the "client". This reverses their usual roles, but that's OK - all processes on D-Bus are treated the same. Telepathy and BlueZ both have situations where the process you'd normally think of as the "server" calls methods on the process you'd normally think of as the "client". It has to be an asynchronous method call (send request, go back to your main loop, get a callback called from your main loop later) because if two processes try to make synchronous method calls to each other, they'll typically deadlock while each waits for the other to reply. You should make asynchronous method calls anyway, though; see &lt;http://smcv.pseudorandom.co.uk/2008</pre> Simon McVittie 2012-05-22T10:56:11 http://permalink.gmane.org/gmane.comp.freedesktop.dbus/14725 <pre>I'm using edge-triggered watches because of boost::asio, which internally does cross platform edge-triggered io, using epoll in linux. Boost::asio is more like a proactor design than a reactor one. This is the kind of library where you just say "Read me 512 bytes" and when it's done it will call your handler with the 512 bytes in a buffer, ready to be used. You can also say "Read data until my custom predicate tells me there is a complete "message" available, then call my handler so i can parse it", with full threading support. It can also act as a regular Reactor, so i can still use it for D-Bus, but only with edge triggered semantics. I haven't looked, but this is maybe the kind of thing libdbus is already doing behind the scenes, with the handle_dispatch thing. I am already dispatching inside the busy read loop, mostly as a hack because of limitations of dbus-c++ bindings. But can't that be fixed by using threads to perform the reads, and concurrently dispatching them in the "main" thread ? The kind of t</pre> Nicolas Cavallari 2012-05-21T19:58:18 http://permalink.gmane.org/gmane.comp.freedesktop.dbus/14724 <pre> Short answer: don't multi-thread with those versions. For best results, do all your D-Bus interaction from your main thread (the one where main() was called). You can use asynchronous method calls with callbacks to avoid blocking your main thread. If you're using libdbus (dbus_* functions) in your multi-threaded application, libdbus 1.4.16 has known thread-safety bugs. They were fixed in 1.5.10, so in principle, what you're doing might work with that version. I am not aware of any thread-safety bugs in 1.5.10 or newer, but that doesn't mean there aren't any! If you're using GDBus (g_dbus_* or g_bus_* functions) in your multi-threaded application, the version of GDBus in GLib 2.30 also has known thread-safety bugs. They were fixed in 2.32. In general GDBus has a pretty good design for thread-safety, so if you must use D-Bus from multiple threads, it's a good choice. If you're using dbus-glib (dbus_g_* functions) in your multi-threaded application, don't. It isn't thread safe and never will be. It also has</pre> Simon McVittie 2012-05-21T17:27:39 http://permalink.gmane.org/gmane.comp.freedesktop.dbus/14723 <pre> Correct; it doesn't do that. Is there any particular reason why you want an edge-triggered watch? This... ... would essentially be equivalent to this, but inside libdbus. As far as I'm aware, the reason for the max_bytes_*_per_iteration variables is mainly to avoid main loop "starvation": if your process sees/produces sufficiently rapid D-Bus traffic that there is always something to read/write, then none of your other fds (including, perhaps, the one telling you to slow down or exit!) will ever be polled. Relatedly, it avoids arbitrary memory consumption under extremely heavy traffic: if you keep reading from a fd indefinitely, without ever pausing to do what libdbus calls "dispatching" (sending in-memory messages to their consumers), and there's always another message to read, then the messages will be queued in memory forever, and will never actually be dispatched to their consumers and (hopefully) freed. If you use edge-triggered watches with busy-reading like this, you're basically always going</pre> Simon McVittie 2012-05-21T17:18:56 http://permalink.gmane.org/gmane.comp.freedesktop.dbus/14722 <pre>Hi All, I am using dbus-1.4.16 (glib binding is done using the library glib-2.30 ) in a multi-threaded environment, like a server(different process) runs in one end, and a client(different process) in one end, but if i run a client, calling a same synchronous function for multiple times using threads, i am getting error like "Error in called_function name, msg="GDBus.Error:org.freedesktop.DBus.Error.NoReply: Message did not receive a reply (timeout by message bus)". (process:2064): GLib-CRITICAL **: g_variant_get_fixed_array: assertion `g_variant_is_of_type (value, G_VARIANT_TYPE_ARRAY)' failed but if i call this function only once, i am gettin my output properly. so i have a doubt like, whether dbus allows simultaneous execution of synchronise functions ? or it is only serial execution. kindly help me. Regards Vinoth _______________________________________________ dbus mailing list dbus-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW&lt; at &gt;public.gmane.org http://lists.freedesktop.org/mailman/listinfo/dbus </pre> Vinoth V 2012-05-21T15:01:57 http://permalink.gmane.org/gmane.comp.freedesktop.dbus/14721 <pre>Hi, I am trying to use D-Bus in a C++(11) application. I tried using dbus-c++, and integrated it with a external mainloop (boost::asio) which internally uses edge triggered epoll. But i found that some signal handlers are deferred, so watches are not always working. I am using the custom watch API from dbus-c++, which is essentially a thin wrapper around the DBusWatch API from libdbus. Looking at the code, libdbus does not seem to support edge triggered watches. Edge triggered support would essentially mean that libdbus must read()/write() from/to the fd until it returns EAGAIN. From what i see, the only limitation seems to come from the default value of the max_bytes_{read,written}_per_iteration variables. I think that setting them to an arbitrary high number should be enough to make libdbus work with edge triggered epoll. Am i correct ? And how could i change these variables ? The alternative would be to call the (wrapped) dbus_watch_handle() repeatedly until the fd is not readable/writable anymore, bu</pre> Nicolas Cavallari 2012-05-21T12:58:46 http://permalink.gmane.org/gmane.comp.freedesktop.dbus/14720 <pre> No, there is no one working on fixing that bug. It requires someone with interest in the result. Maybe that could be you. </pre> Thiago Macieira 2012-05-21T10:14:42 http://permalink.gmane.org/gmane.comp.freedesktop.dbus/14719 <pre>Thanks for your reply. By the way, is there a plan to fix this bug in future version ? Cheers Liang. _______________________________________________ dbus mailing list dbus-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW&lt; at &gt;public.gmane.org http://lists.freedesktop.org/mailman/listinfo/dbus </pre> 007900800083-m4dJw2ia6OdeoWH0uzbU5w< at >public.gmane.org 2012-05-21T08:39:53 http://permalink.gmane.org/gmane.comp.freedesktop.dbus/14718 <pre> It's a bug. </pre> Thiago Macieira 2012-05-21T07:15:13 http://permalink.gmane.org/gmane.comp.freedesktop.dbus/14717 <pre>Hi: I use dbus-monitor to monitor method call and reply message on system dbus. But I only get method call message, but can not any reply message. However i can get both types of messages on session dbus with dbus-monitor. I find someone has meet similiar issue in early version http://lists.freedesktop.org/archives/dbus/2009-April/011146.html. Could someone kindly tell me how to fix it or it is a bug in system dbus. Thanks a lot. I am using dbus-1.5.8, and system.conf is : &lt;policy context="default"&gt; &lt;!-- All users can connect to system bus --&gt; &lt;allow user="*"/&gt; &lt;!-- Holes must be punched in service configuration files for name ownership and sending method calls --&gt; &lt;deny own="*"/&gt; &lt;deny send_type="method_call"/&gt; &lt;!-- Signals and reply messages (method returns, errors) are allowed by default --&gt; &lt;allow send_type="signal"/&gt; &lt;allow send_requested_reply="true" send_type="method_return"/&gt; &lt;allow send_requested_reply="true" sen</pre> 007900800083-m4dJw2ia6OdeoWH0uzbU5w< at >public.gmane.org 2012-05-21T00:25:18 http://permalink.gmane.org/gmane.comp.freedesktop.dbus/14716 <pre>_______________________________________________ dbus mailing list dbus-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW&lt; at &gt;public.gmane.org http://lists.freedesktop.org/mailman/listinfo/dbus </pre> Martin Vidner 2012-05-17T11:25:13 http://permalink.gmane.org/gmane.comp.freedesktop.dbus/14715 <pre>_______________________________________________ dbus mailing list dbus-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW&lt; at &gt;public.gmane.org http://lists.freedesktop.org/mailman/listinfo/dbus </pre> Sruthi M 2012-05-17T07:15:27 http://permalink.gmane.org/gmane.comp.freedesktop.dbus/14714 <pre> First of all, please don't write HTML-only email. I'd recommend avoiding HTML completely, since the text portion of your email is what counts. Second, I'm sorry but there's no way to retrieve the information about which connections have demonstrated interest in a particular signal. If you really wish to get this information, you can modify the daemon so that you can retrieve the list of match rules and the connections they apply to. Then use the rules to determine which connections are interested in those signals. Note that rules like "type='signal'" will match for any and all signals. </pre> Thiago Macieira 2012-05-14T16:43:47 http://permalink.gmane.org/gmane.comp.freedesktop.dbus/14713 <pre>_______________________________________________ dbus mailing list dbus-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW&lt; at &gt;public.gmane.org http://lists.freedesktop.org/mailman/listinfo/dbus </pre> 007900800083-m4dJw2ia6OdeoWH0uzbU5w< at >public.gmane.org 2012-05-14T15:44:10 http://permalink.gmane.org/gmane.comp.freedesktop.dbus/14712 <pre> You don't read/write messages like that using dbus-java, that's just an internal class for reading the wire protocol. You interact with dbus on an object/method level. Read the documentation: http://dbus.freedesktop.org/doc/dbus-java/dbus-java/ Matt _______________________________________________ dbus mailing list dbus-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW&lt; at &gt;public.gmane.org http://lists.freedesktop.org/mailman/listinfo/dbus </pre> Matthew Johnson 2012-05-09T16:58:21 http://permalink.gmane.org/gmane.comp.freedesktop.dbus/14711 <pre>Hello guys, I am new to Dbus world. I would highly appreciate if someone would react to my email. I m using ubuntu 12.04 and making a program with Dbus java. I could connect successfully to the session bus but when i am trying to read or write i get strange errors. I should mention that i got all the jar files by installing directly from ubuntu so I didnt not build anything special. just apt-get install libdbus-java. the peace of code that i have is here. mDBusConn = DBusConnection.getConnection("tcp:host=xxx.xxx.xxx.xxx,port=123544"); InputStream in = new ByteArrayInputStream(data); MessageReader mReader = MessageReader(in); the error that i get during the compilation is *[javac] DbusChannel.java:39: cannot find symbol [javac] symbol : method MessageReader(java.io.InputStream) [javac] location: class com.tomtom.reflection2.dbus.DbusChannel [javac] MessageReader mReader = MessageReader(in); [javac] ^ [javac] 1 error* </pre> Lusy Hakobyan 2012-05-09T15:48:55 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.freedesktop.dbus