So I reported this bug back in October 2012, but it has had zero attention paid:
https://bugzilla.redhat.com/show_bug.cgi?id=863592
it seems like kind of a significant bug, and it got into the release of F18, and it's still in F19. Is anyone ever going to get around to dealing with it?
The problem is that the "Important updates are available" notification launches the *online* update tool. If our story is that offline updates are the Way To Go for 'normal' users - which is certainly what https://fedoraproject.org/wiki/Features/OfflineSystemUpdates seems to be saying - then that's inconsistent. It seems like once the 'Install updates and restart' bit was done people just kinda figured the feature was done, without considering how interaction with gnome-pk should be handled. Note the item "Update gnome-packagekit to support offline updates" under 'Scope' is not marked as 'done', but the feature is listed as 100% complete.
There's an implication on the feature page that there should be a distinction drawn between updates of 'OS components' (which should be offline) and 'application updates and installations' (which should still be possible online), but there's no indication this has actually been implemented, and in my testing, the update notification pops up and calls gnome-packagekit even when the update package set contains the kernel, or systemd, or anything like that.
It just seems like the intersection between gnome-pk and offline updates isn't really done yet, and needs to get finished off...
Hi Adam,
Thanks for drawing attention to this. I personally often feel drowned by Bugzilla, especially after ABRT's automated entries, and I wish we had an ongoing manually maintained list of issues like this that are high profile, hardware independent, etc.
On Fri, 2013-04-05 at 16:26 -0700, Adam Williamson wrote:
There's an implication on the feature page that there should be a distinction drawn between updates of 'OS components' (which should be offline) and 'application updates and installations' (which should still be possible online), but there's no indication this has actually been implemented, and in my testing, the update notification pops up and calls gnome-packagekit even when the update package set contains the kernel, or systemd, or anything like that.
Right. As far as I know the current UI mockups center around what gnome-software is attempting to implement. Lots to do here obviously to enable gnome-software; for example there's the bug that was discussed here regarding the icon data last month ( https://bugzilla.redhat.com/show_bug.cgi?id=488968 ).
But we probably don't need to block on that; something stupid like by doing:
diff --git a/plugins/updates/gsd-updates-manager.c b/plugins/updates/gsd-updates-manager.c index bb242ab..02a7d30 100644 --- a/plugins/updates/gsd-updates-manager.c +++ b/plugins/updates/gsd-updates-manager.c @@ -228,7 +228,7 @@ libnotify_action_cb (NotifyNotification *notification, goto out; } if (g_strcmp0 (action, "show-update-viewer") == 0) { - ret = g_spawn_command_line_async (BINDIR "/gpk-update-viewer", + ret = g_spawn_command_line_async (BINDIR "/gnome-software", &error); if (!ret) { g_warning ("Failure launching update viewer: %s",
and ensuring gnome-software puts everything in the "OS update" box (to update offline) would get us to a saner place, from which further iteration is possible.
On 08/04/13 09:27 AM, Colin Walters wrote:
Hi Adam,
Thanks for drawing attention to this. I personally often feel drowned by Bugzilla, especially after ABRT's automated entries, and I wish we had an ongoing manually maintained list of issues like this that are high profile, hardware independent, etc.
Sadly, we don't really have the resources to make any kind of appreciable dent in bug triage :/
On Fri, 2013-04-05 at 16:26 -0700, Adam Williamson wrote:
There's an implication on the feature page that there should be a distinction drawn between updates of 'OS components' (which should be offline) and 'application updates and installations' (which should still be possible online), but there's no indication this has actually been implemented, and in my testing, the update notification pops up and calls gnome-packagekit even when the update package set contains the kernel, or systemd, or anything like that.
Right. As far as I know the current UI mockups center around what gnome-software is attempting to implement. Lots to do here obviously to enable gnome-software; for example there's the bug that was discussed here regarding the icon data last month ( https://bugzilla.redhat.com/show_bug.cgi?id=488968 ).
But we probably don't need to block on that; something stupid like by doing:
diff --git a/plugins/updates/gsd-updates-manager.c b/plugins/updates/gsd-updates-manager.c index bb242ab..02a7d30 100644 --- a/plugins/updates/gsd-updates-manager.c +++ b/plugins/updates/gsd-updates-manager.c @@ -228,7 +228,7 @@ libnotify_action_cb (NotifyNotification *notification, goto out; } if (g_strcmp0 (action, "show-update-viewer") == 0) {
ret = g_spawn_command_line_async (BINDIR "/gpk-update-viewer",
ret = g_spawn_command_line_async (BINDIR "/gnome-software", &error); if (!ret) { g_warning ("Failure launching update viewer: %s",and ensuring gnome-software puts everything in the "OS update" box (to update offline) would get us to a saner place, from which further iteration is possible.
Right, it seems like something that could be improved in the short term quite appreciably by fairly simple hacks. Anything that doesn't result in the online update app showing up would help, really.
Thanks for drawing attention to this. I personally often feel drowned by Bugzilla, especially after ABRT's automated entries, and I wish we had an ongoing manually maintained list of issues like this that are high profile, hardware independent, etc.
I apply a filter to filter them out so I have three views in BZ, abrt, no abrt and the kitchen sink. It helps me to see what bugs are filed outside of the abrt automated firehose.
Peter
On Fri, 2013-04-05 at 16:26 -0700, Adam Williamson wrote:
There's an implication on the feature page that there should be a distinction drawn between updates of 'OS components' (which should be offline) and 'application updates and installations' (which should still be possible online), but there's no indication this has actually been implemented, and in my testing, the update notification pops up and calls gnome-packagekit even when the update package set contains the kernel, or systemd, or anything like that.
Right. As far as I know the current UI mockups center around what gnome-software is attempting to implement. Lots to do here obviously to enable gnome-software; for example there's the bug that was discussed here regarding the icon data last month ( https://bugzilla.redhat.com/show_bug.cgi?id=488968 ).
But we probably don't need to block on that; something stupid like by doing:
diff --git a/plugins/updates/gsd-updates-manager.c b/plugins/updates/gsd-updates-manager.c index bb242ab..02a7d30 100644 --- a/plugins/updates/gsd-updates-manager.c +++ b/plugins/updates/gsd-updates-manager.c @@ -228,7 +228,7 @@ libnotify_action_cb (NotifyNotification *notification, goto out; } if (g_strcmp0 (action, "show-update-viewer") == 0) {
ret = g_spawn_command_line_async (BINDIR "/gpk-update-viewer",
ret = g_spawn_command_line_async (BINDIR "/gnome-software", &error); if (!ret) { g_warning ("Failure launching update viewer: %s",and ensuring gnome-software puts everything in the "OS update" box (to update offline) would get us to a saner place, from which further iteration is possible.
-- desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop
----- Original Message -----
Hi Adam,
Thanks for drawing attention to this. I personally often feel drowned by Bugzilla, especially after ABRT's automated entries, and I wish we had an ongoing manually maintained list of issues like this that are high profile, hardware independent, etc.
At least for ABRT, we now have a very nice tool to check high profile & hot automated bugs [1]. So I'd say it's "safe" to filter ABRT bugs based on these hot problems.
On 6 April 2013 00:26, Adam Williamson awilliam@redhat.com wrote:
Not zero attention. It's just hard to solve. I've been talking to the designers, but need mockups on what the UI should look like.
It just seems like the intersection between gnome-pk and offline updates isn't really done yet, and needs to get finished off...
Right, agreed. Poke me on irc "hughsie" if you can help design some wireframes or tell me what needs to be done.
Richard.
On 09/04/13 01:35 AM, Richard Hughes wrote:
On 6 April 2013 00:26, Adam Williamson awilliam@redhat.com wrote:
Not zero attention. It's just hard to solve. I've been talking to the designers, but need mockups on what the UI should look like.
It just seems like the intersection between gnome-pk and offline updates isn't really done yet, and needs to get finished off...
Right, agreed. Poke me on irc "hughsie" if you can help design some wireframes or tell me what needs to be done.
I don't think I'm the best guy to help with a final design, I was thinking more along the lines of short-term stuff like 'just make clicking the notification trigger the "install updates and restart" action with a confirmation dialog' or something like that. Glad to hear you've been working on it, but I couldn't tell that from the bug trackers :)
...
Not zero attention. It's just hard to solve. I've been talking to the designers, but need mockups on what the UI should look like.
It just seems like the intersection between gnome-pk and offline updates isn't really done yet, and needs to get finished off...
...
I don't think I'm the best guy to help with a final design, I was thinking more along the lines of short-term stuff like 'just make clicking the notification trigger the "install updates and restart" action with a confirmation dialog' or something like that. Glad to hear you've been working on it, but I couldn't tell that from the bug trackers :)
We do have some mockups [1] for this already, but they assume the presence of the new Software application. The same workflow might be possible with the existing pieces though.
Some points here:
1. The notification should only be displayed once the updates have been silently downloaded in the background - it isn't a notification that updates are available, but that they are ready to be installed.
2. We should always install system updates offline - having online and offline for them seems odd and inconsistent.
3. We might also want to consider reminders. I'm not sure if there have been discussions about this already, but showing a notification on a daily basis seems about right.
I'm keen to see this fixed too, and actually filed a bug about it upstream [2]. If there are any outstanding design questions, feel free to ask and we will work it out.
Allan
[1] https://live.gnome.org/GnomeOS/Design/Whiteboards/SoftwareUpdates#Tentative_... [2] https://bugzilla.gnome.org/show_bug.cgi?id=692146
desktop@lists.stg.fedoraproject.org
-
Adam Williamson -
Allan Day -
Colin Walters -
Jaroslav Reznik -
Peter Robinson -
Richard Hughes