13:00:02 <stickster> #startmeeting Workstation Working Group
13:00:02 <zodbot> Meeting started Mon Sep 11 13:00:02 2017 UTC.  The chair is stickster. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:00:02 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
13:00:02 <zodbot> The meeting name has been set to 'workstation_working_group'
13:00:03 <stickster> #meetingname workstation
13:00:03 <zodbot> The meeting name has been set to 'workstation'
13:00:04 <stickster> #topic Roll call
13:00:05 <stickster> .hello pfrields
13:00:10 <zodbot> stickster: pfrields 'Paul W. Frields' <stickster@gmail.com>
13:01:02 <juhp_> .hello petersen
13:01:04 <zodbot> juhp_: petersen 'Jens Petersen' <petersen@redhat.com>
13:01:05 <stickster> ping juhp juhp_ kalev mclasen otaylor cschalle ryanlerch rdieter walters
13:01:22 <stickster> oh crap, /walters/mcatanzaro/ sorry
13:01:34 <kalev> morning
13:01:34 <mclasen> .hello mclasen
13:01:35 <zodbot> mclasen: mclasen 'Matthias Clasen' <mclasen@redhat.com>
13:01:40 * stickster blames two weeks of travel
13:02:45 <stickster> #topic Agenda
13:02:53 <stickster> #link https://pagure.io/fedora-workstation/issues?status=Open&tags=meeting
13:03:07 <mcatanzaro> .hello catanzaro
13:03:08 <zodbot> mcatanzaro: catanzaro 'Michael Catanzaro' <mcatanzaro@gnome.org>
13:03:27 <stickster> reminder, if you want something covered in the meeting you need to do the following: 1. File an issue, if not done already; 2. tag it with "meeting" (which helpfully appears in the tags for you)
13:04:06 <stickster> #info two issues tagged 'meeting' currently: (1) Removing setroubleshoot; (2) Follow up on SQLite breaking GTK+ search
13:04:10 <mcatanzaro> the SQLite issue is resolved
13:04:21 <stickster> mcatanzaro: Ah, great. If so, could you please close the ticket as fixed then?
13:04:23 * kalev nods.
13:04:34 <mcatanzaro> Well, the underlying problem is not: there is almost no QA for updates and stuff breaks
13:04:41 <kalev> I talked to the maintainer and enable fts5 support in sqlite which made tracker work again
13:04:46 <mcatanzaro> I'll close the ticket
13:04:53 <mcatanzaro> But we really need to gate updates better
13:05:02 <stickster> mcatanzaro: It sounds like we could still use the discussion here, but let's hold on that, it's #2 on the agenda.
13:05:15 <stickster> #topic 1: Remove setroubleshoot
13:05:25 <stickster> #link https://pagure.io/fedora-workstation/issue/24
13:07:38 <mcatanzaro> So... we want to remove setroubleshoot :)
13:07:42 <mcatanzaro> Without replacement
13:07:51 <stickster> The ticket has some useful links to the upstream GNOME design for better problem feedback to the user, which is awesome. What's happening on that front to interact with the right devs (e.g. SELinux/abrt crew) to ensure they continue to receive error reports (if needed)?
13:08:07 <mcatanzaro> Nobody's working on it
13:08:43 <kalev> shouldn't this be a first step before removing setroubleshoot?
13:09:02 <stickster> kalev: +1
13:09:15 <mcatanzaro> I don't see why
13:09:35 <mcatanzaro> Ideally someone would be working on it, but I'm not gonna volunteer for this one :)
13:10:10 <stickster> Well, let's ask this... I'm running Workstation. I hit an SELinux error that prevents my service/app/whatever from working. Will I still receive an SELinux error notification telling me that happened?
13:10:13 <kalev> I feel like removing the only reporting mechanism we have is going to make fedora's selinux support much worse in the long run
13:10:44 <mcatanzaro> stickster: No, you won't. That's the goal, since the SELinux error notifications a full of confusing technical detail.
13:10:52 <mclasen> not annoying users with error notifications that they have no use for and no chance of doing anything about is the  main goal here...
13:11:14 <mcatanzaro> Ideally the user would see no notification and the developer would get some anonymous report of the issue, like on FAF or something
13:11:29 <stickster> So all I get in that case is a silent failure, my thing doesn't work, and I can then conclude (in my naïvete) that Workstation is at fault
13:11:39 <otaylor> stickster: isn't it?
13:11:45 <mclasen> workstation _is_ at fault
13:11:52 <otaylor> (sorry to be late)
13:11:54 <mclasen> for shipping you a broken selinux configuration
13:12:03 <stickster> well yes, but does the developer get something filed to help them fix it?
13:12:13 <mclasen> which developer can fix it ?
13:12:37 <otaylor> stickster: the one reason to have notificaitons is for the subset set of users that would know "it's broken because of selinux and I should setenforce 0"
13:12:42 <mclasen> in my experience, selinux issues usually go like: 1) selinux guys decide to make a policy change
13:12:46 <mcatanzaro> #chair otaylor
13:12:50 <mclasen> 2) stuff breaks
13:12:50 <stickster> oh sorry!
13:12:56 <mclasen> 3) selinux guys make another change to fix it
13:12:59 <stickster> #chair kalev mcatanzaro otaylor mclasen
13:12:59 <zodbot> Current chairs: kalev mcatanzaro mclasen otaylor stickster
13:13:21 <kalev> right, so we need a way to get selinux people to know that stuff has broken
13:13:24 <kalev> how do we do that?
13:13:25 <stickster> mclasen: Any package can ship an SELinux policy module, actually. But in general you're right.
13:14:18 <otaylor> mclasen: there has to be problem rpeorting from 2=>3, but I suspect that people who can report a problem can probably also find the information in journalctl
13:14:20 <stickster> What we don't want is to break the feedback loop to the maintainer and/or SELinux policy maintainers to fix things that don't work
13:14:46 <mclasen> we need to get our endusers out of that loop, though
13:15:17 <stickster> Ideally, though, the system should notify the user in a readable way there was a problem, and that it's been reported so they can follow the fix iff. desired
13:16:12 * kalev agrees.
13:17:15 <kalev> I think it's important that users get an error message that says that something went wrong. if we start silently failing they are just going to feel less in control of their computer
13:17:19 <stickster> If removing setroubleshoot is going to break the flow of bugs/feedback entirely, then without any sort of mitigation (like docs or some other notification) it seems more like "wallpapering over the joists without any drywall"
13:17:48 <juhp_> yeah
13:18:21 <mclasen> notifying the user about a broken state of the system has very little to do with selinux though
13:18:27 <mclasen> the system can by broken for all sorts of reasons
13:19:58 <mclasen> it seems weird that we insist on notfying the user if a service fails due to an selinux error, but not if it fails due to out-of-disk, or some other error
13:19:58 <stickster> I completely sympathize with not wanting to put e.g. "httpd_enable_foo=1" in front of users; it's one of the most mumbo-jumbo things you can see. But if we're just hiding the error in a way that also prevents anyone hearing about it, ugh.
13:20:36 <stickster> In the disk example, I do get notifications ahead of time telling me I'm running out of space
13:20:59 <otaylor> I think the troublesome thing is not really notifying the users, it's that setroubleshoot assumes that the use can (or wants to) *do something about it* - which is simply not true for a "default user"
13:21:00 <stickster> There's no such preventative maintenance on SELinux
13:21:33 <otaylor> so there's a lot of complexity there that is "woah"
13:21:44 <mcatanzaro> TBH we would not be complaining if setroubleshoot was more like ABRT: present a non-confusing error message and otherwise stay out of the way
13:21:48 <mcatanzaro> But... it's not
13:22:30 <mcatanzaro> Also, in F27, after the first selinux error, it will run forever in the background and be impossible to quit, because it uses a tray icon to stay open and the tray is going away.
13:22:36 <otaylor> I think that we need to get to a point where the default experience is based on considering a selinux problem a non-user-fixable OS assembly error, and anything else is something that you have to opt into
13:23:01 <mcatanzaro> (It's actually not impossible to quit: you can show the window manually by opening it up from the overview. But most users will not realize it's running unnecessarily even without a window.)
13:23:20 <mclasen> I think thats a good way to put it
13:25:26 <stickster> I haven't seen the issue on F27 with the sealert browser continuing to run when it shouldn't be
13:25:26 * otaylor doesn't actually know what topic was being debated, so is unable to suggest a way forward
13:25:52 <juhp_> otaylor: https://pagure.io/fedora-workstation/issue/24
13:25:56 <stickster> But the troubleshooter *does* allow the user to fix errors temporarily so they can continue with their operation
13:26:01 <otaylor> juhp: thanks
13:26:05 <kalev> I think so too, it's not something that users should know how to fix and I don't think setroubleshoot should offer instructions on how to fix things -- but how do we make sure that developers learn about selinux problems?
13:26:44 <kalev> I don't think removing the feedback loop helps keeping fedora high quality
13:26:51 <stickster> In any case, kalev's point is the same as mine. Breaking the feedback loop is my main concern.
13:27:33 <stickster> Why not engage with the SELinux team folks to get them to help with a more user-friendly solution?
13:28:09 <otaylor> If we didn't install setroubleshoot/sealert what would be the experience - silent breakage and messages in the journal?
13:28:12 <stickster> well, user- and dev-friendly to be fair
13:28:49 * mclasen is still +1 on removing it
13:29:25 <otaylor> For 28 I think we need to design the experience, but need to figure out what makes sense for f27 which has zero runway (assuming that we're discussing f27)
13:30:12 <mclasen> best to start over, instead of a painful slow process of making incremental changes to a fundamentally wrong tool, in my opinion
13:30:27 <mcatanzaro> For F27 timeframe the only options are "do nothing" and "remove it"... we can't realistically change anything this late in the game
13:31:01 <mcatanzaro> I'm fine with either option for F27, what I care about is the long-term solution
13:31:27 <mcatanzaro> Ideally that would be a new bug reporting program that replaces both setroubleshoot and ABRT, built from scratch by GNOME. But Workstation WG cannot take on a project like that.
13:31:57 * mclasen tries sealert on f28
13:32:01 <mclasen> $ sealert
13:32:03 <mclasen> could not attach to desktop process
13:32:06 <mclasen> problem solved!
13:32:14 <juhp_> haha
13:32:30 <mcatanzaro> I hope that's an selinux bug ;)
13:32:35 <juhp_> lol
13:32:54 <stickster> urgh, running f26 on this station
13:33:00 <stickster> but it's 'sealert -b' here
13:33:05 <juhp_> seems to work on 26 anyway
13:33:29 <mclasen> stickster: sealert -b doesn't give me that message, but no window either
13:34:00 <otaylor> mcatanzaro: maybe you have no selinux messages to browse :-)
13:34:06 <mclasen> and sealert --noservice gives me: ModuleNotFoundError: No module named 'setroubleshoot.browser'
13:34:07 <otaylor> (mclasen meant)
13:34:08 <mclasen> not reassuring
13:34:11 <stickster> We're past the Beta Freeze at this point, I think removing setroubleshoot is a bad idea for F27 in any case, and we're talking about F28 here.
13:34:42 <kalev> is anyone here familier with abrt? can we make add selinux reporting to abrt easily?
13:34:47 <juhp_> anyone have f27?
13:34:56 <kalev> I have f27, but don't have setroubleshoot installed :)
13:35:00 * stickster will need to pull a copy today but has no time until later
13:35:04 <stickster> lol
13:35:25 <juhp_> I couldn't install before flock
13:35:32 <mclasen> sealert seems busted on my system, basically
13:36:00 <mcatanzaro> kalev: jfilak promised to add selinux reporting to ABRT, but he's gone :(
13:36:36 <mclasen> so, i guess we should take decisions on f27 and f28 separately ?
13:36:49 <mclasen> or are we still doing fact-finding for f27 ?
13:38:00 <stickster> I think we should be aiming at a F28 change here, not touching F27 post-Beta freeze
13:38:30 <stickster> But yeah, still need to determine what's going on with F27... if things are broken similarly there, it's a bad sign
13:38:33 <juhp_> oops, I forgot this is still f25 on my home machine
13:38:42 <stickster> juhp_: tsk tsk!
13:39:18 <stickster> #proposed #action stickster find out if F27 setroubleshoot is broken (i.e. non-launching)
13:39:34 <stickster> Also...
13:40:06 <stickster> #proposed #action mcatanzaro talk with setroubleshoot maintainers about seeing if they can work with the GNOME redesign on the wiki (shown in the ticket)
13:40:22 <mcatanzaro> I don't wanna! :)
13:40:32 * mcatanzaro pouts
13:40:52 <otaylor> I don't think that's really worth hvaing in absence of a bigger plan to implement that design
13:41:18 <mcatanzaro> TBH I think it needs to be GNOME/desktop team developers working on the UI if we want the result to be satisfactory.
13:41:28 <stickster> otaylor: what bigger plan are you talking about? that implies more work that no one's taking on ;-)
13:41:34 <mcatanzaro> As we learned from ABRT
13:42:09 <otaylor> I think the "GNOME redesign on the wiki" is a comprehensive plan for error reporting that has been banging around for 4-5 years
13:42:21 <stickster> hmm, I see
13:42:39 <stickster> But then blocking on that seems even more nonsensical
13:43:28 <kalev> I think it makes sense to remove setroubleshoot from the default install in a long run and replace it with something else that autoreports things to bugzilla (an abrt plugin?)
13:43:37 <kalev> not sure an setroubleshoot redesign is worth the effort here
13:43:38 <stickster> I may be missing something, what prevents some discussion btw GNOME devs and SELinux guys on how to maintain a feedback loop to continue improving policy?
13:44:16 <stickster> Basically, if we can figure out how to do that ^ it's easy to be +1 on removing setroubleshoot.
13:44:49 * stickster withdraws proposal #2 above, it's fine if that's overreach
13:45:06 <otaylor> stickster: that sounds like good discussion to have, and improving the situation is a very reasonable goal. I'm just not sure that asking mcantazaro to point the selinux developers to some big redesign on the wiki makes any sense
13:45:08 <mcatanzaro> I don't think anything prevents discussion... we just need a volunteer.
13:45:16 <kalev> I have to step away from keyboard for a bit, sorry
13:45:21 <stickster> otaylor: that's fair
13:46:05 <mclasen> I don't think a discussion with the goal of having selinux team improve the ui makes much sense
13:46:13 <stickster> mclasen: that's not the goal
13:46:26 <otaylor> <x> to do some background research, talk to the designers and then set up a meeting with designers, selinux people, and possibly abrt developers (if making abrt do the reporting seems plausible)
13:46:38 <stickster> mclasen: the goal is to ensure that in removing setroubleshoot we don't break all feedback. Maybe there's a way to do a background function to report errors, via abrt or something else.
13:47:03 <mclasen> we can have a discussion about about apis that we may discover to be missing as we write a better error reporting frontend
13:47:21 <mclasen> but that requires to identify resources for picking that up as a project, first
13:48:38 * stickster will figure out who in selinux team (and abrt) needs to be involved to discuss the feedback problem, and will get kalev to help identify a designer if needed (in the case this can't be done invisibly)
13:49:16 <stickster> with the understanding that we're not doing this in f27, not enough time to coordinate anything meaningful
13:49:44 <stickster> oops
13:50:00 <stickster> #action stickster figure out who in selinux team (and abrt) needs to be involved to discuss the feedback problem, and ask kalev to help identify a designer if needed (in the case this can't be done invisibly)
13:50:16 <stickster> #action stickster also get F27 somewhere to see current situation
13:50:21 <stickster> ;-)
13:50:41 <stickster> #topic 2: Sqlite/GTK+ breakage followup
13:50:55 * stickster notes we've managed to run out the clock mostly, I need to vacate in 7 min
13:51:00 <mclasen> do we have time for one open-floor issue at the end ?
13:51:13 <mclasen> I have a quick thing
13:51:14 <stickster> mclasen: only if this one is really short.
13:51:20 <mcatanzaro> Let's defer this discussion to the next meeting, mclasen has an open floor issue and I've noticed one too: mozjs52
13:51:25 <stickster> okeydoke
13:51:28 <mclasen> gnome 3.26 will support color emoji
13:51:34 <stickster> #topic 3: All other stuff (mclasen)
13:51:37 <mclasen> but we need a suitable font
13:51:45 <mclasen> can we add emojione to the default install ?
13:51:58 <mclasen> and possibly add a dependency somewhere so it gets pulled in on upgrades ?
13:52:12 <mcatanzaro> I don't see any reason not to add it to default install.
13:52:17 <mcatanzaro> Not sure where a dependency would make sense.
13:52:58 <otaylor> workstation-release?
13:53:01 <stickster> mclasen: Are you talking about something licensed as seen here? https://www.emojione.com/licenses -- because even the free license looks problematic.
13:53:07 <stickster> Maybe I'm looking at the wrong thing.
13:53:23 <juhp_> we have google-noto-emoji-fonts
13:53:59 <mcatanzaro> OK well looks like emojione is out of the question... how about the noto thing, mclasen?
13:54:14 <mclasen> https://koji.fedoraproject.org/koji/packageinfo?packageID=24743
13:54:32 <stickster> uhhhh
13:54:33 <mclasen> not sure whats wrong with using the package thats already in fedora ?
13:55:25 <juhp_> Is emojione better?
13:55:41 <mclasen> I don't like either of them too much, visually
13:56:39 <mcatanzaro> Hm, sadly I think this calls for FE-Legal review... https://github.com/eosrei/emojione-color-font/blob/master/LICENSE.md looks mostly fine but for "specific attribution requirements for commercial use"
13:56:42 <stickster> mclasen: I'm having trouble reconciling the license, the github sources seem to indicate MIT, which is not what this package says
13:56:55 <mclasen> the package is an older version, afaik
13:56:58 <stickster> mcatanzaro: I'm also concerned there may be a licensing issue here
13:57:05 <mcatanzaro> Maybe that package shouldn't be in Fedora at all.
13:57:09 <mclasen> best to discuss that with hadess
13:57:13 <mclasen> he will give you all the details
13:57:19 <mcatanzaro> We'll have to defer this to next meeting as we're out of time anyway.
13:57:20 <juhp_> Maybe check the package review first?
13:57:27 <stickster> juhp_: yup
13:57:43 <mclasen> and I'm sure he will appreciate the 5-minute-google-backseat-lawyering :-)
13:57:44 <stickster> mcatanzaro: Can you take a look at that and hit us up in #fedora-workstation?
13:57:58 <mcatanzaro> OK
13:58:04 <stickster> could be an older fork, yes
13:58:16 <stickster> #action mcatanzaro take a look at emojione and follow up in IRC
13:58:31 <stickster> OK gotta run folks
13:58:36 <stickster> Thanks for coming
13:58:37 <stickster> #endmeeting