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):

Seems as bad practice to drop packages by upstream request. ср, 25 янв. 2023 г. в 14:38, Pete Walter <walter.pete(a)yandex.com&gt;: > > 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" <vondruch(a)redhat.com&gt;: > > 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(a)lists.fedoraproject.org > To unsubscribe send an email to devel-leave(a)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(a)lists.fedoraproject.org > To unsubscribe send an email to devel-leave(a)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

On Wed, Jan 25, 2023 at 5:56 AM Vít Ondruch <vondruch(a)redhat.com&gt; wrote: Can you elaborate on why you feel that way? josh

On Wed, Jan 25, 2023 at 06:01:17PM +0100, Vít Ondruch wrote: 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

Adam Williamson wrote: Sure, but they should not be allowed to directly retire the package in such a case, only to orphan it. 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

On Thu, Jan 26 2023 at 03:49:55 PM -0000, Patrick Griffis via devel <devel(a)lists.fedoraproject.org&gt; wrote: 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

On Wed, Jan 25, 2023 at 10:00:22AM -0800, Adam Williamson wrote: 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 <mattdm(a)fedoraproject.org&gt; Fedora Project Leader

Vít Ondruch píše v St 25. 01. 2023 v 18:01 +0100: 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. 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

Neal Gompa píše v Čt 26. 01. 2023 v 07:51 -0500: 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

On Thu, Jan 26 2023 at 09:23:35 AM -0500, Neal Gompa <ngompa13(a)gmail.com&gt; wrote: I agree, but if we tighten the rules then these apps will just disappear. So I'm not sure what to do about it.

On 1/26/23 8:42 AM, Jiri Eischmann wrote: 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/... 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.

Dne 26. 01. 23 v 14:55 Jiri Eischmann napsal(a): 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. I trust authors of the SW, but I don't trust in their trust to the libraries they bundle in the Flatpak. Vít

Dne 26. 01. 23 v 16:07 Jiri Eischmann napsal(a): BTW does the flathub version support all the platforms Fedora does? Cannot tell from the Flathub pages :/ 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. This is mostly just flexibility for upstream. 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

On Thu, Jan 26, 2023 at 12:01 PM Adam Williamson <adamwill(a)fedoraproject.org&gt; wrote: 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!

On Wed, Jan 25, 2023 at 06:01:17PM +0100, Vít Ondruch 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. 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 :|

On 2/8/23 08:41, Kevin Kofler via devel wrote: I mean there *is* a lowest common denominator: 1 :) -- Sincerely, Demi Marie Obenour (she/her/hers)

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(a)lists.fedoraproject.org > To unsubscribe send an email to devel-leave(a)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

On Fri, Jan 27, 2023 at 12:15 AM Sandro <lists(a)penguinpee.nl&gt; wrote: 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

On Tue, Mar 14, 2023 at 1:31 AM Sandro <lists(a)penguinpee.nl&gt; wrote: 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