Re: Retiring Bottles in favor of Flatpak provided by upstream
On Tue, Mar 14, 2023 at 1:31 AM Sandro wrote: > > On 27-01-2023 00:15, Sandro wrote: > >> I'm not sure I can commit to maintaining these myself, though. Let me > >> know if you're interested in helping out. > > Yes, orjson has been mentioned by @atim and @thunderbirdtr, the > > co-maintainers, in the PR. If that becomes available there might be some > > progress to be made in keeping up with upstream. > > > > Albeit, working with upstream appears to have been a mixed bag (reading > > between the lines in the comments). But since I have not been > > experiencing this first hand, I'd prefer the co-maintainers to elaborate. > > > > > > > I'll ponder my options a little longer and hope the co-maintainers will > > shed their light on the state of affairs. > > There has been some development regarding Bottles, which I would like to > share. > > First of all, with orjson coming closer to being included in Fedora > (many thanks to @gotmax23 and @decathorpe), we decided to give it > another go and try to get an up to date Bottles shipped in Fedora 38. > Currently it builds in Copr[1], but I haven't found the time to test it > and scrutinize the build. > > I also announced our intentions upstream[2]. Upstream has responded with > discouragement[3,4]. I'm still relatively new to packaging and don't > have a lot of experience dealing with upstream. So, I'm asking for some > input on how to react to upstream's response in a productive, > collaborative manner. > > I get the feeling there's a fundamental misunderstanding of the open > source paradigm in upstream's arguments. I'm hoping that we can convince > them by showing off an up to date and working Bottles package. It sounds like there's also some misconceptions about how Fedora works as a distro? Unpredictable release cycles are not a problem, adding new dependencies is neither, since packages can be updated and added in all Fedora releases at basically any point in time. Fedora is more like a rolling release in that regard, unlike debian or ubuntu, where AFAIK no new packages can be added (or updates other than bugfixes pushed) after a certain point of the release cycle. I also find it rather interesting that they think orjson is a "Fedora problem". The issues we have that currently prevent packaging it are *upstream bugs*. I have recently managed to find the source of the segfaults on s390x. Apparently the nice Rust bindings for CPython provided by "PyO3" are too high-level for orjson, so the project uses the low-level pyo3-ffi (i.e. unsafe Rust-to-C FFI) to interact with libpython. And the way orjson does this is partially unsound: https://github.com/ijl/orjson/issues/338 (Yes, this issue has been closed as "Fixed", but the "fix" actually changed nothing regarding big-endian compatibility, and the same segfault is still present.) The equivalent to the broken-on-big-endian interfaces have been *disabled* in the high-level PyO3 APIs on BE arches (because I reported that they were broken and unsafe one and a half years ago, which I also discovered when packaging pyo3 for Fedora): https://github.com/PyO3/pyo3/issues/1824 Yes, this exact problem only affects big-endian architectures, so I assume that neither Bottles (flathub does not ship stuff for s390x) nor orjson (yeet a """fix""" and then apparently ignore the issue) care about it, but the same code that "works" in x86_64 relies on undefined behaviour and / or things that are "implementation defined" in C compilers, so the fact that they currently work is more or less just a happy coincidence (i.e. GCC and LLVM agreeing on bitfield memory layout across different architectures). I'm currently trying to submit a change to PyO3 to make these APIs work on big-endian architectures as well: https://github.com/PyO3/pyo3/pull/3015 Once this change is available, orjson could drop its bundled copy of unsafe code from pyo3-ffi (which it apparently does to use APIs that are marked as private ...) and use the new APIs directly. I have already verified that this works as expected across all Fedora architectures in COPR. Again, Bottles developers might not care, but this is the reason why linux distributions exist. Because *we need to care* about these nitty-gritty low-level things to *make things work*, even if upstream developers don't (or cannot). (And since more projects than just Bottles are starting to depend on orjson, having it work correctly on all our architectures is more important than just making Bottles work on x86_64, which seems to be the only thing the project cares about - maybe rightfully so, given that they depend on Wine.) Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:
Re: Retiring Bottles in favor of Flatpak provided by upstream
On 27-01-2023 00:15, Sandro wrote: I'm not sure I can commit to maintaining these myself, though. Let me know if you're interested in helping out. Yes, orjson has been mentioned by @atim and @thunderbirdtr, the co-maintainers, in the PR. If that becomes available there might be some progress to be made in keeping up with upstream. Albeit, working with upstream appears to have been a mixed bag (reading between the lines in the comments). But since I have not been experiencing this first hand, I'd prefer the co-maintainers to elaborate. I'll ponder my options a little longer and hope the co-maintainers will shed their light on the state of affairs. There has been some development regarding Bottles, which I would like to share. First of all, with orjson coming closer to being included in Fedora (many thanks to @gotmax23 and @decathorpe), we decided to give it another go and try to get an up to date Bottles shipped in Fedora 38. Currently it builds in Copr[1], but I haven't found the time to test it and scrutinize the build. I also announced our intentions upstream[2]. Upstream has responded with discouragement[3,4]. I'm still relatively new to packaging and don't have a lot of experience dealing with upstream. So, I'm asking for some input on how to react to upstream's response in a productive, collaborative manner. I get the feeling there's a fundamental misunderstanding of the open source paradigm in upstream's arguments. I'm hoping that we can convince them by showing off an up to date and working Bottles package. [1] https://copr.fedorainfracloud.org/coprs/gui1ty/bottles/builds/ [2] https://github.com/bottlesdevs/Bottles/issues/2345#issuecomment-1445064038 [3] https://github.com/bottlesdevs/Bottles/issues/2345#issuecomment-1452794525 [4] https://github.com/bottlesdevs/Bottles/issues/2345#issuecomment-1453072569 -- Sandro ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Retiring Bottles in favor of Flatpak provided by upstream
On 2/8/23 08:41, Kevin Kofler via devel wrote:
> (*) I know this term ("lowest common denominator") is mathematically
> nonsense. There is only a least/lowest common multiple and a greatest common
> denominator in mathematics. :-)
I mean there *is* a lowest common denominator: 1 :)
--
Sincerely,
Demi Marie Obenour (she/her/hers)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Retiring Bottles in favor of Flatpak provided by upstream
Daniel P. Berrangé wrote:
> Looking at Flatpaks with both my upstream author hat and distro maintainer
> hat, the main advantages I see is not the isolation. It is that they have
> the potential to eliminate the massive amount of duplicated work between
> every distro re-packaging the same app, and ensure more timely availablity
> of new releases to end users by de-coupling from the distro release cycle.
But that comes at the cost of "lowest common denominator" (*) packaging with
bundled dependencies (at least those not included in the runtime), inability
to use distro-specific compiler flags (e.g., you either always build with or
always without frame pointers, independently of what the user's distribution
prefers), less system integration (also due to the isolation), etc.
> As an upstream author, I want the latest releases of my software to be
> available for users to install as quickly as possible. Distros largely
> aren't satisfying that desire as well as I would like. If I rely on
> distro packaging, there can 3-12 month delay before a distro gets my
> new release in front of a user depending on their release cycle.
Users of non-rolling-release distros do not necessarily *want* to get
upgraded the latest major version of your application (with, e.g., major UI
changes) at an unexpected point in time at which they just want to get work
done. (And just not upgrading Flatpaks is also not a good idea because of
security.)
Where it makes sense, distro-provided opt-in PPA mechanisms such as Copr,
OBS, Launchpad PPAs, etc. can be used (but sure, it is yet another place
where the application needs to be packaged, that is the drawback).
> The tragedy would be if every distro ends up re-doing the
> creation and shipping of flatpaks, just as they do today
> with the distros specific packaging formats.
Is that not exactly what Fedora Flatpaks are about?
Kevin Kofler
(*) I know this term ("lowest common denominator") is mathematically
nonsense. There is only a least/lowest common multiple and a greatest common
denominator in mathematics. :-)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Retiring Bottles in favor of Flatpak provided by upstream
On Wed, Jan 25, 2023 at 06:01:17PM +0100, Vít Ondruch wrote: > > Dne 25. 01. 23 v 15:59 Josh Boyer napsal(a): > > On Wed, Jan 25, 2023 at 5:56 AM Vít Ondruch wrote: > > > I am not user of Bottles so I won't complain about this particular case, > > > but the push towards (upstream) Flatpaks is unfortunate :/ > > Can you elaborate on why you feel that way? > > > I don't trust upstream Flatpacks. I don't trust they follow any standard > except standard of their authors. > > And I don't like Flatpacks, because their main advantage (their isolation) > is also their biggest disadvantage. There can't be both without making > compromises. If I am not mistaken, the isolation is also mostly myth, > because it is disabled in most cases. Looking at Flatpaks with both my upstream author hat and distro maintainer hat, the main advantages I see is not the isolation. It is that they have the potential to eliminate the massive amount of duplicated work between every distro re-packaging the same app, and ensure more timely availablity of new releases to end users by de-coupling from the distro release cycle. As an upstream author, I want the latest releases of my software to be available for users to install as quickly as possible. Distros largely aren't satisfying that desire as well as I would like. If I rely on distro packaging, there can 3-12 month delay before a distro gets my new release in front of a user depending on their release cycle. Then there is the problem of distro maintainers not packaging the app correctly by forgetting to correctly handle/enable new build deps. Or a distro maintainer ceases to have time to work on it, leaving users stuck on outdated releases indefinitely. Or any one of the 3rd party libraries my app relies on may be outdated. Maintaining a OS distro to a high standard takes alot of resources, and there are an uncountable number of Linux distros out there which users may end up using, which just amplifies the amount of resources needed. The sad thing is that they're essentially doing the same work over and over again, just with a different package format, all to end up delivering a user experiance that is largely identical when it comes to the desktop interface. Except that doesn't end up being identical largely due to problems with keeping packaging up2date with limited distro resources. No one distro ends up doing it right for every app, which is frustrating as both a user and upstream app maintainer. So flatpaks have the promise of getting get of a huge amount of duplicated effort at the application layer, allowing desktop apps to be packaged once and run anywhere. This shouldn't be read as saying distros don't add value. They certainly do. The ability to curate a set of software, such that users can choose to only install OSS packages is valuable. Users have greater confidence of quality in the distros, even if that is sometimes misplaced. The distro maintainers have also frequently highlighted problems to upstream wrt licensing of code. The distros have driven the security response processes to vulnerabilities too, which is especially valuable for the long tail of pacakges which don't have a dedicated upstream vulnerability handling process. There are many things distros have done well, but the amount of effort spent by distro maintainers to achieve this is enourmous and inefficient. When building flatpaks, while an upstream author may be well placed to build their own app and update it whenever there are important changes, they may not want to keep track of all the 3rd party library deps they build on top of. The flathub.org build gives you a base runtime, which for a GNOME app may have 90% of what you need to depend on, but there are usually still extra libraries to add. It is desirable to be able to re-issue application flatpaks whenever the base runtime, or any of the extra libs get updated. The distros should be able to add value here by providing the base runtimes, and by ensuring all likely library deps are pre-packaged, and being able to re-issue flatpaks anytime a dep gets updated. This should not require the distros to take on the job of actually writing flatpaks for the application leaf nodes though. Flatpaks have the promise of being able to benefit both the upstream authors and the distro maintainers, if we can figure out the right tradeoff. Keep the best aspects that distros provide, while reducing the amount of work distros have to do by avoiding need to re-package every leaf-application in distro specific formats. The tragedy would be if every distro ends up re-doing the creation and shipping of flatpaks, just as they do today with the distros specific packaging formats. With regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
Re: Retiring Bottles in favor of Flatpak provided by upstream
On Wed, Feb 8, 2023 at 5:06 AM Matthew Miller wrote: > > On Wed, Jan 25, 2023 at 10:00:22AM -0800, Adam Williamson wrote: > > No, that's the promise of Fedora Flatpaks, which is an effort with a > > distinct identity and philosophy (but which is, uh, not being its best > > possible self so far, I think everyone would agree). It's not the > > Joining this discussion late (I plead "FOSDEM"), but I want to chime in on > this -- I do agree, and think that making that better should be a focus. > > Not only will this make things better on Fedora Silverblue (and others), but > it also is a way we can expand our reach -- we can bring the benefits of > distro packaging (with, you know, guidelines and policies and transparency > and so on) to people who might be running a different distro underneath. > > (And then hopefully coax them over entirely. I mean, if they want. No > pressure.) > I already know of a couple of distros considering using Fedora Flatpaks over Flathub for three reasons: 1. All OSS 2. Transparent build 3. Multi-arch -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Retiring Bottles in favor of Flatpak provided by upstream
On Wed, Jan 25, 2023 at 10:00:22AM -0800, Adam Williamson wrote: > No, that's the promise of Fedora Flatpaks, which is an effort with a > distinct identity and philosophy (but which is, uh, not being its best > possible self so far, I think everyone would agree). It's not the Joining this discussion late (I plead "FOSDEM"), but I want to chime in on this -- I do agree, and think that making that better should be a focus. Not only will this make things better on Fedora Silverblue (and others), but it also is a way we can expand our reach -- we can bring the benefits of distro packaging (with, you know, guidelines and policies and transparency and so on) to people who might be running a different distro underneath. (And then hopefully coax them over entirely. I mean, if they want. No pressure.) -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Retiring Bottles in favor of Flatpak provided by upstream
On Fri, Jan 27, 2023 at 12:15 AM Sandro wrote: > > Having read all the responses, I'm more inclined to head down the road > of orphanage, giving other people a chance to adopt the package. Due to > my limited knowledge of (packaging) Rust, I don't feel I'm the right > person to be main admin for Bottles. I didn't know about the Rust > dependency when I adopted it, nor did I pay attention to the fact that > there were still co-maintainers listed, whom I could have asked before > adopting Bottles. Just note that Bottles itself still contains no Rust code and is "pure Python", as far as I can tell. If orjson had already been packaged for Fedora, you'd probably not even notice that one of the many Python packages with "native" modules in Bottles' dependency tree is actually implemented in Rust and not in C. :) Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Retiring Bottles in favor of Flatpak provided by upstream
Well, well, well. What a surprise. I'd never thought getting this amount of response. Let me try to answer some questions that came up as best as I can. I will not go into the discussion of RPM vs. Flatpak. That should probably be carried on in a thread of its own. Suffice to say that my knowledge of Flatpak as well as Rust (packaging) is limited. What I didn't include in my announcement is the fact I only recently picked up Bottles when it was last orphaned. Seeing that no-one else joined the group of maintainers then, I'd bet Bottles would be retired by now. Pete Walter wrote: Can you assign the package to me instead of retiring it? I can get it updated so we can keep it in Fedora. There's an open PR [1] for getting the package updated to 2022.10.14.1. Meanwhile the version scheme has been changed and the latest release is now 50.2 - six releases onward. PRs are welcome. I'd be willing to hand the package to you. But I'd like to actually hear from the co-maintainers, who have been maintaining the package de facto before I adopted it. Fabio Valentini wrote: It looks like Bottles itself doesn't contain any Rust code, so I assume some of its Python dependencies now build native modules that are implemented in Rust? ... If the projects use maturin as their build backend, some more work is involved, since packaging maturin itself for Fedora will require significant investment of time and resources (that I am currently unable to provide alone). Maxwell G via devel wrote: What (rust) dependencies are missing? Is it just python-orjson? ... I'm not sure I can commit to maintaining these myself, though. Let me know if you're interested in helping out. Yes, orjson has been mentioned by @atim and @thunderbirdtr, the co-maintainers, in the PR. If that becomes available there might be some progress to be made in keeping up with upstream. Albeit, working with upstream appears to have been a mixed bag (reading between the lines in the comments). But since I have not been experiencing this first hand, I'd prefer the co-maintainers to elaborate. Let me finish with some thoughts on how to go forward. I thought about retiring the package, because we were unable to get an update out the door due to the dependency on python-orjson and because the package had been orphaned before. So, when I received the request from upstream, it seemed like a reasonable solution to get people to use the latest release. Users I had contact with, didn't mind me referring them to the Flathub release. Having read all the responses, I'm more inclined to head down the road of orphanage, giving other people a chance to adopt the package. Due to my limited knowledge of (packaging) Rust, I don't feel I'm the right person to be main admin for Bottles. I didn't know about the Rust dependency when I adopted it, nor did I pay attention to the fact that there were still co-maintainers listed, whom I could have asked before adopting Bottles. I'll ponder my options a little longer and hope the co-maintainers will shed their light on the state of affairs. Cheers, Sandro [1] https://src.fedoraproject.org/rpms/bottles/pull-request/1 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Retiring Bottles in favor of Flatpak provided by upstream
I’ve been wanting to package python-orjson specifically, and to get up to speed on Rust packaging in general. I would be happy to co-maintain python-orjson and its dependencies. It’s a weak dependency for python-fastapi, and python-cattrs would like to have it for some integration tests. – Ben Beasley (FAS music) On Thu, Jan 26, 2023, at 12:29 PM, Maxwell G via devel wrote: > On Tue Jan 24, 2023 at 22:44 +0100, Sandro wrote: >> Development of Bottles is moving fast and we have been struggling to >> keep up with upstream releases, especially since the introduction of >> Rust components. > > What (rust) dependencies are missing? Is it just python-orjson? > > I worked on packaging that last night. It seems this library is gaining > in popularity. Four new rust dependencies and updating pyo3 to 0.17 > (while creating compat packages for 0.16) are needed. Updating pyo3 is > straightforward and Fabio started working on it (thanks!). > > https://copr.fedorainfracloud.org/coprs/gotmax23/orjson/builds/ > https://git.sr.ht/~gotmax23/fedora-python-orjson > > I'm not sure I can commit to maintaining these myself, though. Let me > know if you're interested in helping out. > >> Upstream has approached the maintainers [1,2] and asked us to retire the >> package in favor of the Flatpak packages provided by upstream. > > I wish this upstream was more friendly to distribution packagers... > Approaching downstream maintainers like this feels inappropriate and > somewhat antithetical to the tenets of OSS. > > -- > Maxwell G (@gotmax23) > Pronouns: He/Him/His > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Retiring Bottles in favor of Flatpak provided by upstream
On Tue Jan 24, 2023 at 22:44 +0100, Sandro wrote: > Development of Bottles is moving fast and we have been struggling to > keep up with upstream releases, especially since the introduction of > Rust components. What (rust) dependencies are missing? Is it just python-orjson? I worked on packaging that last night. It seems this library is gaining in popularity. Four new rust dependencies and updating pyo3 to 0.17 (while creating compat packages for 0.16) are needed. Updating pyo3 is straightforward and Fabio started working on it (thanks!). https://copr.fedorainfracloud.org/coprs/gotmax23/orjson/builds/ https://git.sr.ht/~gotmax23/fedora-python-orjson I'm not sure I can commit to maintaining these myself, though. Let me know if you're interested in helping out. > Upstream has approached the maintainers [1,2] and asked us to retire the > package in favor of the Flatpak packages provided by upstream. I wish this upstream was more friendly to distribution packagers... Approaching downstream maintainers like this feels inappropriate and somewhat antithetical to the tenets of OSS. -- Maxwell G (@gotmax23) Pronouns: He/Him/His ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Retiring Bottles in favor of Flatpak provided by upstream
On Thu, Jan 26, 2023 at 12:01 PM Adam Williamson wrote: > > On Thu, 2023-01-26 at 14:55 +0100, Jiri Eischmann wrote: > > Robert Marcano via devel píše v Čt 26. 01. 2023 v 09:00 -0400: > > > On 1/26/23 8:42 AM, Jiri Eischmann wrote: > > > > Vít Ondruch píše v St 25. 01. 2023 v 18:01 +0100: > > > > > > > > > > Dne 25. 01. 23 v 15:59 Josh Boyer napsal(a): > > > > > > On Wed, Jan 25, 2023 at 5:56 AM Vít Ondruch > > > > > > > > > > > > wrote: > > > > > > > I am not user of Bottles so I won't complain about this > > > > > > > particular case, > > > > > > > but the push towards (upstream) Flatpaks is unfortunate :/ > > > > > > Can you elaborate on why you feel that way? > > > > > > > > > > > > > > > I don't trust upstream Flatpacks. I don't trust they follow any > > > > > standard > > > > > except standard of their authors. > > > > > > > > I maintain both packages in Fedora and flatpaks on Flathub, so I > > > > can > > > > compare. The review to get an app to Flathub was as thorough as > > > > Fedora > > > > package review. In some ways even stricter. It's not like "it > > > > builds, > > > > it runs, you're good to go". They care about some standards, about > > > > builds being verifiable etc. > > > > > > That doesn't seems to be enforced because many builds scripts just > > > download binaries built by other projects, for example; > > > > > > https://github.com/flathub/org.gnome.gitlab.somas.Apostrophe/blob/master/org.gnome.gitlab.somas.Apostrophe.json#L89 > > > > > > Note: building the entire pandoc and TeX toolchain is very hard and I > > > understand this example packager decision, but It doesn't make more > > > trustful that version that one on Fedora. > > > > > > Flathub is definitely more flexible at that. I was involved in the deal > > with Mozilla which was not willing to do special builds in Flathub > > infra since from their point of view it was more secure to use builds > > done in their infra and just upload them to Flathub. We still found > > having official builds from Mozilla and Mozilla officially endorsing > > Flathub more beneficial than having Firefox rebuilt by a 3rd party in > > Flathub infra. > > > > But Flathub is still a curated repo. If you want to deviate from > > standards you have to justify it, if you're doing something fishy your > > flatpak may be taken out. But ultimetaly you have to trust the author, > > but that applies to Fedora, too, just to lesser extend. > > Firefox is an interesting example, though, because it's *exactly* a > case where I trust the Fedora builds more than I trust upstream's. > Mozilla makes some, to me, sub-optimal choices in search of revenue; > this isn't a dilemma Fedora has. (This is also why I run Fennec, not > Mozilla's Firefox, on Android). This was one of the main nits I had > running Silverblue on my main system for a while, actually - the baked- > in Fedora firefox package couldn't play h264 video, to which a common > 'fix' is to just install the Mozilla flatpak instead, but I didn't want > to do that because I'd much rather have a Fedora packaged build. Mozilla makes other questionable decisions in their builds too, like having ASLR disabled. It's actually hard to figure out what upstreams are doing with their own builds, and sometimes they intentionally make it harder to figure it out. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Retiring Bottles in favor of Flatpak provided by upstream
On Thu, 2023-01-26 at 15:49 +, Patrick Griffis via devel wrote: > > IMHO, retiring a Fedora package in favor of an upstream binary of > > whatever > > kind (Flatpak, Snap, AppImage, RPM, binary tarball, whatever) is a > > major > > disservice to Fedora users and defeats the whole point of having a > > distribution to begin with. > > How is an orphan package a good service to users? It will just become > outdated and degrade over time. I think it is far more responsible, > and respectful of users, to accept that some packages are better > maintained elsewhere. Orphaned packages get automatically retired after a short period of time if nobody adopts them. So orphaning is a courtesy to give someone else a *chance* to adopt the package; if nobody does, it'll then get retired without you having to do anything extra. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Retiring Bottles in favor of Flatpak provided by upstream
On Thu, 2023-01-26 at 14:55 +0100, Jiri Eischmann wrote: > Robert Marcano via devel píše v Čt 26. 01. 2023 v 09:00 -0400: > > On 1/26/23 8:42 AM, Jiri Eischmann wrote: > > > Vít Ondruch píše v St 25. 01. 2023 v 18:01 +0100: > > > > > > > > Dne 25. 01. 23 v 15:59 Josh Boyer napsal(a): > > > > > On Wed, Jan 25, 2023 at 5:56 AM Vít Ondruch > > > > > > > > > > wrote: > > > > > > I am not user of Bottles so I won't complain about this > > > > > > particular case, > > > > > > but the push towards (upstream) Flatpaks is unfortunate :/ > > > > > Can you elaborate on why you feel that way? > > > > > > > > > > > > I don't trust upstream Flatpacks. I don't trust they follow any > > > > standard > > > > except standard of their authors. > > > > > > I maintain both packages in Fedora and flatpaks on Flathub, so I > > > can > > > compare. The review to get an app to Flathub was as thorough as > > > Fedora > > > package review. In some ways even stricter. It's not like "it > > > builds, > > > it runs, you're good to go". They care about some standards, about > > > builds being verifiable etc. > > > > That doesn't seems to be enforced because many builds scripts just > > download binaries built by other projects, for example; > > > > https://github.com/flathub/org.gnome.gitlab.somas.Apostrophe/blob/master/org.gnome.gitlab.somas.Apostrophe.json#L89 > > > > Note: building the entire pandoc and TeX toolchain is very hard and I > > understand this example packager decision, but It doesn't make more > > trustful that version that one on Fedora. > > > > Flathub is definitely more flexible at that. I was involved in the deal > with Mozilla which was not willing to do special builds in Flathub > infra since from their point of view it was more secure to use builds > done in their infra and just upload them to Flathub. We still found > having official builds from Mozilla and Mozilla officially endorsing > Flathub more beneficial than having Firefox rebuilt by a 3rd party in > Flathub infra. > > But Flathub is still a curated repo. If you want to deviate from > standards you have to justify it, if you're doing something fishy your > flatpak may be taken out. But ultimetaly you have to trust the author, > but that applies to Fedora, too, just to lesser extend. Firefox is an interesting example, though, because it's *exactly* a case where I trust the Fedora builds more than I trust upstream's. Mozilla makes some, to me, sub-optimal choices in search of revenue; this isn't a dilemma Fedora has. (This is also why I run Fennec, not Mozilla's Firefox, on Android). This was one of the main nits I had running Silverblue on my main system for a while, actually - the baked- in Fedora firefox package couldn't play h264 video, to which a common 'fix' is to just install the Mozilla flatpak instead, but I didn't want to do that because I'd much rather have a Fedora packaged build. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Retiring Bottles in favor of Flatpak provided by upstream
On Thu, Jan 26 2023 at 03:49:55 PM -, Patrick Griffis via devel wrote: How is an orphan package a good service to users? It will just become outdated and degrade over time. Either (a) somebody else will take the package after it has been orphaned, or else (b) the package will be retired automatically after a few weeks. It won't stay orphaned for very long. If the only problem with the package is the current Fedora maintainer isn't able to keep up with updates, as seems to be the case here, then orphaning gives a chance for somebody else to try to do better. Hopefully a new maintainer will only take the package if confident that they can keep it updated. Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Retiring Bottles in favor of Flatpak provided by upstream
Dne 26. 01. 23 v 16:07 Jiri Eischmann napsal(a): Vít Ondruch píše v Čt 26. 01. 2023 v 15:37 +0100: Dne 26. 01. 23 v 14:55 Jiri Eischmann napsal(a): Robert Marcano via devel píše v Čt 26. 01. 2023 v 09:00 -0400: On 1/26/23 8:42 AM, Jiri Eischmann wrote: Vít Ondruch píše v St 25. 01. 2023 v 18:01 +0100: Dne 25. 01. 23 v 15:59 Josh Boyer napsal(a): On Wed, Jan 25, 2023 at 5:56 AM Vít Ondruch wrote: I am not user of Bottles so I won't complain about this particular case, but the push towards (upstream) Flatpaks is unfortunate :/ Can you elaborate on why you feel that way? BTW does the flathub version support all the platforms Fedora does? Cannot tell from the Flathub pages :/ I don't trust upstream Flatpacks. I don't trust they follow any standard except standard of their authors. I maintain both packages in Fedora and flatpaks on Flathub, so I can compare. The review to get an app to Flathub was as thorough as Fedora package review. In some ways even stricter. It's not like "it builds, it runs, you're good to go". They care about some standards, about builds being verifiable etc. That doesn't seems to be enforced because many builds scripts just download binaries built by other projects, for example; https://github.com/flathub/org.gnome.gitlab.somas.Apostrophe/blob/master/org.gnome.gitlab.somas.Apostrophe.json#L89 Note: building the entire pandoc and TeX toolchain is very hard and I understand this example packager decision, but It doesn't make more trustful that version that one on Fedora. Yes, this is good example. I cannot imagine anybody would do the reviews for the 3rd party libraries. That is the main difference to Fedora, because there are no 3rd party libraries there. But let's not pretend it doesn't happen in Fedora at all. Yes, of course you are right. But the mindset is what matters to me. We try to do our best to avoid vendoring and 3rd party libraries. We do our best to use single copy of library which is properly maintained. Flatpacks on Flathub are antithesis to what Fedora does in this regard. Yes, unlike on Flathub guidelines rule it out, but in the reality I've seen quite a few packages with (unacknowledged) bundled libraries in Fedora repos. The package goes through the initial review, a new version introduces a new dependency which is not available in the Fedora repo, you don't want to go through the hassle of introducing and maintaining a new package, you quietly bundle it. No source is pristine. It's always a compromise. Flathub is more flexible in what you can include in the flatpak This is mostly just flexibility for upstream. , but Flatpak mitigates it by isolation (although it may not be set strict enough for some apps). Isolation is not silver bullet. E.g. if Flatpak included vulnerable OpenSSL or OpenSSL which does not obey the system crypto policies, this would be asking for troubles. What Flathub does for identifying such SW? I don't think it can do much, but I might be wrong. Vít Jiri ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Retiring Bottles in favor of Flatpak provided by upstream
> IMHO, retiring a Fedora package in favor of an upstream binary of whatever > kind (Flatpak, Snap, AppImage, RPM, binary tarball, whatever) is a major > disservice to Fedora users and defeats the whole point of having a > distribution to begin with. How is an orphan package a good service to users? It will just become outdated and degrade over time. I think it is far more responsible, and respectful of users, to accept that some packages are better maintained elsewhere. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Retiring Bottles in favor of Flatpak provided by upstream
Vít Ondruch píše v Čt 26. 01. 2023 v 15:37 +0100: > > Dne 26. 01. 23 v 14:55 Jiri Eischmann napsal(a): > > Robert Marcano via devel píše v Čt 26. 01. 2023 v 09:00 -0400: > > > On 1/26/23 8:42 AM, Jiri Eischmann wrote: > > > > Vít Ondruch píše v St 25. 01. 2023 v 18:01 +0100: > > > > > Dne 25. 01. 23 v 15:59 Josh Boyer napsal(a): > > > > > > On Wed, Jan 25, 2023 at 5:56 AM Vít Ondruch > > > > > > > > > > > > wrote: > > > > > > > I am not user of Bottles so I won't complain about this > > > > > > > particular case, > > > > > > > but the push towards (upstream) Flatpaks is unfortunate > > > > > > > :/ > > > > > > Can you elaborate on why you feel that way? > > > > > > > > > > I don't trust upstream Flatpacks. I don't trust they follow > > > > > any > > > > > standard > > > > > except standard of their authors. > > > > I maintain both packages in Fedora and flatpaks on Flathub, so > > > > I > > > > can > > > > compare. The review to get an app to Flathub was as thorough as > > > > Fedora > > > > package review. In some ways even stricter. It's not like "it > > > > builds, > > > > it runs, you're good to go". They care about some standards, > > > > about > > > > builds being verifiable etc. > > > That doesn't seems to be enforced because many builds scripts > > > just > > > download binaries built by other projects, for example; > > > > > > https://github.com/flathub/org.gnome.gitlab.somas.Apostrophe/blob/master/org.gnome.gitlab.somas.Apostrophe.json#L89 > > > > > > Note: building the entire pandoc and TeX toolchain is very hard > > > and I > > > understand this example packager decision, but It doesn't make > > > more > > > trustful that version that one on Fedora. > > > Yes, this is good example. I cannot imagine anybody would do the > reviews > for the 3rd party libraries. That is the main difference to Fedora, > because there are no 3rd party libraries there. But let's not pretend it doesn't happen in Fedora at all. Yes, unlike on Flathub guidelines rule it out, but in the reality I've seen quite a few packages with (unacknowledged) bundled libraries in Fedora repos. The package goes through the initial review, a new version introduces a new dependency which is not available in the Fedora repo, you don't want to go through the hassle of introducing and maintaining a new package, you quietly bundle it. No source is pristine. It's always a compromise. Flathub is more flexible in what you can include in the flatpak, but Flatpak mitigates it by isolation (although it may not be set strict enough for some apps). Jiri > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Retiring Bottles in favor of Flatpak provided by upstream
Maybe we can start by filtering out the most outrageous applications: anything that uses --filesystem=home, --filesystem=host, or unfiltered session bus access. That still leaves plenty of possible sandbox holes, but it's better than nothing. We could do this just in GNOME Software and KDE Discover for starters, but it'd probably be confusing for the software centers to show fewer apps than Flathub has available. So maybe would be better for the software centers to just present the apps as insecure, and try to convince Flathub to have them removed. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Retiring Bottles in favor of Flatpak provided by upstream
On Thu, Jan 26 2023 at 09:23:35 AM -0500, Neal Gompa wrote: But we know that people don't read those. We also know that ISVs cannot generally be trusted with regards to the permissions they set for their own apps. This is literally why Android and iOS changed their model. If you want to encourage "upstream Flatpaks", you cannot do this reasonably with a "trust-developer" mindset, because there is no longer a check to keep them from doing stupid/malicious things. I agree, but if we tighten the rules then these apps will just disappear. So I'm not sure what to do about it. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Retiring Bottles in favor of Flatpak provided by upstream
Dne 26. 01. 23 v 14:55 Jiri Eischmann napsal(a): Robert Marcano via devel píše v Čt 26. 01. 2023 v 09:00 -0400: On 1/26/23 8:42 AM, Jiri Eischmann wrote: Vít Ondruch píše v St 25. 01. 2023 v 18:01 +0100: Dne 25. 01. 23 v 15:59 Josh Boyer napsal(a): On Wed, Jan 25, 2023 at 5:56 AM Vít Ondruch wrote: I am not user of Bottles so I won't complain about this particular case, but the push towards (upstream) Flatpaks is unfortunate :/ Can you elaborate on why you feel that way? I don't trust upstream Flatpacks. I don't trust they follow any standard except standard of their authors. I maintain both packages in Fedora and flatpaks on Flathub, so I can compare. The review to get an app to Flathub was as thorough as Fedora package review. In some ways even stricter. It's not like "it builds, it runs, you're good to go". They care about some standards, about builds being verifiable etc. That doesn't seems to be enforced because many builds scripts just download binaries built by other projects, for example; https://github.com/flathub/org.gnome.gitlab.somas.Apostrophe/blob/master/org.gnome.gitlab.somas.Apostrophe.json#L89 Note: building the entire pandoc and TeX toolchain is very hard and I understand this example packager decision, but It doesn't make more trustful that version that one on Fedora. Yes, this is good example. I cannot imagine anybody would do the reviews for the 3rd party libraries. That is the main difference to Fedora, because there are no 3rd party libraries there. Flathub is definitely more flexible at that. I was involved in the deal with Mozilla which was not willing to do special builds in Flathub infra since from their point of view it was more secure to use builds done in their infra and just upload them to Flathub. We still found having official builds from Mozilla and Mozilla officially endorsing Flathub more beneficial than having Firefox rebuilt by a 3rd party in Flathub infra. But Flathub is still a curated repo. If you want to deviate from standards you have to justify it, if you're doing something fishy your flatpak may be taken out. But ultimetaly you have to trust the author, but that applies to Fedora, too, just to lesser extend. I trust authors of the SW, but I don't trust in their trust to the libraries they bundle in the Flatpak. Vít Jiri ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Retiring Bottles in favor of Flatpak provided by upstream
On Thu, Jan 26, 2023 at 8:25 AM Jiri Eischmann wrote: > > Neal Gompa píše v Čt 26. 01. 2023 v 07:51 -0500: > > On Thu, Jan 26, 2023 at 7:43 AM Jiri Eischmann > > wrote: > > > > > > Vít Ondruch píše v St 25. 01. 2023 v 18:01 +0100: > > > > > > > > Dne 25. 01. 23 v 15:59 Josh Boyer napsal(a): > > > > > On Wed, Jan 25, 2023 at 5:56 AM Vít Ondruch > > > > > > > > > > wrote: > > > > > > I am not user of Bottles so I won't complain about this > > > > > > particular case, > > > > > > but the push towards (upstream) Flatpaks is unfortunate :/ > > > > > Can you elaborate on why you feel that way? > > > > > > > > > > > > I don't trust upstream Flatpacks. I don't trust they follow any > > > > standard > > > > except standard of their authors. > > > > > > I maintain both packages in Fedora and flatpaks on Flathub, so I > > > can > > > compare. The review to get an app to Flathub was as thorough as > > > Fedora > > > package review. In some ways even stricter. It's not like "it > > > builds, > > > it runs, you're good to go". They care about some standards, about > > > builds being verifiable etc. > > > The Flathub CI seems to be more extensive than what we have in > > > Fedora. > > > > > > > All of that is optional in Flathub too. That makes it inherently > > weaker. Firefox doesn't go through that, nor does OBS Studio. > > > > > > And I don't like Flatpacks, because their main advantage (their > > > > isolation) is also their biggest disadvantage. There can't be > > > > both > > > > without making compromises. If I am not mistaken, the isolation > > > > is > > > > also > > > > mostly myth, because it is disabled in most cases. > > > > > > Why? Apps come with permissions they require (which you can > > > override > > > btw). Just because some apps require access to your whole > > > filesystem > > > doesn't mean the isolation is a myth. You know the permissions, you > > > may > > > decide not to use such an app. None of the flatpaks maintained by > > > me > > > require this kind of access and are well isolated. > > > > > > > How are people supposed to figure out you can change app permissions? > > It's described precisely nowhere. For GNOME in particular, there's no > > way to review and update app permissions (either to open them up or > > close them further). KDE Plasma is getting this capability with KDE > > Plasma 5.27. > > I mentioned overriding the permissions only as a side note. I don't > think it's something that necessarily has to be advertised to users, > simply because it can break apps. > However, any user can review the permission beforehand and decide > whether they're OK with them or not. That's well advertised in GNOME > Software and KDE Discover already. > But we know that people don't read those. We also know that ISVs cannot generally be trusted with regards to the permissions they set for their own apps. This is literally why Android and iOS changed their model. If you want to encourage "upstream Flatpaks", you cannot do this reasonably with a "trust-developer" mindset, because there is no longer a check to keep them from doing stupid/malicious things. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Retiring Bottles in favor of Flatpak provided by upstream
On 26/01/2023 13:42, Jiri Eischmann wrote: I maintain both packages in Fedora and flatpaks on Flathub, so I can compare. The review to get an app to Flathub was as thorough as Fedora package review. In some ways even stricter. It's not like "it builds, it runs, you're good to go". They care about some standards, about builds being verifiable etc. The Flathub CI seems to be more extensive than what we have in Fedora. I can't agree. Some links: - https://github.com/flathub/org.signal.Signal/blob/master/org.signal.Signal.yaml#L67-L70 - https://github.com/flathub/im.riot.Riot/blob/master/im.riot.Riot.yaml#L98-L102 - https://github.com/flathub/org.blender.Blender/blob/master/org.blender.Blender.json#L149-L152 These popular apps are third-party DEB repacks. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Retiring Bottles in favor of Flatpak provided by upstream
Robert Marcano via devel píše v Čt 26. 01. 2023 v 09:00 -0400: > On 1/26/23 8:42 AM, Jiri Eischmann wrote: > > Vít Ondruch píše v St 25. 01. 2023 v 18:01 +0100: > > > > > > Dne 25. 01. 23 v 15:59 Josh Boyer napsal(a): > > > > On Wed, Jan 25, 2023 at 5:56 AM Vít Ondruch > > > > > > > > wrote: > > > > > I am not user of Bottles so I won't complain about this > > > > > particular case, > > > > > but the push towards (upstream) Flatpaks is unfortunate :/ > > > > Can you elaborate on why you feel that way? > > > > > > > > > I don't trust upstream Flatpacks. I don't trust they follow any > > > standard > > > except standard of their authors. > > > > I maintain both packages in Fedora and flatpaks on Flathub, so I > > can > > compare. The review to get an app to Flathub was as thorough as > > Fedora > > package review. In some ways even stricter. It's not like "it > > builds, > > it runs, you're good to go". They care about some standards, about > > builds being verifiable etc. > > That doesn't seems to be enforced because many builds scripts just > download binaries built by other projects, for example; > > https://github.com/flathub/org.gnome.gitlab.somas.Apostrophe/blob/master/org.gnome.gitlab.somas.Apostrophe.json#L89 > > Note: building the entire pandoc and TeX toolchain is very hard and I > understand this example packager decision, but It doesn't make more > trustful that version that one on Fedora. > > Flathub is definitely more flexible at that. I was involved in the deal with Mozilla which was not willing to do special builds in Flathub infra since from their point of view it was more secure to use builds done in their infra and just upload them to Flathub. We still found having official builds from Mozilla and Mozilla officially endorsing Flathub more beneficial than having Firefox rebuilt by a 3rd party in Flathub infra. But Flathub is still a curated repo. If you want to deviate from standards you have to justify it, if you're doing something fishy your flatpak may be taken out. But ultimetaly you have to trust the author, but that applies to Fedora, too, just to lesser extend. Jiri > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Retiring Bottles in favor of Flatpak provided by upstream
Neal Gompa píše v Čt 26. 01. 2023 v 07:51 -0500: > On Thu, Jan 26, 2023 at 7:43 AM Jiri Eischmann > wrote: > > > > Vít Ondruch píše v St 25. 01. 2023 v 18:01 +0100: > > > > > > Dne 25. 01. 23 v 15:59 Josh Boyer napsal(a): > > > > On Wed, Jan 25, 2023 at 5:56 AM Vít Ondruch > > > > > > > > wrote: > > > > > I am not user of Bottles so I won't complain about this > > > > > particular case, > > > > > but the push towards (upstream) Flatpaks is unfortunate :/ > > > > Can you elaborate on why you feel that way? > > > > > > > > > I don't trust upstream Flatpacks. I don't trust they follow any > > > standard > > > except standard of their authors. > > > > I maintain both packages in Fedora and flatpaks on Flathub, so I > > can > > compare. The review to get an app to Flathub was as thorough as > > Fedora > > package review. In some ways even stricter. It's not like "it > > builds, > > it runs, you're good to go". They care about some standards, about > > builds being verifiable etc. > > The Flathub CI seems to be more extensive than what we have in > > Fedora. > > > > All of that is optional in Flathub too. That makes it inherently > weaker. Firefox doesn't go through that, nor does OBS Studio. > > > > And I don't like Flatpacks, because their main advantage (their > > > isolation) is also their biggest disadvantage. There can't be > > > both > > > without making compromises. If I am not mistaken, the isolation > > > is > > > also > > > mostly myth, because it is disabled in most cases. > > > > Why? Apps come with permissions they require (which you can > > override > > btw). Just because some apps require access to your whole > > filesystem > > doesn't mean the isolation is a myth. You know the permissions, you > > may > > decide not to use such an app. None of the flatpaks maintained by > > me > > require this kind of access and are well isolated. > > > > How are people supposed to figure out you can change app permissions? > It's described precisely nowhere. For GNOME in particular, there's no > way to review and update app permissions (either to open them up or > close them further). KDE Plasma is getting this capability with KDE > Plasma 5.27. I mentioned overriding the permissions only as a side note. I don't think it's something that necessarily has to be advertised to users, simply because it can break apps. However, any user can review the permission beforehand and decide whether they're OK with them or not. That's well advertised in GNOME Software and KDE Discover already. Jiri ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Retiring Bottles in favor of Flatpak provided by upstream
On 1/26/23 8:42 AM, Jiri Eischmann wrote: Vít Ondruch píše v St 25. 01. 2023 v 18:01 +0100: Dne 25. 01. 23 v 15:59 Josh Boyer napsal(a): On Wed, Jan 25, 2023 at 5:56 AM Vít Ondruch wrote: I am not user of Bottles so I won't complain about this particular case, but the push towards (upstream) Flatpaks is unfortunate :/ Can you elaborate on why you feel that way? I don't trust upstream Flatpacks. I don't trust they follow any standard except standard of their authors. I maintain both packages in Fedora and flatpaks on Flathub, so I can compare. The review to get an app to Flathub was as thorough as Fedora package review. In some ways even stricter. It's not like "it builds, it runs, you're good to go". They care about some standards, about builds being verifiable etc. That doesn't seems to be enforced because many builds scripts just download binaries built by other projects, for example; https://github.com/flathub/org.gnome.gitlab.somas.Apostrophe/blob/master/org.gnome.gitlab.somas.Apostrophe.json#L89 Note: building the entire pandoc and TeX toolchain is very hard and I understand this example packager decision, but It doesn't make more trustful that version that one on Fedora. The Flathub CI seems to be more extensive than what we have in Fedora. And I don't like Flatpacks, because their main advantage (their isolation) is also their biggest disadvantage. There can't be both without making compromises. If I am not mistaken, the isolation is also mostly myth, because it is disabled in most cases. Why? Apps come with permissions they require (which you can override btw). Just because some apps require access to your whole filesystem doesn't mean the isolation is a myth. You know the permissions, you may decide not to use such an app. None of the flatpaks maintained by me require this kind of access and are well isolated. Jiri ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Retiring Bottles in favor of Flatpak provided by upstream
On Thu, Jan 26, 2023 at 7:43 AM Jiri Eischmann wrote: > > Vít Ondruch píše v St 25. 01. 2023 v 18:01 +0100: > > > > Dne 25. 01. 23 v 15:59 Josh Boyer napsal(a): > > > On Wed, Jan 25, 2023 at 5:56 AM Vít Ondruch > > > wrote: > > > > I am not user of Bottles so I won't complain about this > > > > particular case, > > > > but the push towards (upstream) Flatpaks is unfortunate :/ > > > Can you elaborate on why you feel that way? > > > > > > I don't trust upstream Flatpacks. I don't trust they follow any > > standard > > except standard of their authors. > > I maintain both packages in Fedora and flatpaks on Flathub, so I can > compare. The review to get an app to Flathub was as thorough as Fedora > package review. In some ways even stricter. It's not like "it builds, > it runs, you're good to go". They care about some standards, about > builds being verifiable etc. > The Flathub CI seems to be more extensive than what we have in Fedora. > All of that is optional in Flathub too. That makes it inherently weaker. Firefox doesn't go through that, nor does OBS Studio. > > And I don't like Flatpacks, because their main advantage (their > > isolation) is also their biggest disadvantage. There can't be both > > without making compromises. If I am not mistaken, the isolation is > > also > > mostly myth, because it is disabled in most cases. > > Why? Apps come with permissions they require (which you can override > btw). Just because some apps require access to your whole filesystem > doesn't mean the isolation is a myth. You know the permissions, you may > decide not to use such an app. None of the flatpaks maintained by me > require this kind of access and are well isolated. > How are people supposed to figure out you can change app permissions? It's described precisely nowhere. For GNOME in particular, there's no way to review and update app permissions (either to open them up or close them further). KDE Plasma is getting this capability with KDE Plasma 5.27. And Flatseal (a third party app that someone has to figure out exists) isn't a valid answer. Just like how customizing GNOME using Tweaks isn't a valid answer. :) -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Retiring Bottles in favor of Flatpak provided by upstream
Vít Ondruch píše v St 25. 01. 2023 v 18:01 +0100: > > Dne 25. 01. 23 v 15:59 Josh Boyer napsal(a): > > On Wed, Jan 25, 2023 at 5:56 AM Vít Ondruch > > wrote: > > > I am not user of Bottles so I won't complain about this > > > particular case, > > > but the push towards (upstream) Flatpaks is unfortunate :/ > > Can you elaborate on why you feel that way? > > > I don't trust upstream Flatpacks. I don't trust they follow any > standard > except standard of their authors. I maintain both packages in Fedora and flatpaks on Flathub, so I can compare. The review to get an app to Flathub was as thorough as Fedora package review. In some ways even stricter. It's not like "it builds, it runs, you're good to go". They care about some standards, about builds being verifiable etc. The Flathub CI seems to be more extensive than what we have in Fedora. > And I don't like Flatpacks, because their main advantage (their > isolation) is also their biggest disadvantage. There can't be both > without making compromises. If I am not mistaken, the isolation is > also > mostly myth, because it is disabled in most cases. Why? Apps come with permissions they require (which you can override btw). Just because some apps require access to your whole filesystem doesn't mean the isolation is a myth. You know the permissions, you may decide not to use such an app. None of the flatpaks maintained by me require this kind of access and are well isolated. Jiri ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Retiring Bottles in favor of Flatpak provided by upstream
Adam Williamson wrote: > OTOH, it's not reasonable to dictate to the person maintaining a Fedora > package whether they should think that's a reasonable use of their time > or not. The current maintainers of Bottles decided they trust the > upstream developers to distribute their software 'properly' and thus > didn't want to dedicate their time to maintaining the package any more; > that's entirely their decision to make. Sure, but they should not be allowed to directly retire the package in such a case, only to orphan it. > Of course, it should still be the case that someone who still sees > value in distribution packaging of bottles can take the package over if > they want to, as Pete Walter has already asked to do. Which is why the package must be orphaned, not retired. IMHO, retiring a Fedora package in favor of an upstream binary of whatever kind (Flatpak, Snap, AppImage, RPM, binary tarball, whatever) is a major disservice to Fedora users and defeats the whole point of having a distribution to begin with. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Retiring Bottles in favor of Flatpak provided by upstream
On Wed, 2023-01-25 at 17:42 +, Richard W.M. Jones wrote: > On Wed, Jan 25, 2023 at 06:01:17PM +0100, Vít Ondruch wrote: > > > > Dne 25. 01. 23 v 15:59 Josh Boyer napsal(a): > > > On Wed, Jan 25, 2023 at 5:56 AM Vít Ondruch wrote: > > > > I am not user of Bottles so I won't complain about this particular case, > > > > but the push towards (upstream) Flatpaks is unfortunate :/ > > > Can you elaborate on why you feel that way? > > > > > > I don't trust upstream Flatpacks. I don't trust they follow any > > standard except standard of their authors. > > > > And I don't like Flatpacks, because their main advantage (their > > isolation) is also their biggest disadvantage. There can't be both > > without making compromises. If I am not mistaken, the isolation is > > also mostly myth, because it is disabled in most cases. > > In addition to this, the supposed promise of Flatpaks (eg [1]) is that > they are built from Fedora's RPMs. No, that's the promise of Fedora Flatpaks, which is an effort with a distinct identity and philosophy (but which is, uh, not being its best possible self so far, I think everyone would agree). It's not the promise of flatpaks in general. > But how does that work for > "upstream" Flatpaks? How do we know they don't contain non-free > software? How do we ensure we can obtain and rebuild from source? Basically, you have to trust that the maintainer of the upstream F/OSS project cares about and ensures those things. I'm not 100% a fan of this either (having seen enough cases where upstream's interpretation of F/OSS differs from mine or Fedora's, and enough cases where upstream just didn't take enough care about it). OTOH, it's not reasonable to dictate to the person maintaining a Fedora package whether they should think that's a reasonable use of their time or not. The current maintainers of Bottles decided they trust the upstream developers to distribute their software 'properly' and thus didn't want to dedicate their time to maintaining the package any more; that's entirely their decision to make. Of course, it should still be the case that someone who still sees value in distribution packaging of bottles can take the package over if they want to, as Pete Walter has already asked to do. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Retiring Bottles in favor of Flatpak provided by upstream
On Wed, Jan 25, 2023 at 06:01:17PM +0100, Vít Ondruch wrote: > > Dne 25. 01. 23 v 15:59 Josh Boyer napsal(a): > >On Wed, Jan 25, 2023 at 5:56 AM Vít Ondruch wrote: > >>I am not user of Bottles so I won't complain about this particular case, > >>but the push towards (upstream) Flatpaks is unfortunate :/ > >Can you elaborate on why you feel that way? > > > I don't trust upstream Flatpacks. I don't trust they follow any > standard except standard of their authors. > > And I don't like Flatpacks, because their main advantage (their > isolation) is also their biggest disadvantage. There can't be both > without making compromises. If I am not mistaken, the isolation is > also mostly myth, because it is disabled in most cases. In addition to this, the supposed promise of Flatpaks (eg [1]) is that they are built from Fedora's RPMs. But how does that work for "upstream" Flatpaks? How do we know they don't contain non-free software? How do we ensure we can obtain and rebuild from source? Rich. [1] https://fedoramagazine.org/an-introduction-to-fedora-flatpaks/ -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Retiring Bottles in favor of Flatpak provided by upstream
Dne 25. 01. 23 v 15:59 Josh Boyer napsal(a): On Wed, Jan 25, 2023 at 5:56 AM Vít Ondruch wrote: I am not user of Bottles so I won't complain about this particular case, but the push towards (upstream) Flatpaks is unfortunate :/ Can you elaborate on why you feel that way? I don't trust upstream Flatpacks. I don't trust they follow any standard except standard of their authors. And I don't like Flatpacks, because their main advantage (their isolation) is also their biggest disadvantage. There can't be both without making compromises. If I am not mistaken, the isolation is also mostly myth, because it is disabled in most cases. Vít josh ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Retiring Bottles in favor of Flatpak provided by upstream
On Wed, Jan 25, 2023 at 5:56 AM Vít Ondruch wrote: > > I am not user of Bottles so I won't complain about this particular case, > but the push towards (upstream) Flatpaks is unfortunate :/ Can you elaborate on why you feel that way? josh ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Retiring Bottles in favor of Flatpak provided by upstream
On Wed, Jan 25, 2023 at 12:38 PM Pete Walter wrote: > > I am not happy about dropping Fedora packages in favor of upstream Flatpaks > either. > > Can you assign the package to me instead of retiring it? I can get it updated > so we can keep it in Fedora. It looks like Bottles itself doesn't contain any Rust code, so I assume some of its Python dependencies now build native modules that are implemented in Rust? If that's the case, then it should be possible to package them for Fedora. The most prominent example is probably python-cryptography, and assuming the Python packages use setuptools with the setuptools_rust backend for building the native module, it can be used as a guide for how to package Python packages with Rust dependencies correctly. If the projects use maturin as their build backend, some more work is involved, since packaging maturin itself for Fedora will require significant investment of time and resources (that I am currently unable to provide alone). However, it should be possible in almost all cases to "port" Python packages from maturin to setuptools_rust, since setuptools_rust is more flexible and less opinionated than maturin (and they are almost entirely compatible with each other, since they're developed by the same project). Additionally, Fedora builds don't need any of the additional bells and whistles that maturin provides for upstream development (i.e. cross-compilation to different targets + architectures), so porting projects back from maturin to setuptools_rust should usually be possible without losing any functionality that is required for building RPM packages for Fedora. Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Retiring Bottles in favor of Flatpak provided by upstream
Seems as bad practice to drop packages by upstream request. ср, 25 янв. 2023 г. в 14:38, Pete Walter : > > I am not happy about dropping Fedora packages in favor of upstream Flatpaks > either. > > Can you assign the package to me instead of retiring it? I can get it updated > so we can keep it in Fedora. > > Pete > > 25.01.2023, 10:56, "Vít Ondruch" : > > I am not user of Bottles so I won't complain about this particular case, > but the push towards (upstream) Flatpaks is unfortunate :/ > > > Vít > > > Dne 24. 01. 23 v 22:44 Sandro napsal(a): > > Hi, > > Development of Bottles is moving fast and we have been struggling to > keep up with upstream releases, especially since the introduction of > Rust components. > > Upstream has approached the maintainers [1,2] and asked us to retire > the package in favor of the Flatpak packages provided by upstream. > > I'm planning to move forward with retiring Bottles in the coming days. > I will add a comment in all open bug reports, letting users know they > should switch to the Flatpak release. > > Bottles in F36 and F37 will not receive any further updates unless > there are security related issues surfacing. > > [1] https://github.com/bottlesdevs/Bottles/issues/2345 > [2] https://bugzilla.redhat.com/show_bug.cgi?id=2160007 > > Cheers, > > Sandro > > , > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Retiring Bottles in favor of Flatpak provided by upstream
I am not happy about dropping Fedora packages in favor of upstream Flatpaks either. Can you assign the package to me instead of retiring it? I can get it updated so we can keep it in Fedora. Pete 25.01.2023, 10:56, "Vít Ondruch" :I am not user of Bottles so I won't complain about this particular case,but the push towards (upstream) Flatpaks is unfortunate :/VítDne 24. 01. 23 v 22:44 Sandro napsal(a): Hi, Development of Bottles is moving fast and we have been struggling to keep up with upstream releases, especially since the introduction of Rust components. Upstream has approached the maintainers [1,2] and asked us to retire the package in favor of the Flatpak packages provided by upstream. I'm planning to move forward with retiring Bottles in the coming days. I will add a comment in all open bug reports, letting users know they should switch to the Flatpak release. Bottles in F36 and F37 will not receive any further updates unless there are security related issues surfacing. [1] https://github.com/bottlesdevs/Bottles/issues/2345 [2] https://bugzilla.redhat.com/show_bug.cgi?id=2160007 Cheers, Sandro,___devel mailing list -- devel@lists.fedoraproject.orgTo unsubscribe send an email to devel-le...@lists.fedoraproject.orgFedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelinesList Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.orgDo not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Retiring Bottles in favor of Flatpak provided by upstream
I am not user of Bottles so I won't complain about this particular case, but the push towards (upstream) Flatpaks is unfortunate :/ Vít Dne 24. 01. 23 v 22:44 Sandro napsal(a): Hi, Development of Bottles is moving fast and we have been struggling to keep up with upstream releases, especially since the introduction of Rust components. Upstream has approached the maintainers [1,2] and asked us to retire the package in favor of the Flatpak packages provided by upstream. I'm planning to move forward with retiring Bottles in the coming days. I will add a comment in all open bug reports, letting users know they should switch to the Flatpak release. Bottles in F36 and F37 will not receive any further updates unless there are security related issues surfacing. [1] https://github.com/bottlesdevs/Bottles/issues/2345 [2] https://bugzilla.redhat.com/show_bug.cgi?id=2160007 Cheers, Sandro OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Retiring Bottles in favor of Flatpak provided by upstream
Hi, Development of Bottles is moving fast and we have been struggling to keep up with upstream releases, especially since the introduction of Rust components. Upstream has approached the maintainers [1,2] and asked us to retire the package in favor of the Flatpak packages provided by upstream. I'm planning to move forward with retiring Bottles in the coming days. I will add a comment in all open bug reports, letting users know they should switch to the Flatpak release. Bottles in F36 and F37 will not receive any further updates unless there are security related issues surfacing. [1] https://github.com/bottlesdevs/Bottles/issues/2345 [2] https://bugzilla.redhat.com/show_bug.cgi?id=2160007 Cheers, Sandro -- Sandro FAS: gui1ty IRC: Penguinpee Elsewhere: [Pp]enguinpee ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
