Description of problem: Running pk-update-icon just hangs. If it isn't a application that the user is supposed to run manually, it should be moved out to library path instead. Additional info: pk-[TAB] lists pk-update-icon as one of the applications so users would find it and just hanging on the command line isn't expected behaviour.
I found more such PackageKit related applications # pk-import-desktop returns nothing # pk-install-file and pk-install-package shouldn't be in the user path either # pk-import-specspo returns pk-import-specspo TI:08:25:32 TH:0x99aabf0 FI:pk-import-common.c FN:pk_import_get_package_list,72 - failed to open file
What path should they be? /usr/libexec/? What's the output: pk-import-desktop --verbose pk-import-specspo --verbose Thanks. Richard.
Created attachment 299711 [details] pk-import verbose output
Yes. Everything not meant to be directly invoked binaries must be moved to libexec as per Fedora packaging guidelines. If you need help with packaging changes, let me know. Output of pk-import-specspo --verbose is large and attached above. # pk-import-desktop --verbose TI:17:12:37 TH:0x93e1f58 FI:pk-debug.c FN:pk_debug_init,248 - Verbose debugging 1 (on console 1) TI:17:12:37 TH:0x93e1f58 FI:pk-extra.c FN:pk_extra_set_database,434 - trying to open database '/var/lib/PackageKit/extra-data.db' TI:17:12:37 TH:0x93e1f58 FI:pk-extra.c FN:pk_extra_set_database,437 - Can't open database: unable to open database file TI:17:12:37 TH:0x93e1f58 FI:pk-import-desktop.c FN:main,266 - could not open database (null)
Ahh, the pk-import-* tools are meant to be run using sudo -- i've added message to tell the user what's going on.
I've added pk-import-* to libexec.
I don't think the gui tools should be installed in libexec, and mclasen agrees with me. The pk-import-* tools have been moved into libexec for the next release. I've sent a mail to the mailing list about multiple gpk-update-icon instances.