Red Hat Bugzilla – Bug 439738
Last modified: 2013-03-13 01:43:06 EDT
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.
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
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:
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.