Launchpad has imported 1 comments from the remote bug at https://bugs.freedesktop.org/show_bug.cgi?id=92746.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2015-10-30T19:32:23+00:00 Graeme Hewson wrote: If I issue "udisksctl dump" and then issue "udisksctl info" for one of the objects in the dump, I get an error message. For instance: $ udisksctl info --object-path /org/freedesktop/UDisks2/drives/TSSTcorp_CDDVDW_SH_S223Q_TSSTcorp_CDDVDW_SH_S223Q (udisksctl info:4995): GLib-GIO-CRITICAL **: g_dbus_object_manager_get_object: assertion 'g_variant_is_object_path (object_path)' failed Error looking up object with path /org/freedesktop/UDisks2/drives/TSSTcorp_CDDVDW_SH_S223Q_TSSTcorp_CDDVDW_SH_S223Q This is confusing. It turns out that object paths must be relative to /org/freedesktop/UDisks2. For instance: $ udisksctl info --object-path drives/TSSTcorp_CDDVDW_SH_S223Q_TSSTcorp_CDDVDW_SH_S223Q /org/freedesktop/UDisks2/drives/TSSTcorp_CDDVDW_SH_S223Q_TSSTcorp_CDDVDW_SH_S223Q: org.freedesktop.UDisks2.Drive: [snip] I don't know if this is a bug in the executable or in the man page. In either case, I suggest it would be very helpful to state in udisksctl(1) that relative object paths must/can (whichever it is) be used. That is, if the executable is fine as it is, and is designed to accept only relative paths, then that should be stated in the man page, perhaps with an example. On the other hand, if it's decided that the executable should accept absolute paths, then it would be helpful to accept relative paths too, as now, and that too should be documented. According to the man pages, I'm running udisks 2.1.5. (Originally reported at https://bugs.launchpad.net/ubuntu/+source/udisks2/+bug/1511468 because the man pages mention the distribution bug tracker. :) Reply at: https://bugs.launchpad.net/ubuntu/+source/udisks2/+bug/1511468/comments/2 ** Changed in: udisks Status: Unknown => Confirmed ** Changed in: udisks Importance: Unknown => Medium -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to udisks2 in Ubuntu. https://bugs.launchpad.net/bugs/1511468 Title: udisksctl doesn't accept absolute object-paths Status in udisks: Confirmed Status in udisks2 package in Ubuntu: New Bug description: If I issue "udisksctl dump" and then issue "udisksctl info" for one of the objects in the dump, I get an error message. For instance: $ udisksctl info --object-path /org/freedesktop/UDisks2/drives/TSSTcorp_CDDVDW_SH_S223Q_TSSTcorp_CDDVDW_SH_S223Q (udisksctl info:4995): GLib-GIO-CRITICAL **: g_dbus_object_manager_get_object: assertion 'g_variant_is_object_path (object_path)' failed Error looking up object with path /org/freedesktop/UDisks2/drives/TSSTcorp_CDDVDW_SH_S223Q_TSSTcorp_CDDVDW_SH_S223Q This is confusing. It turns out that object paths must be relative to /org/freedesktop/UDisks2. For instance: $ udisksctl info --object-path drives/TSSTcorp_CDDVDW_SH_S223Q_TSSTcorp_CDDVDW_SH_S223Q /org/freedesktop/UDisks2/drives/TSSTcorp_CDDVDW_SH_S223Q_TSSTcorp_CDDVDW_SH_S223Q: org.freedesktop.UDisks2.Drive: [snip] I don't know if this is a bug in the executable or in the man page. In either case, I suggest it would be very helpful to state in udisksctl(1) that relative object paths must/can (whichever it is) be used. To manage notifications about this bug go to: https://bugs.launchpad.net/udisks/+bug/1511468/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : [email protected] Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
