13:01:23 <mcatanzaro> #startmeeting Workstation WG
13:01:24 <zodbot> Meeting started Mon Aug 19 13:01:23 2019 UTC.
13:01:24 <zodbot> This meeting is logged and archived in a public location.
13:01:24 <zodbot> The chair is mcatanzaro. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:01:24 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
13:01:24 <zodbot> The meeting name has been set to 'workstation_wg'
13:01:30 <mcatanzaro> #meetingname workstation
13:01:30 <zodbot> The meeting name has been set to 'workstation'
13:01:36 <mcatanzaro> #topic Roll call
13:01:38 <mcatanzaro> .hello catanzaro
13:01:39 <zodbot> mcatanzaro: catanzaro 'Michael Catanzaro' <mcatanzaro@gnome.org>
13:01:44 <cmurf> .hello chrismurphy
13:01:45 <zodbot> cmurf: chrismurphy 'Chris Murphy' <bugzilla@colorremedies.com>
13:02:08 <aday> i'm not sure this is going to work, but let's try
13:02:12 <aday> .hello aday
13:02:13 <zodbot> aday: aday 'None' <aday@redhat.com>
13:02:26 <aday> wat
13:02:54 <cmurf> maybe hello2
13:03:03 <aday> .hello2 aday
13:03:04 <zodbot> aday: aday 'None' <aday@redhat.com>
13:03:10 <cmurf> haha ok
13:03:16 <aday> :D
13:03:28 <aday> FAS *does* know my name
13:04:26 <cmurf> I wish FAS would do aliases
13:04:31 <cmurf> .hello cmurf
13:04:33 <zodbot> cmurf: Sorry, but you don't exist
13:06:16 <mcatanzaro> So Owen and Langdon are off today
13:06:32 <mcatanzaro> That leaves four missing
13:07:11 <mcatanzaro> cschalle, juph[m] ^
13:07:24 * cschalle hi
13:07:57 <mcatanzaro> No kalev or mclasen on GIMPNet
13:09:04 <cschalle> mclasen is out travelling
13:09:16 <cmurf> well let's move on, if there's something we actually need to vote on we can do it in the ticket
13:09:56 <mcatanzaro> Nobody ever votes in the ticket :P but yes, we rarely have formal votes anyway
13:10:43 <mcatanzaro> #info Four WG members in attendance, two regrets, four missing. Quorum is six.
13:10:56 <mcatanzaro> #topic Automatically install the OpenH264 codecs
13:11:12 <mcatanzaro> So there are only two topics tagged with meeting and I don't think there's too much to discuss, maybe we can finish early today
13:11:34 <mcatanzaro> For OpenH264 I'd just request an update from cschalle as to status, I understand it was stalled on releng as of our last meeting
13:12:00 <mcatanzaro> #undo
13:12:00 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x7f6d461d6d50>
13:12:02 <mcatanzaro> #undo
13:12:02 <zodbot> Removing item from minutes: INFO by mcatanzaro at 13:10:43 : Four WG members in attendance, two regrets, four missing. Quorum is six.
13:12:04 <mcatanzaro> #topic Automatically install the OpenH264 codecs
13:12:13 <mcatanzaro> (I think I counted wrong :)
13:12:35 <cschalle> I am actually not sure about the status, have been our travelling so no chance to check in, but I will see if I can get some answers this week
13:12:59 <mcatanzaro> OK, sounds good. Can you provide an update in the ticket, then?
13:13:04 <cschalle> will do
13:13:26 <mcatanzaro> Moving on, last topic
13:13:33 <mcatanzaro> #topic LUKS by default
13:13:49 <mcatanzaro> cmurf: I know it's only been two weeks, but any update here? Got a subgroup formed, perhaps?
13:14:42 <Son_Goku> .hello ngompa
13:14:42 <cmurf> I have a draft email for desktop@ and I'll mention it on #fedora-workstation
13:14:44 <zodbot> Son_Goku: ngompa 'Neal Gompa' <ngompa13@gmail.com>
13:14:48 <Son_Goku> sorry folks, I went into the wrong channel ;P
13:14:51 <cmurf> haha
13:15:14 <Son_Goku> went into f-m-1 instead of f-m-2 :O
13:15:24 <cmurf> Any recommended/preferred service for a phone call?
13:15:37 <Son_Goku> Bluejeans or Zoom works for me
13:15:43 <cmurf> I figure we can use #fedora-workstation to do the initial organization, discussion, and then get a lot done in a 30 minute call
13:16:03 <Son_Goku> I do a lot of Bluejeans for Koji, DNF, OpenShift, and other community meetings
13:16:21 <Son_Goku> but I'm set up for Zoom as well because of $DAYJOB
13:16:51 <cmurf> I used Bluejeans maybe a year ago, but I can get that setup again.
13:17:01 * cmurf wonders if there's a flatpak
13:17:06 <aday> there is!
13:17:14 <cmurf> that's badass
13:17:17 <Son_Goku> cmurf, Bluejeans also works entirely from the web
13:17:26 <Son_Goku> I use it through Firefox or Chrome as-is
13:17:36 * aday has found that the flatpak works better than bluejeans in the browser
13:17:37 <cmurf> ahh soo
13:17:39 <Son_Goku> Zoom requires an app locally, iirc, there's no flatpak
13:17:57 <aday> cmurf: we can use my account if needed
13:18:04 <Son_Goku> though funnily enough, Zoom supports Wayland *only* through gnome
13:18:14 <Son_Goku> for screencasting
13:18:25 <cmurf> OK I'l finish the email, send it out, we'll discuss details on #fedora-workstation to setup the voice meeting date/time and agenda
13:19:25 <cmurf> #action cmurf to poke himself to wrap up his encryption subgroup kickoff invite and send it this week
13:21:41 <cmurf> what's next?
13:21:49 <Son_Goku> did we talk about oh264 yet?
13:21:59 <mcatanzaro> We did, cschalle said he'd provide an update in the ticket
13:22:04 <mcatanzaro> That's all on the agenda, but we can move on to responsiveness if you want
13:22:04 <Son_Goku> okay cool
13:22:33 <mcatanzaro> Oh I forgot to chair y'all
13:22:39 <mcatanzaro> #chair Son_Goku cmurf aday cschalle
13:22:39 <zodbot> Current chairs: Son_Goku aday cmurf cschalle mcatanzaro
13:24:07 <mcatanzaro> #info We are one member short of quorum with two regrets and three missing. Please make an effort to attend the meetings or send regrets!
13:24:37 <Son_Goku> regrets?
13:25:06 <mcatanzaro> Say in advance you won't make it
13:25:34 <Son_Goku> ah
13:25:35 <mcatanzaro> Anyway, cmurf unless you want to continue with another topic (e.g. responsiveness) I think we can wrap up the meeting here
13:25:51 <cmurf> #topic Better interactivity in low-memory situations
13:25:56 <cmurf> #link https://pagure.io/fedora-workstation/issue/98
13:26:23 <cmurf> I think we have had good conversations on devel@ but need to zero in on some solutions. It's a difficult problem.
13:26:39 <cmurf> Most of the solutions are work arounds, that may work in some cases and not others.
13:26:59 <mcatanzaro> Yeah, I understand any proper solution is really going to depend on cgroups like Owen suggested, do you agree?
13:27:54 <cmurf> I don't know enough about it honestly.
13:28:18 <cmurf> The question mark in my mind with containing the example so far is that it will try to bust out, and will fail.
13:28:29 <cmurf> At least the system isn't taken down. But the command still fails.
13:29:15 <mcatanzaro> Failure is better than the status quo though
13:29:47 <mcatanzaro> Other suggestions: enable zram (sounds like we should do this with SOME uncertain amount of zram), enable earlyoom userspace daemon to kill things faster
13:29:55 <cmurf> Yes. I was considering wading into the related lkml thread and pointing out this slightly different example case than what was presented there.
13:30:19 <mcatanzaro> I notice hadess has just posted in https://bugzilla.redhat.com/show_bug.cgi?id=1731978#c17 "zram is enabled by default on F31, correct?" but I think we only have it enabled for the live session, right?
13:30:36 <cmurf> There are three zram implementations :-D
13:30:46 <mcatanzaro> FWIW I think presenting this example to LKML would be a great idea
13:30:50 <cmurf> anaconda is enabled by default on live and netinstalls now
13:31:26 <cmurf> it conflicts with the zram package by pbrobinson which is why the change to enable it by default on installed systems was reverted
13:31:33 <cmurf> it's non-fatal conflict but ugly
13:31:59 <cmurf> and then there's the ideal proposal of getting the upstream systemd zram generator to work, and all parties to agree to use that
13:32:41 <mcatanzaro> Hm OK
13:32:42 <cmurf> so zram isn't enabled on Fedora 31 by default, and yes that's still something I'm going to coordinate
13:32:43 <mcatanzaro> The exact example we present to LKML doesn't matter so much, what matters is that our example reliably exhaust RAM on plausible desktop systems.
13:33:28 <cmurf> What do people think about the encryption subgroup coming up with a recommendation for: encryption+partitioning+swap?
13:33:36 <cmurf> there are several issues that all interrelate
13:34:27 <cmurf> mcatanzaro: sure and I have no problem with concurrent action on this problem
13:34:40 <cmurf> so i'll leap into the lkml fire, why not?
13:35:40 <cmurf> OK I'll present the combination of issues in the encryption invite email and see where that goes
13:35:57 <aday> cmurf: makes sense, but we might need to enlarge the group and it obviously grows the scale of the task
13:37:03 <cmurf> aday: it's a possible risk, we can make the primary task one of encryption, and the others are more incidental
13:37:23 <mcatanzaro> I guess they are all interrelated indeed
13:38:04 <cmurf> ok so I found this tasklist (that's become a bit stale)
13:38:06 <cmurf> https://fedoraproject.org/wiki/Workstation/Tasklist
13:38:14 <cmurf> but in that list are two items related to this topic
13:38:21 <cmurf> Prefer D-Bus activation in gnome-session
13:38:23 <cmurf> Move apps to desktop file name == bus id
13:38:51 <cmurf> both mention systemd user sessions for isolation, which is explicitly mentioned by Lennart in the devel@ thread as recommended way of containing programs
13:40:34 <cmurf> there's also a concept of a post-install (re)configuration of swap based on use cases, rather than a one size fits all in the installer
13:41:07 <cmurf> and Lennart mentions that in the devel@ thread as well, in that a systemd unit could use a small swap normally, and then switch to an additional bigger swap right before hibernation
13:41:58 <cmurf> anyway I don't wanna hog our time here with tons of details, but this problem really is a details problem
13:42:05 <cmurf> so that's the update I've got for now
13:43:17 <mcatanzaro> #topic Open floor
13:43:41 <mcatanzaro> #action cmurf to schedule encryption/partitioning/responsiveness subgroup meeting
13:43:49 <mcatanzaro> #undo
13:43:49 <zodbot> Removing item from minutes: ACTION by mcatanzaro at 13:43:41 : cmurf to schedule encryption/partitioning/responsiveness subgroup meeting
13:43:51 <mcatanzaro> #undo
13:43:51 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x7f6d44e3a810>
13:43:55 <mcatanzaro> #action cmurf to schedule encryption/partitioning/responsiveness subgroup meeting
13:43:58 <mcatanzaro> #topic Open floor
13:44:05 <cmurf> i've got two :D but want others to go first since I've got 50 lines above staring at me
13:45:32 <cmurf> quickly: bunch of work by various people: anaconda, dracut, squashfs, (soon hopefully) releng, to improve Fedora images by switching from xz to zstd; and device-mapper overlay, to overlayfs based overlays
13:45:36 <cmurf> #link https://pagure.io/releng/issue/8581
13:45:38 <cmurf> #link https://pagure.io/releng/issue/8646
13:46:28 <cmurf> testing so far cuts the /dev/loop1 CPU consumption during installs from ~80-100% to less than 10%
13:46:40 <cmurf> installs are ~20% faster
13:46:50 <cmurf> Lives are more responsive
13:47:25 <Son_Goku> cmurf, could you help with getting things in place for l-c-d-t, including i-l-t-m?
13:47:52 <Son_Goku> s/i-l-t-m/l-i-t-m/
13:48:17 <mcatanzaro> Son_Goku: aoeu asdf yabba-dabba-doo?
13:48:43 <Son_Goku> livecd-tools / livecd-iso-to-mediums
13:48:45 <cmurf> yep I filed a ticket with livecd-tools about it and i'll help  with that
13:48:49 <Son_Goku> thanks
13:49:22 <Son_Goku> this should also bring us in alignment with openSUSE and Mageia, both of which use squashfs+overlay schemes
13:49:30 <cmurf> right
13:49:35 <Son_Goku> (though interestingly, both are somewhat different than the standard one in dracut)
13:49:45 <cmurf> sad panda
13:49:59 <Son_Goku> both of them predate dracut's upstream support, contributed by Sugar a few years ago
13:50:07 <cmurf> gotcha that makes sense
13:50:26 <Son_Goku> we should take a look to see if there's anything worth borrowing from their implementations too
13:50:39 <Son_Goku> I know that Mageia's has the neat feature that changes persist to the final installation on disk
13:51:04 <Son_Goku> which would be awesome to have in Fedora
13:51:10 <cmurf> they may be copying from the merged upper and lower dirs, rather than the base dir
13:51:26 <Son_Goku> perhaps, I haven't had a chance to dig into it much (despite being dracut maintainer there...)
13:51:47 <cmurf> i'll download a copy and look at it
13:52:09 <Son_Goku> there's some interesting properties of openSUSE's version, which you can experiment with by producing media using kiwi on Fedora
13:52:27 <Son_Goku> but kiwi also supports producing media with upstream dracut's squash+overlay feature
13:52:47 <cmurf> i've only ever used opensuse media in a VM
13:53:15 <cmurf> so i'll give that a shot also and see how it sets up the live environment
13:53:22 <Son_Goku> cool
13:53:28 <Son_Goku> I'd like us to have the best of both in our implementation :D
13:53:30 <cmurf> using the stuff already in dracut, this really does just work out of the box
13:53:43 <Son_Goku> yeah, and livecd-tools has supported it for a while
13:53:51 <cmurf> there's two little changes in anaconda to point to the new source location, and then it just works
13:54:43 <cmurf> curiously the zstd compressed squashfs is 5% bigger, even at level 22 compression, compared to xz
13:55:00 <Son_Goku> yeah, it would be
13:55:02 <cmurf> but it's way way way faster to decompress on the consumer size
13:55:04 <cmurf> side
13:55:05 <Son_Goku> different style of compression
13:55:31 <cmurf> there might be some optimizations possible, like maybe a 512K block size
13:55:32 <Son_Goku> it'd probably help slightly if we got the initramfs to also be zstd compressed
13:55:47 <cmurf> that's true, it's huge
13:55:52 <Son_Goku> OpenMandriva is doing this already, if I remember correctly
13:56:07 <Son_Goku> they've also got kmods compressing with zstd
13:56:35 <cmurf> yep
13:56:52 <cmurf> the decompression speed is a big bang for the bug times 1000s of users
13:57:01 <cmurf> s/bug/buck
13:57:23 <Son_Goku> yes
13:57:35 <mcatanzaro> OK well, short on time
13:57:53 <cmurf> we do have to be careful of level 22, because it requires more memory for decompression
13:58:06 <Son_Goku> I think zstd level 19 is probably fine
13:58:09 <cmurf> so i'm sensitive to affected IoT, and ARM, etc.
13:58:14 <Son_Goku> that's what we're using for rpm and zchunk
13:58:33 <cmurf> Facebook has a variant using squashfs called XAR for selfexecuting archives, and they're using level 16
13:58:47 <cmurf> yeah 19 might be where we need to leave it
13:58:57 <cmurf> there's a big leap in resources for 20+
13:59:01 <Son_Goku> yep
13:59:38 <cmurf> so maybe experiment with 512K block size, for an installation that's perhaps not a big risk because most every block needs to be decompressed
14:00:16 <cmurf> anyway i'm done
14:00:22 <cmurf> andhogged all the time anyway
14:00:32 <mcatanzaro> That's OK, the time is there to be used
14:00:36 <mcatanzaro> Thanks everyone!
14:00:40 <mcatanzaro> #endmeeting