13:03:34 #startmeeting workstation 13:03:34 Meeting started Mon Sep 16 13:03:34 2019 UTC. 13:03:34 This meeting is logged and archived in a public location. 13:03:34 The chair is langdon. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:03:34 Useful Commands: #action #agreed #halp #info #idea #link #topic. 13:03:34 The meeting name has been set to 'workstation' 13:03:43 .hello chrismurphy 13:03:44 cmurf: chrismurphy 'Chris Murphy' 13:03:53 #topic rollcall 13:04:01 .hello ngompa 13:04:02 Son_Goku: ngompa 'Neal Gompa' 13:04:03 .hello mclasen 13:04:05 mclasen: mclasen 'Matthias Clasen' 13:04:05 .hello kalev 13:04:08 kalev: kalev 'Kalev Lember' 13:04:12 is that the right meeting name? i feel like it is wrong.. but it might be lack of coffee 13:04:14 .hello2 13:04:15 langdon: langdon 'Langdon White' 13:05:14 langdon: yep that's correct 13:05:18 cool 13:05:30 anyone else for rollcall? (me goes to dig up chair list) 13:05:50 * mclasen saw cschaller come in a minute ago 13:06:07 .hello petersen 13:06:08 petersen: petersen 'Jens Petersen' 13:06:12 * langdon likes having a meeting cheatsheet on the wiki page like we do in modularity :) 13:07:04 langdon: chair some people so we can volunteer others for action items 13:07:13 cmurf: in progress... 13:07:30 had to do editing 13:07:31 #chair mcatanzaro, mclasen, aday, Son_Goku, kalev, cmurf, petersen, cschaller, otaylor 13:07:31 Current chairs: Son_Goku aday cmurf cschaller kalev langdon mcatanzaro mclasen otaylor petersen 13:07:51 k.. moving to agenda 13:07:55 #topic agenda 13:08:04 anybody got agenda items? 13:08:40 Son_Goku: what was the outcome of the size q? should that be an agenda topic? 13:08:45 https://pagure.io/fedora-workstation/issues?status=Open&tags=meeting&close_status= 13:08:48 that'll work 13:08:50 oh.. ha #104 13:09:22 ok.. and an open floor.. 13:09:41 #info using https://pagure.io/fedora-workstation/issues?status=Open&tags=meeting&close_status= for today's agenda.. starting from oldest first then open floor 13:09:54 so, let's get started 13:09:57 .hello catanzaro 13:09:58 mcatanzaro: catanzaro 'Michael Catanzaro' 13:10:13 #topic "Replace Rhythmbox with GNOME Music in default install" https://pagure.io/fedora-workstation/issue/33 13:10:18 anyone care to comment? 13:10:53 * mclasen just had to install rhythmbox yesterday to play some oggs/mp4s that music refused to find 13:10:56 I would like aday's input here 13:11:29 he hasn't checked in.. anyone know his status? 13:11:34 If you don't like Music, at least remove Rhythmbox, it's worse than totem as a default video player 13:11:41 * Son_Goku shrugs 13:11:42 *music player 13:11:58 * cschalle_ hi 13:12:03 hey cschalle_ :) 13:12:09 * mclasen has generally no horse in 'default app' discussions 13:12:20 mclasen: me either, much :) 13:12:29 i like to play music... 13:12:39 Btw I was curious why SB iso is larger WS? 13:12:44 ok.. so let's table and punch it on the ML? 13:12:56 langdon: +1 13:12:58 petersen: SB? and is thta #104? 13:13:05 Just defer to the next meeting when aday is here 13:13:19 what mcatanzaro said 13:13:22 anything default must work, and pass basic functionality or it's a blocker per a release criterion 13:13:24 This would be for F32 btw.... 13:13:33 #info defering #33 until next meeting when aday will (hopefully) be here 13:13:41 ok.. moving on 13:13:44 I'm reasonably confident that music will be fine by F32, but meh 13:13:59 #topic "Automatically install the OpenH264 codecs" https://pagure.io/fedora-workstation/issue/84 13:14:20 oh dear, this 13:14:27 cmurf: lol 13:14:33 welp 13:14:38 this is a *fun* topic 13:14:40 I talked to cschalle about this during guadec and have two actionable proposals to help with this 13:14:57 oh? 13:15:10 kalev: \o/ 13:15:15 can they be added to the ticket? 13:15:27 yes, but let's discuss here first 13:15:37 ack 13:16:12 proposal 1: Workstation WG requests releng to change fedora-cisco-openh264 from enabled=0 to enabled=1 13:16:44 why would we want enabled=0 ? 13:16:49 otherwise I'm just gonna say +1 13:16:59 is there anything else in that repo? 13:17:04 it's not like it provides ffmpeg or anything 13:17:17 the only problem with it is that it provides the illusion that you can build Fedora packages using it 13:17:27 not sure, cschalle maybe remembers this. he was the one talking to fedora leadership to get openh264 enabled 13:17:27 (you can't, since openh264 packages are not available in the buildroot) 13:17:55 and aday has arrived 13:17:55 sorry i'm late 13:18:01 no worries :) 13:18:14 Son_Goku: can they be added to the build root? 13:18:28 langdon, I dunno 13:18:42 I vaguely recall there was some mumbo jumbo about not making it a dependency of packages in the main repo 13:18:45 * langdon fingers *cannot* decide if it is buildroot vs build root (although his brain decided on buildroot a while ago) 13:18:53 I don't know either 13:19:40 langdon, I believe all apps that can use it currently dlopen() it 13:19:45 OK, so the repo defaults to enabled=1, then...? 13:19:47 ok cool, I'm not hitting related bug 1749566 on a cleanly installed F31 Workstation 13:20:06 anyway, we can table voting on this if cschalle is not around 13:20:06 Software does ask me twice to enable 3rd party repo, but the plugin does install without error 13:20:14 We're still held up waiting for releng to build it in the first place, or...? 13:20:19 mcatanzaro: yes 13:20:21 cmurf: wants you to be really really sure! 13:20:24 do we need to vote on this ? 13:20:39 do we need to hear proposal-2? 13:20:40 This has been delayed several meetings already, I'd rather discuss today unless there's a controversy that really requires cschalle 13:20:47 mclasen: yes, I don't want to ask releng to change this without Workstation WG's weight behind this 13:20:57 +1 13:20:59 Really dumb question here but what does fedora-cisco-openh264 give us in terms of functionality exactly? 13:21:29 petersen: it gives a gstreamer codec for video playback for a lot of common video formats 13:21:35 err, let me rephrase 13:21:43 petersen: it gives a gstreamer codec for video playback for a very common video format 13:21:56 MP4 ;) 13:21:59 I think it means users can install "GStreamer Multimedia Codecs - H.264 without having to explicitly enable 3rd party repo 'fedora-cisco-open264' 13:22:01 yep :) 13:22:14 because it'd already be enabled 13:22:27 Hm okay 13:22:29 And in fact, users should be prompted to automatically install it by the gstreamer codec installer 13:22:44 kalev: What's proposal 2? 13:23:07 So if I download an mp4 I will be able to play it basically? 13:23:13 proposal 2: Install fedora-workstation-repositories by default in Workstation 13:24:04 kalev, wait, we _don't_ already do that? 13:24:15 Just asking since I don't have it installed... 13:24:17 as with the other proposal, cschalle knows best why we ended up _not_ shipping it by default originally. he seemed to think the original reasons no longer apply 13:24:21 Son_Goku: no 13:24:31 but that package doesn't even enable repos by default... 13:24:36 correct 13:24:40 cschalle: around to comment ? 13:24:49 petersen: you'll get GNOME Software offering to install GStreamer Multimedia Codecs - H264 for you 13:24:53 it won't already be installed 13:25:07 if it's possible to just install it on the media I'd prefer that but I'm guessing there's some licensing issue with that? 13:25:26 I think the license is fedora only? 13:25:52 ? 13:26:03 we can't ship it on media right now as I understand it. it has to come directly from cisco (we don't have license to redestribute the openh264 library) 13:26:11 gotcha 13:26:35 (sadly, this makes it much more difficult for fedora flatpak runtime) 13:27:03 the repo points at a fp.o url 13:27:09 OK well, both proposals seem uncontroversial to me 13:27:13 would be neat if there were a way to get it to install during the first batch of updates 13:27:18 but neither has the goal, right? 13:27:33 fedora-workstation-repos will be installed by all repos disabled, should be no reason for FESCo or anyone to object to this right? 13:27:35 langdon: yes, the fp.o url has the repo metadata. the actual .rpm is downloaded from cisco 13:27:45 kalev: ahh gotcha.. duh 13:27:47 mcatanzaro: that's a question to cschalle 13:27:57 cmurf: In theory it's not needed to install it automatically so long as the gstreamer codec installer works 13:28:01 the proposals just simplify the problem.. not actually install it.. is simplify sufficient? 13:28:04 mcatanzaro: in the past, that wasn't good enough for some 13:28:12 In practice, you've noticed there are some problems with PackageKit 13:28:21 ok i'm getting the request to install from Software, not some separate installer 13:28:37 And WebKit's use of the codec installer has been broken for several years (it's impossible to make it work correctly on the web for some reason) 13:29:04 let's move on to next topic and switch back to this one if/when cschalle joins 13:29:14 Well do we need to? Is there any controversy? 13:29:31 I'd say +1 to both proposals, and also ask kalev to make sure the codec installer works when playing MP4 video in totem 13:29:33 do you want to take a vote? like pref for 1 vs 2? 13:29:52 langdon: no, they are separate proposals. We'd need to do both. 13:30:21 +1 to both proposals 13:30:26 ohhh.. it did seem weird given the content of that rpm.. but figured i just missed something 13:30:31 is the second proposal related to codecs at all ? 13:30:52 I presume the codec installer won't work if the repo file is not installed 13:31:35 * langdon attempting to formalize 13:31:56 mclasen: it's related PyCharm, Google Chrome, Nvidia driver and Steam whos .repo files are in fedora-workstation-repos 13:32:03 we have a working AAC codec for high profile video now? 13:32:03 #info proposal to perform 2 changes to enable the codec 13:32:13 #info change 1: Workstation WG requests releng to change fedora-cisco-openh264 from enabled=0 to enabled=1 13:32:26 #info change 2: Install fedora-workstation-repositories by default in Workstation 13:32:52 I'll note again that these are completely separate proposals. one doesn't depend on the other 13:33:03 +1 to both still 13:33:07 +1 to both 13:33:09 and I'll also note that fedora-cisco-openh264 comes fedora-repos package 13:33:13 proposed #agreed the Workstation WG will pursue changes 1 & 2 as outlined above assuming kalev and cschalle prove they are technically feasible 13:33:24 +1 to both, as well 13:33:57 is that a good agreed? 13:34:06 i don't think i caught enough of the discussion to vote - i abstain 13:34:21 Alright - not sure why we are conflating these two things - sorry to grumble 13:34:29 maybe let's do separate votes, so you can do #agreed Workstation WG requests releng to change fedora-cisco-openh264 from enabled=0 to enabled=1 13:34:32 and so on 13:34:45 then are they not both required? 13:34:54 apparently not 13:34:56 no. they are completely separate 13:35:16 one is helping with codec install, other is helping with various 3rd party stuff install that we have in fedora-workstation-repositories 13:35:17 kalev: ha.. i meant to "meet the req of #84" 13:35:46 kalev: ok.. so the 2nd one is mostly not relevant to #84 ? 13:35:55 * kalev nods. 13:36:10 ok.. so how about this.. #proposal-2 moves to open floor 13:36:14 So we don't "have to" do both :-) 13:36:28 vote please: #agreed Workstation WG requests releng to change fedora-cisco-openh264 from enabled=0 to enabled=1 13:36:41 aday: i have you as 0 .. so u are good 13:36:49 +1 13:37:02 but anyone who was +1 .. need to confirm you are +1 w/ just the one change 13:37:29 +1 13:37:32 +1 (but I have a feeling we can't) 13:37:47 petersen: legally or technically? 13:37:51 legally 13:37:59 or Fedora legally :) 13:38:09 morally? dunno 13:38:14 so.. let's propose it and see what fesco says ? 13:38:18 okay 13:38:51 With my FESCo hat on: please ask fedora-legal *first*? 13:38:52 petersen: Surely it's been approved by legal already... I don't think cschalle would present it to us otherwise 13:39:06 They've been involved with this from step 1 13:39:11 Providing the text of that decision is also sufficient. 13:39:17 sgallagh: i am never sure of the order of operations on that sort of thing 13:39:34 (I want to make sure it doesn't read "the user must opt in" or anything like that) 13:39:46 Proposed action: cschalle to clarify that this proposal is already approved by Fedora Legal 13:39:48 langdon: I'm just saving you some time, since that's the first thing we'll ask 13:39:56 mcatanzaro: yeah I mean Fedora is pretty strict bicbw completely here 13:40:06 /s/that/if/ 13:40:49 ok.. so ill put that in the ticket (the bit about cschalle) but can i also put in the vote results? like can we still vote assuming it is legal? 13:41:19 yes that's reasonable 13:41:26 Other proposed action: kalev or cschalle to ensure the PackageKit GStreamer codec installer can propose and install OpenH.264 plugin when playing an MP4 video in totem 13:41:43 mcatanzaro: ill add that too 13:41:49 (Or come up with some other scheme to ensure it gets installed) 13:42:46 kalev: Is the fedora-cisco-openh264 repo file already installed by default? Or is that a separate action? (I had assumed it was part of fedora-workstation-repositories.) 13:43:06 mcatanzaro: it's installed by default. it's part of fedora-repos package 13:43:16 I filed https://pagure.io/fedora-workstation/issue/105 for proposal 2 13:43:34 I do not think it's installed by default... 13:43:56 it is 13:44:06 it is installed by default, but enabled=0 13:44:09 And that's based on the fact I just installed the H264 GStreamer thing in Software, and fedora-cisco-openh264.repo has a brand new inode number 13:44:13 that suggests it was just installed 13:44:22 or it was replaced *shrug* 13:44:25 gnome-software edited the file and changed it enabled=1 13:44:35 ok 13:45:12 cmurf: It's in the fedora-repos package, same package that provides the main and updates repos... I'd say we're good 13:45:29 root.20190915/etc/yum.repos.d/fedora-cisco-openh264.repo 13:45:30 confirmed 13:45:41 that root is from before the updates 13:45:43 yes 13:46:02 kalev: Any comment on the proposed PackageKit action item? Without that, it seems like only the first half of a plan to get the codec installed? 13:46:09 mcatanzaro: it should already be working ... 13:46:36 We should check, right? And cmurf left a comment in the ticket indicating there was some problem. 13:46:45 If it's already working then it should be an easy action item :) 13:46:48 * kalev looks. 13:47:01 yeah i just mentioned that problem isn't happening today, i'll update the bug 13:47:08 i feel like we should close this down.. we only have 14m left.. 13:47:31 well it's not happening on 31, not sure about 30 - i'll test that in a VM 13:47:43 and report in the bug and ticket 13:47:43 i have mcatanzaro +1, mclasen +1, aday +0, Son_Goku ??, kalev +1, cmurf +1, petersen +1, cschaller ??, otaylor ??, langdon +1 for : #agreed Workstation WG requests releng to change fedora-cisco-openh264 from enabled=0 to enabled=1 13:47:50 ack 13:47:53 +1 13:48:10 langdon: If we make progress on a big issue like this, it's a productive meeting IMO :) 13:48:18 * Son_Goku shrugs 13:48:27 we still can't depend on it from the main software suite 13:48:27 mcatanzaro: ha.. i agree.. and i think we did... but i think we are swirling now 13:48:37 but at least the gst plugin will be there 13:48:38 Should we vote on proposal 2? 13:48:43 Son_Goku: like depend that it is there? 13:48:49 petersen: if we switch topics 13:48:57 ah sorry 13:49:01 langdon, we can't use openh264-devel from normal packages 13:49:17 #agreed Workstation WG requests releng to change fedora-cisco-openh264 from enabled=0 to enabled=1 [+7] 13:49:33 so then we shouldn't enable it globally? 13:49:48 #topic "Ship fedora-workstation-repositories on install media" https://pagure.io/fedora-workstation/issue/105 13:49:51 Son_Goku: It's intended to be used via GStreamer, or dlopened by Firefox, so I see no problems. 13:49:58 * Son_Goku shrugs 13:50:07 ah can't okay 13:50:10 , 13:50:24 mcatanzaro, it'd be nice if things like freerdp could use it, but oh well 13:50:30 Ship fedora-workstation-repositories on install media... are there any practical consequences of this? If gnome-software installs the repos on-demand, it's not really needed, is it? Or would this cause gnome-software to display proprietary software in search results without needing to select the opt-in first? 13:50:41 Sorry technically can't? 13:51:23 Son_Goku: I think that could be renegotiated, at least for non-installed-by-default packages 13:51:36 mcatanzaro: the way gnome-software installs fedora-workstation-repositories on demand is very awkward, making the user go through a bunch of steps to get the repos finally installed and enabled 13:51:44 what kalev said 13:51:55 mclasen, the lack of H264 support in freerdp makes remote desktop performance suck a lot 13:52:05 since the RDP protocol now uses it for efficient screencasting 13:52:14 mcatanzaro, the end result is the same, but getting there would be a lot simpler 13:52:36 Son_Goku: freerdp could also dlopen it, i guess. just a matter of writing the code 13:52:37 So this is to remove the "enable proprietary software repos" banner from gnome-software? I thought it was a simple yes/no banner? 13:52:45 mclasen, probably 13:52:46 mcatanzaro: yes 13:52:55 Son_Goku: please leave this discussion for another time, thanks 13:52:59 one fix at a time 13:53:08 mcatanzaro, but then it has to go off and install repos, rather than just enabling them 13:53:40 if we had fedora-workstation-repos on the install media, we could trivially do gnome-initial-setup integration that asks the user if they want to enable 3rd party repos 13:53:58 right now with the separate, not-installed-by-default package setup it's super tricky 13:54:44 i'm still a +1 to include fedora-workstation-repos on install media 13:54:44 Having the repos preinstalled seems like a reasonable request to Council... but getting rid of the banner seems like a big ask, Council would want to see us add another sort of warning before installing proprietary software (at least for the first time) 13:54:49 And that would require UI design 13:55:08 it really should be at g-i-s anyway 13:55:12 I very much doubt Council is going to let us just drop the banner without adding new UI to replace it 13:55:21 that way the nvidia driver can be enabled, installed, and configured immediately 13:55:34 i like the idea of doing it in g-i-s 13:55:40 mcatanzaro: there is already another UI that asks the user if they want to enable a preinstalled, but disabled repo 13:55:47 i didn't see a proposal to drop the banner. did i miss something? 13:55:50 mcatanzaro: we'd be just running through that code path 13:55:51 (if it were possible, I'd actually have it even earlier than that, but that involves Anaconda...) 13:56:05 nooo 13:56:11 I'll note that all repos that fedora-workstation-repos installs are enabled=0, so gnome-software always asks before enabling any of the repos 13:56:21 point and shoot installers please :D 13:56:22 aday: "So this is to remove the "enable proprietary software repos" banner from gnome-software? I thought it was a simple yes/no banner?" "kalev: yes" (a bit ambiguous "yes" though ;) 13:56:26 this proposal is removing one step in the process (installing fedora-workstation-repos) 13:56:30 mcatanzaro: +1 on the banner 13:56:31 cmurf, Anaconda could get a DOOM interface :P 13:56:33 mcatanzaro: yes 13:56:45 kalev: do we have the background as to *why* fedora-workstation-repos was asked to be installed on-demand ? 13:56:58 Son_Goku: lol 13:56:58 I wonder why this needs to be in g-i-s considering there is nothing we would preinstall from these repos, so your choice has zero impact before you get to gnome-software anyway 13:57:14 mcatanzaro, NVIDIA driver 13:57:18 otaylor_: it has proprietary repos in it i assume 13:57:37 we have 3m.. do we want to take any kind of vote on this? 13:57:45 My assumption is that Fedora wanted to make it clearly opt-in 13:57:48 otaylor_: I think some people felt that our default install should be 'pure' 13:57:49 langdon: Not with 3m left 13:57:57 otaylor_: yes. it was discussed by fedora council and they requested it to be like that. cschalle knows the details (but he's not here right now) 13:58:13 kalev: so we'd need to ask the council again? 13:58:23 otaylor_: that's a question to cschalle 13:58:24 If the goal is to install NVIDIA driver, that sounds like a good goal, but I don't take that from this proposal 13:58:32 kalev: seems like he needs to be here for this discussion 13:58:34 sorry, I assumed he'd be here, otherwise I wouldn't have brought this up 13:58:37 yes 13:58:39 otaylor_, kalev : yes, i think we need a more definitive answer on this 13:58:45 If the goal is to move this to g-i-s but not install anything when enabled, I'm skeptical. Seems like that's the current goal. 13:58:56 I've been going on here for a while saying that we should table this until cschalle is around, but other people wanted to vote :) 13:58:59 If the goal is just to reduce the work gnome-software has to do, so it only needs to enable repos already there, +1 from me 13:59:18 Repository files that make some select non-Fedora software available 13:59:20 mcatanzaro: the goal is both 13:59:20 via search in gnome-software. 13:59:22 fedora-workstation-repositories-31-1.fc31.src.rpm 13:59:32 OK, let's continue discussion next meeting? 13:59:33 that's the literal rpm description for that rpm 13:59:49 mcatanzaro: +1 13:59:49 I don't understand why we'd want this in g-i-s if there are no packages we want to install at g-i-s time 13:59:51 yes, let's continue next time when cschalle is around 14:00:07 let's them show up in searches when the user does get to Software 14:00:19 IMO the broken g-i-s page should just be deleted :) 14:00:22 i am not clear why adding repos is so "expensive" that it seems like a barrier 14:00:37 langdon, lack of discoverability helps and hurts us 14:00:44 sure 14:00:50 ok.. let's close it down? 14:00:54 * kalev nods. 14:00:55 yep 14:00:58 Oh crap, wait 14:00:59 please add anythoughts to the ticket.. 14:01:00 I gotta get going anyway 14:01:01 We need to deal with https://pagure.io/fedora-workstation/issue/104 today 14:01:04 it is in the #topic 14:01:06 oh yeah 14:01:11 ugh 14:01:21 fun 14:01:22 proposal: bump size limit to 3 GB 14:01:27 langdon: I'm going to hijack you real quick 14:01:35 #topic Workstation live image is over size target 14:01:35 #topic Workstation x86_64 live image is over size target : https://pagure.io/fedora-workstation/issue/104 14:01:38 ha 14:01:41 #proposal Bump size limit to 3 GB 14:01:43 mine was better! 14:01:44 :) 14:01:48 #topic Workstation x86_64 live image is over size target : https://pagure.io/fedora-workstation/issue/104 14:01:57 Everyone +1 :) 14:01:59 +1 14:02:00 1 14:02:02 i think it makes no difference if it's 3GB or 4GB because there's no such thing as 3GB media 14:02:04 1 14:02:08 and +1 14:02:11 +1 (grr + button didn't work) 14:02:13 cmurf, makes a difference for persistence 14:02:18 no 14:02:21 +1 14:02:24 +1 14:02:27 FAT32 has 4GiB file limit :D 14:02:34 though really I would prefer smaller media 14:02:38 cmurf, yes, and 4GB sticks are a thing 14:02:41 and also the delimiter is the baked in ext4 size 14:02:44 cmurf: hah 14:03:09 has anybody looked at the growth ? 14:03:10 if we make the image 4GB, the literal most common SD card and USB stick size will not be able to do persistence at all 14:03:14 cmurf: And download speed... think of the people on a 1 Mbps connection, that's rocket speed compared to what we had access to in Greece last month 14:03:15 yes it's in the ticket 14:03:20 mclasen, it's because we stuffed SB tools on WS 14:03:27 im +0 because I don't like the growth without some mechanism for tracking growth in the future 14:03:29 I don't know if rpm-ostree somehow got bundled into there 14:03:33 mcatanzaro: sure, but maximum size is about blocking Fedora 14:03:38 mclasen: We looked at the growth and it's really all just podman 14:03:38 I hope this doesn't open the floodgates though 14:03:40 our own target size can be whatever we want 14:03:52 petersen, of course it does 14:03:52 as long as it's below the maximum 14:03:56 lol 14:04:11 Son_Goku: as in, podman ? 14:04:16 cmurf: Honestly I'd prefer a lower maximum so that we can review the package set more often when it's reached 14:04:16 Son_Goku: sorry.. "SB"? 14:04:18 once we increase the size, all the arguments about libreoffice, langpacks, etc. will return 14:04:21 langdon, Silverblue 14:04:27 mclasen: I was working on F31 flatpak runtime and did a pre-installed package diff while doing this: https://paste.fedoraproject.org/paste/S4ry1WTt9VZ1SWFutg4v-w 14:04:31 gotcha.. acronym expansion fail 14:04:40 mcatanzaro: +1 14:04:41 mclasen, podman, moby-engine, docker, rpm-ostree, and buildah are now supposedly on the Workstation image 14:04:56 podman does NOT show up in my diff, I'll note 14:05:08 dunno why :) 14:05:12 Not all in my live imagine 14:05:13 3GB using SI units, i.e. 1000 bytes 14:05:13 the only one those that's arguably sb's fault is rpm-ostree 14:05:28 just to make it clear since the limit right now is in SI units 14:05:29 cmurf: Would you be willing to prepare a review of live image size around every beta release, like you did a couple days ago? I think the max doesn't matter if we review the live image contents regularly 14:05:29 mclasen, there all in the @container-tools comps group 14:05:37 I would be finer with <3GB 14:05:50 yes, but containers are of interest beyond sb 14:05:50 we could remove docker / moby-engine by default, IMO 14:05:55 anyway, irrelevant 14:05:56 mclasen: yes 14:05:59 I personally would rather _not_ increase the size 14:06:01 -1 14:06:14 especially since it's such a tiny overage 14:06:19 ah, I know why podman didn't show up on the diff: it was already pre-installed for F30 14:06:21 docker is not in WS Live is it? 14:06:22 kalev: The size increase is due to podman and containernetworking-plugins, it's all there in the ticket 14:06:42 kalev: it's not I checked on a clean install of F30 just two days ago 14:06:44 Son_Goku: I'd prefer we stay as small as possible, but without a concrete plan to get under the limit, we *definitely* should not block F31 on an artificial limit 14:06:56 otaylor, we have several weeks to fix this 14:07:05 and on F31, rpm -qa|rep moby/docker shows up nothing 14:07:05 ok.. im blanking on the syntax for votes.. but i have +7, 1 abstain, 1 - 14:07:06 Actually I have a proposal to try to drop google-noto-serif-cjk for F32, sshhh 14:07:10 Ah yeah, it was rejected as a beta blocker so we'll ship oversize for beta 14:07:14 That means we can defer this to next week 14:07:17 but i know i hjave another meeting .. so can we call it? 14:07:22 petersen's proposal would definitely bring us under 2 GB 14:07:28 langdon: Let's continue next week 14:07:29 I know 14:07:35 I don't think it's urgent to continue now. Let's continue next week. 14:07:42 sorry that vote was for 3g 14:07:43 We have 3 weeks until Final freeze 14:07:57 ohh.. so we can defer? i missed that 14:08:01 yeah, we can defer 14:08:09 agree with otaylor. this needs a strategy 14:08:09 guys... 14:08:10 Sorry I forgot we didn't really need to decide this today :P 14:08:11 that's why I'm voting -1 right now 14:08:18 haha 14:08:25 ok.. then i am gonna say "no vote" 14:08:26 Can we revisit after more thought then? 14:08:30 yes 14:08:34 cool 14:08:34 langdon: yes, "no vote" 14:08:35 and make it first next time.. 14:08:39 * kalev nods. 14:08:48 although.. next meeting is 2wks.. which is a little tight 14:08:55 Who is next chairperson? 14:08:59 not set 14:09:06 schedule needs a revise 14:09:06 Even better 14:09:07 petersen: It'll be me, I just set the schedule alphabetically 14:09:10 I can chair 14:09:31 #info mcatanzaro proposed new schedule at https://apps.fedoraproject.org/calendar/workstation/ 14:09:32 do we have any idea how size increase impacts download time? 14:09:48 fast downloads probably = happy users 14:09:56 they impact it *a lot* 14:09:59 aday: Directly proportional to the size increase 14:10:21 The bigger the better ;-P Feels more valuable hahaha 14:10:29 I have to go, sorry 14:10:34 if we increase the size, we might want to discuss with infra to see if we can compensate 14:10:35 me too 14:10:43 ok.. mind if i #endmeeting? 14:10:48 I've got to go too 14:10:51 yes, please 14:10:52 this can move to #f-workstation i assume? 14:10:59 sure 14:11:03 ok.. 14:11:05 wrap it up here, move to fedora-workstation 14:11:09 #endmeeting