Hi Jonathan,

Would you help to look at the question :-) We want to clarify what's the current pk notification behavior in this?

Thank you!

(In reply to Ludwig Nussel from comment #0)
> Yesterday afternoon I installed a fresh 42.2 Build0263 with GNOME. I left it
> running over night. It did not show any update notification even though a
> kernel update should be available.
> 
> When is the update notification supposed to trigger for the first time?

By default, updates are checked once a day. See the description of the gsettings key "org.gnome.settings-daemon.plugins.updates.frequency-get-updates":

"How often to check for updates. Value is in seconds. This is a maximum amount of time that can pass between a security update being published, and the update being automatically installed or the user notified."

> How can I see when it triggered last time?

Once the notification is triggered, it'll stay in the system message tray.

> How can the data be forged to verify it's working?

You can change the value of "org.gnome.settings-daemon.plugins.updates.frequency-get-updates" to a smaller value, let's say 10. Then log out and log in. You'll see the notification for updates.

(In reply to Jonathan Kang from comment #2)
> (In reply to Ludwig Nussel from comment #0)
> > Yesterday afternoon I installed a fresh 42.2 Build0263 with GNOME. I left it
> > running over night. It did not show any update notification even though a
> > kernel update should be available.
> > 
> > When is the update notification supposed to trigger for the first time?
> 
> By default, updates are checked once a day. See the description of the
> gsettings key
> "org.gnome.settings-daemon.plugins.updates.frequency-get-updates":

Ok, and when does it happen for the first time after installation?
Where is the timestamp of the last check stored?
How can I see the updates plugin is activated and running?
 
> > How can I see when it triggered last time?
> 
> Once the notification is triggered, it'll stay in the system message tray.
> 
> > How can the data be forged to verify it's working?
> 
> You can change the value of
> "org.gnome.settings-daemon.plugins.updates.frequency-get-updates" to a
> smaller value, let's say 10. Then log out and log in. You'll see the
> notification for updates.

Doesn't work for me. zypper patch does show updates though.

(In reply to Ludwig Nussel from comment #3)
> (In reply to Jonathan Kang from comment #2)
> > (In reply to Ludwig Nussel from comment #0)
> > > Yesterday afternoon I installed a fresh 42.2 Build0263 with GNOME. I left it
> > > running over night. It did not show any update notification even though a
> > > kernel update should be available.
> > > 
> > > When is the update notification supposed to trigger for the first time?
> > 
> > By default, updates are checked once a day. See the description of the
> > gsettings key
> > "org.gnome.settings-daemon.plugins.updates.frequency-get-updates":
> 
> Ok, and when does it happen for the first time after installation?

One day after the first startup.

> Where is the timestamp of the last check stored?

the value of gsettings key "org.gnome.settings.daemon.plugins.updates.last-updates-notification".

> How can I see the updates plugin is activated and running?

Use this command: gsettings get org.gnome.settings-daemon.plugins.updates

>  
> > > How can I see when it triggered last time?

Check the value of gsettings key "org.gnome.settings.daemon.plugins.updates.last-updates-notification".

$ gsettings list-recursively org.gnome.settings-daemon.plugins.updates
org.gnome.settings-daemon.plugins.updates frequency-get-updates 10
org.gnome.settings-daemon.plugins.updates frequency-get-upgrades 604800
org.gnome.settings-daemon.plugins.updates last-updates-notification uint64 0
org.gnome.settings-daemon.plugins.updates notify-distro-upgrades false
org.gnome.settings-daemon.plugins.updates frequency-updates-notification 604800
org.gnome.settings-daemon.plugins.updates priority 0
org.gnome.settings-daemon.plugins.updates connection-use-mobile false
org.gnome.settings-daemon.plugins.updates auto-download-updates true
org.gnome.settings-daemon.plugins.updates frequency-refresh-cache 86400
org.gnome.settings-daemon.plugins.updates update-battery false
org.gnome.settings-daemon.plugins.updates ignored-devices ''
org.gnome.settings-daemon.plugins.updates banned-firmware '*/intel-ucode/*'
org.gnome.settings-daemon.plugins.updates media-repo-filenames 'media.repo,.discinfo'
org.gnome.settings-daemon.plugins.updates enable-check-firmware true
org.gnome.settings-daemon.plugins.updates active true

(In reply to Jonathan Kang from comment #4)
> (In reply to Ludwig Nussel from comment #3)
> [...]
> > Ok, and when does it happen for the first time after installation?
> 
> One day after the first startup.

Is there a way to lower this to something like one minute if nothing
was initialized yet?
There will be important updates available right away after all.
Doesn't make sense for people to e.g. surf one day with an old
Firefox.

Another test
rpm -e ntp
init S
<log in as root>
date --set "next week"
hwclock --systohc
reboot


still not update notification ...

The following does not reproduce the issue, but I was trying to get things clear,
summarizing what I saw among zypper and pk in a fresh installed Leap 42.2
RC1 (default pattern, Gnome).

With proper configure of g-s-d settings mentioned in the bug, I can see the
update notification bubble after a short interval of first booting. However
only a single available update (for the package
update-test-affects-package-manager) is shown in the Update Viewer after I
clicking the bubble however. This is one of those pacakges used for testing
update stack during the development phase. The package is special since it
is designed to "require the software stack restart" after installing.

At that moment, this single update is consistent with what I got when
running `pkcon get-updates`. I then install the only update and reboot,
After the reboot, wait for several minutes, the notification bubble pops up
again, it then goes with a bunch of other available update after being
clicked. (including a kernel-default update and several other
"update-test-*" update)

Go back from the fresh installed system, let me review from zypper side.

We have `zypper lu` and `zypper lp`. With zypper lu, it lists all 6
available updates explicitly from beginning (1 kernel, 5 update-test-*
packages). With zypper lp, it outputs results with 2 separate sections. The
first section seems including a single patch (for update-test-affects-package-manager)
suggested to be installed, followed by another section with all other
available updates.

So it seems some consistency with `zypper lp` and `pk` side.

For packagekit specifically, it looks intended to filter out those
packages requires system restart. Only these are updated and the system is
restarted, it then pops up other available updates (including the
kernel-default security update).

(In reply to Ludwig Nussel from comment #5)
> $ gsettings list-recursively org.gnome.settings-daemon.plugins.updates
> org.gnome.settings-daemon.plugins.updates frequency-get-updates 10
> org.gnome.settings-daemon.plugins.updates frequency-get-upgrades 604800
> org.gnome.settings-daemon.plugins.updates last-updates-notification uint64 0
> org.gnome.settings-daemon.plugins.updates notify-distro-upgrades false
> org.gnome.settings-daemon.plugins.updates frequency-updates-notification
> 604800
> org.gnome.settings-daemon.plugins.updates priority 0
> org.gnome.settings-daemon.plugins.updates connection-use-mobile false
> org.gnome.settings-daemon.plugins.updates auto-download-updates true
> org.gnome.settings-daemon.plugins.updates frequency-refresh-cache 86400
> org.gnome.settings-daemon.plugins.updates update-battery false
> org.gnome.settings-daemon.plugins.updates ignored-devices ''
> org.gnome.settings-daemon.plugins.updates banned-firmware '*/intel-ucode/*'
> org.gnome.settings-daemon.plugins.updates media-repo-filenames
> 'media.repo,.discinfo'
> org.gnome.settings-daemon.plugins.updates enable-check-firmware true
> org.gnome.settings-daemon.plugins.updates active true

Probably it makes sense to shorten the frequency-refresh-cache as well. Something like:

  org.gnome.settings-daemon.plugins.updates frequency-get-updates 120
  org.gnome.settings-daemon.plugins.updates frequency-refresh-cache 20

(In reply to Yifan Jiang from comment #10)
> (In reply to Ludwig Nussel from comment #5)
> > $ gsettings list-recursively org.gnome.settings-daemon.plugins.updates
> > org.gnome.settings-daemon.plugins.updates frequency-get-updates 10
> > org.gnome.settings-daemon.plugins.updates frequency-get-upgrades 604800
> > org.gnome.settings-daemon.plugins.updates last-updates-notification uint64 0
> > org.gnome.settings-daemon.plugins.updates notify-distro-upgrades false
> > org.gnome.settings-daemon.plugins.updates frequency-updates-notification
> > 604800
> > org.gnome.settings-daemon.plugins.updates priority 0
> > org.gnome.settings-daemon.plugins.updates connection-use-mobile false
> > org.gnome.settings-daemon.plugins.updates auto-download-updates true
> > org.gnome.settings-daemon.plugins.updates frequency-refresh-cache 86400
> > org.gnome.settings-daemon.plugins.updates update-battery false
> > org.gnome.settings-daemon.plugins.updates ignored-devices ''
> > org.gnome.settings-daemon.plugins.updates banned-firmware '*/intel-ucode/*'
> > org.gnome.settings-daemon.plugins.updates media-repo-filenames
> > 'media.repo,.discinfo'
> > org.gnome.settings-daemon.plugins.updates enable-check-firmware true
> > org.gnome.settings-daemon.plugins.updates active true
> 
> Probably it makes sense to shorten the frequency-refresh-cache as well.
> Something like:
> 
>   org.gnome.settings-daemon.plugins.updates frequency-get-updates 120
>   org.gnome.settings-daemon.plugins.updates frequency-refresh-cache 20

Besides, I also shorten the interval to notify "non-critical" updates, something like:

org.gnome.settings-daemon.plugins.updates frequency-updates-notification 160

I investigated more into the code, and found something useful described as down below:

1. There exists a regular check(every hour) about whether to emit the "get-updates" signal. The check is simply to see if the time has reached the threshold(the value of gsettings key "org.gnome.settings-daemon.plugins.updates.frequency-get-updates").

2. Once the "get_updates" action has been finished, it'll check if there is any importance updates. If yes, then notify users about it. If not, it'll check whether to notify users about normal updates. The following piece of code defines whether to pop up a notification about normal updates.

> /* find out if enough time has passed since the last notification */
> time_now = g_get_real_time () / 1000000;
> freq_updates_notify = g_settings_get_int (manager->priv->settings_gsd,
                                                  GSD_SETTINGS_FREQUENCY_UPDATES_NOTIFICATION);
> g_settings_get (manager->priv->settings_gsd,
                  GSD_SETTINGS_LAST_UPDATES_NOTIFICATION,
                  "t", &time_last_notify);
> if (time_last_notify > 0 &&
      (guint64) freq_updates_notify > time_now - time_last_notify) {
          g_debug ("not showing non-critical notification as already shown %i hours ago",
          (guint) (time_now - time_last_notify) / (60 * 60));
          return;
> }

So, as yifan mentioned, settings the value of "org.gnome.settings-daemon.plugins.updates.last-updates-notification" to a smaller one should be able to trigger notifications about non-critical updates.

(In reply to Ludwig Nussel from comment #6)
> (In reply to Jonathan Kang from comment #4)
> > (In reply to Ludwig Nussel from comment #3)
> > [...]
> > > Ok, and when does it happen for the first time after installation?
> > 
> > One day after the first startup.
> 
> Is there a way to lower this to something like one minute if nothing
> was initialized yet?
> There will be important updates available right away after all.
> Doesn't make sense for people to e.g. surf one day with an old
> Firefox.

Yes, it can be implemented. Emit and only emit the "get-updates" signal once right after a fresh installed system.

(In reply to Jonathan Kang from comment #14)
 
> > Is there a way to lower this to something like one minute if nothing
> > was initialized yet?
> > There will be important updates available right away after all.
> > Doesn't make sense for people to e.g. surf one day with an old
> > Firefox.
> 
> Yes, it can be implemented. Emit and only emit the "get-updates" signal once
> right after a fresh installed system.

Considering that all stored timers (last-notification, last refresh) are set to '0' during installation of the schema, one would expect this to 'just happen', no?

(In reply to Dominique Leuenberger from comment #15)
> 
> Considering that all stored timers (last-notification, last refresh) are set
> to '0' during installation of the schema, one would expect this to 'just
> happen', no?

No. "last-updates-notification" is time when users are notified about non-critical updates. That value is in seconds since the epoch, or zero for never.

(In reply to Jonathan Kang from comment #16)

> No. "last-updates-notification" is time when users are notified about
> non-critical updates. That value is in seconds since the epoch, or zero for
> never.

you mean ""last-updates-notification" is time when users were notified [...}
                                                         ^^^^

(In reply to Dominique Leuenberger from comment #17)
> (In reply to Jonathan Kang from comment #16)
> 
> > No. "last-updates-notification" is time when users are notified about
> > non-critical updates. That value is in seconds since the epoch, or zero for
> > never.
> 
> you mean ""last-updates-notification" is time when users were notified [...}
>                                                          ^^^^

Exactly.

(In reply to Jonathan Kang from comment #18)
> (In reply to Dominique Leuenberger from comment #17)
> > (In reply to Jonathan Kang from comment #16)
> > 
> > > No. "last-updates-notification" is time when users are notified about
> > > non-critical updates. That value is in seconds since the epoch, or zero for
> > > never.
> > 
> > you mean ""last-updates-notification" is time when users were notified [...}
> >                                                          ^^^^
> 
> Exactly.

So, still: on a fresh install, last-updates-notification is = 0 (user was never notified); get-updates should fire within an hour of first boot (as it does every hour); so latest 1 hour after the setup, there should be a notification on a new system (very likely earlier)

(In reply to Dominique Leuenberger from comment #19)
> (In reply to Jonathan Kang from comment #18)
> > 
> > Exactly.
> 
> So, still: on a fresh install, last-updates-notification is = 0 (user was
> never notified); get-updates should fire within an hour of first boot (as it
> does every hour); so latest 1 hour after the setup, there should be a
> notification on a new system (very likely earlier)

No. A check of whether to emit "get-updates" signal is performed every hour. It doesn't mean get-updates will fire every hour.

(In reply to Jonathan Kang from comment #20)

> No. A check of whether to emit "get-updates" signal is performed every hour.
> It doesn't mean get-updates will fire every hour.

Of course not - but the first get_updates check is latest one hour after the system was setup; and at that time last-updates-notification is set to 0 (no notification was ever shown); hence there MUST be a notification within 1 hour

(In reply to Dominique Leuenberger from comment #21)
> (In reply to Jonathan Kang from comment #20)
> 
> > No. A check of whether to emit "get-updates" signal is performed every hour.
> > It doesn't mean get-updates will fire every hour.
> 
> Of course not - but the first get_updates check is latest one hour after the
> system was setup; and at that time last-updates-notification is set to 0 (no
> notification was ever shown); hence there MUST be a notification within 1
> hour

I don't quite understand it. The only way to emit a "get-updates" signal is make the system "uptime" bigger than the value of "org.gnome.settings-daemon.plugins.updates.frequency-get-updates". And the default value is 86400 seconds.

One note is that the get_updates check(which is performed once a hour) is to check whether running get_update or not rather than running get_updates.

There is a fix(request#434715)[1] that was submitted to openSUSE:Leap:42.2. But that fix wasn't submitted to GA, leaper submitted a new request[2] removing that fix later on to sync the package.


*[1] https://build.opensuse.org/request/show/434715
*[2] https://build.opensuse.org/request/show/436176

gnome-settings-daemon has been corrected again:

r13 | lnussel_factory | 2016-11-03 15:16:13 | 97e89ce0c5f5e84082c08d1200eeb25c | 3.20.1 | rq438492

- Modify gnome-settings-daemon-bring-back-updates-plugin.patch: Fix
  updates notification not popping up in openSUSE (bsc#1004343).