Bug #12133

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

Added by intrigeri 2017-01-12 13:17:38 . Updated 2017-02-01 00:37:16 .

Status:
Resolved
Priority:
Normal
Assignee:
sajolida
Category:
Target version:
Tails_3.0
Start date:
2017-01-12
Due date:
% Done:

10%

Feature Branch:
Type of work:
Discuss
Blueprint:

Starter:
Affected tool:
Deliverable for:

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.

Subtasks

Related issues

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

History

#1 Updated by intrigeri 2017-01-30 11:10:38

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

#2 Updated by intrigeri 2017-01-30 11:29:19

  • 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
  • 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 2017-01-30 12:33:23

  • 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 2017-01-30 12:41:16

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 2017-01-31 19:10:57

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 2017-02-01 00:37:16

  • Status changed from In Progress to Resolved

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