14:10:33 <mcatanzaro> #startmeeting Workstation WG
14:10:33 <zodbot> Meeting started Mon Dec 18 14:10:33 2017 UTC.  The chair is mcatanzaro. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:10:33 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:10:33 <zodbot> The meeting name has been set to 'workstation_wg'
14:10:40 <mcatanzaro> #meetingname workstation
14:10:40 <zodbot> The meeting name has been set to 'workstation'
14:10:48 <mcatanzaro> #topic Roll call
14:10:57 <mcatanzaro> .hello catanzaro
14:10:58 <zodbot> mcatanzaro: catanzaro 'Michael Catanzaro' <mcatanzaro@gnome.org>
14:11:24 <juhp_> ah I see the markup links in the reminder email...
14:11:52 <juhp_> wonder how it is generated...
14:12:00 <juhp_> .hello petersen
14:12:01 <rdieter> .hello rdieter
14:12:02 <zodbot> juhp_: petersen 'Jens Petersen' <petersen@redhat.com>
14:12:05 <zodbot> rdieter: rdieter 'Rex Dieter' <rdieter@gmail.com>
14:12:47 <mclasen> .hello mclasen
14:12:48 <zodbot> mclasen: mclasen 'Matthias Clasen' <mclasen@redhat.com>
14:12:59 <otaylor> .hello otaylor
14:13:00 <zodbot> otaylor: otaylor 'Owen Taylor' <otaylor@redhat.com>
14:13:10 <mcatanzaro> #chair juhp_ rdieter mclasen otaylor kalev_afk
14:13:10 <zodbot> Current chairs: juhp_ kalev_afk mcatanzaro mclasen otaylor rdieter
14:13:37 <mcatanzaro> #topic Langpacks UX and installation
14:13:57 <mcatanzaro> juhp_: Anything you wanted to discuss about this?
14:14:28 <juhp_> erm, yes and no
14:15:19 <juhp_> I have no much updates but I had another "crazy idea": a wrapper around libreoffice that would ask the user if they want langpacks installed
14:15:39 <juhp_> potentially could also be used for other apps
14:16:53 <mcatanzaro> Red Hat has LibreOffice developers, so we could ask them to add langpack installation support without needing a wrapper script, right?
14:17:03 <juhp_> I am little worried the feature might make the experience of gnome-intial-setup worse: well it would need to be carefully implemented anyway
14:17:16 <juhp_> mcatanzaro: yeah potentially
14:17:26 <otaylor> mcatanzaro: advantage of separate wrapper app is separate translations
14:17:30 <juhp_> Dunno if it is something they would want to add to libreoffice itself
14:17:45 <juhp_> But worth exploring
14:18:04 <otaylor> mcatanzaro: disadvantage is that it's going to look confusing in the gnome-shell ui - would take a lot of care with startup notification, etc.
14:18:12 <juhp_> I have asked them what they think about the wrapper, but waiting to hear back
14:18:32 <mcatanzaro> What applications need langpacks asides from LibreOffice? It also affects systemwide spellcheck and hyphenation dictionaries, right? But it does not affect normal *.mo files for normal applications?
14:18:42 <juhp_> otaylor: hmm true - I haven't thought enough about the UX
14:19:10 <mcatanzaro> #info Considering creating a LibreOffice wrapper app instead of modifying gnome-initial-setup to support langpacks
14:19:28 <otaylor> I think it probably can be done fine in the initial setup - it's basically just "Downloading extra software for your language..." - it doesn't have to get into a lot of options and details
14:19:32 <juhp_> mcatanzaro: well there is some list in comps I think (perhaps deprecated)
14:20:46 <juhp_> otaylor: true, what happens if the system is rebooted or the session ends quickly?
14:21:18 <juhp_> On a slower network it could take minutes to install
14:21:46 <otaylor> juhp_: do we have exact data for how big it is? I thought we discussed a few tens of megabytes last time
14:21:47 <juhp_> well maybe pkgkit just fails and live goes on...
14:22:06 <juhp_> otaylor: right and downloading the repo metadata
14:22:18 <otaylor> otaylor: so you are saying if it fails, there's no mechanism to resume, because initial setup doesn't get run again
14:22:25 <otaylor> err s/otaylor/juhp/
14:23:10 <juhp_> I am not sure what happens - presumable the transaction just fails or doesn't get started
14:23:29 <juhp_> otaylor: I dunno - it just seems potentially fragile
14:23:48 <juhp_> or system waits?
14:24:07 <juhp_> need to experience perhaps
14:24:21 <juhp_> anyway yes still considering if we can do it in gnome-initial-setup
14:24:55 <juhp_> s/experience/experiment/
14:24:56 <otaylor> juhp_: probably best to discuss with kalev and hughsie if you haven't already - hughsie may have ideas about what this looks like in g-s terms
14:25:18 <juhp_> okay I try to ask them more again
14:25:22 <otaylor> if it's a background operation, it probably should be associated with gnome-software in some way
14:25:23 <juhp_> thanks
14:25:31 <juhp_> yes that would be better
14:26:13 <otaylor> I don't think it's ideal to do as a wrapper either if it's going to trigger minutes of waiting for repodata to download.
14:26:55 <juhp_> true
14:27:06 <juhp_> of course one could say "no thanks"
14:27:20 <juhp_> or "later"
14:28:03 <mcatanzaro> #action juhp_ to continue investigating how best to handle langpack installation.
14:28:24 <juhp_> okay thanks
14:28:32 <mcatanzaro> Shall we move on to the next item?
14:29:45 <juhp_> sure
14:29:45 <mcatanzaro> #topic Remove setroubleshoot
14:30:31 <mcatanzaro> So it looks like there are (probably?) no development resources to create a replacement for setroubleshoot. Hence this becomes a simple question: are we willing to remove it without replacement, and cut off the flow of selinux bug reports?
14:31:12 <mcatanzaro> I think the right long-term answer is "yes, selinux developers should create something better than setroubleshoot if they want bug reports." But losing bug reports is not going to be good for quality.
14:32:39 <mcatanzaro> What are the rest of you thinking?
14:33:25 <juhp_> hmm
14:33:54 <otaylor> I think setroubleshoot is a developer/sysadmin tool, and the emphasis on fixing it is wrong for the normal user. So I can't say I think it belongs installed by default.
14:34:30 <otaylor> presumably if the selinux denial causes an operational error, we should get some bug reports anyways. Our problem, from my perspective is not *getting* bug reports, but dealing with them effectively.
14:34:42 <mclasen> what quality are the bug reports improving ?
14:35:43 <juhp_> personally i seldom look at the reports anymore
14:35:54 <otaylor> (The counter argument is that we're targeting developers, and setroubleshoot is vaguely useful at solving the httpd+selinux problems that many people will run into.... but it feels like we could do so much better there, and it's not going to help with a modern containerized workflow anyways.)
14:36:03 <mcatanzaro> Not sure if I understand mclasen's question, but of course the point of the bug reports is to inform the selinux policy developers about an error in the policy, so that they can fix it.
14:36:42 <otaylor> mclasen: the main thing it would be improving is making our logs less scary and more informative
14:36:47 <mclasen> right
14:37:17 <otaylor> People should *not* look into the logs on a newly installed operating system and see a stream of errors, even if they are harmless
14:37:20 <mclasen> if we want to reduce application breakage due to policy errors, surely the easiest thing would be to just turn off selinux
14:37:36 * mclasen is on vacation, so free to throw out heretic thoughts
14:37:51 <otaylor> But I think that's a bit of an advanced goal in terms of our approach to OS quality.
14:38:45 <mcatanzaro> I'm not brave enough to push through "disable selinux" when stickster is not here... also apparently the Council has said we're not allowed to do that? Or something along those lines. stickster would know.
14:39:20 <mcatanzaro> But maybe we can close the setroubleshoot issue today... it looks like otaylor and myself would both vote to remove setroubleshoot without replacement, right otaylor? What about rdieter, juhp_, mclasen?
14:40:01 <otaylor> mcatanzaro: yes. (Being clear that "remove" here means remove from the default install.)
14:40:16 <mclasen> yes
14:40:21 <juhp_> I am tempted to remove it too - I don't really feel it gives a good UX - though it feels unfortunate that something better is not available
14:40:37 <mcatanzaro> Yes, I'll just remove it from comps. People can still install it if they want it, of course.
14:40:45 <juhp_> of course
14:41:15 <juhp_> Maybe it more important for Server?
14:41:25 <juhp_> it's
14:43:20 <mcatanzaro> I'm not sure if it would work at all on server.
14:43:29 <otaylor> juhp_: we wouldn't be affecting comps for server if there's some sort of headless part of setroubleshoot that cockpit uses or something
14:43:44 <otaylor> (I haven't investigated if there's anything like that)
14:43:46 <juhp_> ah yes right
14:43:59 <juhp_> maybe it doesn't work for the server case even
14:44:46 <mcatanzaro> #agreed Remove setroubleshoot from default Workstation install, without replacement.
14:45:12 <juhp_> http://cockpit-project.org/guide/latest/feature-selinux
14:45:33 <mcatanzaro> I'll try not to remove it from Server
14:46:12 <mcatanzaro> But Pague is *so* *unbearably* *slow* that it is taking ages to load the comps XML file, so I don't know exactly where it is in comps yet.
14:46:47 <mcatanzaro> (Seriously, this is so much worse than cgit. Ugh.)
14:47:20 <mcatanzaro> OK, it's in workstation-product, I can remove it from there without affecting Server at all.
14:47:51 <juhp_> yes
14:48:19 <rdieter> no objection to removing setroubleshoot here
14:48:26 <juhp_> rdieter: thanks
14:49:05 <rdieter> if you value esthetics over function I guess.  I think now policy violations may cause things to fail silently, rather than (sometimes) give a notice
14:49:24 <rdieter> not sure which is more bad :-/
14:49:24 <mcatanzaro> Yes, all selinux errors will now be silent errors.
14:49:54 <mcatanzaro> We'll see how it works out... fortunately, errors are quite rare nowadays.
14:49:58 <mcatanzaro> #topic Open floor
14:51:06 <mcatanzaro> Anybody want to discuss something else? If not, we can end now.
14:51:32 <mcatanzaro> Oh, the next meeting is scheduled for January 1... shall we cancel that? I would expect low attendance.
14:51:44 * otaylor won't be there
14:51:54 <rdieter> +1 to punting jan 1
14:52:07 <mcatanzaro> Let's reconvene on Monday, January 15. Same bat time, same bat channel.
14:52:49 <mcatanzaro> We can just ignore the reminder emails telling us that there is a meeting on the first, because I probably don't have permission to edit the calendar. Not sure. (Anybody know how to do that?)
14:52:50 <juhp_> sounds good
14:54:12 <mcatanzaro> I think stickster has to edit the calendar. Oh well.
14:54:14 <mcatanzaro> #endmeeting