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