Bug 752564 - Apper wakes up yumBackend.py every 5 to 10 minutes
Summary: Apper wakes up yumBackend.py every 5 to 10 minutes
Alias: None
Product: Fedora
Classification: Fedora
Component: apper
Version: 16
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Rex Dieter
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2011-11-09 21:04 UTC by Martin Kho
Modified: 2013-02-01 15:51 UTC (History)
30 users (show)

Fixed In Version: apper-0.7.1-3.fc16
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2012-05-03 22:50:38 UTC
Type: ---

Attachments (Terms of Use)
[patch] to keep Apperd from waking up packagekitd (560 bytes, patch)
2012-04-13 12:57 UTC, Martin Kho
no flags Details | Diff
[patch] Apperd is doing now what it has to do... (1.94 KB, patch)
2012-04-16 20:45 UTC, Martin Kho
no flags Details | Diff
[PATCH] Don't ask for updates twice (2.66 KB, patch)
2012-04-19 10:15 UTC, Martin Kho
no flags Details | Diff
[PATCH] revert part of upstream patch + some extra's (5.28 KB, patch)
2012-04-21 12:19 UTC, Martin Kho
no flags Details | Diff

System ID Priority Status Summary Last Updated
KDE Software Compilation 271649 NOR RESOLVED apper does not obey update interval 2020-05-13 15:58:52 UTC

Description Martin Kho 2011-11-09 21:04:36 UTC
Description of problem:

The checking for updates happens in Fedora 16 KDE final with the default setting (Daily check for updates). I mentioned this behaviour on the kde-fedora mailing list [1] with hourly checking.

[1] http://lists.fedoraproject.org/pipermail/kde/2011-October/010404.html

Version-Release number of selected component (if applicable):

How reproducible:
it just happen

Steps to Reproduce:
1. run top in a console and keep an eye on the clock
(the cpu-monitor widget can help)
Actual results:
yumBachend.py checks every five minutes for updates

Expected results:
yumBackend.py checks for updates once a day

Additional info:
In top I see that apper-sentinel is activated before yumBackends.py starts.
My apper config:



Height 1024=549
Width 1280=799

Height 1024=280
Width 1280=430



Height 1024=305
Height 1200=305
Width 1280=450
Width 1920=450

Comment 1 Martin Kho 2011-11-10 10:54:25 UTC

I've explicitly set 'interval=86400' in section [CheckUpdate] (change Check for updates to Hourly (Apply) and change back to Daily (Apply) and everything seems fine. When Check for updates is set to Hourly I still have the five minutes cycle as mentioned on the kde-fedora mailing list.

Martin Kho

Comment 2 Fedora Update System 2011-11-20 22:29:30 UTC
kde-settings-4.7-14.fc16 has been submitted as an update for Fedora 16.

Comment 3 Fedora Update System 2011-11-21 22:53:57 UTC
Package kde-settings-4.7-14.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing kde-settings-4.7-14.fc16'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).

Comment 4 Martin Kho 2011-11-23 08:43:14 UTC

