17:00:53 <decathorpe> #startmeeting FESCo (2022-07-12)
17:00:53 <zodbot> Meeting started Tue Jul 12 17:00:53 2022 UTC.
17:00:53 <zodbot> This meeting is logged and archived in a public location.
17:00:53 <zodbot> The chair is decathorpe. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
17:00:53 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:53 <zodbot> The meeting name has been set to 'fesco_(2022-07-12)'
17:00:57 <decathorpe> #meetingname fesco
17:00:57 <zodbot> The meeting name has been set to 'fesco'
17:01:13 <decathorpe> #chair nirik, decathorpe, zbyszek, sgallagh, mhroncok, dcantrell, music, mhayden, Conan_Kudo, Pharaoh_Atem, Son_Goku, King_InuYasha, Sir_Gallantmon, Eighth_Doctor
17:01:13 <zodbot> Current chairs: Conan_Kudo Eighth_Doctor King_InuYasha Pharaoh_Atem Sir_Gallantmon Son_Goku dcantrell decathorpe mhayden mhroncok music nirik sgallagh zbyszek
17:01:23 <decathorpe> #topic Init Process
17:01:30 <sgallagh> .hi
17:01:30 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
17:01:31 <nirik> morning everyone.
17:01:38 <dcantrell> .hello2
17:01:39 <zodbot> dcantrell: dcantrell 'David Cantrell' <dcantrell@redhat.com>
17:01:45 <salimma> .hi
17:01:46 <zodbot> salimma: salimma 'Michel Alexandre Salim' <michel@michel-slm.name>
17:01:54 <davide> .hello dcavalca
17:01:54 <dcantrell> nirik: EHLO
17:01:56 <zodbot> davide: dcavalca 'Davide Cavalca' <dcavalca@fb.com>
17:02:07 <zbyszek[m]> Fabio Valentini: meeting?
17:02:17 <zbyszek[m]> .hello2
17:02:18 <zodbot> zbyszek[m]: Sorry, but user 'zbyszek [m]' does not exist
17:02:25 <salimma> zbyszek: Fabio started it already
17:02:33 <zbyszek[m]> Pff, I'm on a train and I'm apparently having huge lag.
17:02:42 <zbyszek[m]> Sorry if I respond out of context.
17:03:00 <sgallagh> I wish I had that excuse.
17:03:11 <zbyszek[m]> I'll have to disembark at :40 too.
17:03:35 <nirik> dcantrell: 501 Syntax: EHLO hostname :)
17:03:45 <dcantrell> nirik: haha :)
17:04:47 <decathorpe> ok, I count 7 members as present, I think we can start?
17:05:13 <decathorpe> or rather, 6 members and one audience
17:05:57 <Eighth_Doctor> .hello ngompa
17:05:58 <MichaelCatanzaro> .hello catanzaro
17:05:59 <zodbot> Eighth_Doctor: ngompa 'Neal Gompa' <ngompa13@gmail.com>
17:06:02 <zodbot> MichaelCatanzaro: catanzaro 'Michael Catanzaro' <mcatanza@redhat.com>
17:06:08 <OwenTaylor[m]> .hello otaylor
17:06:09 <zodbot> OwenTaylor[m]: otaylor 'Owen Taylor' <otaylor@redhat.com>
17:07:10 <decathorpe> #link https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/S26Y3HFGRK2EWDO6FDCTSCGHMJY54ZXZ/ Schedule
17:07:15 <salimma> Fabio Valentini: I think dcavalca and I are both audience
17:07:20 <dustymabe> .hi
17:07:21 <zodbot> dustymabe: dustymabe 'Dusty Mabe' <dusty@dustymabe.com>
17:07:38 <decathorpe> right. I can't count
17:07:53 <bcotton> .hello2
17:07:54 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
17:07:56 <decathorpe> any particular preference for the order our topics?
17:08:35 <zbyszek[m]> We'll have to vote through acclamation
17:09:12 <decathorpe> meh.
17:09:30 <decathorpe> #topic Change: Deprecate openssl1.1 package
17:09:35 <decathorpe> .fesco 2821
17:09:37 <zodbot> decathorpe: Issue #2821: Change: Deprecate openssl1.1 package - fesco - Pagure.io - https://pagure.io/fesco/issue/2821
17:09:58 <decathorpe> last update: the change owners were unable to update their proposal
17:10:17 <nirik> sounds like we should wait a week until they can?
17:10:26 <decathorpe> given that there's been multiple -1 votes on the current version, do we want to wait until next week?
17:10:40 <zbyszek[m]> No, there's been another update half an hour ago
17:10:52 <zbyszek[m]> > @decathorpe I kindly ask to discuss also a limited version of the proposal
17:11:00 <zbyszek[m]> bbl
17:11:10 * nirik is fine waiting, I would be +1 to a more limited version that just marked the package as deprecated...
17:11:15 <decathorpe> Does that mean adding "Provides: deprecated()" to the openssl1.1 packages?
17:11:53 <decathorpe> The most recent comment isn't clear wrt/ what "limited version" means.
17:12:08 <Eighth_Doctor> I wouldn't want to vote on it without a concrete update
17:12:17 <dcantrell> right, and the change proposal page still hasn't changed since July 1
17:12:18 <zbyszek[m]> That's how I understood it.
17:12:18 <Eighth_Doctor> as the proposal stands, I'm -1
17:12:18 <music[m]> Likewise, I will +1 if the limited version is just the usual depreciation process, but there doesn’t seem to be a concret proposal yet.
17:13:15 <sgallagh> OpenSSL is really a special case though.
17:13:38 <zbyszek[m]> proposal: say "please adjust the page to the new scope" in the ticket and revisit next week.
17:13:41 <sgallagh> It's an incredible amount of work to keep it alive and in sync with 3.x
17:14:36 <decathorpe> It also would put an incredible amount of work on the maintainers of affected packages if openssl1.1-devel were just dropped. I don't think that would be fair.
17:15:00 <zbyszek[m]> Yeah, I think it's less disruption to the distro to keep it limping along.
17:15:00 <nirik> zbyszek[m]: +1
17:15:18 <dcantrell> zbyszek[m]: +1
17:15:33 <sgallagh> Can we perhaps look into getting a regular (weekly? Monthly?) report to the devel list of packages still requiring 1.1 at runtime?
17:15:53 <decathorpe> Something similar to what happened with Python2 ?
17:16:06 <sgallagh> I think we should at least be advocating for getting people to move up to a supportable crypto library
17:16:12 <Eighth_Doctor> also openssl1.1 is still maintained in RHEL 8
17:16:25 <Eighth_Doctor> so keeping it at least in sync with that is I think workable
17:16:44 <sgallagh> Conan Kudo: You'd be surprised how difficult that can still be
17:17:01 <sgallagh> Since RHEL has much more stringent policies on available algorithms than Fedora does
17:17:16 <Eighth_Doctor> but those are managed by crypto-policies, which is external to openssl
17:17:29 <sgallagh> It's less external than we'd like it to be :-/
17:18:13 <music[m]> In the ticket, I suggested that the change owners might benefit from setting up a tracking bug and filing “warning” bugs on packages still using 1.1.
17:18:48 <decathorpe> Right. That's all good feedback, but the Change hasn't been updated yet.
17:19:01 <decathorpe> which leads me to ... Proposal: Give Change owners another week to update their Change proposal or work out a concrete plan for a more limited version.
17:19:54 <nirik> as zbyszek[m] proposed a bit ago.... :) but still +1
17:20:08 <sgallagh> Honestly, I'd almost be in favor of just announcing "We'll leave OpenSSL 1.1 in the distro, but it will receive no regular or security updates after $DATE"
17:20:20 <decathorpe> nirik: let's just make it official ;)
17:20:27 <dcantrell> decathorpe: +1
17:20:34 <sgallagh> In any case, +1 to giving them one more week
17:21:17 <MichaelCatanzaro> sgallagh: You would leave a security-critical library in the distro, receiving no security updates?
17:21:35 <sgallagh> Note the word "almost" :)
17:22:35 <decathorpe> Conan Kudo music zbyszek vote?
17:22:38 <Eighth_Doctor> +1 to one more week
17:23:24 <zbyszek[m]> Fabio Valentini: +1 to your proposal too
17:24:07 <music[m]> i am +1 to allowing one more week
17:24:32 <zbyszek[m]> Is python2.7/3.6/3.7 also marked as deprecated?
17:24:54 <decathorpe> #agree Give change owners one more week to update their proposal (+7, 0, -0)
17:24:55 <zbyszek[m]> Also what about pypy? Is anyone using that? If we can't update it to openssl-3.0, mark it as deprecated too?
17:25:22 <decathorpe> Can we move discussion of the technical side of things to the mailing list?
17:26:09 <decathorpe> because I'd like to move on to the next topic, otherwise it's going to be a long meeting.
17:26:30 <zbyszek[m]> Yes please.
17:26:51 <decathorpe> #topic #2828 Change: Unfiltered Flathub
17:26:54 <decathorpe> .fesco 2828
17:26:55 <zodbot> decathorpe: Issue #2828: Change: Unfiltered Flathub - fesco - Pagure.io - https://pagure.io/fesco/issue/2828
17:27:32 <zbyszek[m]> I'm +1
17:27:39 <Eighth_Doctor> -1
17:28:08 <decathorpe> So you want to vote synchronously, or do we need to discuss something?
17:28:31 <zbyszek[m]> (As long as the user can clearly see whether they are installing rpm or flatpak, and change the choice. From the discussion on the list, this is the case at least with gnome-software.)
17:28:48 <Eighth_Doctor> as long as we don't have vendor preferences in gnome-software, I don't want this
17:28:53 <gotmax[m]> zbyszek: Yes, but the default matters hete
17:28:59 <nirik> My only hesitation is the pref order...
17:29:21 <gotmax[m]> *here
17:29:23 <Eighth_Doctor> I want Fedora content (first-party) to be preferred by default regardless of format
17:29:57 <zbyszek[m]> Conan Kudo: I agree. But don't we get that if rpm is preferred?
17:30:00 <Eighth_Doctor> zbyszek: flatpak is preferred in g-s right now
17:30:03 <dcantrell> am I missing something?  I'm reading the proposal as stating that
17:30:29 <dcantrell> Eighth_Doctor: are you talking about a case like gimp or libreoffice which is both in rpm format and I assume flatpak format?
17:30:33 <Eighth_Doctor> g-s has Flatpak > RPM, but doesn't have Fedora > others
17:30:33 <nirik> flatpak (first fedora flatpak if available, then flathub if avaiable) then rpm
17:30:49 <OwenTaylor[m]> zbyszek: I'd say the workstation working group does *not* want to change the format order to prefer rpm over Flatpak - so prefering Fedora RPMs over Flathub Flatpaks owuld require adding fine-grained ordering to GNOME Software.
17:31:35 <zbyszek[m]> OK, but is a flathub flatpak preferred over a fedora rpm? This would be bad.
17:31:41 <decathorpe> as I understand it, doing "Fedora Flatpak > Fedora RPM > Flathub Flatpak" is not possible right now?
17:31:41 <Eighth_Doctor> zbyszek: it is
17:32:02 <zbyszek[m]> Pfff, that's a bummer.
17:32:10 <MichaelCatanzaro> Eighth_Doctor: To be clear, Flathub would not be enabled by default.  But, if enabled (non-default), then I understand you still want Fedora RPMs to be preferred. (I responded on the mailing list to indicate why it's not a good idea...)
17:32:10 <Eighth_Doctor> this concern was raised by myself, xvitaly, and several others
17:32:11 <OwenTaylor[m]> zbyszek: if the proposal is accepted without changes, yes, a flathub flatpak is prefered over a fedora rpm (when installing through Software)
17:32:28 <gotmax[m]> I don't remember who said this on the ML, but the fact that content from other vendors is preferred over the community's own efforts is not great
17:32:44 <gotmax[m]> It feels a bit like a spit in the face to Fedora packagers
17:33:16 <zbyszek[m]> OK, so I misunderstood the situation. I'll need to fire up gnome-software and play around with this. So I withdraw my vote for now.
17:33:23 <sgallagh> As the proposal stands, I agree it's not acceptable for us to prefer an unvetted third-party repo over our community-packaged stuff.
17:33:33 <sgallagh> So right now, I'm -1
17:33:39 <MichaelCatanzaro> zbyszek[m]: Fedora RPMs are sadly unsafe because they are not sandboxed. Ideally we would not display RPMs in GNOME Software anymore at all, or Flatpaks that disable the sandbox. But the ecosystem doesn't seem to be there yet...
17:33:46 <sgallagh> But only on the prioritization order; I'm fine with enabling Flathub in general, so long as it's lower prio
17:33:55 <decathorpe> > Fedora RPMs are sadly unsafe
17:33:58 <music[m]> I’m torn on this. I understand the arguments that flatpaks can be sandboxed and can offer other advantages, but there is nothing guaranteeing that flatpaks on flathub-as-a-whole follow any of the practices that support that argument. I’m worried that unfiltered Flathub combined with always defaulting to Flatpak will really push users to packages that are in many (not all) cases still unsandboxed but also maintained to a lower
17:33:58 <music[m]> standard.
17:33:59 <gotmax[m]> AFAIK, no other current third party repository overrides Fedora content
17:34:14 <gotmax[m]> By third party, I mean in the ones we ship .repo files for
17:34:14 <decathorpe> this is disingenuous at best.
17:35:12 <sgallagh> There are also numerous pieces of useful software whose flatpak implementation is... suboptimal.
17:35:19 <MichaelCatanzaro> MichaelCatanzaro: This is why Flathub should be preferred. User safety. I do agree there is a problem with unsandboxed apps on Flathub, though, and this proposal does not address that....
17:35:32 <sgallagh> (For example, Visual Studio Code loses a lot of its functionality since there's no obvious way to install helper software into the flatpak)
17:35:48 <gotmax[m]> I don't think it's universally agreed upon that flatpaks are always "more safe"
17:36:54 <sgallagh> I think we can agree that Flatpak's have a more security/isolation-first design, but that doesn't mean it's getting used that way.
17:36:59 * nirik wonders how many things we are actually talking about here. It's the set of things that are on flathub, are not fedora flatpaks and have a fedora rpm available...
17:37:13 <MichaelCatanzaro> decathorpe: It's true though. Unless the software has its own strong sandbox -- and only web browsers do, almost no other apps  do -- it's surely not safe. Unless it's incapable of opening files or connecting to the internet....
17:37:21 <gotmax[m]> Stephen Gallagher: Yes, I guess that's true
17:38:04 <OwenTaylor[m]> Stephen Gallagher: I think that's largely restricted to IDE's - most other software that doesn't work as Flatpaks is not packaged as Flatpaks
17:38:05 <gotmax[m]> But whether or not they are actually packaged to our standards is worth considering as well
17:38:10 <dustymabe> the way I look at it Fedora RPMS->safe, Fedora Flatpak->safe, third part RPM->untrusted, third party flatpak->untrusted but at least sandboxed
17:38:15 <MichaelCatanzaro> Sadly, Fedora has failed big time to secure RPM applications. All other distros similarly failed....
17:38:33 <decathorpe> dustymabe: +1
17:38:53 <Eighth_Doctor> likewise
17:39:00 <sgallagh> Owen Taylor: And the proposal as-written would mean that people installing an IDE (VSCode, PyCharm, Eclipse, etc.) would end up with a crippled version.
17:39:01 <dustymabe> I'm blindly putting a lot of trust in Fedora, but I like to sleep at night and not worry about every problem in the world
17:39:25 <MichaelCatanzaro> dustymabe: There's no way we can hold a productive discussion if you hold this view. One memory safety vulnerability and your Fedora RPM is no longer looking so safe. And our apps have *tons* of memory safety vulnerabilities.
17:39:43 <sgallagh> Michael Catanzaro: I'm going to require you to back up that statement, because it's very much "begging the question"
17:39:47 <Eighth_Doctor> Michael Catanzaro: please stop being antagonistic to everyone who holds contrary views to you
17:39:55 <Eighth_Doctor> on flatpak vs rpm
17:40:13 * dustymabe runs flatpaks, btw
17:40:17 <decathorpe> please, this is starting to be off-topic.
17:40:30 <Eighth_Doctor> the view that I personally hold is that I can trust the process around Fedora packages, which is why I trust them more than third parties
17:40:39 <dustymabe> this ^^
17:40:42 <dcantrell> I think that's the key point, yes
17:40:47 <Eighth_Doctor> and Fedora packages are easily mutable, whereas third party Flatpaks are not
17:40:52 <OwenTaylor[m]> Stephen Gallagher: yes, that's called out in the workstation ticket. I think if we were prefering Fedora RPMs (and fedora third-party repos for pycharm, etc.) over Flatpaks, that largely doesn't need a special-case solution. We *could* filter out IDe's from Flathub, but I don't see that as useful.
17:41:26 <MichaelCatanzaro> E.g. this story https://www.vice.com/en_us/article/v7gd9b/facebook-helped-fbi-hack-child-predator-buster-hernandez is an example where Facebook (hi ;) exploited a memory safety vulnerability in totem to achieve remote code execution... that happened in Tails, not Fedora, but there is no technical difference that would make it harder to do here. If they can do it to bad guys, the bad guys can similarly do it to other users.
17:41:26 <MichaelCatanzaro> Sandboxing is essential for user safety. This is why prioritizing Flathub is sadly preferable. :/
17:41:45 <MichaelCatanzaro> I wish Fedora RPMs were secure, but they simply are not.
17:41:46 <sgallagh> Owen Taylor: It's slightly off-topic, but I'd love to see that issue somehow addressed in Flatpak. Otherwise IDEs will be practically impossible to use on Silverblue
17:42:33 <sgallagh> Michael Catanzaro: And  I wish flatpaks were secure *and* functional, but in many cases the packager has chosen only one or the other.
17:42:42 * decathorpe reminds everyone we have spent 15 minutes on this topic
17:42:43 <bcotton> Secure is a spectrum, not a binary. And sandboxing isn't the only aspect of security
17:42:50 <gotmax[m]> I don't think it's fair to make blanket statements about Fedora RPMs like this just like it wouldn't be to do the same about flatpaks
17:43:00 <sgallagh> Ben Cotton (he/him)++
17:43:26 <sgallagh> Sandboxing is one part of a defense-in-depth strategy.
17:43:33 <sgallagh> I am not at all arguing that it's a bad thing.
17:44:45 <nirik> so, right now there's a filter, showing only some subset of flathub to those who enable it right? that subset is curated by the working group right?
17:45:11 <gotmax[m]> Stephen Gallagher: You have to manually type bcotton if you want karma to work properly
17:45:26 <sgallagh> bcotton++
17:45:26 <zodbot> sgallagh: Karma for bcotton changed to 5 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:45:27 <salimma> bcotton++
17:45:29 <zodbot> salimma: Karma for bcotton changed to 6 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:45:38 <Eighth_Doctor> bcotton++
17:45:38 <zodbot> Eighth_Doctor: Karma for bcotton changed to 7 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:45:45 <Eighth_Doctor> oh yay that worked
17:45:51 <MichaelCatanzaro> sgallagh: I understand some apps on flathub suffer degraded functionality, specifically IDEs. Ideally they should not be on flathub at all if so, but... the proposal as written does include a denylist. It was planned to be an empty denylist, to be reserved in case of unexpected legal emergencies, but we could add particular apps there to cause RPMs to be preferred for those apps.
17:46:35 <gotmax[m]> Otherwise it shows up on IRC as `Ben Cotton (he/him)++` and that doesn't work for zodbot
17:46:35 <gotmax[m]> Anyways...
17:46:37 <sgallagh> OK, that's worth exploring.
17:47:14 <sgallagh> Though as a general rule, I still agree with the Fedora > 3rd-party recommendation, since if someone installed Fedora they have implicitly extended that trust to us.
17:47:18 <nirik> could we add any flathub apps that are packaged as fedora rpms? ie, a poor way to prefer them (I know it would mean that they wouldn't be able to switch to flatpak)
17:47:24 <gotmax[m]> Stephen Gallagher: Agreed
17:47:35 <sgallagh> That trust has to extend to us trying our best to give them vetted software when possible
17:47:43 <salimma> would it make sense to expose this ordering to the user? so we set a default but let it be overridden
17:47:46 <davide> what's the supply chain security story for flathub? for Fedora RPMs, we know where they come from, they the licenses are correct, etc. thanks to the review processes we have
17:47:53 <MichaelCatanzaro> <bcotton> "Secure is a spectrum, not a..." <- True... but it is arguably the most important aspect. A sandboxed app riddled with vulnerabilities is probably safer for users than a pristine unsandboxed app, though it depends on use (if you feed the app your sensitive documents, that would be bad).
17:47:59 <gotmax[m]> nirik: I think it's possible to just set it through Gnome Software and not have to do any filtering
17:48:04 <nirik> salimma: that is already the case.
17:48:04 <gotmax[m]> for that purpose
17:48:07 <Eighth_Doctor> davide: they don't have any of that
17:48:31 <Eighth_Doctor> I also did not receive a nice reception when I asked about it before
17:49:07 <gotmax[m]> Well, you can override it per install, but there's not an easy way exposed to the user to set it on a global level
17:49:09 <nirik> davide: there's a git repo per app so you can see whats in it, things are built on their hw. Many/some apps are repackaging other packages (.debs, etc). There was a blog post recently about how many...
17:49:10 <gotmax[m]> AFAIK, at least
17:49:17 <Eighth_Doctor> "we're not a distro, so we don't need to care" was basically the sentiment I got
17:49:42 <davide> oh so potentially they're not even built from source?
17:49:44 <davide> that seems... bad
17:49:49 <OwenTaylor[m]> I'm not sure it's that useful to debate sandboxing vs. what supply chain protections are in flathub here, unless that would change anybody's vote to say "it's OK to install Flathub Flatpaks instead of Fedora RPMs by default"
17:50:08 <Eighth_Doctor> Owen Taylor: it's part of the reason why I vote -1 to it
17:50:24 <Eighth_Doctor> I cannot trust their process, their inputs, or their outputs
17:50:40 <nirik> https://blogs.gnome.org/wjjt/2022/06/14/how-many-flathub-apps-reuse-other-package-formats/
17:51:01 <music[m]> davide: As I understand it, even proprietary software would be included. Correct me if I’m wrong.
17:51:45 <OwenTaylor[m]> Davide Cavalca: well, an example is that the Blender packages on Flathub use the Blender foundation built binaries
17:51:57 <gotmax[m]> music: Yes, it does. But users have to explicitly enable third party software first.
17:52:09 <OwenTaylor[m]> Davide Cavalca: Certainly most packages of open source software on Flathub are built on Flathub infrastructure from source
17:52:14 <salimma> music[m]: you're correct. there's two VS Code in flathub, one is proprietary
17:52:15 <nirik> element on flathub uses the debs (but they don't provide an rpm)
17:52:22 <MichaelCatanzaro> davide: Correct, but I think this is mostly for proprietary software...
17:52:27 <Eighth_Doctor> nah
17:52:32 <Eighth_Doctor> it's also true for OSS as well
17:52:56 <Eighth_Doctor> cf element
17:52:57 <Eighth_Doctor> and I think jitsi meet too?
17:52:58 * Eighth_Doctor checks
17:53:09 <MichaelCatanzaro> nirik: TL;DR: 88% built from source, 12% weird stuff
17:53:27 <Eighth_Doctor> yup
17:53:28 <sgallagh> No, 12% is known to be repackaged
17:53:36 <sgallagh> The other 88% may or may not be built from source
17:53:36 <Eighth_Doctor> Jitsi meet is repacked from AppImage
17:53:44 <sgallagh> It could also just be repackaging pre-existing binaries.
17:54:00 <MichaelCatanzaro> sgallagh: Yes, that's more accurate (but it probably is built normally)
17:54:20 <Eighth_Doctor> I don't think we can make that assumption, given the query was based on known package archive formats
17:54:23 <sgallagh> Fair, but unknowable for practical purposes
17:54:27 <Eighth_Doctor> it didn't check for just incorporating raw binaries
17:54:57 <music[m]> Right, this may be a bit of a sidetrack, but just because something is built from “source” doesn’t mean it’s what Fedora would consider source. Java bytecode, transpiled and minified JS/CSS, ELF files checked into git…
17:54:59 <OwenTaylor[m]> I think if you restricted yourself to things packaged in Fedora, the number of things that aren't built from source would be small - not non-zero (see Blender above) but < 10.
17:55:39 <decathorpe> another bad example is firefox. it doesn't even have a repo in github.com/flathub, so you have no idea where that comes from
17:56:04 <MichaelCatanzaro> decathorpe: That one doesn't have a repo because it's pushed directly by Mozilla
17:56:13 <decathorpe> oh, is that better? :D
17:56:29 <gotmax[m]> Also, re the security aspect, how do we know whether or not the libraries bundled in flathub flatpaks are up to date and not vulnerable themselves? In Fedora, prodsec files bugs for security issues, but I would guess there isn't a similar procedure for flathub.
17:56:30 <MichaelCatanzaro> i.e. Mozilla does the builds. Whether that is better or not... I will not say. :D
17:56:33 <Eighth_Doctor> Blender is actually done this way: https://github.com/flathub/org.blender.Blender/blob/master/org.blender.Blender.json
17:56:39 <Eighth_Doctor> just binaries
17:56:54 <MichaelCatanzaro> decathorpe: Maybe not  :)
17:56:55 <Eighth_Doctor> ironically it builds blenders deps, but not blender itself
17:57:10 * decathorpe reminds everyone we have spent 30 minutes on this topic
17:57:50 <dcantrell> how about we vote
17:58:14 <gotmax[m]> dcantrell: That seems more productive to me
17:58:48 <sgallagh> Based on all of this discussion, I think I'm -1 on enabling Flathub en masse
17:59:05 <sgallagh> However, I'd like to see a better mechanism for vetting things to be included in the Fedora-approved collection
17:59:14 <sgallagh> Something akin to our RPM package review process
17:59:30 <zbyszek[m]> What would we be voting on? Because if the vote is just straight up/down accept/reject, I'd prefer to have a week more to dig into this and ask some more questions. The discussion here raised various good points.
17:59:38 <sgallagh> That way we can increase the available Flatpaks without decreasing quality
17:59:54 <decathorpe> Stephen Gallagher: (we already have that - it's the curated flathub filter)
18:00:12 <sgallagh> Fabio Valentini: Yes, but what process is used to populate that filteR?
18:00:16 <OwenTaylor[m]> There's a process defined in https://pagure.io/fedora-flathub-filter/ - it's more of a question of getting the crank churning.
18:00:30 <sgallagh> I'd like that codified and made available to the community at large to manage.
18:00:48 <MichaelCatanzaro> sgallagh: We will have to debate whether to keep the Fedora-approved collection if this proposal passes. It has received primarily negative feedback from users. Owen wants to keep it, but I'm not sure what to do.
18:00:58 <decathorpe> Question: Is there the possibility of getting the Change proposal amended within a reasonable timeframe (i.e. until the next meeting or so)?
18:00:58 <MichaelCatanzaro> s/passes/does not pass/
18:01:05 <decathorpe> Or is there no interest in doing that?
18:01:20 <OwenTaylor[m]> For people who are voting no, I'd like to know whether they would be +1 if Fedora RPMs were preferred over Flathub Flatpaks
18:01:25 <mclasen> decathorpe: when is the next meeting ?
18:01:31 <Eighth_Doctor> there was interest from other distributions on rolling out fedora flathub filter
18:01:42 <decathorpe> mclasen: next week, same time, same place.
18:01:57 <dcantrell> OwenTaylor[m]: I am -1 as written, but if the proposal were modified to prioritize all Fedora software over third party software I would be a +1
18:01:58 <OwenTaylor[m]> Fabio Valentini: I think that depends on how it would be modified :-)
18:02:08 <Eighth_Doctor> Owen Taylor: I'd consider it if Fedora was universally preferred, yes
18:02:10 <music[m]> So I was just looking back at the proposal, and one thing I hadn’t quite caught before is that this proposal will have no impact on users who don’t specifically enable third-party software. Correct?
18:02:18 <sgallagh> Owen Taylor: I'd be weakly +1, but I'd still much rather we establish an easy-to-follow review policy to get additional Fedora flatpak's approved
18:02:21 <mclasen> not much from me until then. Owen and Michael may have time to work on it
18:02:41 <MichaelCatanzaro> music[m]: Correct, this only affects users who *opt-in*. It remains disabled by default.
18:03:03 <Eighth_Doctor> most people will opt-in to third-party though, esp since that covers nvidia driver
18:03:10 <Eighth_Doctor> there is no granularity there
18:03:11 <MichaelCatanzaro> We would probably request two weeks to amend the proposal because most decisions happen on Tuesdays
18:03:15 <sgallagh> Sure, but I wonder how many people *don't* hit the "Enable third-party repositories" button
18:03:24 <MichaelCatanzaro> Eighth_Doctor: Quite possible.
18:03:25 <sgallagh> I suspect it may be functionally the default, if not technically.
18:03:26 <decathorpe> Still, it might be unexpected behaviour if opting in to third-party stuff will actually override things that were already available.
18:03:32 <Eighth_Doctor> between steam and nvidia, thirdparty gets enabled quite often
18:03:40 <sgallagh> decathorpe++
18:03:40 <zodbot> sgallagh: Karma for decathorpe changed to 2 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
18:05:12 <sgallagh> Owen Taylor: So yeah, I could be on-board so long as Fedora-provided software is preferred over Flathub.
18:05:35 <decathorpe> So, would it be possible to amend this change so that the default preference would be "Fedora Flatpak > Fedora RPM > Flathub Flatpak"?
18:06:06 <decathorpe> With this change, I'd be less likely to vote against it.
18:06:14 * sgallagh would slightly prefer "Fedora RPM > Fedora Flatpak > Flathub", but that's not worth side-tracking on.
18:06:26 <Eighth_Doctor> me too
18:06:39 <Eighth_Doctor> but Fedora > third party is the important thing here
18:06:45 <sgallagh> Agreed
18:06:58 <dustymabe> +1
18:08:01 <sgallagh> Michael Catanzaro: To address your concerns: what I'd like to see also is that if a properly-secured Flatpak is added to Fedora Flatpaks, we should retire the RPM version.
18:08:21 <zbyszek[m]> Ewww, please no.
18:08:36 <Eighth_Doctor> please don't do that
18:08:44 <decathorpe> I'm not even sure how that would work, given the the Fedora Flatpaks are built from the RPM packages.
18:08:47 <zbyszek[m]> I like flatpaks, but being forced to use flatpaks doesn't seem nice.
18:09:04 <Eighth_Doctor> that's also how we piss off our userbase like Ubuntu has been doing
18:09:05 <sgallagh> OK, that's more controversial than I expected, so I withdraw it.
18:09:08 * decathorpe reminds everyone to stay on topic please
18:09:11 <sgallagh> Let's not get diverted
18:09:12 <gotmax[m]> Is it even possible to add more Fedora flatpaks now that the tools have been orphaned?
18:09:23 * decathorpe sighs
18:10:00 <sgallagh> Fabio Valentini: How about just a quick vote: Do we accept the Change as-is?
18:10:04 <mclasen> gotmax[m]: kalev is reviving fedmod
18:10:05 <music[m]> So not to drag this conversation too far backwards, but if this were approved as-is, and I installed FooApp in F37, I would get the flatpak unless I explicitly chose the rpm in the gnome-software dropdown (ignoring for the moment Fedora flatpaks).  Is that right? And if I already had FooApp installed from RPM in F36 and I upgraded to F37: I would stay on the RPM, or get switched to the third-party Flatpak?
18:10:12 <sgallagh> I don't see many people saying +1 to that question right now
18:10:35 <sgallagh> music: Stays with the RPM
18:10:43 <gotmax[m]> I don't think any FESCO members did
18:10:46 <MichaelCatanzaro> music[m]: Correct. App type would not change on upgrade.
18:11:09 <music[m]> Ok, that’s what I thought.
18:12:00 <decathorpe> Stephen Gallagher: good idea, let's move this forward.
18:12:35 <decathorpe> Please vote on the proposal as-is (but change owners will have the chance to give us an updated proposal):
18:12:58 <Eighth_Doctor> -1
18:13:03 <zbyszek[m]> -0
18:13:04 <dcantrell> -1
18:13:06 <decathorpe> -1
18:13:18 <nirik> +0
18:14:05 <sgallagh> -1
18:14:13 <zbyszek[m]> I need to drop. See you next week.
18:14:30 <decathorpe> zbyszek++ thanks, see you next week.
18:14:30 <zodbot> decathorpe: Karma for zbyszek changed to 3 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
18:15:03 <decathorpe> music: vote? you're the only one missing
18:15:06 <music[m]> I’m still finding both sides of the discussion somewhat persuasive. I suppose I’m still +0.
18:15:19 <decathorpe> thanks everyone
18:15:19 <sgallagh> Just a general reminder that voting 0 here is functionally equivalent to -1
18:15:58 <mhroncok> hey
18:15:59 <decathorpe> It doesn't make a difference in this case.
18:16:01 * gotmax[m] waves
18:16:02 <mhroncok> sorry for missing the meeting, got an emergency at home
18:16:14 <sgallagh> mhroncok: I hope nothing too serious.
18:16:14 <decathorpe> mhroncok: hey, just in time for the controversy
18:16:21 <sgallagh> Meeting is still going, FWIW
18:16:41 <gotmax[m]> decathorpe: mhroncok: ^
18:16:44 <gotmax[m]> About the flatpak change
18:16:57 * decathorpe seems to have bad luck and always ends up running meetings with controversial stuff
18:17:14 <sgallagh> It's not bad luck, we plan it that way maliciously ;-)
18:17:20 <gotmax[m]> decathorpe++ for running/moderating the meeting
18:17:20 <zodbot> gotmax[m]: Karma for decathorpe changed to 3 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
18:18:01 <mhroncok> -0 I guess (I wasn't paying that much attention, but I am not in favor of prefering 3rd party over Fedora stuff)
18:18:29 <decathorpe> great
18:18:36 <dcantrell> decathorpe++
18:18:36 <zodbot> dcantrell: Karma for decathorpe changed to 4 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
18:18:37 <Eighth_Doctor> decathorpe++
18:18:39 <zodbot> Eighth_Doctor: Karma for decathorpe changed to 5 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
18:18:57 <bcotton> decathorpe++
18:18:57 <zodbot> bcotton: Karma for decathorpe changed to 6 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
18:19:47 <decathorpe> #agree REJECTED: Proposal is rejected as-is, but Change owners will - of course - be able to submit and updated Change proposal. (+0, 4, -4)
18:20:27 <sgallagh> #info Primary objection was due to the overriding of Fedora-packaged software by third-party flatpaks
18:20:33 <OwenTaylor[m]> I'm not sure if the vote formally concluded or not, but we'll discuss whether we want to resubmit for F37 with changes - we'll need to check with the Software maintainers and designers about what's feasible in this release.
18:21:12 <bcotton> The FAA says I have to drop now. Enjoy the rest of the meeting
18:21:23 <decathorpe> bcotton++
18:21:23 <zodbot> decathorpe: Karma for bcotton changed to 8 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
18:21:32 <decathorpe> #topic #2759 Proposal: periodic check on packagers reachability
18:21:33 <sgallagh> safe travels, bcotton_
18:21:35 <decathorpe> .fesco 2759
18:21:36 <zodbot> decathorpe: Issue #2759: Proposal: periodic check on packagers reachability - fesco - Pagure.io - https://pagure.io/fesco/issue/2759
18:22:12 <decathorpe> I suggest that we look at this asynchronously and vote in ticket?
18:22:20 <decathorpe> The policy has been updated to take feedback into account since last week.
18:22:21 <sgallagh> Yeah, this meeting is long enough, I thinjk
18:22:30 <decathorpe> My thoughts exactly.
18:22:44 <sgallagh> Oh, and a quick thank-you to Owen Taylor and Michael Catanzaro for fielding our questions today.
18:23:10 <sgallagh> I know it's not the outcome you were hoping for, but we appreciate your involvement
18:23:13 <decathorpe> Yes, thank you for being here.
18:23:31 <decathorpe> Even if it makes meetings longer, the decisions are more well-informed.
18:23:45 <dustymabe> MichaelCatanzaro++
18:23:49 <dustymabe> OwenTaylor[m]++
18:24:01 <Eighth_Doctor> mcatanzaro++
18:24:06 <Eighth_Doctor> otaylor++
18:24:06 <zodbot> Eighth_Doctor: Karma for otaylor changed to 1 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
18:24:20 <decathorpe> #topic Next Week's Chair
18:24:29 <decathorpe> Any victims ... errr volunteers?
18:24:48 <Eighth_Doctor> I can't do it, I'm going to be on a plane at the time
18:24:56 <decathorpe> oh, the FAA wouldn't be happy about that
18:25:00 <Eighth_Doctor> lol
18:25:18 <Eighth_Doctor> I don't think my flight offers wifi
18:25:31 * Eighth_Doctor is flying up to Rochester, NY next week to setup the Hatch event in the Datto Rochester office
18:25:47 <Eighth_Doctor> https://pagure.io/fedora-hatch-2022-rochester
18:25:47 * sgallagh will also be there
18:26:23 <decathorpe> No volunteers? I really don't want to run next week's meeting too :)
18:26:39 <dcantrell> Eighth_Doctor: if only you could take a Dattco bus to your Datto office
18:26:45 <Eighth_Doctor> lol
18:26:51 <Eighth_Doctor> I've done that to go to Six Flags before
18:27:00 <Eighth_Doctor> for company summer parties
18:27:05 <dcantrell> ha, nice
18:27:14 <Eighth_Doctor> Datto rented Dattco buses
18:27:15 <sgallagh> I'll take it, I guess
18:27:19 <nirik> I haven't done it in a while, I could...
18:27:23 <nirik> or sgallagh can have it. ;)
18:27:23 <sgallagh> Since no one else is jumping in
18:27:32 <sgallagh> Help yourself, nirik
18:27:38 <decathorpe> well what now
18:28:12 <sgallagh> Flip a coin?
18:28:14 <decathorpe> one of you can take next week, the other can take the week after that
18:28:47 <sgallagh> I'll take the 26th, then
18:29:01 <nirik> sure.
18:29:12 <decathorpe> #action nirik will chair the meeting on 2022-07-19
18:29:21 <decathorpe> #action sgallagh will chair the meeting on 2022-07-26
18:29:23 <decathorpe> thank you!
18:29:29 <decathorpe> #topic Open Floor
18:29:33 <sgallagh> Thanks for chairing, Fabio Valentini
18:29:53 <decathorpe> I volunteered last week, so that's what I signed up for :)
18:29:58 <decathorpe> Is there anything for the open floor?
18:30:22 <decathorpe> Otherwise I'll end the meeting at :32.
18:32:24 <decathorpe> Alright, let's wrap up. Thanks everyone, sorry for running long :)
18:32:29 <decathorpe> #endmeeting