Re: NM dbus API bug ?
Thank you very much for your answer. It actually solved my issue. Jean Le mercredi 05 octobre 2011 à 13:53 -0500, Dan Williams a écrit : On Tue, 2011-10-04 at 17:07 +0200, Jean Parpaillon wrote: Hi again :) Your original crash is a dbus-glib bug, which likely was a regression in dbus-glib 0.94 and is fixed by: http://cgit.freedesktop.org/dbus/dbus-glib/commit/?id=3e0828f57c3925ea9b63d22ab82d991a0fea0536 ie it's been fixed in dbus-glib 0.96 and later. I'm quite confused on using NetworkManager DBUS API on master branch. 1/ When getting the object with the path returned by NetworkManager.GetDevices() method, NM crashes (path is of the form: /org/freedesktop/NetworkManager/Devices/0) That is the correct form of paths. Device names can change at runtime so they are not part of the object path as exposed over D-Bus. 2/ If I get the Device object with path like /org/freedesktop/NetworkManager/Devices/eth0, I can get the object but Introspectable interface gives me no interface at all on this object. Strange... Right, because that's not actually an object that NetworkManager exports over D-Bus, which is why you won't get any introspection information. It could be a bug in the Python dbus bindings that you get an object here at all, but the Python bits us lazy bindings so they'll only look up the introspection information when you need it, which can be later than when you create the Interface object. In the end, the bug is in dbus-glib 0.94 and fixed in 0.96. Dan It is WIP ? It is supposed to work right now ? I can try to fix it, if someone gives me some hints :) Regards, Jean Le mardi 04 octobre 2011 à 14:15 +0200, Jean Parpaillon a écrit : Hi all, I'm using NetworkManager from master branch. Running the following python code crash NetworkManager: ### import dbus import sys NM_DBUS_SERVICE = org.freedesktop.NetworkManager NM_MANAGER_PATH = /org/freedesktop/NetworkManager NM_MANAGER_IFACE = org.freedesktop.NetworkManager NM_DEVICE_IFACE = org.freedesktop.NetworkManager.Device bus = dbus.SystemBus() manager_proxy = bus.get_object(NM_DBUS_SERVICE, NM_MANAGER_PATH) manager_iface = dbus.Interface(manager_proxy, dbus_interface=NM_MANAGER_IFACE) for device_path in manager_iface.GetDevices(): print Device: %s % device_path device_proxy = bus.get_object(NM_DBUS_SERVICE, device_path) ### In a few words, it crashes when I try to get dbus proxy object with a path I get from GetDevices() method. The crashes produces the following backtrace: Oct 4 14:01:17 tiflis NetworkManager[26393]: warn caught signal 11. Generating backtrace... Oct 4 14:01:17 tiflis NetworkManager[26393]: *** START ** Oct 4 14:01:17 tiflis NetworkManager[26393]: Frame 0: /usr/sbin/NetworkManager (nm_logging_backtrace+0x3b) [0x45e3fb] Oct 4 14:01:17 tiflis NetworkManager[26393]: Frame 1: /usr/sbin/NetworkManager (0x40+0x4470c1) [0x4470c1] Oct 4 14:01:17 tiflis NetworkManager[26393]: Frame 2: /lib/x86_64-linux-gnu/libpthread.so.0 (0x7fbdf74d9000+0x7fbdf74e8020) [0x7fbdf74e8020] Oct 4 14:01:17 tiflis NetworkManager[26393]: Frame 3: /usr/lib/x86_64-linux-gnu/libdbus-glib-1.so.2 (0x7fbdf793a000 +0x7fbdf79469b0) [0x7fbdf79469b0] Oct 4 14:01:17 tiflis NetworkManager[26393]: Frame 4: /lib/libglib-2.0.so.0 (g_hash_table_foreach+0x43) [0x7fbdf6017bd3] Oct 4 14:01:17 tiflis NetworkManager[26393]: Frame 5: /usr/lib/x86_64-linux-gnu/libdbus-glib-1.so.2 (0x7fbdf793a000 +0x7fbdf794808c) [0x7fbdf794808c] Oct 4 14:01:17 tiflis NetworkManager[26393]: Frame 6: /lib/x86_64-linux-gnu/libdbus-1.so.3 (0x7fbdf76f5000+0x7fbdf7713371) [0x7fbdf7713371] Oct 4 14:01:17 tiflis NetworkManager[26393]: Frame 7: /lib/x86_64-linux-gnu/libdbus-1.so.3 (dbus_connection_dispatch+0x380) [0x7fbdf7705270] Oct 4 14:01:17 tiflis NetworkManager[26393]: Frame 8: /usr/lib/x86_64-linux-gnu/libdbus-glib-1.so.2 (0x7fbdf793a000 +0x7fbdf7945675) [0x7fbdf7945675] Oct 4 14:01:17 tiflis NetworkManager[26393]: Frame 9: /lib/libglib-2.0.so.0 (g_main_context_dispatch+0x1f3) [0x7fbdf60284a3] Oct 4 14:01:17 tiflis NetworkManager[26393]: Frame 10: /lib/libglib-2.0.so.0 (0x7fbdf5fe3000+0x7fbdf6028c80) [0x7fbdf6028c80] Oct 4 14:01:17 tiflis NetworkManager[26393]: Frame 11: /lib/libglib-2.0.so.0 (g_main_loop_run+0x182) [0x7fbdf60292f2] Oct 4 14:01:17 tiflis NetworkManager[26393]: Frame 12: /usr/sbin/NetworkManager (main+0x1155) [0x4220f5] Oct 4 14:01:17 tiflis NetworkManager[26393]: Frame 13: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xfd) [0x7fbdf57f7ead] Oct 4 14:01:17 tiflis NetworkManager[26393]: Frame 14: /usr/sbin/NetworkManager (0x40+0x42224d) [0x42224d] Oct 4 14:01:17 tiflis NetworkManager[26393]: *** END
Re: NM dbus API bug ?
On Tue, 2011-10-04 at 17:07 +0200, Jean Parpaillon wrote: Hi again :) Your original crash is a dbus-glib bug, which likely was a regression in dbus-glib 0.94 and is fixed by: http://cgit.freedesktop.org/dbus/dbus-glib/commit/?id=3e0828f57c3925ea9b63d22ab82d991a0fea0536 ie it's been fixed in dbus-glib 0.96 and later. I'm quite confused on using NetworkManager DBUS API on master branch. 1/ When getting the object with the path returned by NetworkManager.GetDevices() method, NM crashes (path is of the form: /org/freedesktop/NetworkManager/Devices/0) That is the correct form of paths. Device names can change at runtime so they are not part of the object path as exposed over D-Bus. 2/ If I get the Device object with path like /org/freedesktop/NetworkManager/Devices/eth0, I can get the object but Introspectable interface gives me no interface at all on this object. Strange... Right, because that's not actually an object that NetworkManager exports over D-Bus, which is why you won't get any introspection information. It could be a bug in the Python dbus bindings that you get an object here at all, but the Python bits us lazy bindings so they'll only look up the introspection information when you need it, which can be later than when you create the Interface object. In the end, the bug is in dbus-glib 0.94 and fixed in 0.96. Dan It is WIP ? It is supposed to work right now ? I can try to fix it, if someone gives me some hints :) Regards, Jean Le mardi 04 octobre 2011 à 14:15 +0200, Jean Parpaillon a écrit : Hi all, I'm using NetworkManager from master branch. Running the following python code crash NetworkManager: ### import dbus import sys NM_DBUS_SERVICE = org.freedesktop.NetworkManager NM_MANAGER_PATH = /org/freedesktop/NetworkManager NM_MANAGER_IFACE = org.freedesktop.NetworkManager NM_DEVICE_IFACE = org.freedesktop.NetworkManager.Device bus = dbus.SystemBus() manager_proxy = bus.get_object(NM_DBUS_SERVICE, NM_MANAGER_PATH) manager_iface = dbus.Interface(manager_proxy, dbus_interface=NM_MANAGER_IFACE) for device_path in manager_iface.GetDevices(): print Device: %s % device_path device_proxy = bus.get_object(NM_DBUS_SERVICE, device_path) ### In a few words, it crashes when I try to get dbus proxy object with a path I get from GetDevices() method. The crashes produces the following backtrace: Oct 4 14:01:17 tiflis NetworkManager[26393]: warn caught signal 11. Generating backtrace... Oct 4 14:01:17 tiflis NetworkManager[26393]: *** START ** Oct 4 14:01:17 tiflis NetworkManager[26393]: Frame 0: /usr/sbin/NetworkManager (nm_logging_backtrace+0x3b) [0x45e3fb] Oct 4 14:01:17 tiflis NetworkManager[26393]: Frame 1: /usr/sbin/NetworkManager (0x40+0x4470c1) [0x4470c1] Oct 4 14:01:17 tiflis NetworkManager[26393]: Frame 2: /lib/x86_64-linux-gnu/libpthread.so.0 (0x7fbdf74d9000+0x7fbdf74e8020) [0x7fbdf74e8020] Oct 4 14:01:17 tiflis NetworkManager[26393]: Frame 3: /usr/lib/x86_64-linux-gnu/libdbus-glib-1.so.2 (0x7fbdf793a000 +0x7fbdf79469b0) [0x7fbdf79469b0] Oct 4 14:01:17 tiflis NetworkManager[26393]: Frame 4: /lib/libglib-2.0.so.0 (g_hash_table_foreach+0x43) [0x7fbdf6017bd3] Oct 4 14:01:17 tiflis NetworkManager[26393]: Frame 5: /usr/lib/x86_64-linux-gnu/libdbus-glib-1.so.2 (0x7fbdf793a000 +0x7fbdf794808c) [0x7fbdf794808c] Oct 4 14:01:17 tiflis NetworkManager[26393]: Frame 6: /lib/x86_64-linux-gnu/libdbus-1.so.3 (0x7fbdf76f5000+0x7fbdf7713371) [0x7fbdf7713371] Oct 4 14:01:17 tiflis NetworkManager[26393]: Frame 7: /lib/x86_64-linux-gnu/libdbus-1.so.3 (dbus_connection_dispatch+0x380) [0x7fbdf7705270] Oct 4 14:01:17 tiflis NetworkManager[26393]: Frame 8: /usr/lib/x86_64-linux-gnu/libdbus-glib-1.so.2 (0x7fbdf793a000 +0x7fbdf7945675) [0x7fbdf7945675] Oct 4 14:01:17 tiflis NetworkManager[26393]: Frame 9: /lib/libglib-2.0.so.0 (g_main_context_dispatch+0x1f3) [0x7fbdf60284a3] Oct 4 14:01:17 tiflis NetworkManager[26393]: Frame 10: /lib/libglib-2.0.so.0 (0x7fbdf5fe3000+0x7fbdf6028c80) [0x7fbdf6028c80] Oct 4 14:01:17 tiflis NetworkManager[26393]: Frame 11: /lib/libglib-2.0.so.0 (g_main_loop_run+0x182) [0x7fbdf60292f2] Oct 4 14:01:17 tiflis NetworkManager[26393]: Frame 12: /usr/sbin/NetworkManager (main+0x1155) [0x4220f5] Oct 4 14:01:17 tiflis NetworkManager[26393]: Frame 13: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xfd) [0x7fbdf57f7ead] Oct 4 14:01:17 tiflis NetworkManager[26393]: Frame 14: /usr/sbin/NetworkManager (0x40+0x42224d) [0x42224d] Oct 4 14:01:17 tiflis NetworkManager[26393]: *** END ** Any clue ? ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
NM dbus API bug ?
Hi all, I'm using NetworkManager from master branch. Running the following python code crash NetworkManager: ### import dbus import sys NM_DBUS_SERVICE = org.freedesktop.NetworkManager NM_MANAGER_PATH = /org/freedesktop/NetworkManager NM_MANAGER_IFACE = org.freedesktop.NetworkManager NM_DEVICE_IFACE = org.freedesktop.NetworkManager.Device bus = dbus.SystemBus() manager_proxy = bus.get_object(NM_DBUS_SERVICE, NM_MANAGER_PATH) manager_iface = dbus.Interface(manager_proxy, dbus_interface=NM_MANAGER_IFACE) for device_path in manager_iface.GetDevices(): print Device: %s % device_path device_proxy = bus.get_object(NM_DBUS_SERVICE, device_path) ### In a few words, it crashes when I try to get dbus proxy object with a path I get from GetDevices() method. The crashes produces the following backtrace: Oct 4 14:01:17 tiflis NetworkManager[26393]: warn caught signal 11. Generating backtrace... Oct 4 14:01:17 tiflis NetworkManager[26393]: *** START ** Oct 4 14:01:17 tiflis NetworkManager[26393]: Frame 0: /usr/sbin/NetworkManager (nm_logging_backtrace+0x3b) [0x45e3fb] Oct 4 14:01:17 tiflis NetworkManager[26393]: Frame 1: /usr/sbin/NetworkManager (0x40+0x4470c1) [0x4470c1] Oct 4 14:01:17 tiflis NetworkManager[26393]: Frame 2: /lib/x86_64-linux-gnu/libpthread.so.0 (0x7fbdf74d9000+0x7fbdf74e8020) [0x7fbdf74e8020] Oct 4 14:01:17 tiflis NetworkManager[26393]: Frame 3: /usr/lib/x86_64-linux-gnu/libdbus-glib-1.so.2 (0x7fbdf793a000 +0x7fbdf79469b0) [0x7fbdf79469b0] Oct 4 14:01:17 tiflis NetworkManager[26393]: Frame 4: /lib/libglib-2.0.so.0 (g_hash_table_foreach+0x43) [0x7fbdf6017bd3] Oct 4 14:01:17 tiflis NetworkManager[26393]: Frame 5: /usr/lib/x86_64-linux-gnu/libdbus-glib-1.so.2 (0x7fbdf793a000 +0x7fbdf794808c) [0x7fbdf794808c] Oct 4 14:01:17 tiflis NetworkManager[26393]: Frame 6: /lib/x86_64-linux-gnu/libdbus-1.so.3 (0x7fbdf76f5000+0x7fbdf7713371) [0x7fbdf7713371] Oct 4 14:01:17 tiflis NetworkManager[26393]: Frame 7: /lib/x86_64-linux-gnu/libdbus-1.so.3 (dbus_connection_dispatch+0x380) [0x7fbdf7705270] Oct 4 14:01:17 tiflis NetworkManager[26393]: Frame 8: /usr/lib/x86_64-linux-gnu/libdbus-glib-1.so.2 (0x7fbdf793a000 +0x7fbdf7945675) [0x7fbdf7945675] Oct 4 14:01:17 tiflis NetworkManager[26393]: Frame 9: /lib/libglib-2.0.so.0 (g_main_context_dispatch+0x1f3) [0x7fbdf60284a3] Oct 4 14:01:17 tiflis NetworkManager[26393]: Frame 10: /lib/libglib-2.0.so.0 (0x7fbdf5fe3000+0x7fbdf6028c80) [0x7fbdf6028c80] Oct 4 14:01:17 tiflis NetworkManager[26393]: Frame 11: /lib/libglib-2.0.so.0 (g_main_loop_run+0x182) [0x7fbdf60292f2] Oct 4 14:01:17 tiflis NetworkManager[26393]: Frame 12: /usr/sbin/NetworkManager (main+0x1155) [0x4220f5] Oct 4 14:01:17 tiflis NetworkManager[26393]: Frame 13: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xfd) [0x7fbdf57f7ead] Oct 4 14:01:17 tiflis NetworkManager[26393]: Frame 14: /usr/sbin/NetworkManager (0x40+0x42224d) [0x42224d] Oct 4 14:01:17 tiflis NetworkManager[26393]: *** END ** Any clue ? -- Jean Parpaillon RD Engineer http://mandriva.com +33 6 30 10 92 86 xmpp: jean.parpail...@gmail.com signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM dbus API bug ?
Hi again :) I'm quite confused on using NetworkManager DBUS API on master branch. 1/ When getting the object with the path returned by NetworkManager.GetDevices() method, NM crashes (path is of the form: /org/freedesktop/NetworkManager/Devices/0) 2/ If I get the Device object with path like /org/freedesktop/NetworkManager/Devices/eth0, I can get the object but Introspectable interface gives me no interface at all on this object. Strange... It is WIP ? It is supposed to work right now ? I can try to fix it, if someone gives me some hints :) Regards, Jean Le mardi 04 octobre 2011 à 14:15 +0200, Jean Parpaillon a écrit : Hi all, I'm using NetworkManager from master branch. Running the following python code crash NetworkManager: ### import dbus import sys NM_DBUS_SERVICE = org.freedesktop.NetworkManager NM_MANAGER_PATH = /org/freedesktop/NetworkManager NM_MANAGER_IFACE = org.freedesktop.NetworkManager NM_DEVICE_IFACE = org.freedesktop.NetworkManager.Device bus = dbus.SystemBus() manager_proxy = bus.get_object(NM_DBUS_SERVICE, NM_MANAGER_PATH) manager_iface = dbus.Interface(manager_proxy, dbus_interface=NM_MANAGER_IFACE) for device_path in manager_iface.GetDevices(): print Device: %s % device_path device_proxy = bus.get_object(NM_DBUS_SERVICE, device_path) ### In a few words, it crashes when I try to get dbus proxy object with a path I get from GetDevices() method. The crashes produces the following backtrace: Oct 4 14:01:17 tiflis NetworkManager[26393]: warn caught signal 11. Generating backtrace... Oct 4 14:01:17 tiflis NetworkManager[26393]: *** START ** Oct 4 14:01:17 tiflis NetworkManager[26393]: Frame 0: /usr/sbin/NetworkManager (nm_logging_backtrace+0x3b) [0x45e3fb] Oct 4 14:01:17 tiflis NetworkManager[26393]: Frame 1: /usr/sbin/NetworkManager (0x40+0x4470c1) [0x4470c1] Oct 4 14:01:17 tiflis NetworkManager[26393]: Frame 2: /lib/x86_64-linux-gnu/libpthread.so.0 (0x7fbdf74d9000+0x7fbdf74e8020) [0x7fbdf74e8020] Oct 4 14:01:17 tiflis NetworkManager[26393]: Frame 3: /usr/lib/x86_64-linux-gnu/libdbus-glib-1.so.2 (0x7fbdf793a000 +0x7fbdf79469b0) [0x7fbdf79469b0] Oct 4 14:01:17 tiflis NetworkManager[26393]: Frame 4: /lib/libglib-2.0.so.0 (g_hash_table_foreach+0x43) [0x7fbdf6017bd3] Oct 4 14:01:17 tiflis NetworkManager[26393]: Frame 5: /usr/lib/x86_64-linux-gnu/libdbus-glib-1.so.2 (0x7fbdf793a000 +0x7fbdf794808c) [0x7fbdf794808c] Oct 4 14:01:17 tiflis NetworkManager[26393]: Frame 6: /lib/x86_64-linux-gnu/libdbus-1.so.3 (0x7fbdf76f5000+0x7fbdf7713371) [0x7fbdf7713371] Oct 4 14:01:17 tiflis NetworkManager[26393]: Frame 7: /lib/x86_64-linux-gnu/libdbus-1.so.3 (dbus_connection_dispatch+0x380) [0x7fbdf7705270] Oct 4 14:01:17 tiflis NetworkManager[26393]: Frame 8: /usr/lib/x86_64-linux-gnu/libdbus-glib-1.so.2 (0x7fbdf793a000 +0x7fbdf7945675) [0x7fbdf7945675] Oct 4 14:01:17 tiflis NetworkManager[26393]: Frame 9: /lib/libglib-2.0.so.0 (g_main_context_dispatch+0x1f3) [0x7fbdf60284a3] Oct 4 14:01:17 tiflis NetworkManager[26393]: Frame 10: /lib/libglib-2.0.so.0 (0x7fbdf5fe3000+0x7fbdf6028c80) [0x7fbdf6028c80] Oct 4 14:01:17 tiflis NetworkManager[26393]: Frame 11: /lib/libglib-2.0.so.0 (g_main_loop_run+0x182) [0x7fbdf60292f2] Oct 4 14:01:17 tiflis NetworkManager[26393]: Frame 12: /usr/sbin/NetworkManager (main+0x1155) [0x4220f5] Oct 4 14:01:17 tiflis NetworkManager[26393]: Frame 13: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xfd) [0x7fbdf57f7ead] Oct 4 14:01:17 tiflis NetworkManager[26393]: Frame 14: /usr/sbin/NetworkManager (0x40+0x42224d) [0x42224d] Oct 4 14:01:17 tiflis NetworkManager[26393]: *** END ** Any clue ? ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list -- Jean Parpaillon RD Engineer http://mandriva.com +33 6 30 10 92 86 xmpp: jean.parpail...@gmail.com signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Help with NM DBus API
Hi, I'm looking for some insight into how to use the NM DBus API. (I've poked around a bit in the libnm-util and network-manager-applet sources but my small brain is none the wiser.) I have a single *system* connection (no user connections) and I want to change the settings of this system connection. Just looking at the interfaces, it seems I need to call NetworkManagerSettings.ListConnections() on the NetworkManagerSystemSettings service (this is NM 0.7/0.8) to get the path of the connection object; and then call NetworkManagerSettings.Connection.Update( ... ) on this object, with the new settings. If this method call returns successfully (i.e. no error, as it has no out arguments), what does it mean -- that the connection is now active, or merely that the settings have been applied (potentially disconnecting the connection)? Which signals should I register for, to know when the new settings have successfully taken effect? My experiments sending some messages with D-Feet indicate that calling Update() on the System Connection isn't allowed (Read-only connections may not be modified) -- or is this merely a configuration issue around DBus permissions? Finally, any tips on tools for sending DBus messages? dbus-send doesn't support nested containers (which are required by Connection.Update()) and I haven't had much luck sending nested container parameters with D-Feet either. Perhaps bindings to a language like Python will be the way to go for quick exploration. Many thanks, David Röthlisberger ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
RE: Help with NM DBus API
Just looking at the interfaces, it seems I need to call NetworkManagerSettings.ListConnections() on the NetworkManagerSystemSettings service (this is NM 0.7/0.8) to get the path of the connection object; and then call NetworkManagerSettings.Connection.Update( ... ) on this object, with the new settings. If this method call returns successfully (i.e. no error, as it has no out arguments), what does it mean -- that the connection is now active, or merely that the settings have been applied (potentially disconnecting the connection)? This will just update your new settings for that connection. It won't make the connection active. Which signals should I register for, to know when the new settings have successfully taken effect? org.freedesktop.NetworkManagerSettings.Connection.Updated My experiments sending some messages with D-Feet indicate that calling Update() on the System Connection isn't allowed (Read-only connections may not be modified) -- or is this merely a configuration issue around DBus permissions? You should have root permissions to modify the Network Manager System Settings. Perhaps bindings to a language like Python will be the way to go for quick exploration. Yes, this would be a better option. See the samples. http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/examples/python ::DISCLAIMER:: --- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. --- ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
NM DBus API
Hi! Where can I find the docs for the NM DBus API? ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM DBus API
On Thu, Jan 1, 2009 at 00:24, Gabriel Joel Perez gabrielj...@gmail.com wrote: Hi! Where can I find the docs for the NM DBus API? Download NetworkManager sources, run configure with '--with-docs' flag and then run make. That'll create the DBus API documentation file docs/spec.html. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] NM DBUS api documentation build system
On Thursday 28 February 2008 03:09:27 Dan Williams wrote: Committed with a few cleanups, thanks! Nice! I've got some documentation for the various Settings keys and types here in my git - documentation progress hasn't stopped, but I need to make some progress here on my KDE 4 client before tidying it up for you. Will -- Will Stephenson IRC: Bille ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] NM DBUS api documentation build system
On Mon, 2008-02-11 at 23:07 +0100, Will Stephenson wrote: On Monday 11 February 2008 17:27:53 Dan Williams wrote: On Mon, 2008-02-11 at 17:26 +0100, Will Stephenson wrote: On Friday 08 February 2008, Dan Williams said: So a simple patch to dbus-binding-tool to make it ignore namespaced nodes and attributes will allow us to use the TP namespace within the existing introspection XML files and avoid the extra step of spec/*. Ack, maybe it does so already - but is the extra spec/* step really worse than having all of downstream have to use a patched dbus-binding-tool? The patch for dbus-glib is the right thing to do anyway; and I don't think there's a really good reason to have the extra step either. If the fix does get into dbus-glib, we'd just have to rework the spec generation code again, so we might as well do it right the first time IMHO. I'm still not quite sure it's good to pass around extended introspection xml. Are you able to you check the python bindings' behaviour? I'll see what the Qt tools do. If you're still willing to work on this, I'd love a patch that would run the XSLT stuff over the introspection/*.xml (feel free to add all.xml to introspection/* if you like) and generate the HTML docs. I don't think it would be to much work to modify the makefile stuff to rip out the bits that convert spec/* - introspection/* and just preserve the bits that do introspection/* - HTML, right? It's trivial - will post a patch shortly. Patch attached. Committed with a few cleanups, thanks! Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] NM DBUS api documentation build system
On Mon, 2008-02-11 at 23:07 +0100, Will Stephenson wrote: On Monday 11 February 2008 17:27:53 Dan Williams wrote: On Mon, 2008-02-11 at 17:26 +0100, Will Stephenson wrote: On Friday 08 February 2008, Dan Williams said: So a simple patch to dbus-binding-tool to make it ignore namespaced nodes and attributes will allow us to use the TP namespace within the existing introspection XML files and avoid the extra step of spec/*. Ack, maybe it does so already - but is the extra spec/* step really worse than having all of downstream have to use a patched dbus-binding-tool? The patch for dbus-glib is the right thing to do anyway; and I don't think there's a really good reason to have the extra step either. If the fix does get into dbus-glib, we'd just have to rework the spec generation code again, so we might as well do it right the first time IMHO. I'm still not quite sure it's good to pass around extended introspection xml. Are you able to you check the python bindings' behaviour? I'll see what the Qt tools do. Well, remember that dbus-glib _doesn't_ take the *.xml verbatim and pass it through the bus. The *.xml files are processed into a custom syntax and stuffed into the C code. You don't really need the property types for example, because the glib code is able to introspect the property types directly from the GObject itself. So I'm not sure why other bindings are relevant here, because none of the namespaced stuff should ever go over the bus at all. If you're still willing to work on this, I'd love a patch that would run the XSLT stuff over the introspection/*.xml (feel free to add all.xml to introspection/* if you like) and generate the HTML docs. I don't think it would be to much work to modify the makefile stuff to rip out the bits that convert spec/* - introspection/* and just preserve the bits that do introspection/* - HTML, right? It's trivial - will post a patch shortly. Patch attached. Will review, thanks! Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] NM DBUS api documentation build system
On Mon, 2008-02-11 at 17:26 +0100, Will Stephenson wrote: On Friday 08 February 2008, Dan Williams said: So a simple patch to dbus-binding-tool to make it ignore namespaced nodes and attributes will allow us to use the TP namespace within the existing introspection XML files and avoid the extra step of spec/*. Ack, maybe it does so already - but is the extra spec/* step really worse than having all of downstream have to use a patched dbus-binding-tool? The patch for dbus-glib is the right thing to do anyway; and I don't think there's a really good reason to have the extra step either. If the fix does get into dbus-glib, we'd just have to rework the spec generation code again, so we might as well do it right the first time IMHO. If you're still willing to work on this, I'd love a patch that would run the XSLT stuff over the introspection/*.xml (feel free to add all.xml to introspection/* if you like) and generate the HTML docs. I don't think it would be to much work to modify the makefile stuff to rip out the bits that convert spec/* - introspection/* and just preserve the bits that do introspection/* - HTML, right? It's trivial - will post a patch shortly. Great! Thanks! You're welcome. And this time, I trained my spam filter on your mail ;). It is nice to have a unified overview of the API. Thanks again. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] NM DBUS api documentation build system
On Tuesday 05 February 2008 22:27:28 Dan Williams wrote: We definitely need the docs, the only question is how exactly to go about getting them. Sorry, I just found your replies now in my spam trap after Marcel's response indicated you'd replied... I'm working on reading the code and adding documentation to it as I go now. It's taking a while but I hope to have a patch in the next couple of days. Will -- Will Stephenson IRC: Bille ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] NM DBUS api documentation build system
On Wednesday 06 February 2008 15:56:32 Dan Williams wrote: On Wed, 2008-02-06 at 09:20 +0100, Will Stephenson wrote: On Tuesday 05 February 2008 20:55:33 Marcel Holtmann wrote: Hi Will, I must agree here. Something that generate the introspection is not helpful at all. It is hard enough to keep external introspection XML files in sync with the actual runtime introspection. Surely the glib binding generators create the runtime introspection from the xml files? That's the way the Qt bindings work. no they don't. In the dbus-glib case you have the a pre-processing step that uses the XML file to generate glue code. You attach this to a GObject and then the bindings generate the runtime introspection from the runtime information of the object. You could do it without the XML file if you really want to. As far as I can tell looking at dbus-glib, the xml returned by Introspect() is generated at runtime from object info statically generated in the glue code from the introspection xml files. Therefore the introspection xml files are the original source of the interfaces offered by the objects, therefore these are the places where documentation is most effective. I'm trying to document the actual implementation of NM 0.7. I'm aware that it's possible to do all this by hand or write a program that doesn't actually implement the interface it advertises but those are just hypothetical counter-examples. Yeah; the docs, the introspection data, and the generated bindings all need to come from the same place, and that all needs to be done automatically. I don't want to manually update 3 places. Where do the current introspection/*.xml files go in your scheme? The diff removes them but doesn't apparently add anything back that would describe the interfaces. The files in introspection/*.xml move to spec/ Will -- Will Stephenson IRC: Bille ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] NM DBUS api documentation build system
On Friday 08 February 2008 17:52:22 Dan Williams wrote: On Tue, 2008-02-05 at 15:46 +0100, Will Stephenson wrote: Here's a patch that adds api documentation generation to the NM build system. The code is taken from the Telepathy project. I think as others have expressed, I think that process adds an extra, unnecessary step. I think I'd rather see the following: 1) annotate the introspection/*.xml files using the many-times-proposed org.freedesktop.DBus.Doc annotation name which was designed just for this. You'd end up with stuff looking like this: interface name=org.freedesktop.NetworkManager.Device method name=Deactivate annotation name=org.freedesktop.DBus.GLib.CSymbol value=impl_device_deactivate/ annotation name=org.freedesktop.DBus.Doc Deactivates the device, removing applicable routes, IP addresses, and marking the device down. /annotation /method property name=Udi type=s access=read annotation name=org.freedesktop.DBus.Doc The HAL Unique Device Identifier for this device. /annotation /property ... /interface Google knows exactly one hit for org.freedesktop.DBus.Doc, that doesn't say much. Where is this documented? From this example it seems to be less descriptive than Telepathy's format, but I'll reserve judgement until I've had a look at it. If you've got an archive of the dbus list, look for the thread documentation and introspection from Nov 2006 where Simon McVittie compares the tp doc format and another namespaced doc proposal. 2) Assuming dbus-glib's binding tool ignores annotations it doesn't recognize (and if it doesn't, we fix it to do so), the binding tool will just continue as normal creating the glue and bindings file. It should ignore namespaces it doesn't recognise too, making tp: namespaced introspection xml safe even without the (IMO trivial) extra xslt step that removes them. 3) The optional document generation step (enabled at configure-time with --enable-docs or something) can run xslt or something on the introspection XML and generate the HTML documentation. Right, this is how the tp system works too. There are some bits of the code that could stand extra documentation that aren't part of the D-Bus API directly, like the NMSettings subclasses. They are of course D-Bus dictionaries, and the key/value pairs and types are firmly defined. While that spec doesn't live in SVN, it really should live there, and it really should be pulled into the autogenerated docs for consistency. tp uses similar settings dictionaries, and defines their key ranges in these types' docstrings. Have a look at http://telepathy.freedesktop.org/spec.html for its output. Will -- Will Stephenson IRC: Bille ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] NM DBUS api documentation build system
On Feb 5, 2008 8:46 AM, Will Stephenson [EMAIL PROTECTED] wrote: snip I haven't actually added any api documentation yet. I'm working on supporting NM 0.7 in KDE 4 and would do so as I grok 0.7. The patch just replicates the status quo with the ability to add api docs. The system can also add a make check target to assure the docu generation is working but I haven't adapted/copied that yet. Another question is, are you interested in async glib binding support? The system can apparently generate separate async introspection xml but I haven't adapted that either yet as I'm not familiar with the glib bindings. I've tested this locally. Dan, Tambet: what do you think about integrating it? It would make NM client developement much easier. While I'd like to have always up to date documentation, I'm not sure I like this. The patch you sent only removes the introspection XML we currently have and adds some XSLT which I can't read (and thus maintain). It'll make development easier only if someone actually writes that documentation, just converting to more magic makes things harder to understand. And again, I like having documentation as much as anyone, but since we have two developers in total (who are busy with maintenance work for a lot of time), I personally would rather write code. So if anyone wants to help with documentation, it could live in a text file for now. When it has enough information, and if Dan feels comfortable maintaining XSLT, I wouldn't have anything against the proposed solution. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] NM DBUS api documentation build system
Hi Tambet, I haven't actually added any api documentation yet. I'm working on supporting NM 0.7 in KDE 4 and would do so as I grok 0.7. The patch just replicates the status quo with the ability to add api docs. The system can also add a make check target to assure the docu generation is working but I haven't adapted/copied that yet. Another question is, are you interested in async glib binding support? The system can apparently generate separate async introspection xml but I haven't adapted that either yet as I'm not familiar with the glib bindings. I've tested this locally. Dan, Tambet: what do you think about integrating it? It would make NM client developement much easier. While I'd like to have always up to date documentation, I'm not sure I like this. The patch you sent only removes the introspection XML we currently have and adds some XSLT which I can't read (and thus maintain). It'll make development easier only if someone actually writes that documentation, just converting to more magic makes things harder to understand. And again, I like having documentation as much as anyone, but since we have two developers in total (who are busy with maintenance work for a lot of time), I personally would rather write code. So if anyone wants to help with documentation, it could live in a text file for now. When it has enough information, and if Dan feels comfortable maintaining XSLT, I wouldn't have anything against the proposed solution. I must agree here. Something that generate the introspection is not helpful at all. It is hard enough to keep external introspection XML files in sync with the actual runtime introspection. Why should we have another thing to maintain. If you could generate the introspection files from within the source code, that is a different story. Something in combination with Doxygen. Regards Marcel ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM DBus API
On Fri, 2007-10-05 at 10:15 -0600, Pat Sissons wrote: Not really, there have been a few of us who have documented what we discovered as we make our way through the source, but there is no official DBus API documentation. There was talk a little while back about someone setting up a wiki where we could submit our findings, but it never seemed to develop. I'm sure if someone can create a wiki for the information to be stored others will contribute, I know I would. Pretty much anyone can get a user on the live.gnome.org wiki and just start adding stuff... Dan On 10/4/07, Scott Robinson [EMAIL PROTECTED] wrote: Is there a place where the NM DBus and VPN APIs are documented? (besides the code) -- Scott Robinson | http://quadhome.com/ Q: Why are my replies five sentences or less? A: http://five.sentenc.es/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iEYEARECAAYFAkcFnDkACgkQ2wcaZqTSGsQ9LQCg0SYedxkCbP0TWHTj2Sf4xaW4 AKAAn3bi/T4/8RnCwOA/IJXZ9XJtMw+M =w3f8 -END PGP SIGNATURE- ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM DBus API
Not really, there have been a few of us who have documented what we discovered as we make our way through the source, but there is no official DBus API documentation. There was talk a little while back about someone setting up a wiki where we could submit our findings, but it never seemed to develop. I'm sure if someone can create a wiki for the information to be stored others will contribute, I know I would. On 10/4/07, Scott Robinson [EMAIL PROTECTED] wrote: Is there a place where the NM DBus and VPN APIs are documented? (besides the code) -- Scott Robinson | http://quadhome.com/ Q: Why are my replies five sentences or less? A: http://five.sentenc.es/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iEYEARECAAYFAkcFnDkACgkQ2wcaZqTSGsQ9LQCg0SYedxkCbP0TWHTj2Sf4xaW4 AKAAn3bi/T4/8RnCwOA/IJXZ9XJtMw+M =w3f8 -END PGP SIGNATURE- ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list -- Pat ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
NM DBus API
Is there a place where the NM DBus and VPN APIs are documented? (besides the code) -- Scott Robinson | http://quadhome.com/ Q: Why are my replies five sentences or less? A: http://five.sentenc.es/ signature.asc Description: Digital signature ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