Weird! Yesterday I updated kde-settings to the above version and removed the [CheckUpdate] section from ~/kde/share/config/apper. Now the '5 minutes cycle' is back :-(

So globally setting these defaults has no effect?


did I have to log out/reboot?


Martin Kho

Btw. There seems to be more at the door. Suddenly akonadi_imap_resource crashed with a segmentation fault, but that's an other story. Never seen this before. Time for a reboot. I think. :-)

Comment 5 Rex Dieter 2011-11-23 11:18:38 UTC
I would definitely suggest restarting your session to properly test this, yes.

Comment 6 Martin Kho 2011-11-23 15:35:46 UTC
Hi Rex,

It's running (or sleeping :-)) now for a few hours. Anything seems fine. Tomorrow I'll let you know (after a check happened) if everything is still okay.

Martin Kho

Btw. Should I open another report for the 'hourly' slippery?

Comment 7 Martin Kho 2011-11-24 10:40:44 UTC

After 24+ hours I've not seen any problems with the default settings (check Daily). So this issue seems to be solved.


Martin Kho

Comment 8 Kevin Kofler 2011-11-24 13:18:14 UTC
If "hourly" is still every 5 minutes, there's still a bug. An hour has 60 minutes around here. ;-) (Well, 45 at the university. ;-) But definitely not 5…)

Comment 9 Martin Kho 2011-11-28 15:29:59 UTC

It looks like that the "Daily" issue isn't also solved yet :-( Today the 5 minutes cycle is back again. What did I do? Nothing special. Last night I did - in konsole - run the command "yum list *kopete*". Further I had open: Dolphin, KMail2, Chrome (G+) and Firefox (G-search). So it seems to be a rather complicated issue.


Martin Kho

Comment 10 Martin Kho 2011-11-28 15:34:50 UTC
.. and in the systemtray are sitting: besides the default apps, kopete, amarok, and wuala (online storage)

Martin Kho

Comment 11 Fedora Update System 2011-12-02 21:34:48 UTC
kde-settings-4.7-14.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 12 Andy Blanchard 2011-12-04 13:54:12 UTC
Nope, still doing it here; yumBackend.py taking up 100% of a CPU core every five minutes, regular as clockwork.  I tried running a "yum clean all" and "yum check-update" manually in case it was a corrupted package DB, but that didn't change a thing.

Also, for some bizarre reason, it appears to be mucking around with my DPMS settings when it kicks in and again while it's running.  I can run "xset s dpms 0 0 0 -dpms", wait for the CPU to spike then when I run "xset q" it reports times of 48/72/96 and DPMS enabled.  I've tried resetting the settings while it's running and it looks like it resets them at least once more before it exits as well.

Since this is a media centre PC, this is something of a showstopper for me - kind of hard to enjoy a film when you have to twitch the cursor every minute or so... :(

Comment 13 blue_t_fox 2011-12-11 00:24:21 UTC
This bug is _not_ fixed. After checking for updates in apper in the most recent version available for F16, yumBackend.py will wake up every 5-10 minutes and use 100% CPU the entire time. Why this bug was closed I don't know, it should be re-opened.

Comment 14 Michael Carney 2011-12-31 20:07:11 UTC
Removing apper rpm solves the problem; it appears that the issue is with apper-sentinel.

Comment 15 Donald Cohen 2012-01-10 21:05:24 UTC
I wouldn't mind checking every 5 minutes if this did not use 100% of cpu
for a minute or so.
For now I've disabled it.
I thought this was fixed when I updated to kernel 3.1.6-1 but now
I've updated to 3.1.7-1 and it seems to have reappeared.

Comment 16 Martin Kho 2012-01-10 21:31:27 UTC

FYI (This is NOT a solution, but a workaround!!):

The issue seems to happen/start somewhere in the apper daemon (Apper Monitor in System Settings -> Startup and Shutdown -> Service Manager) (polling method?).

When apper 'gets wild' it goes to 'normal operation' after you've stopped the daemon, wait a while (> 5 minutes) and have started it again. At least this 'works' for me.

Hope this help.

Martin Kho

Comment 17 markusN 2012-01-10 21:37:49 UTC
This seems to help for me:

echo "
interval=86400" >> $HOME/.kde/share/config/apper

Comment 18 ken 2012-01-15 19:54:57 UTC
Same bug confirmed (every 5 minutes, 100% one 1 CPU) on "Linux 3.1.8-2.fc16.x86_64 #1 SMP Sat Jan 7 13:35:24 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux"

System is up-to-date.

Comment 19 Donald Cohen 2012-01-18 01:11:18 UTC
Just updated to 3.1.9-1.fc16.x86_64 and the problem is back.
I finally did this to stop it
 mv /usr/share/PackageKit/helpers/yum/yumBackend.py  /usr/share/PackageKit/helpers/yum/yumBackend.pyxxx

Previously I tried the $HOME/.kde/share/config/apper update above and thought it had solved the problem.

Comment 20 Gilboa Davara 2012-01-21 09:33:26 UTC
This bug looks like a duplicate of:

Comment 21 Oliver Henshaw 2012-01-21 10:11:27 UTC
Though I suspect "100% load" and "every 5 minutes" are really two separate bugs - fewer people might notice the "active every 5 minutes"  part if not for the 100% cpu load.

Comment 22 Gilboa Davara 2012-01-21 13:39:08 UTC
Most likely the 5 minute check is the rather overzealous apper default (kde bug?).
The 100% bug is purely a Yum bug.

- Gilboa

Comment 23 Bartosz Wierucki 2012-01-21 16:12:12 UTC
I think the problem is Apper doesn't write its all configuration options into the file: ~/.kde/share/config/apper. Even if you change some options other than the interval the "interval=" line is not appended. I changed the default interval (Daily), saved options, changed the setting back and finally saved changes again. However, this didn't prevent yumBackend.py from running. I had to log out and in. Now, it seems like it is OK.

So, should the config file be generated with all the options set properly, the problem whould't occur. In the meantime one has to do by hand.

Comment 24 Martin Kho 2012-02-18 12:34:37 UTC

The just pushed update for apper (0.7.1-0.7.20120218.fc16) (See bug #749240 [1]) seems to solve this issue too. At least it looks promising. I'v set the check interval to hourly and had no ~5 to 10 minutes wakeups. Maybe the following change [2] did the trick:

-    if (sender()) {
+    if (qobject_cast<PkTransaction*>(sender())) {
         // if we have a sender this method was caller by PkTransaction
+        // be carefull because QSignalMapper from KDialog also calls this method

Hope this 'nasty' issue will also solved. :-)

Martin Kho

[1] https://bugzilla.redhat.com/show_bug.cgi?id=749240
[2]http://quickgit.kde.org/index.php?p=apper.git&a=commitdiff&h=8e43cddd2634b03ee5a05f5287792bb006e903f8 in file /Sentinel/SessionTask.cpp

Comment 25 Martin Kho 2012-02-18 12:36:00 UTC
... and yes it still checks for updates. :-)

Martin Kho

Comment 26 Martin Kho 2012-02-18 12:48:56 UTC

Maw, I was too optimistic ;-( After the first check follows the next one after ~5 minutes. Sorry.

Martin Kho

Comment 27 Bobby 2012-03-18 06:07:23 UTC
I can confirm this bug on a fully updated Fedora 16 i686 install.  Frustration finally caused me to simply remove apper.


Comment 28 Fabien de Saint pern 2012-03-23 12:39:23 UTC
The problem still persists (fully updated Fedora 16 x64)

Comment 29 Paul 2012-04-05 01:28:51 UTC
I confirm the bug on Fedora 16 x64. extremely frustrating when it kills the battery of your laptop.

Linux version 3.3.0-8.fc16.x86_64 (mockbuild@x86-05.phx2.fedoraproject.org) (gcc version 4.6.3 20120306 (Red Hat 4.6.3-2) (GCC) ) #1 SMP Thu Mar 29 18:37:19 UTC 2012


Comment 30 Kevin Kofler 2012-04-05 11:27:17 UTC
So, while the bad news is that this issue is still a mystery, the good news is that bug #748790 is finally getting addressed, which means that at least the excessive checks won't be that taxing on your battery anymore.

That said, I'd love seeing a fix for this one too!

Comment 31 Martin Kho 2012-04-05 13:35:39 UTC

R. Hughes says: "In other words, pkcon refresh now spends just about 20 s CPU time instead of 8 minutes."

Can it be that apper is triggered twice in the 'old' (8 minutes) situation. It uses a 5 minutes timeout. So with the shortening of the pkcon refresh period the apper wake ups will be gone too?

Martin Kho

Comment 32 Rex Dieter 2012-04-05 13:51:54 UTC
quite possible, we'll have to continue testing after bug #748790 is fixed

Comment 33 Martin Kho 2012-04-08 11:44:44 UTC

No, the fix for bug #748790 doesn't fix the wake ups, at lease for me :-(. The only difference is that the refresh is really fast now. And that's certainly good news.

So there have to be something else that is still wrong.


Martin Kho

Comment 34 Martin Kho 2012-04-13 12:03:25 UTC

I've looked (again) into the Apper daemon code (ApperD) and there is something I can't get clear. In this code 'm_lastRefreshCache' plays  a crusial role in the Refresh and Update cicle, correct?
Code from apperd.cpp:
"if (m_lastRefreshCache.isNull() || m_lastRefreshCache.toTime_t() < maxTime) {

In two places 'm_lastRefreshCache' gets a (new) value:

1) --> ApperD::ApperD(...)
if (!m_sentinelIsRunning && nameHasOwner(QLatin1String("org.freedesktop.PackageKit"), QDBusConnection::systemBus())) {
        m_lastRefreshCache = getTimeSinceRefreshCache();

2) --> ApperD::Poll()
if (m_lastRefreshCache.isNull()) {
        m_lastRefreshCache = getTimeSinceRefreshCache();

Now imagine the following scenario:
A refresh and update just happened because m_lastRefreshCache.toTime_t() < maxTime) was true. After five minutes m_lastRefreshCache is not Null and apper-sentinel isn't running and/or org.freedesktop.PackageKit has no owner. 
My question is: In this scenario how get m_lastRefreshCache updated? Is this scenario plausable?


Martin Kho

Martin Kho

Comment 35 Martin Kho 2012-04-13 12:08:08 UTC

I got to the scenario in comment 34, because I killed both apper-sentinel and packagekitd (checked qdbus --system to see if org.freedesktop.PackageKit still existed) and found that the wake up were still there.

Martin Kho

Comment 36 Martin Kho 2012-04-13 12:57:05 UTC
Created attachment 577327 [details]
[patch] to keep Apperd from waking up packagekitd



I've no idea what the side effects are with this patch. Till now I've not seen any wake ups. But have to test it much longer. May be someone who has real programming skills and more inside information into Apper's internals can say  more about the sanity of this patch.

Martin Kho

Comment 37 Martin Kho 2012-04-16 20:45:04 UTC
Created attachment 577834 [details]
[patch] Apperd is doing now what it has to do...

... apperd has to (according to the source code):

1. Refresh the package cache periodicaly (based on the refresh interval set in the configuration file);
2. Update or Display Package Updates;
3. Display Distro Upgrades;
4. Start Sentinel to keep an eye on running transactions.

Point one was especially a problem. The first patch was sub-optimal. There was still one extra call to update the cache. I found that it takes a while before the refresh-cache value is settled after a refresh (and update) call. This brought me to the current patch.

Now apper is doing the following:
a. at start up (mostly at login): cache refresh and update and after five minutes an update call (not cache refresh).

b. running: (I've set the update interval to hourly) every hour the cache is refreshed and updates are checked.

So for me this issue is 'solved'. May be a programmer can look into the patch to see if nothing really nasty is happening.

Thanks and I hope this helps,

Martin Kho

Comment 38 Rex Dieter 2012-04-16 21:01:49 UTC
In the meantime, mind giving apper-0.7.1-2 from koji a try?

Comment 39 Martin Kho 2012-04-16 21:15:27 UTC
Hi Rex,

My patch is essentially doing the same, to make sure the next cycle the new refresh-cache value will be read. So please forget my patch. It seems indeed solved with apper-0.7.1-2. I'll test it thourougly.


Martin Kho

Comment 40 Fedora Update System 2012-04-16 21:31:30 UTC
apper-0.7.1-2.fc17 has been submitted as an update for Fedora 17.

Comment 41 Fedora Update System 2012-04-16 21:32:30 UTC
apper-0.7.1-2.fc16 has been submitted as an update for Fedora 16.

Comment 42 Martin Kho 2012-04-17 08:42:11 UTC

Everything works fine now. When others have confirmed that 0.7.1-2 is working for them, please close this report.

Thanks for the really nice work!

Martin Kho

Comment 43 Lukáš Tinkl 2012-04-17 18:01:38 UTC
Thank you, Martin, for the excellent detective work! :)

Comment 44 Rex Dieter 2012-04-17 18:10:56 UTC
Dannti (usptream dev) informed us this is not yet a complete fix, so stay tuned.

Comment 45 Martin Kho 2012-04-18 11:11:31 UTC

I see after every Refresh and Update six minutes later an Update request. This is still not good?

@Lukáš Tinkl: you're welkom :-)

Martin Kho

Comment 46 Fedora Update System 2012-04-18 19:32:01 UTC
Package apper-0.7.1-2.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing apper-0.7.1-2.fc16'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).

Comment 47 Martin Kho 2012-04-18 21:14:28 UTC

It took me a while to find the debug information from Apper. In kdebugdialog I had to enable kded ... of course :-). Now I see in .xsession-errors the following messages:

kded(1385) ApperD::callApperSentinel: "RefreshAndUpdate"
kded(1385) ApperD::serviceOwnerChanged: "org.kde.ApperSentinel" "" ":1.119"
kded(1385) ApperD::transactionListChanged: tids.size() 1
kded(1385) ApperD::transactionListChanged: tids.size() 2
kded(1385) ApperD::transactionListChanged: tids.size() 1
kded(1385) ApperD::transactionListChanged: tids.size() 2
kded(1385) ApperD::transactionListChanged: tids.size() 1
kded(1385) ApperD::transactionListChanged: tids.size() 0
kded(1385) ApperD::serviceOwnerChanged: "org.kde.ApperSentinel" ":1.119" ""
kded(1385) ApperD::callApperSentinel: "Update"
kded(1385) ApperD::serviceOwnerChanged: "org.kde.ApperSentinel" "" ":1.121"
kded(1385) ApperD::transactionListChanged: tids.size() 1
kded(1385) ApperD::transactionListChanged: tids.size() 2
kded(1385) ApperD::transactionListChanged: tids.size() 1
kded(1385) ApperD::transactionListChanged: tids.size() 0
kded(1385) ApperD::serviceOwnerChanged: "org.kde.ApperSentinel" ":1.121" ""

The time between "RefreshAndUpdate" and "Update" is six minutes. The second call to callApperSentinel is one too much IMO. It's triggered by the signal UpdateChanged from PackageKit [1]. this makes Apper 'thinking' that is needs to 'display or update the system'.

Hope this helps,

Martin Kho

[1] qdbus --system org.freedesktop.PackageKit /org/freedesktop/PackageKit [org.freedesktop.PackageKit.UpdatesChanged]

Comment 48 Martin Kho 2012-04-19 10:15:51 UTC
Created attachment 578566 [details]
[PATCH] Don't ask for updates twice


As mentiond in my previous comment there was an update request after a RefreshAndUpdate request. This patch is meant to prevent from this behaviour. It's rather easy. "when apper had just asked for a RefreshAndUpdate (meaning apper is still active) don't ask for an update again, even PackageKit is telling to do so". The patch is somewhat bigger, because there was a very little change that a variable was used before it was inititalized.

Hope this helps.

Martin Kho

Comment 49 Martin Kho 2012-04-19 13:17:20 UTC
Hi Rex,

Thanks for bringing my patch to the attention upstream. Though I've a little bit the feeling that I misuse your autority, I hope you don't mind :-)

Martin Kho

Comment 50 Kevin Kofler 2012-04-19 13:30:37 UTC
Don't worry, I've talked to the Apper upstream developer on IRC (he's a regular on #fedora-kde, even though he personally runs Kubuntu and/or Debian), he appreciates your work on this bug.

Comment 51 Rex Dieter 2012-04-19 13:36:27 UTC
Indeed, taking 'http://fedoraproject.org/wiki/Wiki#Above_all_else' (a wee bit out of context, but still applicable in general to many things): 

Above all else

Be bold. Don't worry about memorizing all the rules before starting - just dive in, knowing that there's plenty to learn, and ask for help and feedback along the way. People will cheerfully correct you if you ask; it's better to try doing something quickly and then ask if you got it right (all edits on the wiki are reversible) than to not make an edit because you're afraid of "doing something wrong." We absolutely love to see new people try and learn, and will jump in and lend a hand when asked, or if we spot something.

Comment 52 Martin Kho 2012-04-20 21:31:52 UTC

Patch apper-0.7.1-wakeups.patch contains the addition (1) in apperd.cpp that has two contra-effects:

1) It 'wakes up' a call to RefreshAndUpdate, that was 'solved' with addition (2). The origional problem is brought back in again :-(

2) More serious is that it 'blocks' doing a real update. When you press apply in apper, it resolves dependencies, finishes and shows the updates.

+    if (tids.isEmpty()) {
+        // update the last time the cache was refreshed
+        // TODO PackageKit should emit a property change for this
+        m_lastRefreshCache = getTimeSinceRefreshCache();
+    }

+            // Invalidate the last time the cache was refreshed
+            m_lastRefreshCache = QDateTime();

I've tried to remove (1) and everything seems fine. I could update available packages. No unnecessary RefreshAndUpdates.

Martin Kho

Comment 53 Martin Kho 2012-04-21 11:20:27 UTC

One little correction: point 1) isn't caused by patch (1). The 'wake ups' are happening because PackageKit doesn't honour normal (not forced) calls to Refresh and/or Update when there are already updates available (1). "PackageKit raises it's middle finger, and says do something with the available updates first, then we can talk about your next call." And so the refresh-cache would not be reset, causing the 'wake-ups'. They are harmless in sofar I can see, but IMHO not very nice.
A fix could be to prevent the apper daemon from doing anything when apper-sentinel is active.

