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