Re: F39 Change Proposal: LibreOffice 7.6 (Self-Contained)
Il 22/07/23 22:31, Kevin Fenzi ha scritto: > On Fri, Jul 21, 2023 at 04:31:01PM +0100, Aoife Moloney wrote: >> https://fedoraproject.org/wiki/Changes/LibreOffice_7.6 >> >> This document represents a proposed Change. As part of the Changes >> process, proposals are publicly announced in order to receive >> community feedback. This proposal will only be implemented if approved >> by the Fedora Engineering Steering Committee. >> >> == Summary == >> Update LibreOffice suite to 7.6 >> >> >> == Owner == >> * Name: [[User:mattia| Mattia Verga]] >> * Name: [[User:limb| Gwyn Ciesla ]] >> * libreoffice-SIG >> * Email: mattia.ve...@protonmail.com, gw...@protonmail.com >> >> >> >> >> == Detailed Description == >> LibreOffice 7.6 is currently in Beta and the first stable release is >> currently scheduled during F39 development. We aim to bring the latest >> LibreOffice stable release in F39. > When is the stable release scheduled for? ie, how does it align with > fedora release milestones ? Perhaps add that here? > > LO 7.6 will be branched upstream the next week (week 30) and the final release is scheduled by week 33 (Aug 14, 2023 - Aug 20, 2023). F39 Beta freeze is scheduled on Aug 22. An effort building LO 7.6 in Fedora is ongoing in https://copr.fedorainfracloud.org/coprs/mattia/Libreoffice7.6testing/ We are hitting some test failures that need investigation. To upgrade LO to 7.6 some components will need to be updated (mdds, libixion, liborcus). CCing the package maintainer (dtardon) here. Mattia ___ 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: F39 Change Proposal: LibreOffice 7.6 (Self-Contained)
On Fri, Jul 21, 2023 at 04:31:01PM +0100, Aoife Moloney wrote: > https://fedoraproject.org/wiki/Changes/LibreOffice_7.6 > > This document represents a proposed Change. As part of the Changes > process, proposals are publicly announced in order to receive > community feedback. This proposal will only be implemented if approved > by the Fedora Engineering Steering Committee. > > == Summary == > Update LibreOffice suite to 7.6 > > > == Owner == > * Name: [[User:mattia| Mattia Verga]] > * Name: [[User:limb| Gwyn Ciesla ]] > * libreoffice-SIG > * Email: mattia.ve...@protonmail.com, gw...@protonmail.com > > > > > == Detailed Description == > LibreOffice 7.6 is currently in Beta and the first stable release is > currently scheduled during F39 development. We aim to bring the latest > LibreOffice stable release in F39. When is the stable release scheduled for? ie, how does it align with fedora release milestones ? Perhaps add that here? > At the same time we plan to stop building LibreOffice for i686 architecture. Good plan. kevin signature.asc Description: PGP 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
F39 Change Proposal: LibreOffice 7.6 (Self-Contained)
https://fedoraproject.org/wiki/Changes/LibreOffice_7.6 This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Update LibreOffice suite to 7.6 == Owner == * Name: [[User:mattia| Mattia Verga]] * Name: [[User:limb| Gwyn Ciesla ]] * libreoffice-SIG * Email: mattia.ve...@protonmail.com, gw...@protonmail.com == Detailed Description == LibreOffice 7.6 is currently in Beta and the first stable release is currently scheduled during F39 development. We aim to bring the latest LibreOffice stable release in F39. At the same time we plan to stop building LibreOffice for i686 architecture. == Benefit to Fedora == Make Fedora be in parity with upstream release, so users are not forced to switch to external Flatpaks. == Scope == * Proposal owners: Update `libreoffice` package to the latest version and make sure the dependencies are updated. This will be the first major update after Libreoffice-SIG take over maintenance from RH, so there might be a few troubles as the former maintainers were also able to contribute to upstream with patches. * Other developers: N/A (not needed for this Change) * Release engineering: N/A (not needed for this Change) * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Community Initiatives: N/A (not needed for this Change) == Upgrade/compatibility impact == == How To Test == Users running F39 will get LO 7.6 and can use and test any regression from the previous release. == User Experience == == Dependencies == == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change) == Documentation == N/A (not a System Wide Change) == Release Notes == -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford ___ 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: Orphaning packages (was LibreOffice packages)
Am 03.07.23 um 18:07 schrieb Simon de Vlieger: On 7/3/23 13:46, Ralf Corsépius wrote: It is the core of the problem esp. big US companies tend to ignore. May-be you guys are not aware of there are tendencies to legally prohibit such "cloud solutions" in many countries? It's generally not so much 'legally prohibit' as 'data has to be kept within $jurisdiction and is not to be shared outside of it'. If $jurisdiction is large enough cloud operators tend to offer that solution. Its not a cloud provider its a software vendor. Further more a couple of authoritative entities have proven that such solutions do not comply with data protection requirements. Its of value having a standalone package (to getting back to the topic). If not now, for sure in the near future. -- Leon ___ 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: LibreOffice packages
On Sun, Jul 2, 2023 at 5:01 PM Demi Marie Obenour wrote: > On 6/3/23 08:42, Michael Catanzaro wrote: > > On Sat, Jun 3 2023 at 10:26:07 AM -, John Iliopoulos < > jxftw2...@gmail.com> wrote: > >> Hello, > >> > >> While i completely understand why you do this i do think that it is > >> important for desktop/workstation oriented devices to have some > >> optional access to Office directly from the image file. Have you > >> considered shipping the LibreOffice flatpak via the ISO much like > >> Fedora Silverblue does with various other applications? > >> > >> This is the first time i reply to a mailing list so i hope i have not > >> done anything wrong. > > > > Hi. Welcome to the list. You haven't done anything wrong. > > > > For Fedora Workstation, the mid-term plan is to ship all preinstalled > > apps as Fedora Flatpaks. We cannot ship anything from Flathub because > > FESCo will not allow it. I don't *like* this FESCo requirement, but I > > also don't expect that to change. Accordingly, since Fedora Flatpaks > > are built from Fedora RPMs, maintaining the LibreOffice RPMs is > > essential to keep LibreOffice preinstalled. (I think that applies to > > Silverblue as well?) > > Fedora Flatpaks are also a security disaster: they are shipped in OCI > format instead of OSTree format, but they aren’t signed by anyone. > I’ve disabled the Fedora remote and recommend that others do the same. > I think the words "security disaster" are painting a too strong picture here. When you install a Fedora Flatpak, the digest of the content being installed is checked against the checksums embedded in the index downloaded from (e.g. https://registry.fedoraproject.org/index/static?label:org.flatpak.ref:exists=1&os=linux&architecture=amd64&tag=latest). These indexes are statically generated from data queried from Bodhi and Koji and downloaded from a static web server directly from Fedora bypassing the CDN. The most obvious way to get malicious content into this index would be to inject it at build time, by adding it upstream, infiltrating the Fedora project, hacking a Fedora contributor, etc. In all of these cases, if we had container signatures, robosignatory would happily sign it when the update was created. Yes, someone could hack the server hosting the index, get write-access to the mount hosting the indexes, or find some specific way to exploit the indexing process. And in those cases, having checked signatures would help. The first two cases would seem to imply a widespread breach of Fedora infrastructure that would likely affect security of builds as well. What would be needed to implement signatures would be roughly: - Implement container signatures in robosignatory/sigul - Implement distribution of signatures (probably easiest if we move registry.fedoraproject.org to quay.io as planned for a while) - Implement checkingo of container signatures in the Flatpak client One thing that helps now is that for a long time there was a lot of uncertainty in where signatures were going in the container world, but at this point, at least Red Hat parts of the container world seems to be solidly behind the approach of https://github.com/sigstore/cosign. (Still a lot of details / moving parts that would have to be researched.) - Owen ___ 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: Orphaning packages (was LibreOffice packages)
On 7/3/23 13:46, Ralf Corsépius wrote: It is the core of the problem esp. big US companies tend to ignore. May-be you guys are not aware of there are tendencies to legally prohibit such "cloud solutions" in many countries? It's generally not so much 'legally prohibit' as 'data has to be kept within $jurisdiction and is not to be shared outside of it'. If $jurisdiction is large enough cloud operators tend to offer that solution. ___ 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: Orphaning packages (was LibreOffice packages)
Am 01.07.23 um 14:28 schrieb Peter Robinson: On Sat, Jul 1, 2023 at 12:50 PM Vitaly Zaitsev via devel wrote: On 01/07/2023 13:36, Chris Adams wrote: A lot of the corporate world has gone to the "cloud" don't have to worry about local backups of important documents and spreadsheets, they get sharing with minimal effort, they can access things from their mobile devices, etc. And voluntarily hand over all the corporate secrets to Google and Microsoft. Brilliant idea. This sort of comment is off topic, It definitely is not off-topic. It is the core of the problem esp. big US companies tend to ignore. May-be you guys are not aware of there are tendencies to legally prohibit such "cloud solutions" in many countries? Ralf ___ 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: Orphaning packages (was LibreOffice packages)
On 7/3/23 09:23, Victor Toso wrote: On Sat, Jul 01, 2023 at 10:09:15PM +0200, Kalev Lember wrote: Victor (CC'd), do you want to pick up grilo and grilo-plugins? Sure, I'll keep maintaining both in Fedora. Excellent! Can you click on the "Take" button at https://src.fedoraproject.org/rpms/grilo and https://src.fedoraproject.org/rpms/grilo-plugins ? Bastien was the package owner before and now they are orphaned. -- Kalev ___ 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: LibreOffice packages
On 03/07/2023 01:28, Michael Catanzaro wrote: OK, host shared libraries and flatpaked libraries will be loaded at the same time, but I really doubt that's going to be at all significant. Include dozens of bundled libraries here too. Only runtimes can use shared memory. They do consume significant disk space if your disk is really small. ostree deduplication is pretty good, though (and OCI images are deduplicated too) Many Flatpaks from Flathub still use the old runtimes. Each runtime consumes approximately 1 GB of disk space. They need to start doing mass rebuilds with every new major release of the runtime. As a matter of strategy, packaging applications is fine, but nowadays it is *optional*. I don't think so. Our most popular applications are nowadays available from Flathub or other third-party sources, and users are going to install them regardless of whether we package them. Sorry, but I can't trust them since they allow uploading pre-built blobs and DEB repacks for popular and even for security-focused applications: - Firefox (uploaded as ostree blob without sources, has disabled ASLR and hardening); - OBS Studio (uploaded as ostree blob); - Element (DEB repack: https://github.com/flathub/im.riot.Riot/blob/master/im.riot.Riot.yaml#L69-L70); - Signal (DEB repack: https://github.com/flathub/org.signal.Signal/blob/master/org.signal.Signal.yaml#L65-L66); - Blender (static binary repack: https://github.com/flathub/org.blender.Blender/blob/master/org.blender.Blender.json#L150-L151); - VS Codium (DEB repack: https://github.com/flathub/com.vscodium.codium/blob/master/com.vscodium.codium.yaml#L98-L99); - many others: https://github.com/search?q=org%3Aflathub+.deb&type=code They need to forbid uploading pre-built blobs and repacks. All packages (except proprietary ones) should be built on their infrastructure. Flatpaks without sandbox holes are also dramatically more secure than Fedora RPMs, which is why I'm *really* interested in Flatpaks. Also, many Flathub's apps don't use Flatpak isolation at all: - https://github.com/search?q=org%3Aflathub+--filesystem%3Dhost&type=code - https://github.com/search?q=org%3Aflathub+--filesystem%3Dhome&type=code They need to restrict such holes. Snap already did this a few years ago (classic snaps are only allowed in exceptional cases). -- 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: LibreOffice packages
On 7/2/23 19:28, Michael Catanzaro wrote: > On Sun, Jul 2 2023 at 04:59:39 PM -0400, Demi Marie Obenour > wrote: >>> >> Fedora Flatpaks are also a security disaster: they are shipped in OCI >> format instead of OSTree format, but they aren’t signed by anyone. >> I’ve disabled the Fedora remote and recommend that others do the >> same. > > I didn't know about this problem. I agree that sounds pretty bad. I'm > going to ask some colleagues to comment on this. Thank you. As an aside, Fedora container images are also unsigned, and inasmuch as they are both shipped in OCI format, it might be possible to fix both at once. > There are, frankly, many other serious problems with Fedora Flatpaks, > most notably lack of regular updates when the app or bundled > dependencies are updated in Fedora. I think of them as a tech preview > that we shipped too early. That sounds accurate. I recommend turning them off by default _for now_, but hopefully they can be turned back on again in the future. > But these problems are not insurmountable, > and if we can get it right, building Flatpaks from RPMs will allow > Fedora to deliver applications packaged at Fedora's high level of > quality in a modern and safer format. I 100% support this. >>> My $0.02: maintaining complex desktop applications as part of the >>> operating system requires significant effort and produces low value >>> for >>> users when you can easily install that app from Flathub instead. (It >>> *especially* doesn't make sense to do in RHEL, but let's focus on >>> Fedora here.) >> >> What is your reasoning here? I’m not saying I disagree with you, >> but >> I want to know *why* you believe this, especially since flatpaks >> consume >> additional memory and disk space compared to RPMs. > > I do not believe that Flatpaks consume significant additional memory. > OK, host shared libraries and flatpaked libraries will be loaded at the > same time, but I really doubt that's going to be at all significant. > They do consume significant disk space if your disk is really small. > ostree deduplication is pretty good, though (and OCI images are > deduplicated too): > > https://blogs.gnome.org/wjjt/2021/11/24/on-flatpak-disk-usage-and-deduplication/ > > So I don't think many users will seriously care about additional memory > use or disk space. > > As a matter of strategy, packaging applications is fine, but nowadays > it is *optional*. 15 years ago, if Fedora did not ship an application, > you had to compile it yourself or, more likely, switch to Ubuntu or > Debian because they have more applications available. That is not the > case today. Our most popular applications are nowadays available from > Flathub or other third-party sources, and users are going to install > them regardless of whether we package them. Having Fedora packages > provides users with another way to use applications they would use on > Fedora anyway. So for the most complex applications, where packaging is > difficult or time-consuming, Fedora packagers will have to decide for > themselves whether it still makes sense to do that work as opposed to > other possible Fedora work. That makes total sense. If there are N distributions and M applications, traditional packaging takes O(N * M) time, whereas Flatpaks take O(N + M) time. Needless to say, the latter is a lot more sustainable as N and M get bigger. > (Flatpaks without sandbox holes are also dramatically more secure than > Fedora RPMs, which is why I'm *really* interested in Flatpaks. But > currently application declare too many holes: > https://theevilskeleton.gitlab.io/2023/05/11/overview-of-flatpaks-permission-models.html > > ) Sandboxing is also my main interest in Flatpaks. The current state of non-macOS desktop security is honestly rather embarrassing and sandboxing applications is a necessary first step in fixing that. Furthermore, sandboxed applications have well-defined interfaces with the rest of the system, which makes isolation techniques like SELinux, Landlock, or even virtualization much easier to apply. > Anyway, I don't mean to suggest we should stop packaging applications > or that the work to keep the LibreOffice packages maintained is not > valuable (thank you to everyone working on that). Being able to > continue shipping LibreOffice by default is especially important for > users who do not already know about LibreOffice and would otherwise not > realize that Linux has an office suite available. What I really meant > there was that packaging applications is not the most valuable way for > Red Hat to contribute to Fedora. That makes total
Re: LibreOffice packages
On Sun, Jul 2 2023 at 04:59:39 PM -0400, Demi Marie Obenour wrote: Fedora Flatpaks are also a security disaster: they are shipped in OCI format instead of OSTree format, but they aren’t signed by anyone. I’ve disabled the Fedora remote and recommend that others do the same. I didn't know about this problem. I agree that sounds pretty bad. I'm going to ask some colleagues to comment on this. There are, frankly, many other serious problems with Fedora Flatpaks, most notably lack of regular updates when the app or bundled dependencies are updated in Fedora. I think of them as a tech preview that we shipped too early. But these problems are not insurmountable, and if we can get it right, building Flatpaks from RPMs will allow Fedora to deliver applications packaged at Fedora's high level of quality in a modern and safer format. My $0.02: maintaining complex desktop applications as part of the operating system requires significant effort and produces low value for users when you can easily install that app from Flathub instead. (It *especially* doesn't make sense to do in RHEL, but let's focus on Fedora here.) What is your reasoning here? I’m not saying I disagree with you, but I want to know *why* you believe this, especially since flatpaks consume additional memory and disk space compared to RPMs. I do not believe that Flatpaks consume significant additional memory. OK, host shared libraries and flatpaked libraries will be loaded at the same time, but I really doubt that's going to be at all significant. They do consume significant disk space if your disk is really small. ostree deduplication is pretty good, though (and OCI images are deduplicated too): https://blogs.gnome.org/wjjt/2021/11/24/on-flatpak-disk-usage-and-deduplication/ So I don't think many users will seriously care about additional memory use or disk space. As a matter of strategy, packaging applications is fine, but nowadays it is *optional*. 15 years ago, if Fedora did not ship an application, you had to compile it yourself or, more likely, switch to Ubuntu or Debian because they have more applications available. That is not the case today. Our most popular applications are nowadays available from Flathub or other third-party sources, and users are going to install them regardless of whether we package them. Having Fedora packages provides users with another way to use applications they would use on Fedora anyway. So for the most complex applications, where packaging is difficult or time-consuming, Fedora packagers will have to decide for themselves whether it still makes sense to do that work as opposed to other possible Fedora work. (Flatpaks without sandbox holes are also dramatically more secure than Fedora RPMs, which is why I'm *really* interested in Flatpaks. But currently application declare too many holes: https://theevilskeleton.gitlab.io/2023/05/11/overview-of-flatpaks-permission-models.html ) Anyway, I don't mean to suggest we should stop packaging applications or that the work to keep the LibreOffice packages maintained is not valuable (thank you to everyone working on that). Being able to continue shipping LibreOffice by default is especially important for users who do not already know about LibreOffice and would otherwise not realize that Linux has an office suite available. What I really meant there was that packaging applications is not the most valuable way for Red Hat to contribute to Fedora. Contrast the LibreOffice announcement to Bastien's announcement that Red Hat is orphaning a large number of core desktop packages that are not applications and cannot be replaced by Flatpaks. This one will be much more challenging for Fedora deal with. :/ 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: Orphaning packages (was LibreOffice packages)
Peter Robinson wrote: > Someone doing work in EPEL is quite a bit different to my point of a > corporate organisation downstream of RHEL adding value and > differentiation that Red Hat doesn't provide as part of RHEL. The discussion was about people being able or unable to obtain the LibreOffice packages in some parts of the world. Since EPEL is widely mirrored, and mirrors (especially non-US ones) tend to not enforce US export control, people should be able to get the EPEL packages, along with some RHEL rebuild on which to install them, basically everywhere on the world. Whether the packaging work is done in EPEL or specifically in one of the rebuilds does not really matter for that purpose. And I do not really see a good reason why a rebuild should be doing that packaging on their own in their own repositories when it can be done within the EPEL infrastructure that benefits everyone. It is the same as for KDE Plasma&Gear really. What the rebuilds can do though is, e.g., to include the LibreOffice EPEL packages on their live images, as they are already doing with the KDE EPEL packages. 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: Orphaning packages (was LibreOffice packages)
On Sun, Jul 2, 2023 at 10:27 PM Kevin Kofler via devel wrote: > > Peter Robinson wrote: > > Assuming those "binary compatible distributions" choose to add > > LibreOffice back in and support it, given what they actually do in > > terms of actual development it's actually pretty unlikely they're > > going to do all the extra work to add back an office suite and all the > > dependencies it requires. > > If LibreOffice remains maintained in Fedora (and I sure hope so, because > otherwise that would definitely make Fedora useless for me), there is a good > chance that somebody will request and maintain EPEL branches for it, as has > already been done for the KDE Plasma and KDE Gear applications stack. Someone doing work in EPEL is quite a bit different to my point of a corporate organisation downstream of RHEL adding value and differentiation that Red Hat doesn't provide as part of RHEL. ___ 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: Orphaning packages (was LibreOffice packages)
Peter Robinson wrote: > Assuming those "binary compatible distributions" choose to add > LibreOffice back in and support it, given what they actually do in > terms of actual development it's actually pretty unlikely they're > going to do all the extra work to add back an office suite and all the > dependencies it requires. If LibreOffice remains maintained in Fedora (and I sure hope so, because otherwise that would definitely make Fedora useless for me), there is a good chance that somebody will request and maintain EPEL branches for it, as has already been done for the KDE Plasma and KDE Gear applications stack. 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: LibreOffice packages
On 6/3/23 08:42, Michael Catanzaro wrote: > On Sat, Jun 3 2023 at 10:26:07 AM -, John Iliopoulos > wrote: >> Hello, >> >> While i completely understand why you do this i do think that it is >> important for desktop/workstation oriented devices to have some >> optional access to Office directly from the image file. Have you >> considered shipping the LibreOffice flatpak via the ISO much like >> Fedora Silverblue does with various other applications? >> >> This is the first time i reply to a mailing list so i hope i have not >> done anything wrong. > > Hi. Welcome to the list. You haven't done anything wrong. > > For Fedora Workstation, the mid-term plan is to ship all preinstalled > apps as Fedora Flatpaks. We cannot ship anything from Flathub because > FESCo will not allow it. I don't *like* this FESCo requirement, but I > also don't expect that to change. Accordingly, since Fedora Flatpaks > are built from Fedora RPMs, maintaining the LibreOffice RPMs is > essential to keep LibreOffice preinstalled. (I think that applies to > Silverblue as well?) Fedora Flatpaks are also a security disaster: they are shipped in OCI format instead of OSTree format, but they aren’t signed by anyone. I’ve disabled the Fedora remote and recommend that others do the same. > My $0.02: maintaining complex desktop applications as part of the > operating system requires significant effort and produces low value for > users when you can easily install that app from Flathub instead. (It > *especially* doesn't make sense to do in RHEL, but let's focus on > Fedora here.) What is your reasoning here? I’m not saying I disagree with you, but I want to know *why* you believe this, especially since flatpaks consume additional memory and disk space compared to RPMs. -- 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: Orphaning packages (was LibreOffice packages)
On Fri, Jun 30 2023 at 05:40:33 AM +0200, Kevin Kofler via devel wrote: So Red Hat is essentially killing all work on desktop packages, not just on LibreOffice? No. Losing Bastien is extremely unfortunate and demoralizing, but we are not killing all work on desktop packages. 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: Orphaning packages (was LibreOffice packages)
On Sun, Jul 2, 2023 at 11:01 AM Vitaly Zaitsev via devel wrote: > > On 02/07/2023 10:51, Simon de Vlieger wrote: > > The suppliers for these enterprise distributions and the support they > > offer also abide by political lines. > > Indeed. That's why having RHEL repacks (Alma, Rocky, Oracle Linux) is good. > > > While your data won't be gone in an instant you still end up in the same > > situation with using an unsupported office suite. > > You can simply switch to one of these RHEL binary compatible distributions. Assuming those "binary compatible distributions" choose to add LibreOffice back in and support it, given what they actually do in terms of actual development it's actually pretty unlikely they're going to do all the extra work to add back an office suite and all the dependencies it requires. ___ 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: Orphaning packages (was LibreOffice packages)
On 02/07/2023 10:51, Simon de Vlieger wrote: The suppliers for these enterprise distributions and the support they offer also abide by political lines. Indeed. That's why having RHEL repacks (Alma, Rocky, Oracle Linux) is good. While your data won't be gone in an instant you still end up in the same situation with using an unsupported office suite. You can simply switch to one of these RHEL binary compatible distributions. -- 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: Orphaning packages (was LibreOffice packages)
On 7/2/23 08:56, Vitaly Zaitsev via devel wrote: On 01/07/2023 14:28, Peter Robinson wrote: This sort of comment is off topic, various companies are free to do with their data as they wish, just as you are free to do with it as you please. This is not offtopic. What I mean is that a distribution targeted at enterprise use should have a standalone office suite in their repositories, because most enterprise users will won't use Flathub or any other third party repositories due to their internal security policy. They will simply migrate from RHEL to Ubuntu LTS or another enterprise distribution with LO. These two situations can co-exist. Some companies will use cloud-based solutions because of the benefits they offer and some companies prefer to keep everything close to their chest. Frankly it's often more secure with cloud providers than on corporate networks. And they can easily dump you and all your data. Russian Federation is a good example. Both Microsoft and Google have disabled all paid accounts for users and organizations from this country. The suppliers for these enterprise distributions and the support they offer also abide by political lines. While your data won't be gone in an instant you still end up in the same situation with using an unsupported office suite. ___ 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: Orphaning packages (was LibreOffice packages)
On 01/07/2023 14:28, Peter Robinson wrote: This sort of comment is off topic, various companies are free to do with their data as they wish, just as you are free to do with it as you please. This is not offtopic. What I mean is that a distribution targeted at enterprise use should have a standalone office suite in their repositories, because most enterprise users will won't use Flathub or any other third party repositories due to their internal security policy. They will simply migrate from RHEL to Ubuntu LTS or another enterprise distribution with LO. Frankly it's often more secure with cloud providers than on corporate networks. And they can easily dump you and all your data. Russian Federation is a good example. Both Microsoft and Google have disabled all paid accounts for users and organizations from this country. -- 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: Orphaning packages (was LibreOffice packages)
On Jun 29, 2023, at 7:47 AM, Bastien Nocera wrote: > Here is a list of Fedora packages which I maintained or co-maintained which I > won't be able to contribute to anymore: > > sloccount I grabbed sloccount as I’ve found it useful over the years. It looks the right level of incredibly low maintenance to add to the pile. ___ 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: Orphaning packages (was LibreOffice packages)
On 6/29/23 16:47, Bastien Nocera wrote: Hello, As part of the same process outlined in Matthias Clasen's "LibreOffice packages" email, my upstream and downstream work on desktop Bluetooth, multimedia applications (namely totem, rhythmbox and sound-juicer) and libfprint/fprintd is being stopped, and all the rest of my upstream and downstream work will be reassigned depending on Red Hat's own priorities, as I am transferred to another team. While it's possible that some of the maintenance will stay with me in the new team, I've not yet been told which team I would be joining. Here is a list of Fedora packages which I maintained or co-maintained which I won't be able to contribute to anymore: apfs-fuse bluez codespell eosrei-emojione-fonts geocode-glib gnome-bluetooth gnome-epub-thumbnailer gnome-kra-ora-thumbnailer gnome-user-share gom grilo grilo-plugins ifuse iio-sensor-proxy libfprint libglib-testing libimobiledevice libpeas libplist libportal libusbmuxd low-memory-monitor malcontent power-profiles-daemon sloccount switcheroo-control totem totem-pl-parser umockdev usbmuxd I went ahead and picked up some of the GNOME packages from the list: gnome-bluetooth gnome-user-share gom libglib-testing libpeas libportal totem totem-pl-parser Victor (CC'd), do you want to pick up grilo and grilo-plugins? -- Kalev ___ 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: Orphaning packages (was LibreOffice packages)
Am 01.07.23 um 14:28 schrieb Peter Robinson: On Sat, Jul 1, 2023 at 12:50 PM Vitaly Zaitsev via devel wrote: On 01/07/2023 13:36, Chris Adams wrote: A lot of the corporate world has gone to the "cloud" don't have to worry about local backups of important documents and spreadsheets, they get sharing with minimal effort, they can access things from their mobile devices, etc. And voluntarily hand over all the corporate secrets to Google and Microsoft. Brilliant idea. This sort of comment is off topic, various companies are free to do with their data as they wish, just as you are free to do with it as you please. Frankly it's often more secure with cloud providers than on corporate networks. Either way that comment doesn't provide useful discourse in this discussion. No really, it defines requirements that a non-cloud solution addresses. Just to rephrase it; "it's often more secure (confidential) on corporate networks than with cloud providers". So a legitimately contribution to the discourse in having a functional desktop (office) environment. Whether its being flatpaked, rpmish, immutable packaged or what ever the future brings ... -- Leon ___ 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: Orphaning packages (was LibreOffice packages)
On Sat, Jul 1, 2023 at 12:50 PM Vitaly Zaitsev via devel wrote: > > On 01/07/2023 13:36, Chris Adams wrote: > > A lot of the corporate world has gone to the "cloud" > > > don't have to worry about local backups of important documents and > > spreadsheets, they get sharing with minimal effort, they can access > > things from their mobile devices, etc. > > And voluntarily hand over all the corporate secrets to Google and > Microsoft. Brilliant idea. This sort of comment is off topic, various companies are free to do with their data as they wish, just as you are free to do with it as you please. Frankly it's often more secure with cloud providers than on corporate networks. Either way that comment doesn't provide useful discourse in this discussion. ___ 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: Orphaning packages (was LibreOffice packages)
On 01/07/2023 13:36, Chris Adams wrote: A lot of the corporate world has gone to the "cloud" don't have to worry about local backups of important documents and spreadsheets, they get sharing with minimal effort, they can access things from their mobile devices, etc. And voluntarily hand over all the corporate secrets to Google and Microsoft. Brilliant idea. -- 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: Orphaning packages (was LibreOffice packages)
Once upon a time, Kevin Kofler said: > Peter Robinson wrote: > > I would hardly say Libreoffice, bluetooth on the desktop and certain > > iDevice pieces is "killing all work on the desktop" it's more focusing > > on things that are important to their customers in those contexts. > > What corporate desktop customers do not use LibreOffice? If RH considers > LibreOffice unimportant to their customers, it is obvious that they only > care about server customers. A lot of the corporate world has gone to the "cloud" (Google Docs or O365) for their office needs, enough that even where Windows is the predominant desktop OS, they don't get MS Office licenses either. They don't have to worry about local backups of important documents and spreadsheets, they get sharing with minimal effort, they can access things from their mobile devices, etc. -- Chris Adams ___ 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: Orphaning packages (was LibreOffice packages)
On Sat, Jul 1, 2023 at 12:30 PM Peter Robinson wrote: > > On Sat, Jul 1, 2023 at 12:00 AM Kevin Kofler via devel > wrote: > > > > Peter Robinson wrote: > > > I would hardly say Libreoffice, bluetooth on the desktop and certain > > > iDevice pieces is "killing all work on the desktop" it's more focusing > > > on things that are important to their customers in those contexts. > > > > What corporate desktop customers do not use LibreOffice? If RH considers > > LibreOffice unimportant to their customers, it is obvious that they only > > care about server customers. > > Well if the customer gets it via Flatpak they still have it, it also > means it doesn't need to be upgraded in lockstep with the OS so they > can go to newer versions while keeping the same rev of the desktop or > vica versa. > > But then there's also "desktop usecases like retail point of sale and > a whole lot of other single use UX graphical like display boards, > ticket machines, places where they're technical workstations and the > user has a separate windows device for email/office etc. There's a > vast array. Also a lot use online docs like Office365 or Google docs. I personally used to use Libreoffice a lot but now I mostly use gDocs. ___ 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: Orphaning packages (was LibreOffice packages)
On Sat, Jul 1, 2023 at 12:00 AM Kevin Kofler via devel wrote: > > Peter Robinson wrote: > > I would hardly say Libreoffice, bluetooth on the desktop and certain > > iDevice pieces is "killing all work on the desktop" it's more focusing > > on things that are important to their customers in those contexts. > > What corporate desktop customers do not use LibreOffice? If RH considers > LibreOffice unimportant to their customers, it is obvious that they only > care about server customers. Well if the customer gets it via Flatpak they still have it, it also means it doesn't need to be upgraded in lockstep with the OS so they can go to newer versions while keeping the same rev of the desktop or vica versa. But then there's also "desktop usecases like retail point of sale and a whole lot of other single use UX graphical like display boards, ticket machines, places where they're technical workstations and the user has a separate windows device for email/office etc. There's a vast array. ___ 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: Orphaning packages (was LibreOffice packages)
On 29/06/2023 16:47, Bastien Nocera wrote: Hello, As part of the same process outlined in Matthias Clasen's "LibreOffice packages" email, my upstream and downstream work on desktop Bluetooth, multimedia applications (namely totem, rhythmbox and sound-juicer) and libfprint/fprintd is being stopped, and all the rest of my upstream and downstream work will be reassigned depending on Red Hat's own priorities, as I am transferred to another team. While it's possible that some of the maintenance will stay with me in the new team, I've not yet been told which team I would be joining. Here is a list of Fedora packages which I maintained or co-maintained which I won't be able to contribute to anymore: apfs-fuse bluez codespell eosrei-emojione-fonts geocode-glib gnome-bluetooth gnome-epub-thumbnailer gnome-kra-ora-thumbnailer gnome-user-share gom grilo grilo-plugins ifuse iio-sensor-proxy libfprint libglib-testing libimobiledevice libpeas libplist libportal libusbmuxd low-memory-monitor malcontent power-profiles-daemon sloccount switcheroo-control totem totem-pl-parser umockdev usbmuxd I've picked up power-profiles-daemon -- Arthur Bols fas/irc: principis ___ 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: Orphaning packages (was LibreOffice packages)
On Sat, Jul 1, 2023 at 1:00 AM Kevin Kofler via devel wrote: > > What corporate desktop customers do not use LibreOffice? I know two big-name scientific instrument manufacturers that offer RHEL workstations on which to run the control software. I suspect there are other domains with similar use cases, i.e. dedicated computers that only run a certain piece of software or software suite. ___ 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: Orphaning packages (was LibreOffice packages)
Peter Robinson wrote: > I would hardly say Libreoffice, bluetooth on the desktop and certain > iDevice pieces is "killing all work on the desktop" it's more focusing > on things that are important to their customers in those contexts. What corporate desktop customers do not use LibreOffice? If RH considers LibreOffice unimportant to their customers, it is obvious that they only care about server customers. 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: Orphaning packages (was LibreOffice packages)
On Fri, Jun 30, 2023 at 4:41 AM Kevin Kofler via devel wrote: > > Bastien Nocera wrote: > > As part of the same process outlined in Matthias Clasen's "LibreOffice > > packages" email, my upstream and downstream work on desktop Bluetooth, > > multimedia applications (namely totem, rhythmbox and sound-juicer) and > > libfprint/fprintd is being stopped, and all the rest of my upstream and > > downstream work will be reassigned depending on Red Hat's own priorities, > > as I am transferred to another team. > > So Red Hat is essentially killing all work on desktop packages, not just on > LibreOffice? Also considering that several of those packages are libraries > that cannot just be put on Flathub as LibreOffice can (which was their > excuse for terminating all work on LibreOffice packaging). I would hardly say Libreoffice, bluetooth on the desktop and certain iDevice pieces is "killing all work on the desktop" it's more focusing on things that are important to their customers in those contexts. ___ 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: Orphaning packages (was LibreOffice packages)
Bastien Nocera wrote: > As part of the same process outlined in Matthias Clasen's "LibreOffice > packages" email, my upstream and downstream work on desktop Bluetooth, > multimedia applications (namely totem, rhythmbox and sound-juicer) and > libfprint/fprintd is being stopped, and all the rest of my upstream and > downstream work will be reassigned depending on Red Hat's own priorities, > as I am transferred to another team. So Red Hat is essentially killing all work on desktop packages, not just on LibreOffice? Also considering that several of those packages are libraries that cannot just be put on Flathub as LibreOffice can (which was their excuse for terminating all work on LibreOffice packaging). With the layoff and the destruction of the position of the Fedora Program Manager, the termination of public RHEL source releases, and this move, Red Hat is really turning into an unfriendly company, and I really have to wonder whether Fedora is going to be of any use to me in the long run. 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: Orphaning packages (was LibreOffice packages)
On 2023-06-29 18:09, Bastien Nocera wrote: Do you want to pick up the rest of the libimobiledevice stack as well? That's ifuse, libplist, libusbmuxd and usbmuxd. I've just picked these up, thanks! Will work together with Neal on this stack as part of the Fedora Asahi SIG. Cheers Davide ___ 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: Orphaning packages (was LibreOffice packages)
Do you want to pick up the rest of the libimobiledevice stack as well? That's ifuse, libplist, libusbmuxd and usbmuxd. ___ 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: Orphaning packages (was LibreOffice packages)
On Thu, 29 Jun 2023 at 10:48, Bastien Nocera wrote: > Hello, > > As part of the same process outlined in Matthias Clasen's "LibreOffice > packages" email, my upstream and downstream work on desktop Bluetooth, > multimedia applications (namely totem, rhythmbox and sound-juicer) and > libfprint/fprintd is being stopped, and all the rest of my upstream and > downstream work will be reassigned depending on Red Hat's own priorities, > as I am transferred to another team. > > 1. Thank you for all the work you have done on these and other packages in Fedora. The Bluetooth stack is not easy. 2. Thank you for announcing this early and allowing a quick transfer. 3. Good luck with the new team, they are lucky to have you. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ 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: Orphaning packages (was LibreOffice packages)
I've picked up low-memory-monitor On 6/29/23 08:46, Neal Gompa wrote: On Thu, Jun 29, 2023 at 10:48 AM Bastien Nocera wrote: Hello, As part of the same process outlined in Matthias Clasen's "LibreOffice packages" email, my upstream and downstream work on desktop Bluetooth, multimedia applications (namely totem, rhythmbox and sound-juicer) and libfprint/fprintd is being stopped, and all the rest of my upstream and downstream work will be reassigned depending on Red Hat's own priorities, as I am transferred to another team. While it's possible that some of the maintenance will stay with me in the new team, I've not yet been told which team I would be joining. Here is a list of Fedora packages which I maintained or co-maintained which I won't be able to contribute to anymore: apfs-fuse bluez codespell eosrei-emojione-fonts geocode-glib gnome-bluetooth gnome-epub-thumbnailer gnome-kra-ora-thumbnailer gnome-user-share gom grilo grilo-plugins ifuse iio-sensor-proxy libfprint libglib-testing libimobiledevice libpeas libplist libportal libusbmuxd low-memory-monitor malcontent power-profiles-daemon sloccount switcheroo-control totem totem-pl-parser umockdev usbmuxd I've picked up libimobiledevice as I need it for Fedora Asahi work. ___ 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: Orphaning packages (was LibreOffice packages)
On Thu, Jun 29, 2023 at 10:48 AM Bastien Nocera wrote: > > Hello, > > As part of the same process outlined in Matthias Clasen's "LibreOffice > packages" email, my upstream and downstream work on desktop Bluetooth, > multimedia applications (namely totem, rhythmbox and sound-juicer) and > libfprint/fprintd is being stopped, and all the rest of my upstream and > downstream work will be reassigned depending on Red Hat's own priorities, as > I am transferred to another team. > > While it's possible that some of the maintenance will stay with me in the new > team, I've not yet been told which team I would be joining. > > Here is a list of Fedora packages which I maintained or co-maintained which I > won't be able to contribute to anymore: > apfs-fuse > bluez > codespell > eosrei-emojione-fonts > geocode-glib > gnome-bluetooth > gnome-epub-thumbnailer > gnome-kra-ora-thumbnailer > gnome-user-share > gom > grilo > grilo-plugins > ifuse > iio-sensor-proxy > libfprint > libglib-testing > libimobiledevice > libpeas > libplist > libportal > libusbmuxd > low-memory-monitor > malcontent > power-profiles-daemon > sloccount > switcheroo-control > totem > totem-pl-parser > umockdev > usbmuxd > I've picked up libimobiledevice as I need it for Fedora Asahi work. -- 真実はいつも一つ!/ 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
Orphaning packages (was LibreOffice packages)
Hello, As part of the same process outlined in Matthias Clasen's "LibreOffice packages" email, my upstream and downstream work on desktop Bluetooth, multimedia applications (namely totem, rhythmbox and sound-juicer) and libfprint/fprintd is being stopped, and all the rest of my upstream and downstream work will be reassigned depending on Red Hat's own priorities, as I am transferred to another team. While it's possible that some of the maintenance will stay with me in the new team, I've not yet been told which team I would be joining. Here is a list of Fedora packages which I maintained or co-maintained which I won't be able to contribute to anymore: apfs-fuse bluez codespell eosrei-emojione-fonts geocode-glib gnome-bluetooth gnome-epub-thumbnailer gnome-kra-ora-thumbnailer gnome-user-share gom grilo grilo-plugins ifuse iio-sensor-proxy libfprint libglib-testing libimobiledevice libpeas libplist libportal libusbmuxd low-memory-monitor malcontent power-profiles-daemon sloccount switcheroo-control totem totem-pl-parser umockdev usbmuxd Regards ___ 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: SIG proposal: libreoffice-sig
Hi, On Tuesday, 2023-06-27 17:06:56 -, Mattia Verga via devel wrote: > Anyone interested can join the `#libreoffice-sig:fedoraproject.org` matrix > room for discussion. Nope, it's #libreoffice:fedoraproject.org Eike -- GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A signature.asc Description: PGP 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: SIG proposal: libreoffice-sig
Greetings folks, the libreoffice-sig is now live. Anyone interested can join the `#libreoffice-sig:fedoraproject.org` matrix room for discussion. If you're a packager and like to help maintain LO and related packages, you can ask to join the https://accounts.fedoraproject.org/group/libreoffice-sig/ FAS group. If you maintain a LO package or any dependency, you're invited to add commit (or admin) access for libreoffice-sig group to your package and change the default bugzilla assignee to libreoffice-sig group. This will make BZ emails be sent to the libreoffice-...@lists.fedoraproject.org mailing list which you're also encouraged to join (this list is set as private as the only purpose is for BZ related activity; for active discussions please use the matrix room). That should be all, let me know if I have forgot something important. Thanks to all for your work in supporting Libreoffice RPM packaging in Fedora! Mattia ___ 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: SIG proposal: libreoffice-sig
I've filed the request to set up a libreoffice-sig: https://pagure.io/fedora-infrastructure/issue/11372 If I forgot something in the request, please correct it. I've also quickly set up a wiki page which can be enhanced in many ways... ;-) Mattia ___ 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: LibreOffice packages
I built it successfully in the side tag by disabling tests. There's a new release; I'll see if that fixes things. -- Gwyn Ciesla she/her/hers in your fear, seek only peace in your fear, seek only love -d. bowie Sent with Proton Mail secure email. --- Original Message --- On Friday, June 16th, 2023 at 2:34 AM, Dan Horák wrote: > On Thu, 15 Jun 2023 18:40:39 +0200 > Miro Hrončok mhron...@redhat.com wrote: > > > On 01. 06. 23 22:16, Gwyn Ciesla via devel wrote: > > > > > I've taken ownership of libreoffice for the time being, at least to keep > > > the lights on. Co-maintainers, as always, welcome. > > > > Thanks. > > > > Could you please prioritize making it build? The LibreOffice package fails > > to > > build in rawhide for months. It's now blocking the Python 3.12 rebuild: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=2215352 > > > > This is not directed only at Gwyn, but all the other folks who offered help. > > > for the record, the build failure is caused by a failing test, but it > doesn't show if it's the only problem there > > ... > Test name: DesktopLOKTest::testSignDocument_PEM_PDF > assertion failed > - Expression: bResult > Failures !!! > > I believe we need a shared document to track who is doing what and > generally coordinate the actions. > > > Dan > ___ > 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 signature.asc 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: LibreOffice packages
On Thu, 15 Jun 2023 18:40:39 +0200 Miro Hrončok wrote: > On 01. 06. 23 22:16, Gwyn Ciesla via devel wrote: > > I've taken ownership of libreoffice for the time being, at least to keep > > the lights on. Co-maintainers, as always, welcome. > > Thanks. > > Could you please prioritize making it build? The LibreOffice package fails to > build in rawhide for months. It's now blocking the Python 3.12 rebuild: > > https://bugzilla.redhat.com/show_bug.cgi?id=2215352 > > This is not directed only at Gwyn, but all the other folks who offered help. for the record, the build failure is caused by a failing test, but it doesn't show if it's the only problem there ... Test name: DesktopLOKTest::testSignDocument_PEM_PDF assertion failed - Expression: bResult Failures !!! I believe we need a shared document to track who is doing what and generally coordinate the actions. Dan ___ 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: LibreOffice packages
On 01. 06. 23 22:16, Gwyn Ciesla via devel wrote: I've taken ownership of libreoffice for the time being, at least to keep the lights on. Co-maintainers, as always, welcome. Thanks. Could you please prioritize making it build? The LibreOffice package fails to build in rawhide for months. It's now blocking the Python 3.12 rebuild: https://bugzilla.redhat.com/show_bug.cgi?id=2215352 This is not directed only at Gwyn, but all the other folks who offered help. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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: LibreOffice packages
Michael Catanzaro píše v St 07. 06. 2023 v 08:15 -0500: > > Ideally all bundled dependencies should be hooked up to some sort of > automation that notices when there are upstream updates available, > comparable to upstream release monitoring. On Flathub this is done by > flathub-external-data-checker [1], but using it is optional and it's > not useful if it's not used. For Fedora Flatpaks, I don't think any > comparable mechanism exists, but it should be as simple as "update > whenever any component RPM is updated." > > [1] https://github.com/flathub/flatpak-external-data-checker > I used that for flatpaks I maintain for a while, but then removed it because it was rather adding work than reducing it. But it could be just my workflow. I recommend anyone use https://release-monitoring.org/ which can send you notifications of new versions of specified projects. Could be used for any component maintenance including RPMs. I get notified and then it's up to me when and how I act on it. You can build automation based on it, too. My biggest flatpak has 15 modules. Maybe if it had dozens like LibreOffice I'd appreciate more automation. 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: SIG proposal: libreoffice-sig
Hi Adam, On Wednesday, 2023-06-07 13:57:44 -, Adam Ł. wrote: > What ( and eventually where post this message ) about missing feature in > LibreOffic3 ? > (transulcent/transparent groups and interesecion 2d object/text top of video) > https://www.linkedin.com/posts/nandi-bishal_powerpoint-design-study-activity-7072031917180674048-stI8?utm_source=share&utm_medium=member_desktop As all requests for enhancements (RFE), in the upstream's bug tracker: https://bugs.documentfoundation.org/ with the Importance Severity set to 'enhancement'. Eike -- GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A signature.asc Description: PGP 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: LibreOffice packages
On 6/7/23 15:15, Michael Catanzaro wrote: [1] https://github.com/flathub/flatpak-external-data-checker Oh, thanks, didn't know about that. Will try to make use of it for LibreOffice, <https://github.com/flathub/org.libreoffice.LibreOffice/pull/236> "Add metadata for flatpak-external-data-checker". ___ 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: SIG proposal: libreoffice-sig
What ( and eventually where post this message ) about missing feature in LibreOffic3 ? (transulcent/transparent groups and interesecion 2d object/text top of video) https://www.linkedin.com/posts/nandi-bishal_powerpoint-design-study-activity-7072031917180674048-stI8?utm_source=share&utm_medium=member_desktop ___ 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: LibreOffice packages
The main difference is that Fedora - be it rpms, flatpaks from module rpms (current state), flatpaks from whatever - comes with the promise of all the four F's, including freedom from legal issues as outlined in our guidelines. That enables RedHat to make the guarantees which they make for their offerings. Flatpaks from third party sources such as flathub come with no promise whatsover (AFAICT) - unless you track a specific flatpak's provider and figure out their promises/guarantees per flatpak. And without that neither Fedora nor RedHat can ship any app on live media and such. A different question is shipping configuration for third party rpm repos (such as rpmfusion) or flatpak hubs (such flathub). Here, the issue is: - Shipping a Fedora/RHEL specific (enabled) repo/hub config might be considered redistribution, or at least RH legal may consider that a risk too high to take. - Shipping a non-specific (enabled) hub config can hardly be considered redistribution, or at least RH legal does not seem to fear that risk (since unfiltered flathub). From a customer perspective: Your on your own with anything you pull in from third party sources. 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: LibreOffice packages
Ideally all bundled dependencies should be hooked up to some sort of automation that notices when there are upstream updates available, comparable to upstream release monitoring. On Flathub this is done by flathub-external-data-checker [1], but using it is optional and it's not useful if it's not used. For Fedora Flatpaks, I don't think any comparable mechanism exists, but it should be as simple as "update whenever any component RPM is updated." [1] https://github.com/flathub/flatpak-external-data-checker ___ 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: LibreOffice packages
On Tue, 06 Jun 2023 18:07:04 +0200, Fabio Valentini wrote: > On the other hand, the libreoffice flatpak bundles ~80 projects: > - gpgme (huh?) This... > - openldap (huh?) and perhaps this are probably because it is possible to sign and encrypt ODF documents using OpenPGP. Some details are here: https://help.libreoffice.org/latest/en-US/text/shared/guide/openpgp.html Neal ___ 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: LibreOffice packages
On Wednesday, 07 June 2023 at 08:51, Stephan Bergmann wrote: > On 6/6/23 18:07, Fabio Valentini wrote: > > In general, I do like having software available as flatpaks, > > especially if it's not available from Fedora repositories. > > However, there's also the question of *trust* - do I trust the > > software source and / or the people / projects providing them? > > > > Let's take LibreOffice as an example, since it started this whole > > discussion. > > The Fedora package appears to bundle only one "major" dependency, > > hsqldb, and it's documented and justified why this is the case in the > > spec file. > > > > On the other hand, the libreoffice flatpak bundles ~80 projects: > > - OpenJDK 17 (huh? is there no shared JDK flatpak runtime / SDK extension?) > > - krb5 (huh?) > > - xmlsec > > - boost 1.80 > > - gpgme (huh?) > > - mariadb-connector-c > > - openldap (huh?) > > - poppler > > - PostgreSQL 13.10 (huh?) > > - and about 70 more (but with less memorable names) > > > > While I *do* trust the LibreOffice project (somewhat) to ship their > > own software correctly, do I trust them regarding these ~80 bundled - > > and partially security sensitive - libraries, as well? I'm not sure. > > Do I trust the Fedora packages for these libraries? Probably. Many of > > these libraries are installed by default on Fedora, and are not only > > used by LibreOffice, so I basically placed implicit trust in these > > when I first installed Fedora on my machine. > > If you are talking about the LibreOffice upstream flatpak on Flathub (i.e., > <https://github.com/flathub/org.libreoffice.LibreOffice/blob/06020bac005ef56305bcf5bc62ada8db2f259436/org.libreoffice.LibreOffice.json>): > > * It bundles OpenJDK 17 provided by the > org.freedesktop.Sdk.Extension.openjdk17 sdk-extension. Whenever a new > version of the LibreOffice flatpak is provided, it automatically includes > whatever latest version of that openjdk17 extension is provided. (And the > assumption is that the providers of that extension take timely action in > case of any relevant (security) issues.) Still, if there are urgent > (security) issues in the extension, we would need to notice that and rebuild > the LibreOffice flatpak accordingly. (It would be nicer if Java was > provided as an org.freedesktop.Platform extension rather than only as an > org.freedesktop.Sdk extension.) > > * It bundles gvfs (see > <https://github.com/flathub/org.libreoffice.LibreOffice/commit/800d0d553fec6bd093f813cb4aa2f10dcbe10aee> > "Re-enable GIO support") and krb5 (see > <https://github.com/flathub/org.libreoffice.LibreOffice/commit/5b49a9e3ca243910a094f9865e2cdda9e2cda098> > "Add krb5" and > <https://git.libreoffice.org/core/+/227350eb5a9881f795e9ae499c732f0148e4ac38%5E!> > "Introduce optional krb5&gssapi support for internal PostgreSQL") "on its > own": If there are any (security) issues with their upstream sources, we > need to notice that and adapt the LibreOffice flatpak accordingly. > > * It bundles another 83 packages (from pdfium-5408.tar.bz2 to > f543e6e2d7275557a839a164941c0a86e5f2c3f2a0042bfc434c88c6dde9e140-opens___.ttf) > that are "managed" by upstream LibreOffice: These are also used for other > upstream LibreOffice builds (e.g., on macOS and Windows), and if there are > any relevant (security) issues, upstream LibreOffice takes care of that and > provides a new upstream LibreOffice version (and thus a new LibreOffice > flatpak version). And this is exactly where the value of Linux distribution lies. Upstream does not have to "manage" their dependencies and can rely on distributions instead. There are package management solutions for Windows and MacOS, so upstreams could make a one-time effort to support those and delegate instead of the constant time investment to manage dependency bundling for all platforms on their own. I realize this would not happen overnight, but I wish this were the direction in which upstreams are moving instead of bundling everything. Regards, Dominik -- Fedora https://fedoraproject.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ 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: LibreOffice packages
On Wed, Jun 7, 2023 at 8:51 AM Stephan Bergmann wrote: > > If you are talking about the LibreOffice upstream flatpak on Flathub > (i.e., > <https://github.com/flathub/org.libreoffice.LibreOffice/blob/06020bac005ef56305bcf5bc62ada8db2f259436/org.libreoffice.LibreOffice.json>): Yes, that is what I was referring to. > * It bundles OpenJDK 17 provided by the > org.freedesktop.Sdk.Extension.openjdk17 sdk-extension. Whenever a new > version of the LibreOffice flatpak is provided, it automatically > includes whatever latest version of that openjdk17 extension is > provided. (And the assumption is that the providers of that extension > take timely action in case of any relevant (security) issues.) Still, > if there are urgent (security) issues in the extension, we would need to > notice that and rebuild the LibreOffice flatpak accordingly. (It would > be nicer if Java was provided as an org.freedesktop.Platform extension > rather than only as an org.freedesktop.Sdk extension.) > > * It bundles gvfs (see > <https://github.com/flathub/org.libreoffice.LibreOffice/commit/800d0d553fec6bd093f813cb4aa2f10dcbe10aee> > "Re-enable GIO support") and krb5 (see > <https://github.com/flathub/org.libreoffice.LibreOffice/commit/5b49a9e3ca243910a094f9865e2cdda9e2cda098> > "Add krb5" and > <https://git.libreoffice.org/core/+/227350eb5a9881f795e9ae499c732f0148e4ac38%5E!> > "Introduce optional krb5&gssapi support for internal PostgreSQL") "on > its own": If there are any (security) issues with their upstream > sources, we need to notice that and adapt the LibreOffice flatpak > accordingly. > > * It bundles another 83 packages (from pdfium-5408.tar.bz2 to > f543e6e2d7275557a839a164941c0a86e5f2c3f2a0042bfc434c88c6dde9e140-opens___.ttf) > that are "managed" by upstream LibreOffice: These are also used for > other upstream LibreOffice builds (e.g., on macOS and Windows), and if > there are any relevant (security) issues, upstream LibreOffice takes > care of that and provides a new upstream LibreOffice version (and thus a > new LibreOffice flatpak version). > > * It includes ant as a build-time--only dependency. Thank you for the explanation, but still, I would argue that it is not the LibreOffice project's job to do those things, and I don't necessarily trust them to do this right (other people might have a different opinion here). Basically, I'm wondering how this is different from the "don't (re)package everything as RPMs if upstream already provides flatpaks! don't reinvent the wheel!" argument that's sometimes brought in favor of flatpaks. Don't flatpaks do just the same thing, just not with the applications themselves, but basically "reinventing the wheel" by bundling / shipping / maintaining all their dependencies, which are already provided by the underlying Linux distro in most cases? 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: SIG proposal: libreoffice-sig
On 6/7/23 08:00, Mattia Verga via devel wrote: As for admin privileges on the FAS group and ML, I'd like to ask 3-4 people to be set up. @decathorpe, @limb, @sharkcz ? @caolanm and @sbergmann would you like to continue helping in your great work on LO packages outside RH assignment? Yes, you can count me (sbergmann) in on trying to help out as far as my spare time permits. ___ 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: LibreOffice packages
On 6/6/23 18:07, Fabio Valentini wrote: In general, I do like having software available as flatpaks, especially if it's not available from Fedora repositories. However, there's also the question of *trust* - do I trust the software source and / or the people / projects providing them? Let's take LibreOffice as an example, since it started this whole discussion. The Fedora package appears to bundle only one "major" dependency, hsqldb, and it's documented and justified why this is the case in the spec file. On the other hand, the libreoffice flatpak bundles ~80 projects: - OpenJDK 17 (huh? is there no shared JDK flatpak runtime / SDK extension?) - krb5 (huh?) - xmlsec - boost 1.80 - gpgme (huh?) - mariadb-connector-c - openldap (huh?) - poppler - PostgreSQL 13.10 (huh?) - and about 70 more (but with less memorable names) While I *do* trust the LibreOffice project (somewhat) to ship their own software correctly, do I trust them regarding these ~80 bundled - and partially security sensitive - libraries, as well? I'm not sure. Do I trust the Fedora packages for these libraries? Probably. Many of these libraries are installed by default on Fedora, and are not only used by LibreOffice, so I basically placed implicit trust in these when I first installed Fedora on my machine. If you are talking about the LibreOffice upstream flatpak on Flathub (i.e., <https://github.com/flathub/org.libreoffice.LibreOffice/blob/06020bac005ef56305bcf5bc62ada8db2f259436/org.libreoffice.LibreOffice.json>): * It bundles OpenJDK 17 provided by the org.freedesktop.Sdk.Extension.openjdk17 sdk-extension. Whenever a new version of the LibreOffice flatpak is provided, it automatically includes whatever latest version of that openjdk17 extension is provided. (And the assumption is that the providers of that extension take timely action in case of any relevant (security) issues.) Still, if there are urgent (security) issues in the extension, we would need to notice that and rebuild the LibreOffice flatpak accordingly. (It would be nicer if Java was provided as an org.freedesktop.Platform extension rather than only as an org.freedesktop.Sdk extension.) * It bundles gvfs (see <https://github.com/flathub/org.libreoffice.LibreOffice/commit/800d0d553fec6bd093f813cb4aa2f10dcbe10aee> "Re-enable GIO support") and krb5 (see <https://github.com/flathub/org.libreoffice.LibreOffice/commit/5b49a9e3ca243910a094f9865e2cdda9e2cda098> "Add krb5" and <https://git.libreoffice.org/core/+/227350eb5a9881f795e9ae499c732f0148e4ac38%5E!> "Introduce optional krb5&gssapi support for internal PostgreSQL") "on its own": If there are any (security) issues with their upstream sources, we need to notice that and adapt the LibreOffice flatpak accordingly. * It bundles another 83 packages (from pdfium-5408.tar.bz2 to f543e6e2d7275557a839a164941c0a86e5f2c3f2a0042bfc434c88c6dde9e140-opens___.ttf) that are "managed" by upstream LibreOffice: These are also used for other upstream LibreOffice builds (e.g., on macOS and Windows), and if there are any relevant (security) issues, upstream LibreOffice takes care of that and provides a new upstream LibreOffice version (and thus a new LibreOffice flatpak version). * It includes ant as a build-time--only dependency. ___ 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: SIG proposal: libreoffice-sig
Il 06/06/23 21:16, Fabio Valentini ha scritto: > On Tue, Jun 6, 2023 at 9:01 PM Gwyn Ciesla via devel > wrote: >> I would honestly prefer ownership be transferred to the libreoffice -sig, of >> which I am more than happy to be a member. > This is not possible, the "main admin" needs to be a person, and > cannot be a group. However, the default assignee for BugZilla bugs > *can* be overridden to be a group, which is basically the next best > thing. > > In my experience (:sad java face:), what's needed to form a SIG that > can maintain packages is: > > - requesting a FAS group *with* dist-git group > - a private mailing list that will receive bugzilla email > - a bugzilla account registered with the email address of this private > mailing list > - a Wiki page (though this is less important than it used to be) > - (maybe I forgot something) > (but fedora-infra people will also tell you what you need if you open a > ticket) > > Most SIGs also have IRC / Matrix channels or tracking projects on > pagure, but these are all optional and can be added later. > > And I'm not sure how much time I can contribute, but I'd also like to > help keep libreoffice RPMs available in Fedora. :) > > Fabio Ok, as soon as I have some free time I'll file the request to fedora-infra and set up the wiki page. Unless someone beats me in time, I would not object that :-p I was thinkink to use the mailing list address only for bugzilla purposes, since it would be private, and ask to set up a Discourse tag/section for project coordination. Thoughts? As for admin privileges on the FAS group and ML, I'd like to ask 3-4 people to be set up. @decathorpe, @limb, @sharkcz ? @caolanm and @sbergmann would you like to continue helping in your great work on LO packages outside RH assignment? Mattia ___ 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: SIG proposal: libreoffice-sig
I am also interested in keeping the LO packages in Fedora. Hussein On 6/6/23 20:55, Mattia Verga via devel wrote: I'm forking this proposal off from the other thread, as it got buried under tons of posts. Shall we set up a libreoffice-sig to coordinate and ensure that libreoffice and all dependencies are properly maintained and updated as RPMs? Are there enough users which, like me, don't like the idea to only have LO available as a flatpak from an external service like Flathub and would like to join forces to maintain it in RPM repos? What it is needed to set up a SIG? A wiki page and a mailing list? And also a FAS group, I suppose? BTW I've already seen a couple of hiccups which needs to be solved: the Bugzilla assignee of libreoffice package on src.fp.o is set to @sbergmann but I suppose it should now be changed to @limb? And, also, libreoffice 7.5.3 failed to build on Fedora Rawhide, so we now have LO 3.5.3 on F38 and LO 3.5.2 on Rawhide. Mattia ___ 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: SIG proposal: libreoffice-sig
Then I can be that person. :) -- Gwyn Ciesla she/her/hers in your fear, seek only peace in your fear, seek only love -d. bowie Sent with Proton Mail secure email. --- Original Message --- On Tuesday, June 6th, 2023 at 2:16 PM, Fabio Valentini wrote: > On Tue, Jun 6, 2023 at 9:01 PM Gwyn Ciesla via devel > devel@lists.fedoraproject.org wrote: > > > I would honestly prefer ownership be transferred to the libreoffice -sig, > > of which I am more than happy to be a member. > > > This is not possible, the "main admin" needs to be a person, and > cannot be a group. However, the default assignee for BugZilla bugs > can be overridden to be a group, which is basically the next best > thing. > > In my experience (:sad java face:), what's needed to form a SIG that > can maintain packages is: > > - requesting a FAS group with dist-git group > - a private mailing list that will receive bugzilla email > - a bugzilla account registered with the email address of this private > mailing list > - a Wiki page (though this is less important than it used to be) > - (maybe I forgot something) > (but fedora-infra people will also tell you what you need if you open a > ticket) > > Most SIGs also have IRC / Matrix channels or tracking projects on > pagure, but these are all optional and can be added later. > > And I'm not sure how much time I can contribute, but I'd also like to > help keep libreoffice RPMs available in 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 signature.asc 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: SIG proposal: libreoffice-sig
On Tue, 06 Jun 2023 18:55:36 + Mattia Verga via devel wrote: > I'm forking this proposal off from the other thread, as it got buried > under tons of posts. > > Shall we set up a libreoffice-sig to coordinate and ensure that > libreoffice and all dependencies are properly maintained and updated as > RPMs? Are there enough users which, like me, don't like the idea to only > have LO available as a flatpak from an external service like Flathub and > would like to join forces to maintain it in RPM repos? I am surely interested in the RPMs, mainly from the ppc64le (and s390x) point of view. They are very unlikely to get flatpaks. Dan ___ 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: SIG proposal: libreoffice-sig
On Tue, Jun 6, 2023 at 9:01 PM Gwyn Ciesla via devel wrote: > > I would honestly prefer ownership be transferred to the libreoffice -sig, of > which I am more than happy to be a member. This is not possible, the "main admin" needs to be a person, and cannot be a group. However, the default assignee for BugZilla bugs *can* be overridden to be a group, which is basically the next best thing. In my experience (:sad java face:), what's needed to form a SIG that can maintain packages is: - requesting a FAS group *with* dist-git group - a private mailing list that will receive bugzilla email - a bugzilla account registered with the email address of this private mailing list - a Wiki page (though this is less important than it used to be) - (maybe I forgot something) (but fedora-infra people will also tell you what you need if you open a ticket) Most SIGs also have IRC / Matrix channels or tracking projects on pagure, but these are all optional and can be added later. And I'm not sure how much time I can contribute, but I'd also like to help keep libreoffice RPMs available in 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: SIG proposal: libreoffice-sig
I would honestly prefer ownership be transferred to the libreoffice -sig, of which I am more than happy to be a member. -- Gwyn Ciesla she/her/hers in your fear, seek only peace in your fear, seek only love -d. bowie Sent with Proton Mail secure email. --- Original Message --- On Tuesday, June 6th, 2023 at 1:55 PM, Mattia Verga wrote: > I'm forking this proposal off from the other thread, as it got buried > under tons of posts. > > Shall we set up a libreoffice-sig to coordinate and ensure that > libreoffice and all dependencies are properly maintained and updated as > RPMs? Are there enough users which, like me, don't like the idea to only > have LO available as a flatpak from an external service like Flathub and > would like to join forces to maintain it in RPM repos? > > What it is needed to set up a SIG? A wiki page and a mailing list? And > also a FAS group, I suppose? > > BTW I've already seen a couple of hiccups which needs to be solved: the > Bugzilla assignee of libreoffice package on src.fp.o is set to > @sbergmann but I suppose it should now be changed to @limb? And, also, > libreoffice 7.5.3 failed to build on Fedora Rawhide, so we now have LO > 3.5.3 on F38 and LO 3.5.2 on Rawhide. > > Mattia signature.asc 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
SIG proposal: libreoffice-sig
I'm forking this proposal off from the other thread, as it got buried under tons of posts. Shall we set up a libreoffice-sig to coordinate and ensure that libreoffice and all dependencies are properly maintained and updated as RPMs? Are there enough users which, like me, don't like the idea to only have LO available as a flatpak from an external service like Flathub and would like to join forces to maintain it in RPM repos? What it is needed to set up a SIG? A wiki page and a mailing list? And also a FAS group, I suppose? BTW I've already seen a couple of hiccups which needs to be solved: the Bugzilla assignee of libreoffice package on src.fp.o is set to @sbergmann but I suppose it should now be changed to @limb? And, also, libreoffice 7.5.3 failed to build on Fedora Rawhide, so we now have LO 3.5.3 on F38 and LO 3.5.2 on Rawhide. Mattia ___ 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: LibreOffice packages
On Thu, Jun 1, 2023 at 10:00 PM Christian Schaller wrote: > > On Thu, Jun 1, 2023 at 2:36 PM Demi Marie Obenour > wrote: >> >> Why is a Flatpak a better choice for LibreOffice? >> -- >> Sincerely, >> Demi Marie Obenour (she/her/hers) > > There are a lot of ways to answer this, but from any upstream the advantage > of Flatpak is that it means package once and then deploy everywhere. So it > saves them work. > > From a Fedora perspective there is of course nobody telling anyone to not > maintain LibreOffice as RPMS or as a Fedora flatpak going forward, but even > if nobody does we have a good option available in the Flathub package, > especially with the Flathub package not being verified as the official > package of upstream LibreOffice. I wanted to add one thing here. In general, I do like having software available as flatpaks, especially if it's not available from Fedora repositories. However, there's also the question of *trust* - do I trust the software source and / or the people / projects providing them? Let's take LibreOffice as an example, since it started this whole discussion. The Fedora package appears to bundle only one "major" dependency, hsqldb, and it's documented and justified why this is the case in the spec file. On the other hand, the libreoffice flatpak bundles ~80 projects: - OpenJDK 17 (huh? is there no shared JDK flatpak runtime / SDK extension?) - krb5 (huh?) - xmlsec - boost 1.80 - gpgme (huh?) - mariadb-connector-c - openldap (huh?) - poppler - PostgreSQL 13.10 (huh?) - and about 70 more (but with less memorable names) While I *do* trust the LibreOffice project (somewhat) to ship their own software correctly, do I trust them regarding these ~80 bundled - and partially security sensitive - libraries, as well? I'm not sure. Do I trust the Fedora packages for these libraries? Probably. Many of these libraries are installed by default on Fedora, and are not only used by LibreOffice, so I basically placed implicit trust in these when I first installed Fedora on my machine. 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: LibreOffice packages
On Tue, Jun 6, 2023 at 7:50 AM Leon Fauster via devel < devel@lists.fedoraproject.org> wrote: > Is the Fedora OCI flatpak approach not about the trust into the chain of > flatpak creation? src -> signed rpm -> flatpak? So, even in an ideal world > where RHEL is immutable and the best workstation experience is based on > flatpaks - RPMs are the building block. This is completly different to the > Flathub approach ... > https://fedoraproject.org/wiki/Flatpak#Fedora_flatpaks > In both cases, the build is fixed to a cryptographic hash of the source tarball. For Flathub, that is done in the manifest file.. ( https://github.com/flathub/org.libreoffice.LibreOffice/blob/master/org.libreoffice.LibreOffice.json) In Fedora, by the SOURCES file. In both cases, the exact tools versions used to build the binary from the source are recorded. For Flathub, that is done by embedding an extended version of the manifest in the application (at /app/manifest.json). For Fedora, that information is recorded by the buildroot information saved by koji. You could look for more - does the hash in the SOURCES file actually correspond to the published upstream tarball? Is there a signature on that tarball? Do you trust that signature? But I don't see much of a difference in this aspect. Building an intermediate RPM doesn't make the source => Flatpak pipeline more secure. - Owen ___ 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: LibreOffice packages
Is the Fedora OCI flatpak approach not about the trust into the chain of flatpak creation? src -> signed rpm -> flatpak? So, even in an ideal world where RHEL is immutable and the best workstation experience is based on flatpaks - RPMs are the building block. This is completly different to the Flathub approach ... https://fedoraproject.org/wiki/Flatpak#Fedora_flatpaks ___ 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: LibreOffice packages
On Mon, 5 Jun 2023 at 16:14, Michael Catanzaro wrote: > > > On Mon, Jun 5 2023 at 01:37:24 PM -0400, Stephen Smoogen > wrote: > > > > 1. What is a flatpak and what does it mean to have an application in > > it? Is it everything bundled in it or does it use layers? > > Two layers: > > * Runtime (base platform, responsibility of runtime maintainers) > * Application (including bundled dependencies not present in the > runtime) > > It's a compromise between traditional distribution-style dynamic > linking for the most common dependencies (the runtime), plus bundling > for the less-common dependencies the application needs that are not > present in the runtime. > > I just wanted to say thank you for taking the time to answer these questions. It was very helpful. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ 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: LibreOffice packages
On Mon, Jun 5 2023 at 04:46:42 PM -0400, Demi Marie Obenour wrote: Fedora could, of course ship its own SELinux policy for Flatpak (and I recommend this), but Flatpak will not (and cannot reasonably be expected to) integrate with SELinux natively. Well it would have to be a very permissive policy, because it would need to allow everything that any Flatpak app might ever want to do. Doesn't selinux work best when you have a good understanding of the software that you are trying to confine? Could Flatpak be changed to use e.g. KVM + crosvm for isolation? Flatpak does (via seccomp) prevent applications from creating _new_ user namespaces. Maybe in theory, but in practice that won't work because (a) it would be a major breaking change, and (b) flatpaks are integrated with the host system via D-Bus APIs, and throwing a VM boundary into the middle would make D-Bus rather difficult to do. For example, when you want to open a file, the application does not have any access to the host filesystem, so if it attempts to display its own file chooser, you'll see only a sad empty home directory. Instead, an application designed for Flatpak will use the org.freedesktop.portal.FileChooser D-Bus API to ask the portal running on the host system to show a file chooser instead. (The application's UI toolkit, e.g. GTK or Qt, will usually handle this.) Then the user interacts with the host file chooser, and the host mounts the selected file in the sandbox so that the application can only see the file that the user selected. That would need to somehow work across the VM boundary. No doubt it's possible somehow, but using a VM would certainly make that a lot more complicated. Now that's just one of dozens of portal APIs that allow sandboxed apps to interact with the host system. Another example: org.freedesktop.portal.FileTransfer, which allows drag-and-drop to and from the sandboxed application. All the portals would need to be reimplemented to ensure they still work with virtual machines instead of containerized applications. I don't want to say "no don't ever attempt this" but it sounds like a huge undertaking. We have to balance isolation vs. functionality; adding so much isolation such that applications no longer function as expected is too much. (We also have to satisfy users who expect flatpak to add no overheard relative to host system applications, which isn't possible but would be especially not possible if using VMs.) So I don't expect upstream to be interested in this. 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: LibreOffice packages
On Mon, Jun 5 2023 at 04:49:07 PM -0400, Demi Marie Obenour wrote: “several hundred megabits a second on tap at all times” is completely out of the question for the majority of the world’s population. I’m not sure what the median bandwidth in the developing world is, but it is far FAR less than that, not to mention often being metered. My standard response to concerns about image size is to point to: https://blogs.gnome.org/wjjt/2021/11/24/on-flatpak-disk-usage-and-deduplication/ Endless OS is designed for developing world users with metered connections or nonexistent connections, where updates have to be manually copied from a device that does have an internet connection to other devices via a USB stick. All the apps are Flatpaks. ___ 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: LibreOffice packages
On Mon, 2023-06-05 at 16:49 -0400, Demi Marie Obenour wrote: > On 6/5/23 15:01, Adam Williamson wrote: > > On Mon, 2023-06-05 at 19:51 +0200, Roberto Ragusa wrote: > > > On 6/5/23 19:13, Demi Marie Obenour wrote: > > > > > > > Are you willing to do the packaging work? Asking upstream to create > > > > packages for every distribution is not reasonable. > > > > > > I would never want upstream to do packaging, as experience teaches, > > > they would certainly do it wrong. > > > Packaging and integration is a job for the distribution; it is their > > > added value. Otherwise, what's the meaning of a distribution, if > > > the system is composed by a minimal booting image on which you > > > add upstream generated blobs? > > > > This is really the heart of the question, and it's an interesting one. > > > > The idea that the distribution's job is to package up everything you > > might possibly want to use on your system is a very old one that goes > > back to the days before having an internet connection was the norm, let > > alone having several hundred megabits a second on tap at all times. > > “several hundred megabits a second on tap at all times” is completely > out of the question for the majority of the world’s population. I’m not > sure what the median bandwidth in the developing world is, but it is far > FAR less than that, not to mention often being metered. I knew someone was going to bring this up, but let's be realistic. The majority of the world's population does not use Fedora and is not involved in F/OSS development. I entirely support any and all efforts to improve that, but practically speaking, the people who build and use F/OSS mostly have very good internet connections. It is already, realistically speaking, very hard to use Fedora without one. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org 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: LibreOffice packages
On 6/5/23 15:01, Adam Williamson wrote: > On Mon, 2023-06-05 at 19:51 +0200, Roberto Ragusa wrote: >> On 6/5/23 19:13, Demi Marie Obenour wrote: >> >>> Are you willing to do the packaging work? Asking upstream to create >>> packages for every distribution is not reasonable. >> >> I would never want upstream to do packaging, as experience teaches, >> they would certainly do it wrong. >> Packaging and integration is a job for the distribution; it is their >> added value. Otherwise, what's the meaning of a distribution, if >> the system is composed by a minimal booting image on which you >> add upstream generated blobs? > > This is really the heart of the question, and it's an interesting one. > > The idea that the distribution's job is to package up everything you > might possibly want to use on your system is a very old one that goes > back to the days before having an internet connection was the norm, let > alone having several hundred megabits a second on tap at all times. “several hundred megabits a second on tap at all times” is completely out of the question for the majority of the world’s population. I’m not sure what the median bandwidth in the developing world is, but it is far FAR less than that, not to mention often being metered. -- 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: LibreOffice packages
On 6/5/23 16:35, Michael Catanzaro wrote: > On Mon, Jun 5 2023 at 02:09:58 PM -0400, Steve Grubb > wrote: >> Yes. And how does it's security model work? > > The security model is that the application is assumed to be compromised > by malicious input and is trying to do evil things to the host system, > like read your home directory and send copies of your files to a > ransomware operator or nation state. Linux namespaces plus seccomp > filters are used to confine applications to prevent them from messing > with the host system, or reading your personal files, etc. > > It's great in theory. Problem is, as a transition measure to encourage > developers to adopt Flatpak, you can give your application extra > permissions that totally break the security model, and this is > extremely common in practice. You should only trust applications that > don't do this, but most apps do. See [1] for a discussion of this. > > [1] > https://theevilskeleton.gitlab.io/2023/05/11/overview-of-flatpaks-permission-models.html > > There are different degrees of badness. E.g. Epiphany, which I > maintain, has a sandbox hole that allows it to read and write your > Downloads directory, and another hole that allows it to talk to > Geoclue. These are both unacceptable, but certainly not as bad as > allowing read/write access to the user's home directory or root > filesystem, which many apps actually do. > > Flatpak could be pretty darn secure, but only if we stop allowing this, > and I fear that would likely result in applications abandoning the > platform. This is a major threat IMO. I'd love to see more effort > towards improving our portals so that applications don't need to use > static permissions anymore. We need to really clamp down on this so > that users can trust the Flatpak ecosystem. > >> What is the root of trust? > > I think there is no root. A GPG key is provided when installing a > runtime or application. > >> Are they signed by a Fedora key that I already >> have? > > Nope (except presumably for Fedora Flatpaks). > >> How can we verify it's integrity? > > I think the GPG keys are trust-on-first-use. > >> Once installed, how do I verify it's >> integrity? How do I check if anything has been modified? > > I don't know. Non-Fedora Flatpaks are stored using ostree, so people > familiar with ostree would be able to answer this question. Fedora > Flatpaks are OCI containers, so people familiar with OCI containers > would know about that. > > ostree is a "git for binaries" and you can detect normal non-malicious > modification by looking at the history, e.g. `flatpak remote-info --log > flathub org.gnome.Platform//44`; however, this only tells you when > something changed, not what actually changed. > >> Does it integrate >> well with SE Linux, > > No. selinux is entirely outside the Flatpak security model because > Flatpak is a cross-distro tool and selinux is not used outside Fedora > and Red Hat distros. Fedora could, of course ship its own SELinux policy for Flatpak (and I recommend this), but Flatpak will not (and cannot reasonably be expected to) integrate with SELinux natively. >> IMA, fapolicyd, or openscap? > > I'm not familiar with these technologies, but I think the answer is: no. > >> On a locked down system, are >> there sysctls that I have undo such as user namespaces? > > Technically, Flatpak can work without user namespaces, but this is a > legacy configuration and it only works if bubblewrap (/usr/bin/bwrap) > is built to use suid root instead of user namespaces, which is not > recommend and which we do not do in Fedora. (I think Debian maybe still > does this?) So it will surely break if you disable user namespaces, but > you might be able to make it work by rebuilding your own bubblewrap > instead of using Fedora's. > > The Flatpak sandbox does not attempt to guard against kernel bugs -- it > can't, because it has to allow access to all syscalls that applications > might reasonably want to use -- so if you don't trust the kernel to be > secure (including user namespaces), Flatpak is not the tool for you. Could Flatpak be changed to use e.g. KVM + crosvm for isolation? Flatpak does (via seccomp) prevent applications from creating _new_ user namespaces. -- 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: LibreOffice packages
On Mon, Jun 5 2023 at 02:09:58 PM -0400, Steve Grubb wrote: Yes. And how does it's security model work? The security model is that the application is assumed to be compromised by malicious input and is trying to do evil things to the host system, like read your home directory and send copies of your files to a ransomware operator or nation state. Linux namespaces plus seccomp filters are used to confine applications to prevent them from messing with the host system, or reading your personal files, etc. It's great in theory. Problem is, as a transition measure to encourage developers to adopt Flatpak, you can give your application extra permissions that totally break the security model, and this is extremely common in practice. You should only trust applications that don't do this, but most apps do. See [1] for a discussion of this. [1] https://theevilskeleton.gitlab.io/2023/05/11/overview-of-flatpaks-permission-models.html There are different degrees of badness. E.g. Epiphany, which I maintain, has a sandbox hole that allows it to read and write your Downloads directory, and another hole that allows it to talk to Geoclue. These are both unacceptable, but certainly not as bad as allowing read/write access to the user's home directory or root filesystem, which many apps actually do. Flatpak could be pretty darn secure, but only if we stop allowing this, and I fear that would likely result in applications abandoning the platform. This is a major threat IMO. I'd love to see more effort towards improving our portals so that applications don't need to use static permissions anymore. We need to really clamp down on this so that users can trust the Flatpak ecosystem. What is the root of trust? I think there is no root. A GPG key is provided when installing a runtime or application. Are they signed by a Fedora key that I already have? Nope (except presumably for Fedora Flatpaks). How can we verify it's integrity? I think the GPG keys are trust-on-first-use. Once installed, how do I verify it's integrity? How do I check if anything has been modified? I don't know. Non-Fedora Flatpaks are stored using ostree, so people familiar with ostree would be able to answer this question. Fedora Flatpaks are OCI containers, so people familiar with OCI containers would know about that. ostree is a "git for binaries" and you can detect normal non-malicious modification by looking at the history, e.g. `flatpak remote-info --log flathub org.gnome.Platform//44`; however, this only tells you when something changed, not what actually changed. Does it integrate well with SE Linux, No. selinux is entirely outside the Flatpak security model because Flatpak is a cross-distro tool and selinux is not used outside Fedora and Red Hat distros. IMA, fapolicyd, or openscap? I'm not familiar with these technologies, but I think the answer is: no. On a locked down system, are there sysctls that I have undo such as user namespaces? Technically, Flatpak can work without user namespaces, but this is a legacy configuration and it only works if bubblewrap (/usr/bin/bwrap) is built to use suid root instead of user namespaces, which is not recommend and which we do not do in Fedora. (I think Debian maybe still does this?) So it will surely break if you disable user namespaces, but you might be able to make it work by rebuilding your own bubblewrap instead of using Fedora's. The Flatpak sandbox does not attempt to guard against kernel bugs -- it can't, because it has to allow access to all syscalls that applications might reasonably want to use -- so if you don't trust the kernel to be secure (including user namespaces), Flatpak is not the tool for you. If an app coredumps, does a problem report get generated? Who gets it? Nope, there's nothing. You have to manually create a backtrace using flatpak-coredumpctl and then create a bug report yourself. This is really bad. We need ABRT to handle this so we can generate crash reports like we do for Fedora's packaged software. 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: LibreOffice packages
On Mon, Jun 5 2023 at 01:37:24 PM -0400, Stephen Smoogen wrote: 1. What is a flatpak and what does it mean to have an application in it? Is it everything bundled in it or does it use layers? Two layers: * Runtime (base platform, responsibility of runtime maintainers) * Application (including bundled dependencies not present in the runtime) It's a compromise between traditional distribution-style dynamic linking for the most common dependencies (the runtime), plus bundling for the less-common dependencies the application needs that are not present in the runtime. 2. So there are these 'SDKs' that people mention? What is in them? How are they built? How are they updated? Who maintains them and how can we 'verify' in the 'trust and verify' method (aka source code, build flags, build system). Confusingly, SDK has two meanings. First, the SDK is an alternate version of the runtime intended for developers. The runtime normally used by users is the "platform" runtime and the runtime for developers is the SDK. The SDK adds developer tools like gdb, valgrind, etc. For example, GNOME applications usually run against the org.gnome.Platform runtimes, but you might need to tell them to use org.gnome.Sdk instead if you need to debug something. Second, there is freedesktop-sdk, which is the name of the project that produces the base runtime that is the de facto default runtime that most Flatpak applications use. Both the GNOME and KDE runtimes are based on freedesktop-sdk. (The Fedora runtime is a notable exception in that it is mostly independent of freedesktop-sdk, with everything built from Fedora RPMs instead.) The runtimes are maintained in places like [1] and [2] and [3] and [4] by friendly neighborhood open source people, so it's easy to check what they contain. They are built in different ways. [1] and [2] are built using Buildstream. [3] is built using flatpak-builder. [4] is built using modulemd (but that will have to change due to failure of Fedora modularity). So these are three quite different ways of building runtimes. I'm familiar with the Buildstream runtimes. For source code, there are references to tarballs or git repos in each Buildstream element. For build flags, the freedesktop and GNOME runtimes use build flags based on Fedora's build flags [5] with some adjustments (there are no GCC specs, GCC is configured a bit differently than ours). As far as verification, I guess you want to look at build logs? Unfortunately I'm not smart enough to do this reliably anymore, as Buildstream likes to reuse cached builds and I don't know how to see logs for these builds. :( It's a problem. But for at least freedesktop-sdk and GNOME, you can see *some* build logs by looking at the CI artifacts. [1] https://gitlab.com/freedesktop-sdk/freedesktop-sdk [2] https://gitlab.gnome.org/GNOME/gnome-build-meta [3] https://invent.kde.org/packaging/flatpak-kde-runtime [4] https://src.fedoraproject.org/flatpaks/flatpak-runtime/ [5] https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/blob/master/include/flags.yml I think a FAQ around these and others would probably cut down a lot of the uncertainty and doubt people feel. Probably, but I'm not going to volunteer to help with that. :) There is [6], but it's pretty basic and doesn't answer your questions. [6] https://flatpak.org/faq/ ___ 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: LibreOffice packages
On Mon, Jun 5 2023 at 01:05:25 PM -0500, Chris Adams wrote: It's layered, but from what I understand, an upper layer depends on a specific build of a lower layer. So using the up-thread example, if there's a security update to zlib, the lower layer can rebuild to pick it up, but until the upper layer (like say LO) also rebuilds on top of the new lower layer, they'll be running on the old version. Well, *generally* that is entirely untrue. But sometimes it really is true. That's the simple answer. Apologies for turning this into an essay, but there's no simple way to explain this. There are two different considerations here. Point 1: TL;DR what Adam Williamson already said is correct. Flatpak itself only knows about two layers: the runtime and the application. You do have to rebuild the application to use a new *major* version of the runtime (comparable to new major versions of Fedora), but not for normal updates of that runtime. Let's hypothetically say that your app is using the GNOME 44 runtime and there is a bug in the zlib provided by the runtime. You do not need to rebuild your app for users to get the new zlib. However, let's say your application is instead using the GNOME 42 runtime, which is end of life and won't receive any further updates. To get the updated zlib, the application has to update to the newer GNOME 44 or 43 runtime, and users will suffer from the zlib bug until it does so. You can think of different versions of the runtimes as entirely different runtimes: org.gnome.Platform/x86_64/42, org.gnome.Platform/x86_64/43, org.gnome.Platform/x86_64/44. Each runtime receives regular updates independently from your application, but you have to update your application to switch between major versions. It's a compromise between updating too much and breaking your app, vs. updating too little and leaving users to suffer from bugs and security issues. (Compromise is a theme of Flatpak: the split between runtime vs. application is also a compromise between which dependencies are updated by the runtime maintainers, comparable to traditional distribution maintenance, vs. which dependencies are bundled and have to be updated by application maintainers, at the mercy of the app developers' attentiveness.) Point 2: But now, to make things more complicated, sometimes runtimes and applications are *themselves* built from different layers. Flatpak itself doesn't know about these layers, and most Flatpak users don't know about it either, and I wouldn't have even mentioned it here except for your comment, but when you build things this way, you really do have to rebuild the upper layer to update the lower layer. This is why I couldn't say your comment was entirely incorrect. Let's start with runtimes. For example, the GNOME runtimes org.gnome.Platform are based on the freedesktop-sdk runtimes org.freedesktop.Platform. zlib is actually maintained as part of the freedesktop-sdk, so we do not have our own GNOME packaging for zlib: it's all inherited from freedesktop-sdk. We do have to manually update the GNOME runtime to use a newer version of freedesktop-sdk. That is, when we update the zlib element in freedesktop-sdk, users do not actually receive the newer zlib until we update the freedesktop-sdk element in the GNOME runtime. That happens regularly, but it does introduce delay. The GNOME and KDE runtimes are both based on freedesktop-sdk, so these are layered runtimes. The freedesktop-sdk runtime is not based on anything else. Then the Fedora runtimes are the only runtimes I'm aware of that are not based on freedesktop-sdk. So some runtimes are layered, and some are not. Now, most applications are just a single layer, but some include a "base app" which is basically a way for multiple applications to share the same set of bundled dependencies between themselves. Most applications do not use base apps, but if you do, then you do need to rebuild the application in order to update the dependencies from the base app. I think Flathub *could* theoretically do that for you automatically, but I've asked and I'm told it doesn't. What do base apps look like? I searched Flathub for "base" [1] and it looks like base apps are mostly used for web engines. For example, there is an io.qt.qtwebengine.BaseApp and that seems to be how Flathub applications are expected to use QtWebEngine. This means that apps using QtWebEngine need to be careful to monitor for updates and rebuild as required, or else users will wind up using old versions. This is not great, but at least it's somewhat better than manually bundling your own QtWebEngine. (In contrast, WebKitGTK is part of the GNOME runtime, so applications don't have to worry about updating it and can trust that the runtime maintainers will handle that.) Conclusion: * Runtime maintainers are responsible for updating dependencies that are components of the runtime (including freedesktop-sdk) *
Re: LibreOffice packages
Il 05/06/23 19:51, Roberto Ragusa ha scritto: > On 6/5/23 19:13, Demi Marie Obenour wrote: > >> Are you willing to do the packaging work? Asking upstream to create >> packages for every distribution is not reasonable. > I would never want upstream to do packaging, as experience teaches, > they would certainly do it wrong. > Packaging and integration is a job for the distribution; it is their > added value. Otherwise, what's the meaning of a distribution, if > the system is composed by a minimal booting image on which you > add upstream generated blobs? > > Sorry, but the common "why do not do it yourself?" objection is not > the correct way to address my point. As a "consumer" (even if, > not paying) I am just expressing my idea about what I would like or not. > The "producers" (Fedora/RH) can take note, or ignore the feedback. > Their luck will, at the end of the day, depend on the merit of > their choices. > Anyway, yes, I've considered becoming a Fedora packager, I've started > the process and then got discouraged by the abundant bureaucracy. > And these kinds of threads do not help in regaining some enthusiasm in > resuming the process. > > Regards. > Hey Roberto, let me know if there's something specific where I can help you in becoming a Fedora packager, if you're interested. It's a little hard at the beginning, but then you'll find out that once you get the basis it's really easy (if the software you're trying to package doesn't require some weird thing to be built, of course). Feel free to write me directly or to chat with me in Matrix (I'm not often in chat, though). Mattia ___ 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: LibreOffice packages
Once upon a time, Adam Williamson said: > On Mon, 2023-06-05 at 13:05 -0500, Chris Adams wrote: > > It's layered, but from what I understand, an upper layer depends on a > > specific build of a lower layer. So using the up-thread example, if > > there's a security update to zlib, the lower layer can rebuild to pick > > it up, but until the upper layer (like say LO) also rebuilds on top of > > the new lower layer, they'll be running on the old version. > > No, I don't believe that's accurate. It's more of a major/minor thing. > The 'lower layer' can be updated with bug and security fixes without > any rebuild or change needed to 'upper layers'. You only need a rebuild > if the 'lower layer' is doing a "major" incompatible update (this is > something the lower layer is in charge of defining). Okay, that's good to know. I thought I got the layer description from this list, but maybe I just misread (or read someone else's mistaken understanding). Sorry for any confusion. -- Chris Adams ___ 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: LibreOffice packages
On Mon, 2023-06-05 at 19:51 +0200, Roberto Ragusa wrote: > On 6/5/23 19:13, Demi Marie Obenour wrote: > > > Are you willing to do the packaging work? Asking upstream to create > > packages for every distribution is not reasonable. > > I would never want upstream to do packaging, as experience teaches, > they would certainly do it wrong. > Packaging and integration is a job for the distribution; it is their > added value. Otherwise, what's the meaning of a distribution, if > the system is composed by a minimal booting image on which you > add upstream generated blobs? This is really the heart of the question, and it's an interesting one. The idea that the distribution's job is to package up everything you might possibly want to use on your system is a very old one that goes back to the days before having an internet connection was the norm, let alone having several hundred megabits a second on tap at all times. It's a good model that has served us well for a long time and helped us produce something which a lot of people like and enjoy using, which is a great thing. But it's also a model that's showing stress in several ways, and which we can feasibly re-evaluate. Here are some of them that I can think of: 1. There's a lot more software out there. Here's absolutely everything in the first combined Fedora release (after the core/extras split ended): https://archives.fedoraproject.org/pub/archive/fedora/linux/releases/7/Everything/x86_64/os/Fedora/ there are, by my count, 9330 binary packages there. That's a lot! But, per https://github.com/asamalik/counting-fedora-packages , even in 2019 we had 49,464 binary packages, and probably the number has gone up further since then. We're now packaging 5x as much stuff as we did in the olde days. Yet, arguably, it's *less* likely than it was in the Fedora 7 days that you can find everything you actually need in the distribution repository. So, to me, that's one indication of strain in the model. 2. There's less buy-in to the distribution model throughout the F/OSS ecosystem. This is indicated by the existence of flatpaks and snaps, and upstreams which indicate a preference for those. It's also indicated by the existence and popularity of non-distribution software repositories (often tied to languages): pypi, rubygems and so on (and, again, upstreams which express no interest in supporting the downstream distribution model). 3. The model is less directly in the interests of our corporate sponsor. Red Hat's business model and goals have changed quite a lot since the olde days. Even after the RHL -> RHEL/Fedora split that created Fedora, RH was fundamentally still in the "everything- distribution business". RH had a clear direct interest in Fedora being an everything-distribution, because RHEL needed to be one too. That was what customers were buying, though possibly with a slightly different focus on what they actually wanted to do with it than Fedora users, and RHEL was more or less the only thing Red Hat sold. Nowadays, the picture is more complicated. RHEL is still a huge business for Red Hat, but it has other lines of business too. RHEL has also been going more aggressively down the "not an everything-distribution any more" path than Fedora has. RHEL these days does not have anything like as much stuff in it as Fedora does, and RHEL customers - AIUI - are increasingly less likely than before to be buying an everything-OS for traditional computers, and increasingly more likely to be doing something more complicated and hybrid than that. The case in point is a pretty solid example of that: it is fairly inarguable that it's less directly important to RH that Fedora contains an RPM-packaged traditional office suite in 2023 than it was in 2007. This is a complicated reality to navigate, but it *is* a reality, and it's one we're gonna have to figure out. Fedora is still immensely valuable to Red Hat, but it's not necessarily immensely valuable to Red Hat *as an everything-distribution* (disclaimer: this is my personal interpretation, not RH policy, I'm not a person who sets RH policy - ask Matt or Josh for that :>). So what does that mean to us as Fedora? Does it mean we need to work out a different way to be an everything-distribution, or does it mean we need to figure out a different thing to be? I don't think RH wants to or can dictate the outcome of that discussion, but at the same time, we have to recognize RH does not have the same motivation to sponsor Fedora maintenance of every possible thing you can deploy on a computer to the same extent as it did in the past. > Sorry, but the common "why do not do it yourself?" objection is not > the correct way to address my point. As a "consumer" (even if, > not paying) I am just expressing my idea about what I would like or not. > The "producers" (Fedora/RH) can take note, or ignore the feedback. > Their luck will, at the end of the day, depend on the merit of > their choices. Yup, and this is totally fair. (
Re: LibreOffice packages
On Mon, 2023-06-05 at 13:05 -0500, Chris Adams wrote: > Once upon a time, Stephen Smoogen said: > > 1. What is a flatpak and what does it mean to have an application in it? Is > > it everything bundled in it or does it use layers? > > It's layered, but from what I understand, an upper layer depends on a > specific build of a lower layer. So using the up-thread example, if > there's a security update to zlib, the lower layer can rebuild to pick > it up, but until the upper layer (like say LO) also rebuilds on top of > the new lower layer, they'll be running on the old version. No, I don't believe that's accurate. It's more of a major/minor thing. The 'lower layer' can be updated with bug and security fixes without any rebuild or change needed to 'upper layers'. You only need a rebuild if the 'lower layer' is doing a "major" incompatible update (this is something the lower layer is in charge of defining). For e.g., in my `flatpak list` right now, I have these: Name Application ID Version Branch Origin Installation Fedora Platform org.fedoraproject.Platform38 f38 fedora system Freedesktop Platform org.freedesktop.Platform 22.08.12.1 22.08 flathub system the "branch" there is the 'major' version. App flatpaks will say they require "f38" Fedora platform or "22.08" Freedesktop platform, and there can be updates within those branches (e.g. maybe I'll get 22.08.12.2 or 22.08.13.1 of the Freedesktop platform as an update) without the app flatpaks changing. But for an app flatpak to 'rebase' to "f39" or "23.04" (or whatever the next version is gonna be, I don't actually know), *that* would require a rebuild. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org 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: LibreOffice packages
On Mon, 5 Jun 2023 at 14:10, Steve Grubb wrote: > On Monday, June 5, 2023 1:37:24 PM EDT Stephen Smoogen wrote: > > On Mon, 5 Jun 2023 at 13:32, Michael Catanzaro > > > > wrote: > > > On Mon, Jun 5 2023 at 01:13:50 PM -0400, Demi Marie Obenour > > > > > > wrote: > > > > zlib should be added to the standard freedesktop.org runtime if it > is > > > > not > > > > already included. > > > > > > zlib is included in both freedesktop-sdk and also GNOME runtimes, so > > > nobody should need to bundle it. > > > > > > Michael > > > > The problem I see in these conversations are: > > > > 1. What is a flatpak and what does it mean to have an application in it? > Is > > it everything bundled in it or does it use layers? > > 2. So there are these 'SDKs' that people mention? What is in them? How > are > > they built? How are they updated? Who maintains them and how can we > > 'verify' in the 'trust and verify' method (aka source code, build flags, > > build system). > > > > I think a FAQ around these and others would probably cut down a lot of > the > > uncertainty and doubt people feel. > > Yes. And how does it's security model work? > > What is the root of trust? Are they signed by a Fedora key that I already > have? How can we verify it's integrity? Once installed, how do I verify > it's > integrity? How do I check if anything has been modified? Does it integrate > well with SE Linux, IMA, fapolicyd, or openscap? On a locked down system, > are > there sysctls that I have undo such as user namespaces? If an app > coredumps, > does a problem report get generated? Who gets it? > > How can I tell what the security policy that the upstream chose to implement for me. > -Steve > > > -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ 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: LibreOffice packages
On 6/5/23 2:05 PM, Chris Adams wrote: Once upon a time, Stephen Smoogen said: 1. What is a flatpak and what does it mean to have an application in it? Is it everything bundled in it or does it use layers? It's layered, but from what I understand, an upper layer depends on a specific build of a lower layer. So using the up-thread example, if there's a security update to zlib, the lower layer can rebuild to pick it up, but until the upper layer (like say LO) also rebuilds on top of the new lower layer, they'll be running on the old version. These layers (runtimes and addons) can be updated and applications take the changes after being restarted, no nee to rebuild. The rebuild is only needed if the library is bundled with the applications because it isn't part of the chosen runtime or addons. Runtimes contains aren´t and entire Linux distribution, so applications frequently need to bundle libraries. Sites like flathub should add a way to check bundled dependencies in order to notify packagers of updating an application. Like server container need security audit tools. ___ 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: LibreOffice packages
On Monday, June 5, 2023 1:37:24 PM EDT Stephen Smoogen wrote: > On Mon, 5 Jun 2023 at 13:32, Michael Catanzaro > > wrote: > > On Mon, Jun 5 2023 at 01:13:50 PM -0400, Demi Marie Obenour > > > > wrote: > > > zlib should be added to the standard freedesktop.org runtime if it is > > > not > > > already included. > > > > zlib is included in both freedesktop-sdk and also GNOME runtimes, so > > nobody should need to bundle it. > > > > Michael > > The problem I see in these conversations are: > > 1. What is a flatpak and what does it mean to have an application in it? Is > it everything bundled in it or does it use layers? > 2. So there are these 'SDKs' that people mention? What is in them? How are > they built? How are they updated? Who maintains them and how can we > 'verify' in the 'trust and verify' method (aka source code, build flags, > build system). > > I think a FAQ around these and others would probably cut down a lot of the > uncertainty and doubt people feel. Yes. And how does it's security model work? What is the root of trust? Are they signed by a Fedora key that I already have? How can we verify it's integrity? Once installed, how do I verify it's integrity? How do I check if anything has been modified? Does it integrate well with SE Linux, IMA, fapolicyd, or openscap? On a locked down system, are there sysctls that I have undo such as user namespaces? If an app coredumps, does a problem report get generated? Who gets it? -Steve ___ 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: LibreOffice packages
Once upon a time, Stephen Smoogen said: > 1. What is a flatpak and what does it mean to have an application in it? Is > it everything bundled in it or does it use layers? It's layered, but from what I understand, an upper layer depends on a specific build of a lower layer. So using the up-thread example, if there's a security update to zlib, the lower layer can rebuild to pick it up, but until the upper layer (like say LO) also rebuilds on top of the new lower layer, they'll be running on the old version. -- Chris Adams ___ 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: LibreOffice packages
On 6/5/23 19:13, Demi Marie Obenour wrote: Are you willing to do the packaging work? Asking upstream to create packages for every distribution is not reasonable. I would never want upstream to do packaging, as experience teaches, they would certainly do it wrong. Packaging and integration is a job for the distribution; it is their added value. Otherwise, what's the meaning of a distribution, if the system is composed by a minimal booting image on which you add upstream generated blobs? Sorry, but the common "why do not do it yourself?" objection is not the correct way to address my point. As a "consumer" (even if, not paying) I am just expressing my idea about what I would like or not. The "producers" (Fedora/RH) can take note, or ignore the feedback. Their luck will, at the end of the day, depend on the merit of their choices. Anyway, yes, I've considered becoming a Fedora packager, I've started the process and then got discouraged by the abundant bureaucracy. And these kinds of threads do not help in regaining some enthusiasm in resuming the process. Regards. -- Roberto Ragusamail at robertoragusa.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: LibreOffice packages
On Mon, 5 Jun 2023 at 13:32, Michael Catanzaro wrote: > On Mon, Jun 5 2023 at 01:13:50 PM -0400, Demi Marie Obenour > wrote: > > zlib should be added to the standard freedesktop.org runtime if it is > > not > > already included. > > zlib is included in both freedesktop-sdk and also GNOME runtimes, so > nobody should need to bundle it. > > Michael > > The problem I see in these conversations are: 1. What is a flatpak and what does it mean to have an application in it? Is it everything bundled in it or does it use layers? 2. So there are these 'SDKs' that people mention? What is in them? How are they built? How are they updated? Who maintains them and how can we 'verify' in the 'trust and verify' method (aka source code, build flags, build system). I think a FAQ around these and others would probably cut down a lot of the uncertainty and doubt people feel. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren ___ 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: LibreOffice packages
On Mon, Jun 5 2023 at 01:13:50 PM -0400, Demi Marie Obenour wrote: zlib should be added to the standard freedesktop.org runtime if it is not already included. zlib is included in both freedesktop-sdk and also GNOME runtimes, so nobody should need to bundle it. 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: LibreOffice packages
On 6/5/23 12:13, Roberto Ragusa wrote: > On 6/5/23 09:35, Dominik 'Rathann' Mierzejewski wrote: > >> "easily install from Flathub" brings us closer to Windows where you >> "easily" install software from random places on the Internet and they >> bring their own bundled outdated versions of libraries. Flatpaks have >> the added downside of not integrating well with the OS on top of the >> bloat they bring. No, thank you. I'd rather have proper well-integrated >> RPMs installed from official distro repos. > > Unfortunately very few people still understand the value of using > system libraries instead of bundling one hundred of them in each package. > The day a zlib vulnerability is discovered, instead of just updating > a 50k lib rpm (and restart apps, or maybe reboot), you have to update > 30 apps, each of them sized at 50MB, and including possibly badly patched > versions of the lib etc. (good luck knowing which app is affected, > when the fix will be available, ...). zlib should be added to the standard freedesktop.org runtime if it is not already included. > There is a disturbing trend to bundling everything, which comes from > environments with no shared libraries (Android) or from languages > that do not do dynamic linking (golang). Bundling is the norm on Windows and macOS, and is required on Android and iOS. Cross-platform projects like LibreOffice, Firefox, and OBS already have to deal with updating bundled dependencies. > Whatever is not in a rule-conforming rpm, is not correctly packaged, > in my opinion. Are you willing to do the packaging work? Asking upstream to create packages for every distribution is not reasonable. -- 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: LibreOffice packages
Il 05/06/23 17:00, Michael J Gruber ha scritto: > I've taken up hyphen and the orphaned hyphen-* packages. They don't appear to > be high maintenance, but co-admins welcome, of course. Similarly, feel free > to admin as co-admin to other hyphen-* in case something needs coordinations. > The language packages are basically a "cp" in "%install", though, and nothing > to build. Yesterday I've taken hyphen-it, as well as mythes-it, and I've asked to be added as co-admin of hunspell-it. I've also updated hyphen-it and mythes-it as the dictionaries were outdated. As far as I can see, every language points to different sources: I wonder if it would be easier to maintain if we switch to sources provided by LO at https://github.com/LibreOffice/dictionaries so that we'll have a single specfile and source tarball with multiple subpackages, one for each language. The only problem is that in LO repository only the .dat file for thesaurus is provided, but the .idx file is missing. For italian language I had to generate the .idx file myself using http://proofingtoolgui.org/ and provide the sources in custom repository (https://pagure.io/dizionario_italiano). I couldn't find any CLI tool to do that. Mattia ___ 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: LibreOffice packages
On 6/5/23 09:35, Dominik 'Rathann' Mierzejewski wrote: "easily install from Flathub" brings us closer to Windows where you "easily" install software from random places on the Internet and they bring their own bundled outdated versions of libraries. Flatpaks have the added downside of not integrating well with the OS on top of the bloat they bring. No, thank you. I'd rather have proper well-integrated RPMs installed from official distro repos. Unfortunately very few people still understand the value of using system libraries instead of bundling one hundred of them in each package. The day a zlib vulnerability is discovered, instead of just updating a 50k lib rpm (and restart apps, or maybe reboot), you have to update 30 apps, each of them sized at 50MB, and including possibly badly patched versions of the lib etc. (good luck knowing which app is affected, when the fix will be available, ...). There is a disturbing trend to bundling everything, which comes from environments with no shared libraries (Android) or from languages that do not do dynamic linking (golang). Whatever is not in a rule-conforming rpm, is not correctly packaged, in my opinion. Regards. -- Roberto Ragusamail at robertoragusa.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: LibreOffice packages
I've taken up hyphen and the orphaned hyphen-* packages. They don't appear to be high maintenance, but co-admins welcome, of course. Similarly, feel free to admin as co-admin to other hyphen-* in case something needs coordinations. The language packages are basically a "cp" in "%install", though, and nothing to build. ___ 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: LibreOffice packages
On Mon, Jun 5, 2023 at 3:39 PM Vitaly Zaitsev via devel wrote: > > On 05/06/2023 13:54, Josh Boyer wrote: > > I'm not sure what led you to the conclusion that IBM has anything to > > do with this or that "they fired a lot of good engineers". I don't > > see evidence of either being the case. > > > > Please don't state your own assumptions as facts. > > https://news.ycombinator.com/item?id=35687687 HackerNews is not fact, also RH is a subsidiary not a unit with in IBM so it has it's own management, CEO etc. This thread is also widely off topic now. ___ 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: LibreOffice packages
On 05/06/2023 13:54, Josh Boyer wrote: I'm not sure what led you to the conclusion that IBM has anything to do with this or that "they fired a lot of good engineers". I don't see evidence of either being the case. Please don't state your own assumptions as facts. https://news.ycombinator.com/item?id=35687687 -- 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: LibreOffice packages
On Sat, Jun 3, 2023 at 2:43 PM Michael Catanzaro wrote: > We cannot ship anything from Flathub because > FESCo will not allow it. I don't *like* this FESCo requirement, but I > also don't expect that to change. I haven't studied that ruling, but perhaps the assumption was that said software is available both on Flathub and in Fedora? If LO disappears from Fedora, I'd consider it a good argument for re-evaluating that decision. ___ 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: LibreOffice packages
On Sat, 03 Jun 2023 08:45:28 -0500 Michael Catanzaro wrote: > I'm not going to defend callous layoffs during a time when Red Hat is > earning big profits. And I have no clue what our corporate overloads It is a fact of corporate life that if you are a manager and want to be promoted, cutting head count / costs, doing more with less resources, is a great way to move up the ladder. It shows the people above you that you have the right attitude. No one makes it to the executive level without a certain ruthlessness. ___ 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: LibreOffice packages
On Sat, Jun 3, 2023 at 3:56 AM Vitaly Zaitsev via devel wrote: > > On 03/06/2023 02:46, Leslie Satenstein via devel wrote: > > No LibreOffice, no continuation with Fedora. LO better be there with > > F39. Without it, all you have is Firefox. It is not enough to keep > > Fedora Diehards from jumping to another popular distribution. > > Yes, Fedora is dying. Slow, but imminent. IBM doesn't want to keep it in > a good condition, so they fired a lot of good engineers. It's very sad. > I have been using it for years. I'm not sure what led you to the conclusion that IBM has anything to do with this or that "they fired a lot of good engineers". I don't see evidence of either being the case. Please don't state your own assumptions as facts. 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: LibreOffice packages
> I've taken ownership of libreoffice for the time being, at least to keep the > lights > on. Co-maintainers, as always, welcome. Don't know how much time I'll be able to contribute, but you can count me in. As Mattia suggested, I think it might be a good idea to set up libreoffice-sig. A.FI. ___ 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: LibreOffice packages
On Sat, Jun 03, 2023 at 09:09:57AM +0200, Peter Boy wrote: > > Am 03.06.2023 um 02:06 schrieb Sandro : > > What will we ship in Fedora if we were to follow in Red Hat's > > footsteps? LibreOffice Flatpak? That may prove to be the straw > > that broke the camel's back. As I said before, I don't want to > > to reiterate the Flatpak vs. RPM discussion. But maybe that > > topic needs to be picked up and discussed, so we get a better > > understanding of where this will leave us. > > Instead of Flatpak I would prefer to pick up the software directly > from the project. The LibreOffice Flatpak *is* provided directly by the upstream Document Foundation (LibreOffice) project. 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 :| ___ 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: LibreOffice packages
On Saturday, 03 June 2023 at 14:42, Michael Catanzaro wrote: [...] > My $0.02: maintaining complex desktop applications as part of the operating > system requires significant effort and produces low value for users when you > can easily install that app from Flathub instead. (It *especially* doesn't "easily install from Flathub" brings us closer to Windows where you "easily" install software from random places on the Internet and they bring their own bundled outdated versions of libraries. Flatpaks have the added downside of not integrating well with the OS on top of the bloat they bring. No, thank you. I'd rather have proper well-integrated RPMs installed from official distro repos. Regards, Dominik -- Fedora https://fedoraproject.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ 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: LibreOffice packages
Il 02/06/23 09:22, Jiri Vanek ha scritto: > Damn thats a long list. > > Indeed. I can help and pick up a couple of packages, but what about the hunspell*, hyphen*, mythes*? I think those will require more work than what a volunteer packager can bring. Yet, I suspect dropping them will blow up quite a few things. Shall we set up a libreoffice-sig to coordinate community efforts in LO packaging? Mattia ___ 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: LibreOffice packages
On Fri, Jun 2, 2023, 9:09 AM Matthew Miller mailto:mat...@fedoraproject.org>> wrote: I think this sentiment is getting ahead of things. This thread _is_ that effort. Yes, but. In general, a better approach is to say "we plan on orphaning the packages in $timeframe". ... RH, for the moment is still represented as on the DocFoundation's Advisory Board, https://wiki.documentfoundation.org/TDF/Advisory_Board#Composition_of_the_Advisory_Board https://www.documentfoundation.org/advisory-board/ Has there been any indication yet as to their withdrawal there? or not? Dev comms with devs is one approach aspect of engagement with LO. Engagement at the organizational level is another. If RH's organizational support, or lack thereof, is now a risk -- existential or not -- then perhaps spreading that risk across other orgs' interests & support has possible value. Do any of the Fedora Project guidelines -- particularly any restrictions by RH's legal -- prevent increased/direct engagement with the DF's governance/advisory groups? Dev list is probly also not the right place for that discussion. BUT, it's where the immediate, legitimate discussion IS being had. ___ 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