Martin Kho

(1) Currently some dependencies are not met for libsmbclient. So apper-sentinel is 'permanently' active. A good testcase to see what is happening. :-)

Comment 54 Rex Dieter 2012-04-21 11:29:48 UTC
I saw the stuck behavior wrt the current broken samba4 update too.

so, any concrete short-term suggestions?  Drop (-wakups) patch2?  apply yours?  wait?

Comment 55 Martin Kho 2012-04-21 12:19:46 UTC
Created attachment 579163 [details]
[PATCH] revert part of upstream patch + some extra's

Hi Rex,

If've created a patch to revert the blocking part (comment #52) and adds the suggested changes in comment #48 and #53. As soon as upstream comes with better solutions it's easy to drop this patch again.

What do you think, worth doing?

Martin Kho

Comment 56 Martin Kho 2012-04-21 12:22:19 UTC

Note: I'm running apper with this patch now. I could install all packages and apper-sentinel is sitting in my systray. No unnecessary wakeup :-)

Martin Kho

Comment 57 Fedora Update System 2012-04-26 12:32:25 UTC
PackageKit-0.7.4-1.fc17, apper-0.7.1-4.fc17 has been submitted as an update for Fedora 17.

Comment 58 Martin Kho 2012-04-27 08:48:07 UTC

