Bug 509722

SUMMARY

Security updates coming from PackageKit are (incorrectly) treated like normal updates. This has at least two effects:

- DiscoverNotifier doesn't prioritize its status icon as it should when security updates are pending.
- DiscoverNotifier chooses the wrong icon: the one with the blue dot instead of the one with the red dot.

STEPS TO REPRODUCE
1. Wait for a security update to be published on a distro that uses the PackageKit backend.
2. Check for updates in Discover.

OBSERVED RESULT

If a status icon is shown, it's the one with the blue dot.

EXPECTED RESULT

The status icon with the red dot should be shown.

SOFTWARE/OS VERSIONS
KDE Plasma Version: master branch

ADDITIONAL INFORMATION

This is caused by a change within PackageKit: When sending Package and Packages signals over d-bus, the info argument now contains two values packed into one PkInfoEnum. The original info value is still present, and a new severity value is shifted 16 bits and bitwise-OR-ed with the info value. Consequently, it doesn't match any of the values that PackageKitNotifier::package() tests for, so the special case for security updates never fires.

It's worth noting that packagekit-glib2 was updated to decode the two values when this change was introduced, but PackageKit-Qt was not. Its interface still exposes a single "info" value that requires clients to decode in order to see the true info and severity values. If the PackageKit maintainers ever bring their Qt library into parity with their glib2 library, it would make sense for our PackageKitBackend to take advantage of it.

For now, I have locally applied a patch to Discover that teaches PackageKitBackend to decode the values and once again recognize security updates. I could submit it as a merge request.