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