For me apper-0.7.1-4 (and PackageKit-0.7.4-1) works fine. 

There is, however, another bug that blocks cache-refreshes after a succesfull update that needs no reboot/logout. I've opened a report upstream [1].

Shall I open a bugreport in Fedora bugzilla to track this bug?

Martin Kho

[1] https://bugs.kde.org/show_bug.cgi?id=298893

Comment 59 Martin Kho 2012-05-01 07:50:51 UTC

Hum ... upstream did a nice job with version PackageKit 0.7.4-1. :-( For me apper seems totally broken, it never ends a transaction.

This is what I get:
[martin@ps-1866 ~]$ qdbus --system org.freedesktop.PackageKit /org/freedesktop/PackageKit org.freedesktop.PackageKit.GetDaemonState
0       get-updates     /8197_abcadeee_data     state[running] background[0]
1       get-updates     /8198_adbdecec_data     state[ready] background[0]
2       get-distro-upgrades     /8199_eddccaad_data     state[ready] background[0]

After some:
[martin@ps-1866 ~]$ qdbus --system org.freedesktop.PackageKit /org/freedesktop/PackageKit org.freedesktop.PackageKit.StateHasChanged resume

sudo kill <PackageKit_PID>

apper returns to normal.

This looks not good IMHO :-)

Martin Kho

Comment 60 Martin Kho 2012-05-01 09:40:38 UTC

The issue I mentioned in comment #59 only happens when there are a lot of updates (32). I retried it with one update (after a downgrade) and everything looks okay. As far I could see in the 'mass update' there were no updates related to PackageKit or apper.

Martin Kho

Comment 61 Fedora Update System 2012-05-02 04:40:48 UTC
PackageKit-0.7.4-1.fc17, apper-0.7.1-4.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 62 Rex Dieter 2012-05-02 11:53:46 UTC
oops, sorry about the auto-close, will re-open until we have a fix for f16 in stable updates.

Comment 63 Martin Kho 2012-05-02 14:27:28 UTC

Forget all the noise in comments #59 and #60. It looks like it were only temporary hick ups. Besides they has nothing to do with this report :-) Apper  still works fine.

Martin Kho

Comment 64 Fedora Update System 2012-05-03 22:50:38 UTC
apper-0.7.1-3.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.