14:01:00 #startmeeting Workstation WG 14:01:00 Meeting started Mon Feb 25 14:01:00 2019 UTC. 14:01:00 This meeting is logged and archived in a public location. 14:01:00 The chair is kalev. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:01:00 Useful Commands: #action #agreed #halp #info #idea #link #topic. 14:01:00 The meeting name has been set to 'workstation_wg' 14:01:07 #meetingname workstation 14:01:07 The meeting name has been set to 'workstation' 14:01:13 #topic Roll call 14:01:16 .hello ryanlerch 14:01:17 ryanlerch: ryanlerch 'Ryan Lerch' 14:01:21 .hello petersen 14:01:22 juhp: petersen 'Jens Petersen' 14:01:24 morning everybody 14:01:27 .hello kalev 14:01:28 kalev: kalev 'Kalev Lember' 14:01:29 morning! 14:02:00 * kalev goes to look what we have on agenda today. 14:02:10 tis technically morning for me too ;) 14:02:28 :) 14:02:51 .hello otaylor 14:02:52 otaylor: otaylor 'Owen Taylor' 14:03:30 #chair ryanlerch juhp otaylor mclasen 14:03:30 Current chairs: juhp kalev mclasen otaylor ryanlerch 14:03:46 only one issue tagged meeting 14:03:52 .hello mclasen 14:03:53 mclasen: mclasen 'Matthias Clasen' 14:04:55 * kalev nods. 14:05:05 #topic Install gamemode by default? 14:05:12 https://pagure.io/fedora-workstation/issue/88 14:05:28 I missed the previous meeting and I think this got discussed there? 14:05:36 kparal: are you around? 14:05:49 kalev: hello, yes 14:05:53 awesome 14:06:21 kalev: yes we discussed but didn't come to a conclusion 14:06:25 I think mclasen said that it can't work for flatpaks and then you found that it works as a dbus service and might work? 14:06:57 It looks like the minutes were never posted? 14:07:00 yeah 14:07:01 somebody more technical needs to look into that. but mclasen said it doesn't work over dbus and I found a dbus service, so I assumed it might work over dbus 14:07:09 https://meetbot-raw.fedoraproject.org/teams/workstation/workstation.2019-02-11-14.05.log.html is the last log that I found 14:07:22 I was voicing my general disagreement with the general direction 14:07:31 I have no doubt that a dbus service can be retrofit under it 14:07:42 but I'm not volunteering 14:07:50 I think working with flatpaks is a bonus, not something that should really affect the decision. flatpaks are very niche atm 14:08:07 mclasen: have you seen https://pagure.io/fedora-workstation/issue/88#comment-554788 ? 14:08:38 are there any known negatives to installing it by default? 14:08:40 kparal: It seems like what you posted is a *session* daemon - do you understand how that manages to control system level parameters? 14:09:06 otaylor: I assumed it communicates with the host daemon over dbus 14:09:38 ryanlerch: I'm not aware of any 14:11:54 I don't really know much about this, but if shipping this makes games run better and we don't really have to do anything else, that sounds like a win to me :) 14:12:25 certain games, a bit better. but I'd like users to see Fedora as a gamer friendly distro 14:12:43 something that can't be said of Ubuntu, since their very conservative about kernel and mesa 14:12:57 *they're 14:13:06 * kalev nods. 14:13:27 yeah, i'm a +1 14:13:50 not sure how much we want to promote it as a "new feature" 14:13:50 so, since I have the chair and don't really know much about this, let's just vote like a true committee :) 14:14:04 digging into the gamemoded sources, still can't find anything about how it escalates it's privileges 14:14:35 since it only works with certian games, and maybe not flatpaks 14:15:02 I'm +1 ... I think the basic concept is solid - absent system engineering resources to integrate this into systemd, figure out the appropriate mutter hooks, etc. 14:15:06 otaylor: there's a polkit policy inside, perhaps that? 14:15:35 I'm +1 as well 14:15:54 +0 14:16:30 otaylor: https://github.com/FeralInteractive/gamemode/blob/master/data/com.feralinteractive.GameMode.policy.in 14:16:39 kparal: Ah. it installs two helpers, that are privileged via polkit 14:17:29 (given that I think the design is fundamentally not ideal, the policy daemon should be the thing that has escalated privileges. But I'm still +1) 14:17:45 +1, I guess, assuming no bad security implications 14:19:15 I think for the desktop use case, the security implications of allowing the current session to adjust cpu governor and gpu clocking are small. 14:19:24 okay 14:20:14 so, looks like this doesn't pass because we got 4 +1's and need 5 to pass, right? 14:20:26 maybe need to continue in email? 14:21:01 sure, I'll update the ticket and ask if anyone else has votes to add 14:21:02 or on the ticket rather 14:21:08 * mclasen pokes cschaller 14:21:24 cschalle +1 14:21:26 cschalle: we were just discussing installing gamemode 14:21:28 aha! 14:21:34 now we have 5 +1's :) 14:21:38 .hello catanzaro 14:21:39 mcatanzaro: catanzaro 'Michael Catanzaro' 14:21:42 and mcatanzaro as well! everybody's here today 14:21:42 (Sorry I'm late) 14:21:56 no worries. we were just discussing and voting on installing gamemode by default 14:22:21 * otaylor remembers that he took an action to set up a whenisgood for changing the meeting time... 14:22:56 #agreed Workstation WG agrees to install gamemode by default. While we think the design is fundamentally not ideal, the security implications of allowing the current session to adjust cpu governor and gpu clocking are small. 14:23:18 ok, let's move on to a quick F30 status update from me 14:23:23 #topic F30 status 14:23:55 we got the first F30 compose last night, releng had some trouble getting the composes to finish after branching early last week 14:24:04 so now rawhide and F30 are separate. 14:24:28 I'd encourage people to try out F30 and see if anything is amiss. I've personally been running F30 for a month and things seem mostly stable. 14:24:56 (or I mean I've been running rawhide which branched into F30 and rawhide/F31 just now ) 14:25:10 #info We got first F30 compose last night 14:25:28 did we get a g-s release into the compose ? 14:25:37 we had the GNOME 3.32 test day scheduled for today, but QA postponed it to Wednesday because of the compose issues 14:25:48 mclasen: what's g-s? gnome-shell? 14:26:02 software 14:26:12 was interested in rpm-ostree support for silverblue 14:26:14 no, but hopefully there's going to be a new compose tonight 14:26:25 yeah, you should give it a try :) 14:26:54 good 14:27:05 I also split out gnome-software-rpm-ostree subpackage, hope it doesn't cause it to fall out of the compose (it has rich deps which should pull it in, I hope) 14:27:28 #info GNOME 3.32 test day is on Wednesday over at #fedora-test-day 14:27:57 allan is travelling and I was hoping that he could take a look at the 3.32 state in Fedora, but I think he can't because of taht 14:28:11 kalev: the 3.32 packages should be in silverblue composes as well? 14:28:15 otaylor: yep 14:28:38 as for 3.32 builds in rawhide, we are fully up to date, with the exception of a few packages: 14:28:48 gdm: needs downstream patch rebasing, Ray should be aware of it 14:29:05 he's standing here. I'll ask him 14:29:07 gnome-initial-setup: needs downstream patch rebasing and the patch was done by Rui, who has sadly moved on 14:29:55 then there's gssdp and gupnp API version bump upstream that I think seems too hard for us to swallow for F30. I think it's best to leave it out for now. 14:30:14 (none of the dependant packages seem to be ported) 14:30:40 and then there's one of the gnome games, I can't remember which, maybe lightsoff? that needs a new dep. I haven't looked into it 14:30:47 but beyond that we should be fully up to date in Fedora 14:31:25 #info We're almost fully up to date with GNOME 3.32 upstream releases, with the exception of gdm and gnome-initial-setup 14:31:40 next thing I had was that I played a bit with creating flatpaks in Fedora 14:31:57 otaylor has done some great work there 14:32:13 I got 3 flatpaks built: 0ad, wesnoth, thunderbird 14:32:24 the first two are in stable and thunderbird is in testing 14:32:34 I'll try to do a blog post about that and try to get some more people interested in it 14:32:40 kalev: Thanks for working on that! 14:32:54 but I think we should maybe try to aim to get the delta between Silverblue and Workstation packaged as flatpaks 14:33:06 so that we can ship those by default in Silverblue as flatpaks 14:33:37 that includes things like gedit and file-roller and gnome-maps and eog 14:33:40 BTW: https://fedora.fishsoup.net/flatpak-status/ - (will work on making the UI clearer before I post it to a list) 14:33:43 (eog already exists) 14:33:56 * juhp was trying for gedit in Brno 14:34:04 #info We have several new flatpaks built in Fedora: 0ad, wesnoth, thunderbird 14:34:08 That's a website that shows whether the flatpaks we already have need to be rebuilt 14:34:16 I saw a bunch of people request flatpak repos but none got any builds from what I could tell 14:34:28 otaylor: ohh, nice! 14:35:24 anyway, on the topic of flatpaks: should we ship the fedora flatpak repos by default? 14:35:41 #topic ship Fedora flatpak repos by default? 14:36:20 Um... yeah? 14:36:23 we could easily drop a file in /etc/ that pre-installs flatpak remotes 14:36:40 I think so; I don't see any benefit of waiting at this point 14:36:45 * kalev nods. 14:36:58 kalev: Assuming good handling in GNOME Software for overlap :-) 14:37:15 kalev: Did we make any progress at adding multiple-flatpak-sources handling? 14:37:21 Does gnome-software differentiate flatpaks? 14:37:21 how about I do that and add "fedora-flatpak" as enabled, and "fedora-flatpak-testing" as disabled by default repos? 14:37:46 otaylor: yes, we have some nice progress, there's still more issues to fix but it's already much better in yesterday's 3.31.90 release 14:37:57 kalev: Sounds goods to me. 14:38:17 I'm planning on tackling another issue this week that should make it much better 14:38:41 That's good 14:39:05 otaylor: ok, great :) I deliberately included "flatpak" in the repo names so that they differentiate nicely in gnome-software from regular "fedora" 14:39:46 not sure it's a good thing to do or not. I suspect it's going to be hard to change the repo names once people have started using them 14:40:17 kalev: Hmm, it's a bit odd, actually 14:40:34 kalev: Can you make GNOME Software do the disambiguation itself? 14:40:54 kalev: Like add (rpm) and (flatpak) if there are two entries that differ in backend but are different in type? 14:41:07 otaylor: yep, I think so 14:41:31 Odd because 'flatpak install fedora-flatpak org.gnome.gedit' and because on Silverblue, Flatpaks are all there is 14:42:08 * kalev nods. 14:42:16 ok, I'll try to do something on the gnome-software side 14:43:22 ok, I think that's all from me now 14:43:48 #action kalev to make sure fedora flatpak repos are installed by default 14:44:34 Do we want to dig into the Videos discussion from fedora-desktop? 14:44:56 #topic Videos discussion from the fedora-desktop list 14:46:09 so for those who haven't followed the mailing list, hadess posted a message asking if we should drop totem from Fedora as we don't ship enough codecs to make it useful 14:46:24 and supercede it with totem flatpak from flathub 14:46:45 and then a lot of people though that it's not a good idea 14:46:53 and discussion ensued :) 14:47:09 What's the main objection? 14:47:15 I don't have a strong opinion myself ... I understand where Bastien is coming from in wanting his users to experience his software as just-works, but I also think we need to solve the codecs problem 14:47:27 ah 14:47:34 I'm with otaylor here 14:48:17 juhp: Well, it means that we don't have a recommended solution to play videos or music files in software shipped by Fedora ... it's missing functionality until you discover flathub (and would still be so if we split flathub and pointed to some portion by default) 14:48:50 Well the timing is awkward here 14:48:59 There's really two different sides of this a) RPM and b) Flatpak - that need entirely different solutions for the codecs issue 14:49:06 cschalle has promised MP4 support via Centricular's work on OpenH264 plus fdk-aac 14:49:07 and it's getting more complicated because we don't have any means to installs codecs for flatpaks in silverblue if we end up distributing totem as a flatpak from fedora 14:49:18 Right? So that really obviates any need to remove the Videos app, if that's coming 14:49:27 Bastien is saying basically that a) the rpm parts don't work as well as they should b) and the Flatpak parts are vaporware 14:50:18 mcatanzaro: I don't think necessarily - I think that Bastien thinks that users will not figure out how to get wider codec support (h265, whatever) even if it gains mp4 support out of the box 14:50:48 mcatanzaro: But obviously, it makes Videos-as-shipped far more useful. 14:50:48 otaylor: Let not perfect be the enemy of the good 14:50:53 MP4 is the big one 14:51:38 Do people here use Videos regularly? (I apparently don't - still don't have it on this computer after 5 months of Silverblue) 14:52:24 If it had mp4 maybe I would... hmm 14:52:26 Anyways, not actually that relevant - just don't have a good mental model of use cases 14:52:30 most people do video in browsers probably 14:52:51 (unless using specialized software) 14:53:19 I use it semi-regularly for WebM stuff 14:53:34 In the past, I've used it play videos/music that I have around locally "what's this mp3 file? Do i still need it" 14:53:43 Also it's our default music player, yes 14:53:59 We need Videos to play MP3 :( 14:54:19 kwizart, otaylor: if we double down on flatpaks in Fedora, do you think it would be possible to get some codecs built as totem flatpak extensions in rpmfusion? or is it massive work to get the infrastructure in place for that? 14:55:02 kalev: I think actually, my first idea would be to get codecs built as Fedora runtime flatpak extension in Flathub. 14:55:11 kalev, I'm definitly open to that idea, I still need to figure out what's needed on the infra side 14:55:46 (and I also need dedicated time) 14:55:47 kwizart: but also would be wiling to work with rpmfusion :-) ... just the infrastructure is mostly there on flathub already. Though it's less fedora-like. 14:56:11 otaylor: ahh, building them in flathub makes sense, yes 14:56:15 Anyway I don't see cschalle here actually... I'd like to know what our status is on MP4. Seems like fdk-aac is still awaiting review. Not sure about OpenH264 14:57:05 there's a first step of defining how codec runtime extensions work, and figuring out how to make the installation up to Bastien's standards (maybe just one huge extension that fixes everything instead of trying to go codec-by-codec) 14:57:58 I guess we need to figure out something on gnome-software side too to somehow automate this 14:58:06 I think the whole thing is ~a month of work, it's not trivial, but something we need to invest in from my perspective 14:59:24 we are running out of time here so let's wrap up the meeting 14:59:44 kalev: Yep ... thanks for running the meeting! 14:59:49 np! thanks for coming everyone 14:59:59 I'll send out the meeting minutes in a bit 15:00:05 #endmeeting