13:01:14 <mclasen> #startmeeting Workstation WG 13:01:14 <zodbot> Meeting started Mon Jul 16 13:01:14 2018 UTC. 13:01:14 <zodbot> This meeting is logged and archived in a public location. 13:01:14 <zodbot> The chair is mclasen. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:01:14 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 13:01:14 <zodbot> The meeting name has been set to 'workstation_wg' 13:01:24 <mclasen> #meetingname workstation 13:01:24 <zodbot> The meeting name has been set to 'workstation' 13:01:32 <mclasen> #topic Roll call 13:01:42 <stickster> .hello pfrields 13:01:43 <zodbot> stickster: pfrields 'Paul W. Frields' <stickster@gmail.com> 13:01:47 <mclasen> #chair stickster 13:01:47 <zodbot> Current chairs: mclasen stickster 13:01:56 <ryanlerch> .hello ryanlerch 13:01:57 <zodbot> ryanlerch: ryanlerch 'Ryan Lerch' <rlerch@redhat.com> 13:02:02 <mclasen> #chair ryanlerch 13:02:02 <zodbot> Current chairs: mclasen ryanlerch stickster 13:02:02 <juhp> .hello petersen 13:02:03 <zodbot> juhp: petersen 'Jens Petersen' <petersen@redhat.com> 13:02:12 <mclasen> #chair juhp 13:02:12 <zodbot> Current chairs: juhp mclasen ryanlerch stickster 13:02:14 <ryanlerch> evening all! 13:02:51 <aday> o/ 13:03:21 <mclasen> hey, aday 13:03:32 <mclasen> waiting for cschaller to join 13:04:01 * cschalle_ hi 13:04:38 <mclasen> #chair cschalle_ 13:04:38 <zodbot> Current chairs: cschalle_ juhp mclasen ryanlerch stickster 13:05:11 <mclasen> missing owen and kalev, but I think we should get going 13:05:29 <juhp> and Michael 13:05:35 <mclasen> true 13:06:09 <mclasen> I pinged him 13:06:11 <juhp> Maybe everyone not back from GUADEC yet 13:06:17 <stickster> Could be 13:06:24 <mclasen> lets collect an agenda in the meantime 13:06:46 <mclasen> I don't have any tickets marked for meeting, but we can follow up on some anyway 13:07:03 <mclasen> any items to add to the agenda ? 13:07:47 <cschalle_> not from me 13:07:53 * otaylor is here now - sorry to be late 13:07:55 * stickster wondering how things look for talks for Workstation at Flock 13:08:01 <mclasen> #chair otaylor 13:08:01 <zodbot> Current chairs: cschalle_ juhp mclasen otaylor ryanlerch stickster 13:08:17 <mclasen> ok, lets start with that 13:08:26 <mclasen> #topic flock planning 13:08:58 <mclasen> I haven't submitted a talk, but I was looking to be in Dresden wed+thu 13:09:10 <mcatanzaro> .hello catanzaro 13:09:11 <zodbot> mcatanzaro: catanzaro 'Michael Catanzaro' <mcatanzaro@gnome.org> 13:09:15 <mclasen> I know we have an atomic workstation talk submitted 13:09:21 <mclasen> #chair mcatanzaro 13:09:21 <zodbot> Current chairs: cschalle_ juhp mcatanzaro mclasen otaylor ryanlerch stickster 13:09:37 * stickster will be there for the whole shebang 13:09:39 <mclasen> otaylor: you still plan to be at flock ? 13:09:55 <otaylor> the fedora+flatpak hackfest was accepted 13:10:02 <otaylor> yes, I'll be the whole time 13:10:22 <juhp> (Not exactly core workstation), but we have an half-day i18n workshop or hackfest rather planned (devel + QA) 13:10:36 <mclasen> hughsie is also going to be there, afaik 13:11:11 <mclasen> otaylor: there was some talk of a flatpak hackfest - is that still on ? 13:11:20 <mcatanzaro> juhp: I heard Canonical is working on language pack support for g-i-s (or g-c-c?) by the way... would be good to coordinate that stuff with them. 13:11:40 <otaylor> mclasen: Yes 13:11:42 * stickster wonders how "wide" the hackfest schedule is, i.e. will it be typical "6-8 things going at once" or something else 13:11:47 <juhp> mcatanzaro: oh really that's interesting - do you have a contact person? 13:11:57 <juhp> s/have/know 13:11:58 <stickster> I don't expect anyone has an answer to ^^ , that's fine. 13:12:11 <mcatanzaro> juhp: I don't know who is working on it, but try Robert Ancell 13:12:23 <juhp> mcatanzaro: thanks 13:13:15 <stickster> juhp: otaylor: Have you advertised those hackfests through e.g. Fedora planet + other venues? 13:13:19 <mclasen> does anybody have a workstation talk submitted ? I think I'm expected to give a 20 minute update somewhere 13:13:41 <otaylor> mclasen: Looks like jiri submitted a "state of the workstation" that was accepted 13:13:47 <otaylor> https://pagure.io/flock/issue/56 13:13:54 <juhp> I think there are supposed to be Edition talks on the first day? 13:14:05 <mclasen> ah, cool 13:14:10 <otaylor> There's also a silverblue talk from misc - https://pagure.io/flock/issue/59 13:14:21 <mclasen> right, thats the one I meant earlier 13:14:58 <mclasen> stickster: I guess that answers your question ? 13:15:05 <stickster> It does! 13:15:40 <juhp> stickster: not yet 13:15:57 <stickster> #action otaylor juhp publicize your hackfests using the Fedora Planet, also feel free to ping me when you blog and I can help cover in e.g. Twitter 13:16:04 <mclasen> #info we have a silverblue talk, a workstation talk, a flatpak hackfest and an i18n workshop at flock 13:16:21 <juhp> stickster++ 13:16:22 <juhp> thanks 13:16:24 <mclasen> looking at open tickets now 13:16:25 <stickster> #action stickster help folks publicize via Twitter 13:16:55 <stickster> the sooner the better since we're down to the wire for people to make plans to attend if they haven't already 13:16:56 <mclasen> #topic issue 63: disable libvirtd daemon 13:17:27 <mclasen> https://pagure.io/fedora-workstation/issue/63 13:18:29 <mclasen> it has been suggested that we disable system libvirtd, since it is not used by apps in the default install 13:18:47 <mclasen> and the use case for having it on is "run vms at boot", which doesn't strike me as relevant for workstation 13:19:26 <mcatanzaro> +1 disable, anything using it should learn to start it on demand 13:19:29 <stickster> What about i.e. vagrant boxes? 13:19:32 <otaylor> Well, that was an argument againstautostarting it upstream 13:19:46 <mcatanzaro> What is vagrant and why is it useful for workstation? :D 13:19:59 <otaylor> stickster: vagrant-libvirt would be adversly affected, but I had a lot of trouble using vagrant-libvirt 13:20:34 <otaylor> If you run it against the system daemon, your user files aren't accessible to it without extensive selinux/permissions wrangling, and then it doesn't really work well with the user one either. 13:20:35 <stickster> Vagrant's a popular system for getting and managing virtual guests running systems/containers you want to develop on 13:20:59 <otaylor> Everybody actually seems to use vagrant-virtualbox 13:21:09 <mclasen> from what owen says, it sounds like we fail to make it work well on fedora, though 13:21:25 <stickster> otaylor: Hm, interesting -- I haven't used vagrant extensively, but I had no problems at least getting it started and using it to do some testing and limited stuff 13:21:38 <stickster> and that was with libvirt backend. 13:22:07 <stickster> otaylor: are you talking about user files on the host being available to the guest? 13:22:09 <juhp> How about virt-manager? 13:22:24 <otaylor> stickster: maybe it improved? Maybe you were following fedora-centered instructions? Don't know. My experience wasn't positiv. 13:23:08 <ryanlerch> a lot of the fedora web apps have vragrant-libvirt dev setups, fwiw 13:23:11 <otaylor> And I do think that containers (typically with docker-compose) are much better for the typical vagrant use case. VM's are for when you need an entire operating system 13:23:31 <stickster> otaylor: I wasn't doing anything crazy. I installed the standard 'dnf install vagrant', the libvirt provider was installed automatically, and I ran 'vagrant up' to run a box. 13:23:37 <juhp> Okay virt-manager was discussed more in the ticket 13:23:52 <otaylor> Anyways ... socket activation would work for both vagrant and virt-manager 13:24:11 <mclasen> but... libvirtd doesn't support socket activation, from what dan says ? 13:24:13 <otaylor> So do we push on berrange on that? Or just try to get good error messages out of vagrant and virt-manager? 13:25:03 <juhp> I think virt-manager would already give an error message - so suppose need to test to be sure 13:25:06 <otaylor> mclasen: It doesn't do socket activation because of the server use case. But it could be made configurable, presumably. 13:25:12 <ryanlerch> it may be obviousto most here, but what is te reasoning to disabling it by default? 13:25:19 * stickster locates https://bugzilla.redhat.com/show_bug.cgi?id=1326136 13:25:25 <ryanlerch> what is the benefit here to the user? 13:25:26 <otaylor> ryanlerch: not have a process running on all workstations that most people don't use 13:26:20 <ryanlerch> otaylor: okies, thanks! 13:26:28 <ryanlerch> boxes uses libvirt too, right? 13:26:47 <mclasen> boxes uses the session libvirt 13:26:51 <otaylor> ryanlerch: see ticket. 13:27:10 <otaylor> Is session libvirt socket activated? I don't see it on my running on my system. 13:27:13 <stickster> mclasen: how does session libvirt networking support compare with the systemwide libvirt? 13:27:45 <otaylor> stickster: slow 13:27:50 <stickster> oof 13:28:21 <mclasen> stickster: thats not the point, really 13:28:28 <otaylor> stickster: it mostly hurts if you are trying to use nfs mounts from a vm or something like that ... it's probably not slower than your internet connection 13:29:32 <mcatanzaro> Why is Boxes using the Slow version? :D 13:30:10 <mcatanzaro> And what is the advantage of vagrant over Boxes? There's probably a problem if we are recommending that developers use virtualization software other than the one that we ship with.... 13:30:10 <otaylor> (For data, RES-SHARE for libvirtd is about 9 megabytes) 13:30:31 <stickster> mcatanzaro: it's not that the recommendation is different, it's that the world is using what it's using ;-) 13:30:45 <otaylor> mcatanzaro: Boxes is using the slow version, because it allows users to configure vms' without equivalent-to-root permissions 13:31:17 <otaylor> mcatanzaro: vagrant is very different from boxes - boxes is for interactively using a graphical OS, vagrant is for doing server-y stuff from the command line in a semi-automated fashion 13:31:43 <otaylor> It would be *nice* if they worked together - much better experience, but since one is using system-libvirt and one is using user-libvirt, they don't 13:32:58 <otaylor> But really, classic vm's are not where we are pushing development effort. Not worth a lot of effort on that IMO. 13:33:35 <juhp> Does FAW include boxes? 13:33:48 <mclasen> ok, so. whats the outcome here ? should we vote on disabling system libvirt ? 13:34:48 <otaylor> Error from virt-manager is "Virtual Machine Manager Connection Failure" "Unable to connect to libvirt" "Verify that the libvirtd daemon is running" 13:35:07 * stickster is not sure about this one. I'm generally in favor of slimming things down. At the same time I don't want to annoy developers by making it hard for them to use poular tools. That seems like the opposite of what we've been doing. 13:35:53 * juhp tries installing virt-manager in rawhide guest 13:36:01 <otaylor> Error from vagrant is 13:36:04 <otaylor> Bringing machine 'default' up with 'libvirt' provider... 13:36:06 <otaylor> Error while connecting to libvirt: Error making a connection to libvirt URI qemu:///system?no_verify=1&keyfile=/home/otaylor/.ssh/id_rsa: 13:36:08 <otaylor> Call to virConnectOpen failed: Failed to connect socket to '/var/run/libvirt/libvirt-sock': No such file or directory 13:36:16 <ryanlerch> is virt-manager installed by default? is it possible to enable it if virt-manager or vagrant-libvirt are installed? 13:36:21 * mclasen is annoyed at server software running on his workstation 'just because' 13:36:44 <mclasen> libvirt should be socket activatable. I think we should push for that 13:36:46 <otaylor> ryanlerch: libvirt-user and libvirt-system are the same package, if I understand correctly 13:37:08 <otaylor> mclasen: That sounds right to me. At least we should be able to configure it that was by default for the workstation 13:37:19 <juhp> ryanlerch: : no it is not 13:37:39 <juhp> (installed by default) 13:37:49 <mclasen> #action mclasen will follow up with dberrange to ask for socket-activation option for system libvirtd 13:38:03 <stickster> mclasen: Check out that bug I linked above. It hints why the socket activation problem is a difficult one 13:39:36 <mclasen> anything else on this one ? otherwise, I'll move on 13:39:55 <stickster> maybe we just need smarter logic forautostart 13:40:06 <mclasen> #topic issue 61 - package feral gpu governor 13:40:12 <mclasen> https://pagure.io/fedora-workstation/issue/61 13:40:37 <stickster> Are these like cats, where if we feed the GPU governor, it's going to just keep coming around and spawning more? 13:41:06 * otaylor wonders if you have that installed, whether you need a transparent acrylic window on your system and mood lighting 13:41:42 <cschalle_> Christian Kellner has done the initial packaging now of feral gpu governor 13:42:21 <mclasen> did we get the package added to comps ? 13:42:27 <otaylor> note that the package and upstream is called "gamemode" as far as I can tell, so "feral gpu governer" is a bit confusing 13:42:36 <otaylor> and "cpu governer" ? 13:43:15 * mclasen just reading from the ticket 13:43:40 <stickster> So basically this thing just exists to allow your game to request the better governor state while it runs, and restore it to normal when you're done. 13:43:40 <cschalle_> I don't think the ticket mispells governor 13:43:49 <mclasen> any volunteer to add this to comps ? normally I would look at kalev for this 13:44:01 <otaylor> cschalle_: no, the governor mispelling is mine, but it's a *cpu* governor 13:44:13 <cschalle_> otaylor, oops, sorry my mistake 13:44:35 <cschalle_> the title is wrong, but the text of the ticket is correct (regarding CPU cs GPU) 13:44:43 <otaylor> stickster: "better" in the sense that you get more fps, and need less heating in your house 13:45:11 <cschalle_> stickster, but yes that is basically what the tool does 13:45:26 <stickster> *nod 13:45:27 <juhp> otaylor: haha 13:45:29 <cschalle_> stickster, although both feral and valve has said they might add further functionality going forward 13:46:11 <mclasen> #info package for gamemode tool has been added to f28 and rawhide 13:46:27 <otaylor> stickster: while I think the functionality should likely be OS integrated, and I'm not happy with the idea that it's going to grow an "ecosystem" - talking to Prarit, there wasn't an obvious easy alternative, and it seemed to work in a fairly plausible way 13:47:08 <stickster> Yeah, it feels like there should be a generic system to request power hungry performance 13:47:18 <stickster> but in the meantime, this seems harmless enough 13:47:22 <otaylor> (it wasn't obvious that we could just fix our default cpu governer to make it work as fast) 13:47:28 <stickster> I mean, assuming folks are good with the code 13:48:02 <mclasen> stickster: it always looks harmless at first... 13:48:04 <stickster> ha 13:48:17 <stickster> Then someone feeds it after midnight o_O 13:48:21 <cschalle_> stickster, it is not actually about getting power hungry performance, games and a few other types of software are special in the sense that their power needs fluctuate a lot, so the cpu governor keeps scaling down and then you get delays as it scales up again when the game need peak performance 13:48:55 <cschalle_> stickster, if the power need was 'stable' then the default cpu governor would give you just as much power 13:49:13 <stickster> Yeah, I got the gist from the article you linked -- IOW this minimizes the wait, and avoids situations where the governor scales things down when there are too many requests 13:49:20 <cschalle_> stickster, for example a video transcode would not change its performance between the two governor modes as it runs full steam until finished 13:49:29 <mcatanzaro> Is this feral governor a workaround to a problem lower in the stack? 13:50:21 <cschalle_> mcatanzaro, only in the sense that coming up with perfect logic for the governor is almost impossible and while Intel is continously trying to tune they have so far not succeeded in solving this usecase 13:51:01 <mclasen> ok, no volunteer 13:51:02 <otaylor> mcatanzaro: Hard to say. It may be a workaround for not having an "I'm a game, and I'm running right now" api in a system service. It *could* be considered to be a workaround for not having a sophisticated service doing heuristics to guess if a game is running. I don't think changing the kernel governor is going to be successful 13:51:12 <mclasen> #action mclasen to find a volunteer for adding gamemode to comps 13:51:25 <mclasen> #undo 13:51:25 <zodbot> Removing item from minutes: ACTION by mclasen at 13:51:12 : mclasen to find a volunteer for adding gamemode to comps 13:51:27 <cschalle_> mclasen, thanks 13:51:37 <mclasen> #action cschalle_ to find a volunteer for adding gamemode to comps 13:51:41 <mclasen> your baby :-) 13:51:45 <juhp> Does it need to be in comps? :) 13:51:50 <cschalle_> mclasen, can I delegate the task to you? 13:52:01 <otaylor> mcatanzaro: proper system integration might allow doing things like only allowing the currently focused app to request gamemode, or turning it off if battery levels are getting low. 13:52:01 <mclasen> my post-guadec todo list is super-long 13:52:05 <mclasen> I can add it at the bottom 13:53:03 <cschalle_> while never having done it, I assume adding something to comps is trivial? like adding the package name to a file somewhere? 13:53:19 <mclasen> it mainly amounts to finding out where comps is currently hosted 13:53:23 <otaylor> cschalle_: It's finding the right module, and making a pull request aginst it 13:53:28 <mclasen> it has moved around a few times since I last touched it 13:53:34 <juhp> Yeah just a post-request to comps-fxx.xml.in 13:53:41 <stickster> cschalle_: Yes, the file is here: https://pagure.io/fedora-comps/blob/master/f/comps-f29.xml.in 13:54:09 <juhp> Where would it go? Is the proposal to install it by default? 13:54:25 <cschalle_> juhp, yes, install it for default for workstation 13:54:30 <juhp> I see 13:55:14 <mclasen> ok, 5 minutes left for one more quick followup 13:55:21 <mclasen> #topic issue 60 - wayland remoting 13:55:29 <mclasen> https://pagure.io/fedora-workstation/issue/60 13:55:30 * stickster lurks but has to jet for another meeting setup 13:55:43 <cschalle_> ok, I will add it to the Fedora Workstation product core list 13:55:47 <mclasen> thats another comps addition we need. not sure if kalev has done this one 13:56:02 <aday> is gamemode just used from the command line? 13:56:25 <otaylor> aday: No, it's automatically used via d-bus by games that know about it 13:56:36 <aday> ah, ok. carry on :) 13:57:41 <juhp> (s/post/pull) 13:58:36 <mclasen> ok, out of time for this week... 13:59:05 <mclasen> any last-minute item ? 14:00:06 <mclasen> #endmeeting