update-notifier-kde is not aware of packages in "held" state

Confirmed (Kubuntu Dapper).

For anyone searching for the same issue in Ubuntu (Gnome), see bug #75332.

In case someone knowledgeable notices this - how likely is it that a developer adapts the said functionality (to adept_notifier and adept_updater) from any of the other package managers that do the right thing? (Not that it would help me in Dapper, but I'd just like to know.)

The notifier is a useful tool, but this issue does somewhat diminish its utility. Having a package held back, I have the exclamation mark constantly in my tray.

Bug still exists - and its really annoying.

I have but some packeges to "hold" because i need a special version of one package. But now I always have the exclamation-mark in the tray.

Sincerly
Daniel

Bug still exists in Gutsy as far as I can see.

>Bug still exists in Gutsy as far as I can see.
Definitely in gusty, and it's really annoying.

I also can confirm this in gutsy. I downgraded qemu to the feisty version because of a qemu bug. Afterr downgrading qemu, I did "aptitude forbid-version qemu=0.9.0-2ubuntu4" to prevent it from upgrading. This works for aptitude in a terminal .. it successfully skips it. Also, adept manager skips it when I filter for updatable packages. But, adept notifier shows 1 package in the system tray icon. When I click on it and let adept updater to the upgrade .. it updates qemu. Of course this is not what I want. It seems odd that this bug is just with the updater and not with adept manager.

If any more info is needed, please advise.

This bug was nominated for Gutsy but does currently not qualify for a 7.10 stable release update (SRU) and the nomination is therefore declined.
According the the SRU policy, the fix should already be deployed and tested in the current development version before an update to the stable releases will be considered. With 7.10 now released, that policy applies to this bug. See: https://wiki.ubuntu.com/StableReleaseUpdates .
The bug is not being closed as work will continue on fixing it for the next release, Hardy Heron (8.04). If the state of this bug should change such that it qualifies for the SRU process, please contact the person who originally declined it and ask them to re-evaluate it. To help improve the state of this bug see: https://wiki.ubuntu.com/Bugs/HowToTriage .

This is still occurring for Hardy. Any chance it will be fixed before release?

This annoying bug is still present, even in the Hardy release :-(

Fixed with update-notifier-kde, adept_notifier's replacement in Intrepid.

I'm not seeing as to how this is fixed. I have held a package to a specific version, yet am still being notified of the update with Kubuntu Intrepid.
update-notifier-kde Version: 0.9

Re-opening, according to previous comment.

As far as I can see, update-notifier-kde gets its upgrade infos from the apt_check.py script, from the update-notifier-common package. It would seem that this functionality would have to be implemented there.

This seems to really work in Kubuntu 9.04. Held back updates do not get advertised as updates.

Not fixed here. I'm running jaunty alpha with update-notifier-kde version 0.16

I just tested putting a package on hold using aptitude, and then fired up update notifer kde and tested it. It ignored my hold and updated it anyway:

Here's the 3 available updates according to aptitude:

paul :~$ aptitude full-upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Reading extended state information
Initializing package states... Done
The following packages will be upgraded:
  liblensfun-data [0.2.3-0ubuntu2 -> 0.2.3-0ubuntu3] xserver-common [2:1.6.0-0ubuntu3 -> 2:1.6.0-0ubuntu4] xserver-xorg-core [2:1.6.0-0ubuntu3 -> 2:1.6.0-0ubuntu4]
3 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 0B/2430kB of archives. After unpacking 1024kB will be freed.
Do you want to continue? [Y/n/?] n
Abort.

Here's the installed version of xserver-common:

paul :~$ lspkg xserver-common
ii xserver-common 2:1.6.0-0ubuntu3 common files used by various X servers

Here's aptitude putting xserver-common on hold:

paul :~$ aptitude hold xserver-common
Reading package lists... Done
Building dependency tree
Reading state information... Done
Reading extended state information
Initializing package states... Done
No packages will be installed, upgraded, or removed.
0 packages upgraded, 0 newly installed, 0 to remove and 3 not upgraded.
Need to get 0B of archives. After unpacking 0B will be used.
Writing extended state information... Done
Reading package lists... Done
Building dependency tree
Reading state information... Done
Reading extended state information
Initializing package states... Done

Here's verifying that aptitude sees and honors the hold:

paul :~$ aptitude full-upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Reading extended state information
Initializing package states... Done
The following packages will be upgraded:
  liblensfun-data [0.2.3-0ubuntu2 -> 0.2.3-0ubuntu3] xserver-xorg-core [2:1.6.0-0ubuntu3 -> 2:1.6.0-0ubuntu4]
2 packages upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
Need to get 0B/2362kB of archives. After unpacking 1024kB will be freed.
Do you want to continue? [Y/n/?] n
Abort.

Now, this is where I opened update notifier kde and let it do the updates. And it did still update xserver-common, as seen by this version being installed:

paul :~$ lspkg xserver-common
ii xserver-common 2:1.6.0-0ubuntu4 common files used by various X servers

Why did you think this was fixed in jaunt...

I have xserver-xorg-core pinned and I get no notification.

Oh, but this is apt vs. aptitude. It's a duplicate of bug 75332 then.

I'm not transferring this + 5 dupes over to becoming duplicates the other bug by hand, so I'll just invalidate this one.

This bug still exists in 12.04 and its still a bug and not a feature and not "invalid"