update-notifier not visible under unity

Hmm this seems like a pretty serious bug to me, since it results in updates no longer being installed for everyone who has update-manager configured to confirm updates (download, bit not install automatically).

After an upgrade at the beginning of September, it appears that this same issue affects unity-2d. Prior to around September 2, unity-2d continued to show the update-notifier "updates available" icon on the panel.

This is a critical issue; although the default behavior of update-notifier is to spawn a window instead of to show the icon on the panel, many users (myself included) strongly prefer the in-panel notification to the auto-launching of update-manager and will as a result have overridden this default. (In fact, this was a sufficiently frequent question that the Ubuntu 10.04 LTS release notes document for users how to override this behavior.) As a consequence, upon upgrade to oneiric these users will silently cease to receive notifications of updates, including security updates.

One of two things needs to happen here for release. Either the unity/unity-2d change that causes the update-notifier icon to no longer show up on the panel needs to be reverted (which IMHO would be preferred given that it respects the users' explicitly declared preference for receiving notifications), or update-notifier needs somehow to be able to detect that its panel icon isn't going to display, and fall back to auto-spawning the window in spite of the user preference.

I'm assigning this bug to the Ubuntu Desktop team since I have no idea what the rationale is for this most recent change in unity behavior and hopefully someone there does.

Duplicate bug #779496 provides a possible explanation for this regression (missing panel whitelist of update-notifier).

Had a good chat with seb128 about this on IRC, and now understand better what's happening / why / what we can do about it.

The unity-2d behavior change is a deliberate bugfix to bring it in line with the unity-3d behavior. So there is no bug in unity-2d here; the bug is that unity-2d was not *previously* respecting the unity requirements wrt systray behavior.

And this is the exact same behavior that existed in natty when running unity-3d with the "/apps/update-notifier/auto_launch false" setting described in the lucid release notes.

So this is a regression in behavior between beta-1 and beta-2 only for users who are using unity-2d rather than unity-3d.

It is still a very serious regression; users who have modified the behavior of their desktop in a rather common way, and who were not using unity-3d, will upon upgrade to current oneiric no longer receive notifications of available updates - including security updates, and any updates needed in order to fix the lack of updates. It does not impact unity-3d users only because natty already shipped with this behavior, but it does impact all users who are using unity-2d in oneiric, or users who were using the GNOME fallback in natty and may upgrade to oneiric beta-2. Those users who are not using the default unity desktop (in either of natty or oneiric) are also far more likely, proportionally, to have this setting turned on: if they've overridden one default in favor of historic behavior, they're more likely to override another default as well. So I expect a large number of unity-2d users to be affected.

To be fair, the users affected are also much more likely to notice the lack of updates and do something about it. But that's far from certain; users may have applied this setting on behalf of their less-tech-savvy relatives, etc.

We certainly want to get update-notifier ported to use libappindicator, which would make this problem go away. (The update-notifier part of this bug is effectively a duplicate of bug #497913). However, that's unlikely to be done in time for beta-2, and since this bug impacts the very ability of users upgrading to beta-2 to receive further updates, I think it's important that we have some fix/workaround in place for beta-2. I therefore propose that we add update-notifier to the unity-common whitelist (/usr/share/glib-2.0/schemas/com.canonical.Unity.gschema.xml) for beta-2, and we can then evaluate after beta-2 whether it's feasible to port update-notifier to libappindicator for this cycle.

We should also apply the same fix to natty. It won't help all Unity 3d users who are already affected by this issue on natty, but it will help some and limit the damage from spreading any further than it already has.

I'm therefore targeting this bug to natty and also targeting the beta-2 milestone. Strictly speaking we don't need this to be fixed on the beta-2 live CDs, since users of those CDs aren't going to have the non-default update-notifier setting, but we should have something in place at least in the archive for the benefit of upgraders before beta-2 is out.

we may have a unity-2d issue here after all. I've tried various settings for the systray-whitelist:

$ gsettings set com.canonical.Unity.Panel systray-whitelist "['JavaEmbeddedFrame', 'Wine', 'scp-dbus-service', 'update-notifier']"
$ gsettings set com.canonical.Unity.Panel systray-whitelist "['all']"
$

Restarting both unity-2d-panel and unity-panel-service, and update-notifier still doesn't appear.

Is unity-2d not implementing the systray at all, or not implementing the whitelist?

This bug was fixed in the package unity - 4.16.0-0ubuntu2

---------------
unity (4.16.0-0ubuntu2) oneiric; urgency=low

  * com.canonical.Unity.gschema.xml:
    - add Update-notifier to the whitelist (LP: #779382)
 -- Didier Roche <email address hidden> Tue, 20 Sep 2011 08:17:34 +0200

@Kate: I fixed it, and I'm not part of the canonical dx team :)

@Didier, Thanks!

I have a port for s-c now at: lp:~mvo/update-notifier/app-indicator-port

But I'm slightly concerned about adding it at this point of the cycle, mostly because of the
various derivatives using update-notifier. It looks like xubuntu and lubuntu do not have libappindicator
on their default installs, so this would add another dependency for them (not sure how much that
matters for them).

The fallback mode of the app-indicator is also not ideal, if there is no indicator support it will use
a GtkStatusIcon, but it does not provide the full API of it, most importantly for me is that it does
not support setting tooltips for the icon. So that would be a regression for anyone not running
unity.

I look into what can be done to fix this next but the GtkStatusIcon that is used as the fallback is in
the private data so I can not access that. I will see if I can use the "connected" property of the
indicator to do a manual fallback.

Another wart of the port is that I honored the string freeze. So e.g. for the reboot required icon the tooltip is "System restart required". If run in indicator mode, this will become a single item menu with "System restart required". But it would be more intuitive to have something like "Click to restart the system" or something like this.

I just to seb128 about this on irc and he suggested that we should SRU the change instead to benefit from the additional week of testing in -proposed and to minimize the risk of regression. Of course that wil mean that for e.g. xubuntu/lubuntu the SRU adds a new libindicator3-1 dependency.

One way to do it would be to restrict the new codepath to unity, checking XDG_CURRENT_DESKTOP=Unity (which gnome-session sets to this value for unity and unity-2d sessions), in other patches we use that variable already to display unity specific uis and fallbacking to the current code in non-Unity session

The changes are non trivial though so we should probably go with a SRU which let extra margins for testing and is less risky, the current whitelisting solution hit an unity rendering issue but that should be fixed in an unity SRU and only affect users who tweaked their config, no the default installation

On Thu, Sep 29, 2011 at 11:41:18AM -0000, Michael Vogt wrote:
> I just to seb128 about this on irc and he suggested that we should SRU
> the change instead to benefit from the additional week of testing in
> -proposed and to minimize the risk of regression. Of course that wil
> mean that for e.g. xubuntu/lubuntu the SRU adds a new libindicator3-1
> dependency.

Provided that the desktop team is happy to carry the unity whitelist forward
into release to cover the gap, I'm ok with this being an SRU.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

FWIW, lubuntu and xubuntu both ship libappindicator and libindicator in their desktop seeds already.

<charlie-tca> I show indicator plugin in the panel by default in Xubuntu

That is really encouraging actually :)

On Thu, Sep 29, 2011 at 07:07:33PM -0000, Michael Vogt wrote:
> <charlie-tca> I show indicator plugin in the panel by default in Xubuntu

> That is really encouraging actually :)

In that case, do you think we can have this port in for final freeze?

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

I don't know if this is relevant, but yesterday's update of "update-manager" (0.152.18 to 0.152.19) gave me this, which doesn't look right. Its changelog has nothing that sounds related.

I tested this now under xubuntu and it works fine there.

When the fallback sytem kicks in and a GtkStatusIcon is used this breaks as libindicator appends a "-panel" to the icon when its using a fallback but does not check if a icon like this is actually available in the icon theme. There is a bug open about that (LP #820080). I posted a fix there, but until that is fixed this is a regression.

I uploaded a fix for the libappindicator bug LP #820080 now. This much increases my confidence in the fallback mode, the icons show up correctly now in lxde (plus most other indicators are correct now too).

Can this be considered fixed then? Comments seem to indicate it may be the case.

The bug itself is fixed, we have update-notifier showing in unity-3d and unity-2d when asked. Michael wanted to convert to an indicator though, but the Oneiric tracked tasks are indeed closed.

No, update-notifier still has an oneiric-tracked task which is open.

Michael, since libappindicator is accepted, are you happy to upload update-notifier now?

Steve, I uploaded it now into the queue, it should be fine but it will be equally ok if that enter the system via oneiric-updates. The changes are relatively isolated to the abstracted TrayApplet.

This bug was fixed in the package update-notifier - 0.117ubuntu2

---------------
update-notifier (0.117ubuntu2) oneiric; urgency=low

  * port to libappindicator (LP: #779382) to ensure its visible
    under unity{,-2d} for users with the auto_open key set to
    false
 -- Michael Vogt <email address hidden> Wed, 05 Oct 2011 12:18:49 +0200

eol reached https://wiki.ubuntu.com/Releases