Project

General

Profile

Bug #12133

Check what to do in Stretch wrt. gnome-system-log and gnome-logs

Added by intrigeri almost 3 years ago. Updated almost 3 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
-
Target version:
Start date:
01/12/2017
Due date:
% Done:

10%

Feature Branch:
Type of work:
Discuss
Blueprint:
Starter:
Affected tool:

Description

https://tracker.debian.org/news/831092 says that gnome-logs deprecates gnome-system-log. See also previous discussion about these tools asking for the admin password.


Related issues

Related to Tails - Bug #11620: Don't ask for administration password to open System log (as it's not needed) Rejected 08/06/2016

Associated revisions

Revision 9bf78fba (diff)
Added by intrigeri almost 3 years ago

Don't install gnome-system-log anymore (refs: #12133).

It's deprecated (by gnome-logs) in GNOME, and mostly useless anyway as it's not
Journal-aware. Let's discuss in #12133 if we want to add gnome-logs, and how.

History

#1 Updated by intrigeri almost 3 years ago

  • Related to Bug #11620: Don't ask for administration password to open System log (as it's not needed) added

#2 Updated by intrigeri almost 3 years ago

  • Subject changed from Check what to do in Stretch wrt. gnome-system-log to Check what to do in Stretch wrt. gnome-system-log and gnome-logs
  • Description updated (diff)
  • Status changed from Confirmed to In Progress
  • % Done changed from 0 to 10

So:

  • gnome-system-log doesn't display anything useful since it doesn't know about the Journal, nor about other logs we care about (e.g. Tor's one) => IMO we should drop it, regardless of what we do wrt. gnome-logs
  • gnome-logs doesn't display anything useful unless it's run by a user who can access the Journal. It works fine when started with gksudo gnome-logs from a Terminal (but can't start if started from a Root Terminal). So I see four options:
    • don't ship any graphical log viewer; power users who can understand the logs should be able to use journalctl anyway
    • ship it without additional configuration, and hope that the power users who can understand the logs will find out how to start it
    • ship it and patch the .desktop file so that gksudo is used
    • ship it and add PolicyKit configuration so that the user is asked for the admin password

I'm very tempted to do "don't ship any graphical log viewer", and will do that for now. I'll leave this ticket open for discussion until the end of the March sprint though.

#3 Updated by intrigeri almost 3 years ago

  • Assignee changed from intrigeri to sajolida
  • QA Check set to Info Needed
  • Type of work changed from Research to Discuss

sajolida, what do you think? If you prefer not to spend time on this, just tell me, I'll ask -ux@.

#4 Updated by anonym almost 3 years ago

FWIW: +1 for "don't ship any graphical log viewer". I believe the ability make sense out of these logs and being able to use the CLI's log tools are strongly correlated. It doesn't feel like it's worth spending time to support the (presumably) small set of people which would depend on such a tool. If it worked out of the box I guess we could keep it, but since it doesn'y... kill, kill, kill!

#5 Updated by spriver almost 3 years ago

anonym wrote:

FWIW: +1 for "don't ship any graphical log viewer". I believe the ability make sense out of these logs and being able to use the CLI's log tools are strongly correlated. It doesn't feel like it's worth spending time to support the (presumably) small set of people which would depend on such a tool. If it worked out of the box I guess we could keep it, but since it doesn'y... kill, kill, kill!

I'm 100% with this. If users want to view logs they'll most probably be aware of the CLI and the corresponding tools for viewing logs.

#6 Updated by intrigeri almost 3 years ago

  • Status changed from In Progress to Resolved

With 3 people agreeing, I feel comfortable closing this ticket.

Also available in: Atom PDF