14:00:00 <stickster> #startmeeting Workstation WG
14:00:00 <zodbot> Meeting started Wed Jun 22 14:00:00 2016 UTC.  The chair is stickster. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:00 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:00:00 <zodbot> The meeting name has been set to 'workstation_wg'
14:00:02 <stickster> #meetingname workstation
14:00:02 <zodbot> The meeting name has been set to 'workstation'
14:00:03 <stickster> #topic Roll call
14:00:05 <stickster> .hello pfrields
14:00:06 <zodbot> stickster: pfrields 'Paul W. Frields' <stickster@gmail.com>
14:00:26 <kalev> .hello kalev
14:00:26 <zodbot> kalev: kalev 'Kalev Lember' <klember@redhat.com>
14:00:35 <mcatanzaro> .hello catanzaro
14:00:36 <zodbot> mcatanzaro: catanzaro 'None' <mcatanzaro@gnome.org>
14:00:50 <mclasen> .hello mclasen
14:00:51 <zodbot> mclasen: mclasen 'Matthias Clasen' <mclasen@redhat.com>
14:01:05 <otaylor> .hello otaylor
14:01:06 <zodbot> otaylor: otaylor 'Owen Taylor' <otaylor@redhat.com>
14:01:56 <cschalle> \o/
14:02:18 <stickster> #chair kalev mcatanzaro mclasen otaylor cschalle
14:02:18 <zodbot> Current chairs: cschalle kalev mcatanzaro mclasen otaylor stickster
14:02:30 <ryanlerch> .hello ryanlerch
14:02:31 <zodbot> ryanlerch: ryanlerch 'ryan lerch' <rlerch@redhat.com>
14:02:36 <stickster> #chair ryanlerch rdieter
14:02:36 <zodbot> Current chairs: cschalle kalev mcatanzaro mclasen otaylor rdieter ryanlerch stickster
14:02:49 <stickster> \o/  Hi all
14:02:54 <stickster> #topic Quick congrats
14:02:55 <ryanlerch> hi!
14:03:06 <stickster> Congratulations to everyone on a successful F24 launch :-)
14:04:10 <stickster> I haven't seen e.g. download stats at this point, though mattdm will certainly be looking at that shortly... but from the PR angle our announcements picked up tremendously over previous traffic on Fedora Magazine
14:04:34 <stickster> And we also have https://fedoramagazine.org/whats-new-fedora-24-workstation/ generating more hits too
14:05:13 <mcatanzaro> And good job to whoever ran damage control on snap v. flatpak, yesterday's press release and Ars article were just what we needed.
14:05:28 <stickster> mcatanzaro++
14:05:35 <mcatanzaro> #link http://arstechnica.com/information-technology/2016/06/here-comes-flatpak-a-competitor-to-ubuntus-cross-platform-linux-apps/
14:05:38 <mclasen> the press release had actually been in the works for weeks
14:06:10 <stickster> Yeah, probably could have come out sooner except for the fact that the principals do, you know, a lot of engineering work on the side ;-)
14:06:11 * mattdm shows up in a puff of smoke
14:06:30 <mattdm> stickster: for $reasons, download numbers lag by about a week
14:06:50 <stickster> mattdm: Yeah, no worries -- I expect we'll hear about a retrospective at some point, it's not vital for today :-)
14:07:09 <mattdm> yeah :)
14:07:15 <mattdm> this morning I have numbers up through 6/16
14:07:29 <stickster> All right, back to work on Fedora 25 then :-)  The fun never ends!
14:07:45 <stickster> #topic coredumpctl integration
14:08:36 <stickster> mcatanzaro: So AIUI the proposal is to change the way we configure Workstation to use coredumpctl vs. abrt-ccpp, but that ABRT would still function in some reduced capacity? Maybe you can explain more here.
14:09:17 <kalev> does ABRT regress in any way from this change?
14:09:35 <mcatanzaro> Yes. So to summarize here, the proposal in one line is "change the systemd vendor preset on abrt-ccpp.service to disabled". If we do that, core files appear in coredumpctl and that makes developers like me happy.
14:09:45 <mclasen> I don't really see how coredumpctl and abrt are alternatives - they do different things...
14:10:19 <mcatanzaro> ABRT largely continues to work as before, in that you can still report crashes and they still automatically go to the crash server. We get both.
14:10:33 <mcatanzaro> coredumpctl is for developers to do debugging. ABRT is for users to report bugs.
14:10:51 <kalev> you say "largely continues to work", is there something that no longer works?
14:11:15 <kalev> I'm just trying to figure out if we'd annoy ABRT developers if we change this and regress something they've worked hard on
14:11:26 <mcatanzaro> "does ABRT regress in any way from this change?"  -- Yes, there are a few features missing, but I think none we care about. I honestly don't remember any from memory; there's a list on some ABRT wiki page somewhere I'm trying to find right now.
14:11:59 <stickster> It looks like jfilak has already made an update to help ABRT work better with coredumpctl created coredumps
14:12:18 <stickster> mcatanzaro: Is the proposal limited to the Workstation presets?
14:12:26 <mclasen> is coredumpctl itself functional again in rawhide ?
14:12:35 <mclasen> it had this selinux problem
14:13:10 <mcatanzaro> It will annoy ABRT developers, because they want users to use abrt-cli for debugging rather than coredumpctl. Problem is, abrt-cli is frankly not super great and Fedora specific, whereas coredumpctl really is super great and cross-distro, so I don't support the ABRT developers on this.
14:13:13 <mcatanzaro> stickster: Yes.
14:13:18 <mcatanzaro> mclasen: No. Coming to that. ;)
14:14:03 <kalev> I'm a little bit surprised that this is all set up so that it's either or, that we can't have both functional at the same time
14:14:11 <mcatanzaro> The status quo is we have coredumpctl installed by default, but broken out-of-the-box for several years now.
14:14:33 <mcatanzaro> kalev: abrt-cli continues to work, but I think there is some reduced feature set; I'm trying to look it up.
14:14:38 <mclasen> kalev: its a single pipe out of the kernel...
14:14:44 <mcatanzaro> (Sorry, insufficiently prepared. ;)
14:14:55 <stickster> #info Proposal is to change Workstation (only) systemd vendor preset on abrt-ccpp.service to disabled, which causes core files to be handled by coredumpctl; however abrt-cli continues to work with a reduced feature set
14:15:03 <otaylor> mcatanzaro: I think we need a summary, then to invite the abrt developers to the meeting (if we can't come to a good resolution without)
14:15:25 <stickster> #info there are some pending coredumpctl related bugs
14:15:31 <stickster> #link https://bugzilla.redhat.com/show_bug.cgi?id=1341829
14:15:35 <stickster> #link https://bugzilla.redhat.com/show_bug.cgi?id=1317927
14:15:40 <mcatanzaro> We've already invited ABRT developers to discuss this on list twice, IIRC. Let me find a link to their side of the story.
14:16:44 <mcatanzaro> And yes, those are the two bugs are blockers here. Both are regressions in F24; this was working fine in F23 and I tested it for several weeks without problems. But in F24, coredumpctl is totally busted and we can't do anything until those are fixed -- that's a big caveat on this.
14:16:46 <stickster> mcatanzaro: jfilak has been on our list in discussions last month, fwiw
14:17:52 <otaylor> I'm also skeptical this is actually should be workstation-specific
14:18:17 <stickster> mcatanzaro: IIRC you mentioned something about Server possibly being interested as well
14:18:19 <otaylor> Having coredumps work differently on different editions of Fedora sounds like a documentation nightmare
14:18:25 <stickster> otaylor++
14:18:25 <zodbot> stickster: Karma for otaylor changed to 1 (for the f24 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
14:18:31 <stickster> Oh look, cookie for you Owen :-)
14:18:33 <mcatanzaro> otaylor: It probably should be done by other WGs too, but it's more important for Workstation as we don't expect Server and Cloud to be used as development platforms.
14:18:39 <mcatanzaro> #link https://lists.fedoraproject.org/archives/list/desktop@lists.fedoraproject.org/message/XJIRB5RYFYB2Z4IWP7MCMLMOAIENAOPF/
14:18:53 <mcatanzaro> #link https://lists.fedoraproject.org/archives/list/desktop@lists.fedoraproject.org/message/CS3DM46XO3QKBFOONPE7Z6WOFHFF2N7S/
14:19:11 <otaylor> mcatanzaro: On the other hand, the point of coredumpctl is presumably for debugging some dumping server or something. I don't see why I'd use it if a GUI app is crashing.
14:19:15 * stickster thinks it's important this not disadvantage the ABRT team's work -- although it sounds at first take it probably doesn't
14:19:38 <mcatanzaro> otaylor: You'd use it to get a backtrace, of course, with 'coredumpctl gdb'
14:19:46 <kalev> otaylor: yeah, I too think this is something to change in the global presets, not just for Workstation
14:20:23 <otaylor> mcatanzaro: well, yes, if I didn't know a reproducer
14:21:27 <otaylor> But still, can't see this as workstation specific - it's just the sort of thing that is supposed to be consistent across editions
14:21:28 <mcatanzaro> It's not that ABRT is bad, it's that coredumpctl is really, really nice. I'm content if I can turn it on for myself (which I can't in F24), but I think it should be on by default for our users.
14:21:47 <mclasen> out of interest, does ubuntu use systemd for storing coredumps now ?
14:21:51 <mcatanzaro> I'm fine with changing it in global presets instead.
14:22:31 <mcatanzaro> mclasen: No, it's a disadvantage for them. On Ubuntu you have to open a terminal, set unlimit, and run the program to get a core dump in the cwd, then manually open it in gdb. This is primitive.
14:22:36 <mclasen> if so switching to coredumpctl on our side would have the advantage of unifying the commandline ux across distros
14:23:06 <mclasen> they had their own crash collection system before we invented abrt...
14:23:54 <mclasen> what was the name... apport ?
14:24:02 <stickster> sounds familiar
14:24:06 <otaylor> otaylor: I think this either significantly disadvantages abrt, in which case it's going to be hard to say that we should disadvantage a *default* *end-user*  (if mostly hidden) service to enable a somewhat obscure commandline tool, or it doesn't significantly disadvantage abrt, in which case we just need to figure out how to make the switchover in Fedora packaging
14:24:18 <stickster> So the issues I think need resolved: (1) fixing critical bugs that keep this from actually making things better ;-) ; (2) establish that ABRT team et al. can still gather necessary data through the right ABRT backend; (3) discuss with other WGs to make this a global change
14:24:36 <stickster> otaylor: yeah, more or less *jinx :-)
14:24:51 <mcatanzaro> With coredumpctl enabled by default, if anything crashes anywhere, daemon or whatever that's impossible/difficult to get coredumps for on Ubuntu, you just run 'coredumpctl gdb' and gdb opens the last crash for you automatically. You don't have to prepare in advance by setting ulimit (except in F24 now), and you don't have to expect the crash -- makes it possible to get stacktraces for rarely-occurring crashes when you're not activel
14:24:53 <mcatanzaro> y trying to.  (These things are possible with abrt-cli as well, of course.)
14:25:28 <mcatanzaro> stickster: I think only (1) and (3) -- I'm pretty sure (2) is not a problem (it already works).
14:26:05 <stickster> mcatanzaro: I'd just like a sign from jfilak or someone on the ABRT team that's the case
14:26:11 <stickster> it didn't seem resolved in list
14:27:32 <mcatanzaro> stickster: I'm sure he would have objected when I wrote on the list "my crashes are being reported to FAF, and I can manually report to Bugzilla" if it wasn't true. :)
14:27:42 <mcatanzaro> #link https://lists.fedoraproject.org/archives/list/desktop@lists.fedoraproject.org/message/JXJTCXYCBUEGE5X3NTJ3JOSD7KJQJ4GW/
14:28:04 <mcatanzaro> #link https://github.com/abrt/abrt/issues/1108
14:28:19 <mcatanzaro> Features we will lose:
14:28:20 <mcatanzaro> #link https://github.com/abrt/abrt/wiki/CCpp-plugin
14:29:38 <stickster> Hmm, losing throttling initially sounds yucky, but OTOH multiple crashes wouldn't eat up user's cwd space a
14:30:16 <stickster> Well, let's get to an #action on this so we can move on
14:30:24 <mcatanzaro> I think "make compat core" is the only one users might miss -- some users will prefer the traditional. (They can get it back by reenabling the service.)
14:30:55 <stickster> #action mcatanzaro bring proposal to Server + Cloud WGs to find out whether global change is acceptable to all
14:31:18 <stickster> The bugs are... the bugs, they'll need to be fixed obviously, but can be tracked in BZ per usual
14:31:55 <stickster> Not being a developer myself I don't have a dog in this fight, just want to see agreement from all parties this is an OK move and doesn't diss anyone :-)
14:32:17 <otaylor> mcatanzaro: it sounds we might get a regression in backtrace quality for deleted binaries?
14:32:21 <mcatanzaro> stickster: The throttling would move from ABRT to systemd (at least I'm pretty sure it does throttling).
14:32:37 <stickster> mcatanzaro: ah, good point. I wonder if there are other items on that list that systemd handles too
14:32:46 <stickster> not to answer here... but worth looking at
14:33:01 <stickster> anything else we need to capture? I want to move on to F25 topic.
14:33:30 * stickster holds door for 30 sec more
14:34:00 <mcatanzaro> otaylor: I think so. It seems not so important, though, as that's the "truncated" backtrace with just function names. At least, that's my understanding of that  page, not completely sure....
14:34:14 <mcatanzaro> We covered everything I wanted to discuss, I'll bring it up with the other WGs.
14:34:23 <stickster> Thanks mcatanzaro
14:34:29 <stickster> #topic Fedora 25 Workstation
14:34:40 <stickster> So this item is really about next steps
14:34:40 <mclasen> thanks for pushing it, mcatanzaro
14:34:50 <stickster> catanzaro++
14:34:50 <zodbot> stickster: Karma for catanzaro changed to 1 (for the f24 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
14:34:55 <stickster> There you go, cookie :-)
14:35:07 <stickster> #info --- What's next for Flatpak? ---
14:35:52 <stickster> So obviously PR push has helped with visibility. There is already LibreOffice interest/work on a Flatpak AIUI... are there other vendors working on Flatpaks that should be highlighted?
14:36:01 * mclasen has been heads-down working on putting flatpak sandboxing infrastructure in place (portals)
14:36:38 <cschalle> stickster, there are some other discussions ongoing, but they are partly blocking on getting the 3rd party policy approved first
14:37:02 <cschalle> but mattdm is looking at moving that forward now
14:38:27 <otaylor> Discussoins about building flatpaks in Koji are continuing - not much progress to report, but there's another meeting of relevant parties this evening
14:38:30 <mclasen> we're still having a (slow) conversation with the koji/rel-eng teams about integrating flatpak and ostree builds
14:39:24 <mclasen> gnome-software in rawhide supports installing flatpaks; some pieces of functionality are still missing, but should be in place by f25
14:39:25 <stickster> cschalle: I haven't seen fundamental objections to the ideas, beyond general concern of "are we somehow promoting non-free," which I think people have gone to some length not to do
14:39:43 <mclasen> such as automatic locale installation, and repository management
14:40:23 <mclasen> stickster: that sounds like a topic for a blog-post-length discussion...
14:40:32 * mclasen puts it on his topic list
14:40:46 <stickster> :-)
14:41:11 <ryanlerch> for the magazine? ;)
14:41:30 <stickster> #info Koji building of Flatpaks is under active discussion
14:41:52 <stickster> #info working toward better gnome-software management of flatpaks for F25
14:42:08 <mclasen> ryanlerch: I would probably write a blog post; but you can feel free to steal stuff for a magazine article
14:42:21 <stickster> we can always do a "wrapper/pointer" type article for that, sure
14:44:42 <stickster> #action mclasen Will do an update blog post on Flatpak progress toward F25
14:44:57 <stickster> #action stickster ryanlerch Work with mclasen to get an appropriate coverage in Fedora Magazine
14:45:04 <mcatanzaro> There were several fundamental objections on the list, but none that I found convincing. We had some good questions regarding the third-party software proposal as well, which we'll probably want to revisit or clarify....
14:45:57 <mcatanzaro> E.g. what happens when upstream wants us to distribute a flatpak, but a Fedora packager doesn't like flatpak and wants to keep the RPM. Or what happens to KDE, can they just not install GIMP now if we switch GIMP to be a Flatpak, since Apper can't handle Flatpaks?
14:46:00 <stickster> I can understand general unease about non-free software, but ISTM we have quite a few design details addressing that -- labels to make things clear in gnome-software, for instance
14:46:51 <kalev> some of the complaints like the xfce spin being unable to install flatpaks could easily be addressed by making gnome-software available in there
14:47:06 <kalev> not sure that would fly for the KDE spin; maybe
14:47:38 <stickster> kalev: and e.g. having Flatpak upstream work with KDE devs on Apper support? I mean, it's in our best interest not to paint Flatpak into a corner here
14:47:39 <otaylor> We don't want to be in a situation where different desktop spins dictate where we go in a least-capable-wins type way
14:47:41 <mcatanzaro> People want 'sudo dnf install gimp' to still work... folks complain that upstreams are bad at packaging and Fedora packages required to fix that (misses the point IMO)... nobody seems to know how many packages will be switched to using flatpak (even me :)
14:47:55 <stickster> otaylor: Did we say the same thing?
14:47:57 <kalev> also, maybe we should do a downstream rename and call it "Fedora Software Center" or something instead of gnome-software just so that other spins would be more receptive for this
14:48:03 <cschalle> mcatanzaro, well in the writeup I leave it up to the working groups/spin teams to decide which version of the package they want in their offering
14:48:19 <otaylor> stickster: Well, you put it in a more proactive positive way :-)
14:48:26 <mclasen> kalev: could even call it ubuntu software center nowadays :-/
14:48:32 <stickster> otaylor: those are my rose colored glasses at work
14:48:41 <kalev> mclasen: yeah :(
14:49:05 <otaylor> mcatanzaro: I think the question of replacing Fedora packages with upstream Flatpaks is still very much open
14:49:35 <mclasen> kalev: maybe you or hughsie could write a post about libflatpak and how to support flatpak in an app installer ?
14:49:37 <mcatanzaro> otaylor: But we probably don't want to remove RPM packages for apps if it means the other spins can't install those apps anymore. If not to be nice to the spins, at least to avoid the politics of it. We could work on flatpak enablement for apper, or a dnf plugin, for instance, even though neither is really needed for Workstation.
14:50:02 <otaylor> mcatanzaro: I don't think we *can* decide it until upstreams start producing well maintained stable flatpaks of their software
14:50:17 <kalev> mclasen: sure, it's been hughsie doing all the flatpak work, I think he'd be in a better position for the blog post
14:50:28 <otaylor> I think at that point other spins may have a different take on the issue.
14:50:29 <mclasen> I'll talk to him then, thanks
14:50:29 <kalev> mclasen: but maybe I should familiarize myself too
14:50:44 <cschalle> mcatanzaro, otaylor : the proposal do not suggest banning people from making rpms of say Gimp, it only says the working group has the right to evaluate it and decide to use a upstream flatpak if they think its a better option
14:50:47 <stickster> mcatanzaro: Right, that's more along the lines of what I'm saying, although Owen's right that the apps are important here... harder to take a bunch of patches if you don't see the value yet
14:51:00 <mcatanzaro> cschalle: The problem with that is, now we have two different versions of GIMP in the distro, with two different sets of bugs... as mattdm is probably right that Red Hat Bugzilla is going to get reports from both sets of users, which is going to be tough to handle...
14:51:07 <otaylor> cschalle: but installing gimp on Fedora shouldn't have a different meaning in different spins
14:51:15 <cschalle> otaylor, why not?
14:51:21 <cschalle> mcatanzaro, yeah, that might be painful
14:51:57 <otaylor> cschalle: Imagine the confusion... "I love the new version of GIMP that I just got on my Fedora machine" - I just went to Apper and installed GIMP, and it doesn't have that new cool feature. What gives?
14:52:09 <mcatanzaro> Even in just Workstation. If you install with dnf and I install with Software, do we really want users to get two different things?
14:52:18 <kalev> I think we don't need to solve all problems at once
14:52:21 <kalev> let's just ignore the upstream flatpak story for now
14:52:21 <cschalle> otaylor, well you can make that argument against the spins themselves...
14:52:25 <kalev> and just get koji building rpms + flatpaks and point gnome-software to the flatpaks from koji that are equivalent to our rpms
14:52:27 <otaylor> cschalle: Spins are of course, *in general* very confusing for a unified version of Fedora
14:52:30 <kalev> and then figure out what to do next
14:52:53 <otaylor> cschalle: Note that the same confusion would happen in Workstation if someone did 'dnf install gimp' from the commadn line
14:53:34 <cschalle> well my take there is that if you are confident enough to use the command line then sure you can have a rpm gimp, a flatpak gimp and a snappy gimp if you want
14:53:50 <cschalle> for me what matters is what we present in Software
14:54:39 <otaylor> kalev: For the purposes of Atomic Workstation, I think that's definitely viable - we do need to eventually figure out the larger story - but I don't think we need to do so right now and I think we're just going to create unnecessary drama if we propose removing the GIMP rpm before we evolve an upstream flatpak ecosystem
14:55:02 <kalev> right
14:55:14 <stickster> otaylor: And along the way we'll have to trust that we honestly confront and resolve the questions of bugs/feedback, etc.
14:56:18 <stickster> After all, this is still in service of strengthening the overall FOSS ecosystem... so we don't want to push worse decisions on users ("where do I report my issue?")
14:57:19 * stickster wonders if it's possible to deal with that in a more pleasant, auto-assisted way...
14:57:44 <kalev> gnome-software could maybe grow a bug reporting link?
14:57:48 <otaylor> we have a potential advantage that bugs/feedback will get back upstream to the authors more directly about binaries they understand - but we don't have a plan for that yet
14:58:11 <stickster> kalev: possibly, I didn't want to assume that wasn't overloading the intent, but sure
14:58:24 <cschalle> yeah, also to be clear, my goal with the writeup was to make it flexible enough for us (as the Fedora community) to experiement and adjust course as we go and figure out the details, and avoid being so rigid that we need to start a huge policy process ever 2 Months as we go forward. How these things will exactly play out in the end I think it is to early to say
14:58:27 <mclasen> not like it isn't already hit and miss if a bug report in rh bugzilla gets you any reaction...
15:00:35 <stickster> mclasen: Right, but at least you're not confusing the user as to what they need to do
15:00:45 <stickster> mclasen: Disappointing them with the result is a different issue
15:00:49 <otaylor> Extending retrace.fedoraproject.org to deal with flatpaks would be a long-term goal - I'm not sure if a cross-distro flatpak retrace server is doable or desirable
15:01:16 <stickster> OK, we're at top of the hour. Sorry we couldn't get to the major theme stuff, but I *am* going to roll that into the next agenda
15:01:29 <stickster> I also think there's clearly more flatpak discussion needed here
15:02:14 <stickster> #info More flatpak devel discussion needed on list and elsewhere
15:02:28 <stickster> #action stickster Roll remaining F25 items into next meeting agenda
15:02:36 <stickster> Closing in 30 sec unless strenuous objection.
15:05:27 <stickster> #endmeeting