From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9b5) Gecko/2008040217 Fedora/3.0-0.52.beta5.fc9 Firefox/3.0b5 Description of problem: When initially logging in under KDE (4.0.3-3.fc9.x86_64, although the problem's been ongoing throughout the beta 'release'), I can see the "open cardboard box" icon in the lower right of my system tray appear. If I mouse-down on it, it tells me (if I'm quick enough and know I haven't downloaded this morning's updates) that it is gathering the list. If I click on it, I see a rectangular box briefly flash in the center of my screen, but nothing from PackageKit shows up. In concert with this, I see an entry in /var/log/messages like: Apr 5 12:43:28 localhost console-kit-daemon[2223]: WARNING: Couldn't read /proc/2797/environ: Error reading file '/proc/2797/environ': No such process and if I `ps aux | grep 2797` (as root, using su in a terminal window), I see: root 2797 0.1 0.1 60624 2940 ? Sl 12:42 0:00 /usr/sbin/packagekitd I see a similar problem if I try to click on the other line on the icon about viewing a list of available updates. I'm finding expedient to 'kill -9 2797' and then do a 'yum clean all', 'yum check-update', and 'yum update' to get my updates. I don't know offhand if this is somehow poisoning packagekitd from properly performing on subsequent reboots/logins or not. If I am patient and allow packagekitd to download the updates, the icon does change to a badge (?) or somesuch icon, but clicking on it doesn't (seem to) fare any better. Installation environment: HP dv9000z (AMD Turion 64x2, 2GB memory), on a Western Digital MyBook 250MB USB disk, Geforce 6150 Go, the Broadcom WLAN card doesn't appear on the mini-PCI bus at the moment and yes, I know why... Fedora Beta installed from Beta DVD, with all updates up to 1530Z 5 Apr 2008. Version-Release number of selected component (if applicable): gnome-packagekit-0.1.10-1.fc9.x86_64 How reproducible: Always Steps to Reproduce: 1. Login as an ordinary user under KDE 2. Wait a minute or two for all of the desktop setup activity to settle 3. Look for the icon and click on it. Actual Results: Small rectangular box flashes in center of screen. Expected Results: Large(r) box holding steady and reporting packagekitd's activity, i.e., listing the packages that are available, invitation to download and install them, etc. Additional info: Thought it might be due or relevant to the other problems seen recently with the initial KDE integration in Fedora 9 Beta, but the /var/log/messages line made me quite suspicious that it's not (necessarily) KDE related. It may be a permissions problem and/or an interaction with SELinux that I can't easily troubleshoot without some advice/hand-holding.
What does pkcon get updates say? Could you be more specific about what you think the PackageKit bug is please? Are you sure the window that flashes up is gnome-packagekit?
This morning's bug fixes allowed one box to come up that denoted progress of the updates that were downloading. I haven't tried 'pkcon get updates' yet, but will report back in the next day or so when I do. I am sure, now, that it was a gnome-packagekit window that flashed up since it (the download progress meter) now stays up. Before (when I reported the bug), it flashed in response to a mouse-click on the "open cardboard box" icon, so I was reasonably sure it was something to do with gnome-packagekit, but it flashed so fast (literally blink of an eye speed) that I couldn't be totally certain. I still can't get the larger box (that lists the incoming packages) to come up and stay up - I think it did sort of work in the alpha "release", but at that point it didn't display any information - all I got was a pretty, but useless decoration. (I like to be able to monitor exactly what packages are downloading and installing, such as what I see with 'yum install update'). BTW, yesterday, after reporting this bug, but before downloading this morning's (USA ET) packages, I did do an '/sbin/restorecon -R -v /' out of frustration with some of the other idiotic SELinux complaints I was getting, so that might've cleared up the perceived permissions problem(s).
Running from a terminal window in which I'd done an 'su' command: [root@localhost bayard]# pkcon get updates ** ERROR **: This program cannot start until you start the dbus system service. aborting... Aborted [root@localhost bayard]# ps aux | grep dbus dbus 1995 0.6 0.0 29964 1728 ? Ssl 11:57 0:01 dbus-daemon --system gdm 2478 0.0 0.0 21612 544 ? S 11:57 0:00 /usr/bin/dbus-launch --exit-with-session bayard 2619 0.0 0.0 21612 544 ? S 11:57 0:00 dbus-launch --sh-syntax --exit-with-session bayard 2620 0.2 0.0 29616 1340 ? Ssl 11:57 0:00 /bin/dbus-daemon --fork --print-pid 7 --print-address 9 --session root 2981 0.0 0.0 83604 764 pts/2 S+ 12:00 0:00 grep dbus [root@localhost bayard]# pkcon get updates ** ERROR **: This program cannot start until you start the dbus system service. aborting... Aborted (Using a terminal window as an ordinary user immediately after the above) [bayard@localhost ~]$ pkcon get updates get-updates runtime was 0.0 seconds [bayard@localhost ~]$ (By this time the open cardboard box icon was long gone on its own anyway, because there were no new updates to be obtained since I'd installed this morning's batch an hour earlier; will try again tomorrow morning.)
'pkcon get updates' from a user terminal window responded with a curiously refreshing oscillating equal sign cycling back and forth between a pair of square brackets. It then said 'get-updates runtime was 28.3 seconds', at which point the open cardboard box icon disappeared from the icon area in the lower right-hand area of the screen (near the various other icons for power, network connectivity, sound mixer, Klipper, and a couple of unidentifiable ones). [bayard@localhost ~]$ ps aux | grep pack root 2987 0.0 0.1 63120 3220 ? Sl 10:32 0:00 /usr/sbin/packagekitd [bayard@localhost ~]$ ps aux | grep pk bayard 2977 0.0 0.4 259072 8736 ? Sl 10:32 0:00 /usr/bin/gpk-update-icon It's unclear to me how I'm supposed to proceed from here using PackageKitd, with no visible icons, even though apparently something is running somewhere.
>[root@localhost bayard]# pkcon get updates This isn't suppost to work - I've made the error warning better with git master, but you shouldn't be using these tools as the root user. >It's unclear to me how I'm supposed to proceed from here using PackageKitd, with no visible icons Can you manually run gpk-update-viewer?
I haven't tried gpk-update-viewer yet, but will tomorrow. I manually performed this morning's updates using yum from a terminal window under Gnome instead of KDE, and package manager complained that someone else was using yum :-).
Successfully ran gpk-update-viewer under gnome after I'd run packagekitd under KDE this morning. Updates were successfully downloaded and installed under packagekitd. Still need to (remember to) run gpk-update-viewer under KDE initially in the morning (Sorry about that).
Rebooted under 2.6.25-0.201.rc8.git4.fc9.x86_64 after my cursor mysteriously disappeared under 2.6.25-0.204.rc8.git4.fc9.x86_64 (under both KDE and GNOME), and attempted to run gpk-update-viewer from a terminal window opened in KDE: [bayard@localhost ~]$ gpk-update-viewer (gpk-update-viewer:2933): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_width: assertion `pixbuf != NULL' failed (gpk-update-viewer:2933): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_height: assertion `pixbuf != NULL' failed (gpk-update-viewer:2933): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed Segmentation fault (Attempting to run it from a terminal window after doing an 'su' to root fails as expected, because I'm running dbus as an end-user, not as root).
Can you do gpk-update-viewer --verbose and also try running i under gdb to see where it is failing please. Thanks. Richard.
Created attachment 302089 [details] First attempt; forgot the --verbose
Created attachment 302090 [details] Second attempt - forgot the gdb, but is verbose
Created attachment 302091 [details] gdb and --verbose set finally
Incremental progress seen this morning. Had to manually (i.e., using 'yum clean all; yum update') download this morning's patches, BUT when I rebooted a couple of hours later, I was able to click on the icon, have it ignore me once as it has always done as described in this BZ, but when I tried again, the small rectangular box came up, the progress meter oscillated nicely, etc. However, the oscillations stopped after a moment and froze for about 5-8 seconds, but evidently that was due to the final sweep-up - the window and the icon disappeared shortly thereafter, out of boredom since there were no more updates available.
There is clearly a problem with handling missing icons here. You can reproduce the problem by setting gtk-fallback-icon-theme="hicolor" in ~/.gtkrc-2.0 and commenting out the Inherits line in /usr/share/icons/Tango/index.theme. Doing so takes the gnome icon theme out of the icon theme chain, and makes the process-idle icon unavailable. Running gpk-update-viewer after this ends in a quick crash. We probably need to ship some version of process-idle in the gnome-packagekit hicolor additions.
*** Bug 441381 has been marked as a duplicate of this bug. ***
Created attachment 302203 [details] what's in git I've added this patch into git, which fixes the crash for me. If you don't have gnome-icon-theme installed, then you just get the text, rather than the animation.
If bug 441381 is closed a duplicate of this one, then surely this bug should be on the same trackers it was on? Adding it to KDE4Live and F9PKBlocker.
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb7eee710 (LWP 3933)] 0x0804c92f in g_cclosure_marshal_VOID__STRING () (gdb) thread apply all bt Thread 1 (Thread 0xb7eee710 (LWP 3933)): #0 0x0804c92f in g_cclosure_marshal_VOID__STRING () #1 0x0804cad5 in g_cclosure_marshal_VOID__STRING () #2 0x0804e28d in g_cclosure_marshal_VOID__STRING () #3 0x003d55d6 in __libc_start_main () from /lib/libc.so.6 #4 0x0804bfd1 in g_cclosure_marshal_VOID__STRING () No change in backtrace. Is your patch going to hit rawhide or koji? if so I will get the package(s) manually.
What about gpk-prefs or the other gpk* tools running with --verbose the dialog pops up, without the app pops up then vanishes, but in the console it is still running the process. (gpk-application:4364): Gtk-WARNING **: could not load image: Icon 'preferences-desktop-font' not present in theme (gpk-application:4364): Gtk-WARNING **: could not load image: Icon 'applications-games' not present in theme (gpk-application:4364): Gtk-WARNING **: could not load image: Icon 'applications-graphics' not present in theme
Sure, but we can't ship every icon that we use in the gnome-packagekit tarball. [hughsie@hughsie-work gnome-packagekit]$ locate preferences-desktop-font | grep 22 | grep png /usr/share/icons/Tango/22x22/apps/preferences-desktop-font.png /usr/share/icons/gnome/22x22/apps/preferences-desktop-font.png /usr/share/icons/oxygen/22x22/apps/preferences-desktop-font.png
I have /usr/share/icons/gnome/22x22 -rw-r--r-- 1 root root 858 2008-04-01 17:02 preferences-desktop-font.png I would assume since the Qt/KDE frontend for PackageKit isn't ready yet, gnome-packagekit could depend on the icons but since I have them, why is GTK complaining it can't find the them when I use KDE and not complain when I am in a GNOME login session?
Because the icon theme used in kde does not have gnome in its inheritance chain, I'd say.
Installed this morning's new packages, including PackageKit-libs-0.1.12-1.20080412git.fc9.x86_64, PackageKit-0.1.12-1.20080412git.fc9.x86_64, gnome-packagekit-0.1.12-1.20080412git.fc9.x86_64, yum-packagekit-0.1.12-1.20080412git.fc9.x86_64 and these do not alleviate the problem. I'll re-run the gpk-viewer-update tests again and attach the data later today (USA ET), as well as whatever else is requested.
Ran gdb `gpk-update-viewer --verbose` and got a dialog box appropriately reporting that no further updates were available. The 'script' output is attached, and shows some complaints: (gpk-update-viewer:2981): Gtk-WARNING **: could not load image: Icon 'dialog-information' not present in theme Also, please note that, for whatever reason, I don't seem to have a ~/.gtk-2.0 directory, nor a /usr/share/icons/Tango directory. (I do have a ~./.gtk-bookmarks file, and various other subdirectories in /usr/share/icons). Various dbus daemons are running, however. pkcon-get-updates appears to be missing now, as well !?!
Created attachment 302278 [details] gpk-update-viewer --verbose under gdb with today's updates
Your GDB invocation is incorrect, try this instead: gdb --args gpk-update-viewer --verbose But I also don't see GDB intercepting any crash there.
Oh duh, of course it isn't, you're running gpk-update-viewer outside of GDB with the `gpk-update-viewer --verbose` syntax. The correct invocation is: gdb --args gpk-update-viewer --verbose and then inside GDB: run thread apply all bt
Created attachment 302290 [details] gdb session with debuginfo rpms installed on gpk-update-viewer --verbose
Still no usable backtrace unfortunately, but I'm out of ideas on how to get one. :-(
(It looks like it isn't crashing, but exiting now.)
gpk-update-viewer comes up under KDE now gpk-prefs still has issues with a missing window icon the gpk-update-icon menu misses its icons the generic progress dialog also misses some icons
Matthias, I don't think this is a gpk bug - after all it's just asking for a gnome icon in the icon spec that is installed. I don't think it's unreasonable for a GNOME program to require the use of icons from gnome-icon-theme, even when running in KDE. Surely the KDE theme should fall back to gnome-icon-theme when it can't find an icon?
I have no idea what icon set gpk ends up with. Normally, GTK+ applications don't pick up the icon theme settings from KDE. Anyway, I'd say missing icons, while ugly, are not a blocker, as long as the functionality is there.
Kevin, one thing that would solve most missing icon type problems is to add the line gtk-fallback-icon-theme="gnome" to ~/.kde/share/config/gtkrc-2.0 I thought our KDE was supposed to run an xsettings mgr nowadays, btw ?
> I thought our KDE was supposed to run an xsettings mgr nowadays, btw ? No, it isn't, xsettings-kde doesn't work properly in KDE 4. :-( ~/.kde/share/config/gtkrc-2.0 is automatically generated, but it should be fairly easy to patch the generator (we can also patch the copy in kde-settings, but I'm not sure it's actually used).
The laptop that I was using to test Fedora 9 Beta died at about 1700Z/1300EDT today, so I will not be able to follow up on testing, at least for the time being. If I am able to concoct a workaround (using my wife's laptop at her convenience), I'll chime back in. My thanks to all involved for your understanding and patience!
* Tue Apr 15 2008 Lukáš Tinkl <ltinkl> - 4.0.3-15 - fix #441062: packagekit tools do not show icons correctly on KDE ... patched per suggestion in comment #35