Hey,
as you've probably seen, the LibreOffice RPMS have recently been orphaned, and I thought it would be good to explain the reasons behind this.
The Red Hat Display Systems team (the team behind most of Red Hat’s desktop efforts) has maintained the LibreOffice packages in Fedora for years as part of our work to support LibreOffice for Red Hat Enterprise Linux. We are adjusting our engineering priorities for RHEL for Workstations and focusing on gaps in Wayland, building out HDR support, building out what’s needed for color-sensitive work, and a host of other refinements required by Workstation users. This is work that will improve the workstation experience for Fedora as well as RHEL users, and which, we hope, will be positively received by the entire Linux community.
The tradeoff is that we are pivoting away from work we had been doing on desktop applications and will cease shipping LibreOffice as part of RHEL starting in a future RHEL version. This also limits our ability to maintain it in future versions of Fedora.
We will continue to maintain LibreOffice in currently supported versions of RHEL (RHEL 7, 8 and 9) with needed CVEs and similar for the lifetime of those releases (as published on the Red Hat website). As part of that, the engineers doing that work will contribute some fixes upstream to ensure LibreOffice works better as a Flatpak, which we expect to be the way that most people consume LibreOffice in the long term.
Any community member is of course free to take over maintenance, both for the RPMS in Fedora and the Fedora LibreOffice Flatpak, but be aware that this is a sizable block of packages and dependencies and a significant amount of work to keep up with.
Matthias
On 6/1/23 14:30, Matthias Clasen wrote:
Hey,
as you've probably seen, the LibreOffice RPMS have recently been orphaned, and I thought it would be good to explain the reasons behind this.
The Red Hat Display Systems team (the team behind most of Red Hat’s desktop efforts) has maintained the LibreOffice packages in Fedora for years as part of our work to support LibreOffice for Red Hat Enterprise Linux. We are adjusting our engineering priorities for RHEL for Workstations and focusing on gaps in Wayland, building out HDR support, building out what’s needed for color-sensitive work, and a host of other refinements required by Workstation users. This is work that will improve the workstation experience for Fedora as well as RHEL users, and which, we hope, will be positively received by the entire Linux community.
The tradeoff is that we are pivoting away from work we had been doing on desktop applications and will cease shipping LibreOffice as part of RHEL starting in a future RHEL version. This also limits our ability to maintain it in future versions of Fedora.
We will continue to maintain LibreOffice in currently supported versions of RHEL (RHEL 7, 8 and 9) with needed CVEs and similar for the lifetime of those releases (as published on the Red Hat website). As part of that, the engineers doing that work will contribute some fixes upstream to ensure LibreOffice works better as a Flatpak, which we expect to be the way that most people consume LibreOffice in the long term.
Any community member is of course free to take over maintenance, both for the RPMS in Fedora and the Fedora LibreOffice Flatpak, but be aware that this is a sizable block of packages and dependencies and a significant amount of work to keep up with.
Matthias
Why is a Flatpak a better choice for LibreOffice?
On Thu, Jun 1, 2023 at 2:36 PM Demi Marie Obenour demiobenour@gmail.com 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.
Having things as Flatpaks is also of value for us to enable long term efforts such as Fedora Silverblue.
Hope this answers your question.
Christian
On 6/1/23 15:59, Christian Schaller wrote:
On Thu, Jun 1, 2023 at 2:36 PM Demi Marie Obenour demiobenour@gmail.com wrote:
Why is a Flatpak a better choice for LibreOffice?
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.
Did you mean “now”? “not” seems like the opposite of your intended meaning.
Having things as Flatpaks is also of value for us to enable long term efforts such as Fedora Silverblue.
Hope this answers your question.
Christian--
Sincerely, Demi Marie Obenour (she/her/hers)
Yes, sorry about that meant now of course 😃
On Thu, Jun 1, 2023, 6:45 PM Demi Marie Obenour demiobenour@gmail.com wrote:
On 6/1/23 15:59, Christian Schaller wrote:
On Thu, Jun 1, 2023 at 2:36 PM Demi Marie Obenour <demiobenour@gmail.com
wrote:
Why is a Flatpak a better choice for LibreOffice?
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.
Did you mean “now”? “not” seems like the opposite of your intended meaning.
Having things as Flatpaks is also of value for us to enable long term efforts such as Fedora Silverblue.
Hope this answers your question.
Christian--
Sincerely, Demi Marie Obenour (she/her/hers)
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On 01-06-2023 21:59, Christian Schaller wrote:
On Thu, Jun 1, 2023 at 2:36 PM Demi Marie Obenour demiobenour@gmail.com 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.
Having things as Flatpaks is also of value for us to enable long term efforts such as Fedora Silverblue.
A while ago, I send a similar announcement to this list regarding Bottles [1]. Upstream solely wants to focus on their Flatpak package and actively discourages packagers to package Bottles natively for several distributions.
They even go as far as not accepting bug reports unless the bug is reproducible in the official Flatpak package.
The discussion that followed offered some arguments for preferring native RPM packages over Flatpak packages. I'm not going to re-iterate these. They can be looked up in the archive [1].
However, it surprises me that for a package, that is part of the deliverables of Fedora releases, no coordination effort was made to transition the package from Red Hat maintenance to Fedora maintenance. I would even go as far as that this should have been submitted as a change proposal, seeing that the package is in every (live) ISO Fedora ships.
Instead the package is being dropped like a hot potato, without even the courtesy of an announcement beforehand [2].
[1] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/... [2] not strictly required, but customary
PS: For anyone wondering what happened to Bottles, we managed to package all missing dependencies and update Bottles to the latest release, keeping it available as RPM package.
-- Sandro
Il 02/06/23 01:55, Sandro ha scritto:
However, it surprises me that for a package, that is part of the deliverables of Fedora releases, no coordination effort was made to transition the package from Red Hat maintenance to Fedora maintenance. I would even go as far as that this should have been submitted as a change proposal, seeing that the package is in every (live) ISO Fedora ships.
Instead the package is being dropped like a hot potato, without even the courtesy of an announcement beforehand [2].
I'm having a bad feeling about Fedora future lately, seeing all these RH withdrawals from the project.
I hope to be wrong. But could Fedora survive the day RH says goodbye? Shall we start thinking about having a structure (both government and financial) like libreoffice foundation?
BTW dropping RPMs for Flatpaks makes the whole Fedora philosophy useless. Flatpaks just bundles what they need, free software or not (i.e. codecs support) so upstreams have no interest in find OSS solutions.
Mattia
Il 02/06/23 01:55, Sandro ha scritto: I'm having a bad feeling about Fedora future lately, seeing all these RH withdrawals from the project.
That escalated quickly, yes. More worryingly: It escalated non-openly and non-collaboratively.
I hope to be wrong. But could Fedora survive the day RH says goodbye? Shall we start thinking about having a structure (both government and financial) like libreoffice foundation?
We depend quite a bit on infrastructure (both technical and staff-wise) which RedHat still provides generously to us. RH being a profit oriented company (or rather, part of an even more profit oriented company), "generous" probably is a naive description. They have to justify every investment, of course. Apparently, the terms for that justification changed with new stakeholders. I don't think that Fedora has changed a lot since. Maybe a governing structure outside of RedHat would make it easier for them to support Fedora, "lump-sum-wise" (money, man-years), because it would lift their requirement to justify each and every individual "item"?
BTW dropping RPMs for Flatpaks makes the whole Fedora philosophy useless. Flatpaks just bundles what they need, free software or not (i.e. codecs support) so upstreams have no interest in find OSS solutions.
Exactly. To me that seems to be the bigger problem, and it has been developping in that direction for a while already: - Fedora flatpaks never took off, both for technical reasons (it's still difficult for packagers) and ideological ones (marketing of flatpaks vs reality); both related to the way modules came upon us. - Codecs/Multimedia were never easy in Fedora; using (and providing) rpmfusion is made difficult by feature-reduced versions in Fedora, and by the fact that we cannot even include disabled repo config for them in Fedora. - Flathub flatpak config considered to be OK in Fedora by RH legal *because it is not Fedora specific* (as opposed to rpmfusion).
Taking all this together, the direction is: Sell the OS (that is, support and assurances) and let the customer be responsible for what "apps" they run on that OS (from flathub or wherever). Fedora flatpaks do not have any place there (and solve no problem).
I doubt whether that really is what customers want from RedHat. But I'm sure that is nothing which Fedora packagers want to be the upstream for. We'd flock elsewhere, be it distro A for its technical orientation, distro D for its stance on freedom, or some package upstreams to help with that flatpak, on whatsoever distro that will run on.
Lets not make this a drama.
Package maintenance changes have never gone through change proposals.
However, it surprises me that for a package, that is part of the
deliverables of Fedora releases, no coordination effort was made to transition the package from Red Hat maintenance to Fedora maintenance.
My email is that effort.
On Fri, 2 Jun 2023 at 07:20, Matthias Clasen mclasen@redhat.com wrote:
Lets not make this a drama.
Package maintenance changes have never gone through change proposals.
I am sorry, but this was made into a drama by the way this was executed. Surprise is the opposite of engagement and dropping a ton of packages and their dependencies and then announcing it is absolute surprise.
This isn't just package maintenance. This is a major change in what is expected to be included in the next workstation editions with the removal of expected functionality. If the packages are not picked up within a certain amount of time or can be rebuilt it means many packages will need to be edited. Those changes need to be researched, announced, and pushed through.
It is also drama because people in the community have no idea what else will take place? When uncertainty and doubt are allowed into the conversation, people jump to the extremes so they can feel ready to deal with it.
Could we try something different for future changes? 1. Announce that Red Hat will be moving from owning said packages and dependencies on X date. 2. Let people grieve about things for a short while but make it clear its happening. See if community members or other companies will take up the burden 3. Do the orphan or hand over of packages to the new group.
Instead of 3,1,2?
However, it surprises me that for a package, that is part of the
deliverables of Fedora releases, no coordination effort was made to transition the package from Red Hat maintenance to Fedora maintenance.
My email is that effort.
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Fri, Jun 2, 2023 at 2:28 PM Stephen Smoogen ssmoogen@redhat.com wrote:
On Fri, 2 Jun 2023 at 07:20, Matthias Clasen mclasen@redhat.com wrote:
Lets not make this a drama.
Package maintenance changes have never gone through change proposals.
I am sorry, but this was made into a drama by the way this was executed. Surprise is the opposite of engagement and dropping a ton of packages and their dependencies and then announcing it is absolute surprise.
This isn't just package maintenance. This is a major change in what is expected to be included in the next workstation editions with the removal of expected functionality. If the packages are not picked up within a certain amount of time or can be rebuilt it means many packages will need to be edited. Those changes need to be researched, announced, and pushed through.
It is also drama because people in the community have no idea what else will take place? When uncertainty and doubt are allowed into the conversation, people jump to the extremes so they can feel ready to deal with it.
Could we try something different for future changes?
- Announce that Red Hat will be moving from owning said packages and dependencies on X date.
- Let people grieve about things for a short while but make it clear its happening. See if community members or other companies will take up the burden
- Do the orphan or hand over of packages to the new group.
Instead of 3,1,2?
That may not always be possible, sometimes it involves departure or changes of roles for people and those can be delicate and are not always notifiable. I'm not sure that is the case here but I do know, from a blog post [1], that the previous maintainer is no longer at Red Hat.
Peter
[1] https://meeksfamily.uk/~michael/blog/2023-05-15-caolan.html
On Fri, 2 Jun 2023 at 09:40, Peter Robinson pbrobinson@gmail.com wrote:
On Fri, Jun 2, 2023 at 2:28 PM Stephen Smoogen ssmoogen@redhat.com wrote:
On Fri, 2 Jun 2023 at 07:20, Matthias Clasen mclasen@redhat.com wrote:
Lets not make this a drama.
Package maintenance changes have never gone through change proposals.
I am sorry, but this was made into a drama by the way this was
executed. Surprise is the opposite of engagement and dropping a ton of packages and their dependencies and then announcing it is absolute surprise.
This isn't just package maintenance. This is a major change in what is
expected to be included in the next workstation editions with the removal of expected functionality. If the packages are not picked up within a certain amount of time or can be rebuilt it means many packages will need to be edited. Those changes need to be researched, announced, and pushed through.
It is also drama because people in the community have no idea what else
will take place? When uncertainty and doubt are allowed into the conversation, people jump to the extremes so they can feel ready to deal with it.
Could we try something different for future changes?
- Announce that Red Hat will be moving from owning said packages and
dependencies on X date.
- Let people grieve about things for a short while but make it clear
its happening. See if community members or other companies will take up the burden
- Do the orphan or hand over of packages to the new group.
Instead of 3,1,2?
That may not always be possible, sometimes it involves departure or changes of roles for people and those can be delicate and are not always notifiable. I'm not sure that is the case here but I do know, from a blog post [1], that the previous maintainer is no longer at Red Hat.
Yes, I did engage mouth before brain on this. It isn't alway possible, and real life is messy. My apologies to Matthias in my wording makes it sound like this dropping was his decision and the way it was executed was his doing and fault.
Peter
[1] https://meeksfamily.uk/~michael/blog/2023-05-15-caolan.html _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Fri, Jun 2, 2023 at 9:40 AM Peter Robinson pbrobinson@gmail.com wrote:
On Fri, Jun 2, 2023 at 2:28 PM Stephen Smoogen ssmoogen@redhat.com wrote:
On Fri, 2 Jun 2023 at 07:20, Matthias Clasen mclasen@redhat.com wrote:
Lets not make this a drama.
Package maintenance changes have never gone through change proposals.
I am sorry, but this was made into a drama by the way this was
executed. Surprise is the opposite of engagement and dropping a ton of packages and their dependencies and then announcing it is absolute surprise.
This isn't just package maintenance. This is a major change in what is
expected to be included in the next workstation editions with the removal of expected functionality. If the packages are not picked up within a certain amount of time or can be rebuilt it means many packages will need to be edited. Those changes need to be researched, announced, and pushed through.
It is also drama because people in the community have no idea what else
will take place? When uncertainty and doubt are allowed into the conversation, people jump to the extremes so they can feel ready to deal with it.
Could we try something different for future changes?
- Announce that Red Hat will be moving from owning said packages and
dependencies on X date.
- Let people grieve about things for a short while but make it clear
its happening. See if community members or other companies will take up the burden
- Do the orphan or hand over of packages to the new group.
Instead of 3,1,2?
That may not always be possible, sometimes it involves departure or changes of roles for people and those can be delicate and are not always notifiable. I'm not sure that is the case here but I do know, from a blog post [1], that the previous maintainer is no longer at Red Hat.
Peter
[1] https://meeksfamily.uk/~michael/blog/2023-05-15-caolan.html
Yeah, Matthias posting this email was us trying to give the community proper notice. Caolan leaving accelerated things a lot here and also since we felt it correct to inform people about how our plans around RHEL informed this decision in Fedora we needed to spend some time getting internal approval for that, as engineers we don't have the authority to share what could be seen as Red Hat product plans publicly.
So while I understand that people like things to be announced with longer horizons it is simply not always possible. We got this message out as soon as we could.
Christian
On Fri, Jun 02, 2023 at 01:55:30AM +0200, Sandro wrote:
However, it surprises me that for a package, that is part of the deliverables of Fedora releases, no coordination effort was made to transition the package from Red Hat maintenance to Fedora maintenance. I would even go as far as that this should have been
I think this sentiment is getting ahead of things. This thread _is_ that effort. Asking people to submit a Change when they want or need to stop working on something seems... burdensome. (And, uh, what happens if that change is rejected? There's no _making_ people do things.)
On 02-06-2023 16:09, Matthew Miller wrote:
On Fri, Jun 02, 2023 at 01:55:30AM +0200, Sandro wrote:
However, it surprises me that for a package, that is part of the deliverables of Fedora releases, no coordination effort was made to transition the package from Red Hat maintenance to Fedora maintenance. I would even go as far as that this should have been
I think this sentiment is getting ahead of things. This thread _is_ that effort. Asking people to submit a Change when they want or need to stop working on something seems... burdensome. (And, uh, what happens if that change is rejected? There's no _making_ people do things.)
So, what is the contingency plan then? LibreOffice is a huge package and I could imagine that taking over maintenance of it is not an easy endeavor.
Taking into consideration the circumstances explained in replies later, I can understand that hands were tied. Yet, the decision to stop shipping LibreOffice is one that affects future RHEL releases and Red Hat's customers. Yet, the decision to orphan the LibreOffice stack of packages affects a much larger group of users.
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.
Let's hope that at least some lessons will be learned from this rather rushed decision. At least that is what it appears to be.
-- Sandro
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. Leslie Sent from Yahoo Mail on Android
On Fri, Jun 2, 2023 at 8:07 p.m., Sandrolists@penguinpee.nl wrote: On 02-06-2023 16:09, Matthew Miller wrote:
On Fri, Jun 02, 2023 at 01:55:30AM +0200, Sandro wrote:
However, it surprises me that for a package, that is part of the deliverables of Fedora releases, no coordination effort was made to transition the package from Red Hat maintenance to Fedora maintenance. I would even go as far as that this should have been
I think this sentiment is getting ahead of things. This thread _is_ that effort. Asking people to submit a Change when they want or need to stop working on something seems... burdensome. (And, uh, what happens if that change is rejected? There's no _making_ people do things.)
So, what is the contingency plan then? LibreOffice is a huge package and I could imagine that taking over maintenance of it is not an easy endeavor.
Taking into consideration the circumstances explained in replies later, I can understand that hands were tied. Yet, the decision to stop shipping LibreOffice is one that affects future RHEL releases and Red Hat's customers. Yet, the decision to orphan the LibreOffice stack of packages affects a much larger group of users.
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.
Let's hope that at least some lessons will be learned from this rather rushed decision. At least that is what it appears to be.
-- Sandro _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On 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 thinking about orphaning all my packages (more than 70) too.
Am 03.06.2023 um 09:56 schrieb Vitaly Zaitsev via devel devel@lists.fedoraproject.org:
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.
No, or only if we murder it. We have to adjust to a changing world. The first packages which were affected, was the Java stack. Our packaging ruleset fits less and less to the evolution in the development of (Linux) software.
We need to adapt it without giving up the basic principles (such as safety, freedom, reliability, etc). There are already a lot of suggestions for this. At that time, in connection with the Java stack, Fesco resp. the community was not (yet) ready. If now the damage is getting bigger and bigger, maybe that will change.
IBM doesn't want to keep it in a good condition, so they fired a lot of good engineers.
We should not spoil a constructive adjustment process with speculation.
It's very sad. I have been using it for years.
I'm thinking about orphaning all my packages (more than 70) too.
No need to overreact. As you wrote, we „have been using it for years“, and for good reason.
-- Peter Boy https://fedoraproject.org/wiki/User:Pboy PBoy@fedoraproject.org
Timezone: CET (UTC+1) / CEST /UTC+2)
Fedora Server Edition Working Group member Fedora Docs team contributor and board member Java developer and enthusiast
On Sat, Jun 3 2023 at 09:56:40 AM +0200, Vitaly Zaitsev via devel devel@lists.fedoraproject.org wrote:
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 going to defend callous layoffs during a time when Red Hat is earning big profits. And I have no clue what our corporate overloads will decide to do tomorrow if they wake up on the wrong side of the bed. But thus far, I'm not aware of any Fedora engineers who have been laid off or fired. It's people in supporting roles (e.g. Ben) who have actually been laid off. So I think what you're saying is simply not true.
Michael
P.S. Red Hat still makes decisions for itself. There's no point in blaming IBM for stuff that IBM has no involvement in.
On Sat, 03 Jun 2023 08:45:28 -0500 Michael Catanzaro mcatanzaro@redhat.com 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.
On Sat, Jun 3, 2023 at 3:56 AM Vitaly Zaitsev via devel devel@lists.fedoraproject.org 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
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
On Mon, Jun 5, 2023 at 3:39 PM Vitaly Zaitsev via devel devel@lists.fedoraproject.org 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.
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.
Am 03.06.2023 um 02:06 schrieb Sandro lists@penguinpee.nl:
On 02-06-2023 16:09, Matthew Miller wrote:
On Fri, Jun 02, 2023 at 01:55:30AM +0200, Sandro wrote:
However, it surprises me that for a package, that is part of the deliverables of Fedora releases, no coordination effort was made to transition the package from Red Hat maintenance to Fedora maintenance. I would even go as far as that this should have been
I think this sentiment is getting ahead of things. This thread _is_ that effort. Asking people to submit a Change when they want or need to stop working on something seems... burdensome. (And, uh, what happens if that change is rejected? There's no _making_ people do things.)
So, what is the contingency plan then? LibreOffice is a huge package and I could imagine that taking over maintenance of it is not an easy endeavor.
Taking into consideration the circumstances explained in replies later, I can understand that hands were tied. Yet, the decision to stop shipping LibreOffice is one that affects future RHEL releases and Red Hat's customers. Yet, the decision to orphan the LibreOffice stack of packages affects a much larger group of users.
If I understand the announcement correctly, future RHEL will not include LibreOffice anymore. That’s the reason, why the maintainers have withdrawn.
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. LO provides a rpm. Maybe we have to change our packaging strategy and allow „installation rpms“ that pick up an OSS project’s rpm and repack it with the proper system integration. We had something like that for Java a decade ago.
That’s probably not an optimal solution, but IMO way better than yet another re-packager. At least I would be willing to trust an OSS project more than some repackager.
Let's hope that at least some lessons will be learned from this rather rushed decision. At least that is what it appears to be.
Well, my lesson was years ago to drop Fedora desktop from my systems - too bulky, too bloated, too unreliable for my liking. A nice toy, but nothing for serious productive work.
-- Peter Boy https://fedoraproject.org/wiki/User:Pboy PBoy@fedoraproject.org
Timezone: CET (UTC+1) / CEST /UTC+2)
Fedora Server Edition Working Group member Fedora Docs team contributor and board member Java developer and enthusiast
If I understand the announcement correctly, future RHEL will not include LibreOffice anymore. That’s the reason, why the maintainers have withdrawn.
Instead of Flatpak I would prefer to pick up the software directly from the project. LO provides a rpm. Maybe we have to change our packaging strategy and allow „installation rpms“ that pick up an OSS project’s rpm and repack it with the proper system integration. We had something like that for Java a decade ago.
That’s probably not an optimal solution, but IMO way better than yet another re-packager. At least I would be willing to trust an OSS project more than some repackager.
...or, maybe, discuss with upstream a possible collaboration where the official RPMs would become those built in Fedora infrastructure instead of using an external one.
Also, as a more general speaking, with the upcoming change which will make easier to produce flatpaks directly from RPMs without the need of making modules, we can become more attractive to upstreams, as they will have a single infrastructure for publishing both RPMs and Flatpaks. A bi-directional collaboration with upstream, especially those bigger and fully open source like LO, would be beneficial (I think) for both sides. Can Mindshare (or another Fedora team) see if this is achievable?
Mattia
Well, my lesson was years ago to drop Fedora desktop from my systems - too bulky, too bloated, too unreliable for my liking. A nice toy, but nothing for serious productive work.
-- Peter Boy https://fedoraproject.org/wiki/User:Pboy PBoy(a)fedoraproject.org
Timezone: CET (UTC+1) / CEST /UTC+2)
Fedora Server Edition Working Group member Fedora Docs team contributor and board member Java developer and enthusiast
On Sat, Jun 03, 2023 at 09:09:57AM +0200, Peter Boy wrote:
Am 03.06.2023 um 02:06 schrieb Sandro lists@penguinpee.nl: 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
On Fri, Jun 2, 2023, 9:09 AM Matthew Miller mattdm@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". Even if $timeframe is a week, it shifts the perception to "we are communicating future plans" to "by they way we just dropped this thing, good luck." I know the intent of the original post was the former, but that doesn't mean people don't view it as the latter (particularly when seen in the broader context). Ideally, of course, $timeframe is longer than a week, but that's not always feasible. We all have constraints on our time and effort.
Asking people to submit a Change when they want or need to stop
working on something seems... burdensome. (And, uh, what happens if that change is rejected? There's no _making_ people do things.)
As the world's foremost expert on Fedora's Changes process, I agree. That said, there's value in the cross-functional visibility of a Change proposal. I've long thought we need an "announcement only" process that looks very similar to the current process, but I could never quite convince myself I knew how that should work. (This thread is not the place to discuss it, but maybe I'll start a separate conversation about that later)
On Fri, Jun 2, 2023, 9:09 AM Matthew Miller <mattdm@fedoraproject.org mailto:mattdm@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_Ad... 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.
On Thu, Jun 1, 2023 at 10:00 PM Christian Schaller cschalle@redhat.com wrote:
On Thu, Jun 1, 2023 at 2:36 PM Demi Marie Obenour demiobenour@gmail.com 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
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.
On Wed, Jun 7, 2023 at 8:51 AM Stephan Bergmann sbergman@redhat.com 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
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
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
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".
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-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On 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
I've taken ownership of libreoffice for the time being, at least to keep the lights on. Co-maintainers, as always, welcome.
-- 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 Thursday, June 1st, 2023 at 1:30 PM, Matthias Clasen mclasen@redhat.com wrote:
Hey,
as you've probably seen, the LibreOffice RPMS have recently been orphaned, and I thought it would be good to explain the reasons behind this.
The Red Hat Display Systems team (the team behind most of Red Hat’s desktop efforts) has maintained the LibreOffice packages in Fedora for years as part of our work to support LibreOffice for Red Hat Enterprise Linux. We are adjusting our engineering priorities for RHEL for Workstations and focusing on gaps in Wayland, building out HDR support, building out what’s needed for color-sensitive work, and a host of other refinements required by Workstation users. This is work that will improve the workstation experience for Fedora as well as RHEL users, and which, we hope, will be positively received by the entire Linux community.
The tradeoff is that we are pivoting away from work we had been doing on desktop applications and will cease shipping LibreOffice as part of RHEL starting in a future RHEL version. This also limits our ability to maintain it in future versions of Fedora.
We will continue to maintain LibreOffice in currently supported versions of RHEL (RHEL 7, 8 and 9) with needed CVEs and similar for the lifetime of those releases (as published on the Red Hat website). As part of that, the engineers doing that work will contribute some fixes upstream to ensure LibreOffice works better as a Flatpak, which we expect to be the way that most people consume LibreOffice in the long term.
Any community member is of course free to take over maintenance, both for the RPMS in Fedora and the Fedora LibreOffice Flatpak, but be aware that this is a sizable block of packages and dependencies and a significant amount of work to keep up with.
Matthias _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
Gwyn Ciesla via devel wrote:
I've taken ownership of libreoffice for the time being, at least to keep the lights on.
Also of the many dependencies?
As far as I can tell, from the list in the orphaned package report, all these are part of the LibreOffice stack:
flute orphan 0 weeks ago hunspell alexl, gnome-sig, mbarnes, 0 weeks ago orphan, rhughes, rstrode hunspell-af orphan 0 weeks ago hunspell-ak orphan 0 weeks ago hunspell-am orphan 0 weeks ago hunspell-ast orphan 0 weeks ago hunspell-az orphan 0 weeks ago hunspell-be orphan 0 weeks ago hunspell-ber orphan 0 weeks ago hunspell-bg orphan 0 weeks ago hunspell-br orphan 0 weeks ago hunspell-ca orphan 0 weeks ago hunspell-cop orphan 0 weeks ago hunspell-csb orphan 0 weeks ago hunspell-cv orphan 0 weeks ago hunspell-cy orphan 0 weeks ago hunspell-da orphan 0 weeks ago hunspell-dsb orphan 0 weeks ago hunspell-el orphan 0 weeks ago hunspell-en alexl, gnome-sig, mbarnes, 0 weeks ago orphan, rhughes, rstrode hunspell-eo orphan 0 weeks ago hunspell-es olea, orphan 0 weeks ago hunspell-et orphan 0 weeks ago hunspell-fa orphan 0 weeks ago hunspell-fj orphan 0 weeks ago hunspell-fo orphan 0 weeks ago hunspell-fr orphan, remi 0 weeks ago hunspell-fur orphan 0 weeks ago hunspell-fy orphan 0 weeks ago hunspell-ga orphan 0 weeks ago hunspell-gd orphan 0 weeks ago hunspell-gl orphan 0 weeks ago hunspell-grc orphan 0 weeks ago hunspell-gv orphan 0 weeks ago hunspell-haw orphan 0 weeks ago hunspell-hil orphan 0 weeks ago hunspell-hr orphan 0 weeks ago hunspell-hsb orphan 0 weeks ago hunspell-ht orphan 0 weeks ago hunspell-hu orphan 0 weeks ago hunspell-hy orphan 0 weeks ago hunspell-ia orphan 0 weeks ago hunspell-id orphan 0 weeks ago hunspell-is orphan 0 weeks ago hunspell-it orphan 0 weeks ago hunspell-kk orphan 0 weeks ago hunspell-km orphan 0 weeks ago hunspell-ko orphan 0 weeks ago hunspell-ku orphan 0 weeks ago hunspell-ky orphan 0 weeks ago hunspell-la orphan 0 weeks ago hunspell-lb orphan 0 weeks ago hunspell-ln orphan 0 weeks ago hunspell-lt orphan 0 weeks ago hunspell-mg orphan 0 weeks ago hunspell-mi orphan 0 weeks ago hunspell-mk orphan 0 weeks ago hunspell-mn orphan 0 weeks ago hunspell-mos orphan 0 weeks ago hunspell-ms orphan 0 weeks ago hunspell-mt orphan 0 weeks ago hunspell-nds orphan 0 weeks ago hunspell-nl orphan 0 weeks ago hunspell-no orphan 0 weeks ago hunspell-nr orphan 0 weeks ago hunspell-nso orphan 0 weeks ago hunspell-ny orphan 0 weeks ago hunspell-oc orphan 0 weeks ago hunspell-om orphan 0 weeks ago hunspell-pl orphan 0 weeks ago hunspell-pt orphan 0 weeks ago hunspell-qu orphan 0 weeks ago hunspell-quh orphan 0 weeks ago hunspell-ro orphan 0 weeks ago hunspell-ru orphan 0 weeks ago hunspell-rw orphan 0 weeks ago hunspell-sc orphan 0 weeks ago hunspell-se orphan 0 weeks ago hunspell-shs orphan 0 weeks ago hunspell-sk orphan 0 weeks ago hunspell-sl orphan 0 weeks ago hunspell-smj orphan 0 weeks ago hunspell-so orphan 0 weeks ago hunspell-sq orphan 0 weeks ago hunspell-sr orphan 0 weeks ago hunspell-ss orphan 0 weeks ago hunspell-st orphan 0 weeks ago hunspell-sv orphan 0 weeks ago hunspell-sw orphan 0 weeks ago hunspell-tet orphan 0 weeks ago hunspell-th orphan 0 weeks ago hunspell-ti orphan 0 weeks ago hunspell-tk orphan 0 weeks ago hunspell-tl orphan 0 weeks ago hunspell-tn orphan 0 weeks ago hunspell-tpi orphan 0 weeks ago hunspell-ts orphan 0 weeks ago hunspell-uk orphan 0 weeks ago hunspell-ur orphan 0 weeks ago hunspell-uz orphan 0 weeks ago hunspell-ve orphan 0 weeks ago hunspell-vi orphan 0 weeks ago hunspell-wa orphan 0 weeks ago hunspell-xh orphan 0 weeks ago hunspell-yi orphan 0 weeks ago hunspell-zu orphan 0 weeks ago hyphen orphan 0 weeks ago hyphen-bg orphan 0 weeks ago hyphen-ca orphan 0 weeks ago hyphen-cy orphan 0 weeks ago hyphen-da orphan 0 weeks ago hyphen-el orphan 0 weeks ago hyphen-es olea, orphan 0 weeks ago hyphen-eu orphan 0 weeks ago hyphen-fa orphan 0 weeks ago hyphen-fo orphan 0 weeks ago hyphen-fr orphan 0 weeks ago hyphen-ga orphan 0 weeks ago hyphen-gl orphan 0 weeks ago hyphen-grc orphan 0 weeks ago hyphen-hsb orphan 0 weeks ago hyphen-hu orphan 0 weeks ago hyphen-ia orphan 0 weeks ago hyphen-id orphan 0 weeks ago hyphen-is orphan 0 weeks ago hyphen-it orphan 0 weeks ago hyphen-ku orphan 0 weeks ago hyphen-lt orphan 0 weeks ago hyphen-mi orphan 0 weeks ago hyphen-mn orphan 0 weeks ago hyphen-nl orphan 0 weeks ago hyphen-pl orphan 0 weeks ago hyphen-pt orphan 0 weeks ago hyphen-ro orphan 0 weeks ago hyphen-ru orphan 0 weeks ago hyphen-sa orphan, pnemade 0 weeks ago hyphen-sk orphan 0 weeks ago hyphen-sl orphan 0 weeks ago hyphen-sv orphan 0 weeks ago hyphen-tk orphan 0 weeks ago hyphen-uk orphan 0 weeks ago jcommon jerboaa, orphan 0 weeks ago jcommon-serializer orphan 0 weeks ago libbase orphan, sbergmann 0 weeks ago libcmis dtardon, orphan, sbergmann 0 weeks ago libeot dtardon, orphan 0 weeks ago libexttextcat dtardon, orphan 0 weeks ago libfonts orphan, sbergmann 0 weeks ago libformula orphan, sbergmann 0 weeks ago libgsf alexl, bonzini, elmarco, 0 weeks ago gnome-sig, mbarnes, orphan, rhughes, rstrode liblangtag dtardon, erack, orphan 0 weeks ago liblayout orphan 0 weeks ago libloader orphan, sbergmann 0 weeks ago libmspub dtardon, orphan 0 weeks ago libnumbertext orphan 0 weeks ago liborcus dtardon, orphan, sbergmann 0 weeks ago librepository orphan, sbergmann 0 weeks ago libserializer orphan, sbergmann 0 weeks ago libvisio dtardon, orphan 0 weeks ago libwmf alexl, mbarnes, orphan, 0 weeks ago rhughes, rstrode libwpd alexl, dtardon, mbarnes, 0 weeks ago orphan, rhughes, rstrode lpsolve orphan 0 weeks ago mythes orphan 0 weeks ago mythes-bg orphan 0 weeks ago mythes-ca orphan 0 weeks ago mythes-cs orphan 0 weeks ago mythes-da orphan 0 weeks ago mythes-el orphan 0 weeks ago mythes-en orphan, sbergmann 0 weeks ago mythes-es olea, orphan 0 weeks ago mythes-fr orphan 0 weeks ago mythes-ga orphan 0 weeks ago mythes-hu orphan 0 weeks ago mythes-it orphan 0 weeks ago mythes-mi orphan 0 weeks ago mythes-ne orphan 0 weeks ago mythes-nl orphan 0 weeks ago mythes-pl orphan 0 weeks ago mythes-pt orphan 0 weeks ago mythes-ro orphan 0 weeks ago mythes-ru orphan 0 weeks ago mythes-sk orphan 0 weeks ago mythes-sl orphan 0 weeks ago mythes-sv orphan 0 weeks ago mythes-uk orphan 0 weeks ago openoffice-lv orphan 0 weeks ago openoffice.org-diafilter orphan, sbergmann 0 weeks ago pentaho-libxml orphan, sbergmann 0 weeks ago pentaho-reporting-flow-engine orphan 0 weeks ago rasqal kde-sig, orphan, rdieter 0 weeks ago redland jreznik, orphan, rdieter, than 0 weeks ago sac orphan 0 weeks ago writer2latex orphan, sbergmann 0 weeks ago zaf orphan 0 weeks ago zxing-cpp orphan, sbergmann, tdawson 0 weeks ago
Kevin Kofler
Damn thats a long list.
On 6/2/23 01:21, Kevin Kofler via devel wrote:
Gwyn Ciesla via devel wrote:
I've taken ownership of libreoffice for the time being, at least to keep the lights on.
Also of the many dependencies?
As far as I can tell, from the list in the orphaned package report, all these are part of the LibreOffice stack:
flute orphan 0 weeks ago hunspell alexl, gnome-sig, mbarnes, 0 weeks ago orphan, rhughes, rstrode hunspell-af orphan 0 weeks ago hunspell-ak orphan 0 weeks ago hunspell-am orphan 0 weeks ago hunspell-ast orphan 0 weeks ago hunspell-az orphan 0 weeks ago hunspell-be orphan 0 weeks ago hunspell-ber orphan 0 weeks ago hunspell-bg orphan 0 weeks ago hunspell-br orphan 0 weeks ago hunspell-ca orphan 0 weeks ago hunspell-cop orphan 0 weeks ago hunspell-csb orphan 0 weeks ago hunspell-cv orphan 0 weeks ago hunspell-cy orphan 0 weeks ago hunspell-da orphan 0 weeks ago hunspell-dsb orphan 0 weeks ago hunspell-el orphan 0 weeks ago hunspell-en alexl, gnome-sig, mbarnes, 0 weeks ago orphan, rhughes, rstrode hunspell-eo orphan 0 weeks ago hunspell-es olea, orphan 0 weeks ago hunspell-et orphan 0 weeks ago hunspell-fa orphan 0 weeks ago hunspell-fj orphan 0 weeks ago hunspell-fo orphan 0 weeks ago hunspell-fr orphan, remi 0 weeks ago hunspell-fur orphan 0 weeks ago hunspell-fy orphan 0 weeks ago hunspell-ga orphan 0 weeks ago hunspell-gd orphan 0 weeks ago hunspell-gl orphan 0 weeks ago hunspell-grc orphan 0 weeks ago hunspell-gv orphan 0 weeks ago hunspell-haw orphan 0 weeks ago hunspell-hil orphan 0 weeks ago hunspell-hr orphan 0 weeks ago hunspell-hsb orphan 0 weeks ago hunspell-ht orphan 0 weeks ago hunspell-hu orphan 0 weeks ago hunspell-hy orphan 0 weeks ago hunspell-ia orphan 0 weeks ago hunspell-id orphan 0 weeks ago hunspell-is orphan 0 weeks ago hunspell-it orphan 0 weeks ago hunspell-kk orphan 0 weeks ago hunspell-km orphan 0 weeks ago hunspell-ko orphan 0 weeks ago hunspell-ku orphan 0 weeks ago hunspell-ky orphan 0 weeks ago hunspell-la orphan 0 weeks ago hunspell-lb orphan 0 weeks ago hunspell-ln orphan 0 weeks ago hunspell-lt orphan 0 weeks ago hunspell-mg orphan 0 weeks ago hunspell-mi orphan 0 weeks ago hunspell-mk orphan 0 weeks ago hunspell-mn orphan 0 weeks ago hunspell-mos orphan 0 weeks ago hunspell-ms orphan 0 weeks ago hunspell-mt orphan 0 weeks ago hunspell-nds orphan 0 weeks ago hunspell-nl orphan 0 weeks ago hunspell-no orphan 0 weeks ago hunspell-nr orphan 0 weeks ago hunspell-nso orphan 0 weeks ago hunspell-ny orphan 0 weeks ago hunspell-oc orphan 0 weeks ago hunspell-om orphan 0 weeks ago hunspell-pl orphan 0 weeks ago hunspell-pt orphan 0 weeks ago hunspell-qu orphan 0 weeks ago hunspell-quh orphan 0 weeks ago hunspell-ro orphan 0 weeks ago hunspell-ru orphan 0 weeks ago hunspell-rw orphan 0 weeks ago hunspell-sc orphan 0 weeks ago hunspell-se orphan 0 weeks ago hunspell-shs orphan 0 weeks ago hunspell-sk orphan 0 weeks ago hunspell-sl orphan 0 weeks ago hunspell-smj orphan 0 weeks ago hunspell-so orphan 0 weeks ago hunspell-sq orphan 0 weeks ago hunspell-sr orphan 0 weeks ago hunspell-ss orphan 0 weeks ago hunspell-st orphan 0 weeks ago hunspell-sv orphan 0 weeks ago hunspell-sw orphan 0 weeks ago hunspell-tet orphan 0 weeks ago hunspell-th orphan 0 weeks ago hunspell-ti orphan 0 weeks ago hunspell-tk orphan 0 weeks ago hunspell-tl orphan 0 weeks ago hunspell-tn orphan 0 weeks ago hunspell-tpi orphan 0 weeks ago hunspell-ts orphan 0 weeks ago hunspell-uk orphan 0 weeks ago hunspell-ur orphan 0 weeks ago hunspell-uz orphan 0 weeks ago hunspell-ve orphan 0 weeks ago hunspell-vi orphan 0 weeks ago hunspell-wa orphan 0 weeks ago hunspell-xh orphan 0 weeks ago hunspell-yi orphan 0 weeks ago hunspell-zu orphan 0 weeks ago hyphen orphan 0 weeks ago hyphen-bg orphan 0 weeks ago hyphen-ca orphan 0 weeks ago hyphen-cy orphan 0 weeks ago hyphen-da orphan 0 weeks ago hyphen-el orphan 0 weeks ago hyphen-es olea, orphan 0 weeks ago hyphen-eu orphan 0 weeks ago hyphen-fa orphan 0 weeks ago hyphen-fo orphan 0 weeks ago hyphen-fr orphan 0 weeks ago hyphen-ga orphan 0 weeks ago hyphen-gl orphan 0 weeks ago hyphen-grc orphan 0 weeks ago hyphen-hsb orphan 0 weeks ago hyphen-hu orphan 0 weeks ago hyphen-ia orphan 0 weeks ago hyphen-id orphan 0 weeks ago hyphen-is orphan 0 weeks ago hyphen-it orphan 0 weeks ago hyphen-ku orphan 0 weeks ago hyphen-lt orphan 0 weeks ago hyphen-mi orphan 0 weeks ago hyphen-mn orphan 0 weeks ago hyphen-nl orphan 0 weeks ago hyphen-pl orphan 0 weeks ago hyphen-pt orphan 0 weeks ago hyphen-ro orphan 0 weeks ago hyphen-ru orphan 0 weeks ago hyphen-sa orphan, pnemade 0 weeks ago hyphen-sk orphan 0 weeks ago hyphen-sl orphan 0 weeks ago hyphen-sv orphan 0 weeks ago hyphen-tk orphan 0 weeks ago hyphen-uk orphan 0 weeks ago jcommon jerboaa, orphan 0 weeks ago jcommon-serializer orphan 0 weeks ago libbase orphan, sbergmann 0 weeks ago libcmis dtardon, orphan, sbergmann 0 weeks ago libeot dtardon, orphan 0 weeks ago libexttextcat dtardon, orphan 0 weeks ago libfonts orphan, sbergmann 0 weeks ago libformula orphan, sbergmann 0 weeks ago libgsf alexl, bonzini, elmarco, 0 weeks ago gnome-sig, mbarnes, orphan, rhughes, rstrode liblangtag dtardon, erack, orphan 0 weeks ago liblayout orphan 0 weeks ago libloader orphan, sbergmann 0 weeks ago libmspub dtardon, orphan 0 weeks ago libnumbertext orphan 0 weeks ago liborcus dtardon, orphan, sbergmann 0 weeks ago librepository orphan, sbergmann 0 weeks ago libserializer orphan, sbergmann 0 weeks ago libvisio dtardon, orphan 0 weeks ago libwmf alexl, mbarnes, orphan, 0 weeks ago rhughes, rstrode libwpd alexl, dtardon, mbarnes, 0 weeks ago orphan, rhughes, rstrode lpsolve orphan 0 weeks ago mythes orphan 0 weeks ago mythes-bg orphan 0 weeks ago mythes-ca orphan 0 weeks ago mythes-cs orphan 0 weeks ago mythes-da orphan 0 weeks ago mythes-el orphan 0 weeks ago mythes-en orphan, sbergmann 0 weeks ago mythes-es olea, orphan 0 weeks ago mythes-fr orphan 0 weeks ago mythes-ga orphan 0 weeks ago mythes-hu orphan 0 weeks ago mythes-it orphan 0 weeks ago mythes-mi orphan 0 weeks ago mythes-ne orphan 0 weeks ago mythes-nl orphan 0 weeks ago mythes-pl orphan 0 weeks ago mythes-pt orphan 0 weeks ago mythes-ro orphan 0 weeks ago mythes-ru orphan 0 weeks ago mythes-sk orphan 0 weeks ago mythes-sl orphan 0 weeks ago mythes-sv orphan 0 weeks ago mythes-uk orphan 0 weeks ago openoffice-lv orphan 0 weeks ago openoffice.org-diafilter orphan, sbergmann 0 weeks ago pentaho-libxml orphan, sbergmann 0 weeks ago pentaho-reporting-flow-engine orphan 0 weeks ago rasqal kde-sig, orphan, rdieter 0 weeks ago redland jreznik, orphan, rdieter, than 0 weeks ago sac orphan 0 weeks ago writer2latex orphan, sbergmann 0 weeks ago zaf orphan 0 weeks ago zxing-cpp orphan, sbergmann, tdawson 0 weeks ago
Kevin Kofler
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
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
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.
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
I can help co-maintaining and I think I can bring another co-maintainer. We've been creating custom libreoffice packages for a project so, we can bring a little experience
El jue, 1 jun 2023 a las 14:17, Gwyn Ciesla via devel (< devel@lists.fedoraproject.org>) escribió:
I've taken ownership of libreoffice for the time being, at least to keep the lights on. Co-maintainers, as always, welcome.
-- 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 Thursday, June 1st, 2023 at 1:30 PM, Matthias Clasen < mclasen@redhat.com> wrote:
Hey,
as you've probably seen, the LibreOffice RPMS have recently been
orphaned, and I thought it would be good to explain the reasons
behind this.
The Red Hat Display Systems team (the team behind most of Red Hat’s
desktop efforts) has maintained the LibreOffice packages in Fedora for years as part of our work to support LibreOffice for Red Hat Enterprise Linux. We are adjusting our engineering priorities for RHEL for Workstations and focusing on gaps in Wayland, building out HDR support, building out what’s needed for color-sensitive work, and a host of other refinements required by Workstation users. This is work that will improve the workstation experience for Fedora as well as RHEL users, and which, we hope, will be positively received by the entire Linux community.
The tradeoff is that we are pivoting away from work we had been doing on
desktop applications and will cease shipping LibreOffice as part of RHEL starting in a future RHEL version. This also limits our ability to maintain it in future versions of Fedora.
We will continue to maintain LibreOffice in currently supported versions
of RHEL (RHEL 7, 8 and 9) with needed CVEs and similar for the lifetime of those releases (as published on the Red Hat website). As part of that, the engineers doing that work will contribute some fixes upstream to ensure LibreOffice works better as a Flatpak, which we expect to be the way that most people consume LibreOffice in the long term.
Any community member is of course free to take over maintenance, both
for the RPMS in Fedora and the Fedora LibreOffice Flatpak, but be aware that this is a sizable block of packages and dependencies and a significant amount of work to keep up with.
Matthias _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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-leave@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
Hello
If you are still looking for co-maintainers, I can also help.
Hussein
Am 01.06.23 um 22:16 schrieb Gwyn Ciesla via devel:
I've taken ownership of libreoffice for the time being, at least to keep the lights on. Co-maintainers, as always, welcome.
-- 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 Thursday, June 1st, 2023 at 1:30 PM, Matthias Clasen mclasen@redhat.com wrote:
Hey,
as you've probably seen, the LibreOffice RPMS have recently been orphaned, and I thought it would be good to explain the reasons behind this.
The Red Hat Display Systems team (the team behind most of Red Hat’s desktop efforts) has maintained the LibreOffice packages in Fedora for years as part of our work to support LibreOffice for Red Hat Enterprise Linux. We are adjusting our engineering priorities for RHEL for Workstations and focusing on gaps in Wayland, building out HDR support, building out what’s needed for color-sensitive work, and a host of other refinements required by Workstation users. This is work that will improve the workstation experience for Fedora as well as RHEL users, and which, we hope, will be positively received by the entire Linux community.
The tradeoff is that we are pivoting away from work we had been doing on desktop applications and will cease shipping LibreOffice as part of RHEL starting in a future RHEL version. This also limits our ability to maintain it in future versions of Fedora.
We will continue to maintain LibreOffice in currently supported versions of RHEL (RHEL 7, 8 and 9) with needed CVEs and similar for the lifetime of those releases (as published on the Red Hat website). As part of that, the engineers doing that work will contribute some fixes upstream to ensure LibreOffice works better as a Flatpak, which we expect to be the way that most people consume LibreOffice in the long term.
Any community member is of course free to take over maintenance, both for the RPMS in Fedora and the Fedora LibreOffice Flatpak, but be aware that this is a sizable block of packages and dependencies and a significant amount of work to keep up with.
Matthias _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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-leave@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
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.
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.
On Thu, 15 Jun 2023 18:40:39 +0200 Miro Hrončok mhroncok@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
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 dan@danny.cz wrote:
On Thu, 15 Jun 2023 18:40:39 +0200 Miro Hrončok mhroncok@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:
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-leave@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
I appreciate and am empathetic to all of those carrying the burden of this and the thousands of other RPM packages. As a users of Fedora + RPM Fusion + Cinnamon Desktop as my daily laptop driver since 2011, I love Fedora and am a heavy user of Flatpacks. So thank you all.
That said, I will point out that I have heard of at least 4 enterprise customers who use libreoffice as a headless file conversion utility. I have seen it used in customer facing production workflows, such as a financial user support website to handle file uploads provided by end users, as well as medical health records systems used by hospitals and doctors offices. https://www.libreofficehelp.com/batch-convert-writer-documents-pdf-libreoffi...
I am not asking for a change in strategy. I understand our resource challenges. I only wanted to share this perspective. Packaging the RPMS in EPEL could alleviate the pain for these customers in the RHEL 10 timeframe, as well as a container image (maybe built from the rpms pulled from EPEL?).
Hope this is helpful. And again, THANK YOU!
Terry Bowling Sr. Product Manager - RHEL Installation & Build Services Experience Red Hat, Inc.
On Thu, Jun 1, 2023 at 2:31 PM Matthias Clasen mclasen@redhat.com wrote:
Hey,
as you've probably seen, the LibreOffice RPMS have recently been orphaned, and I thought it would be good to explain the reasons behind this.
The Red Hat Display Systems team (the team behind most of Red Hat’s desktop efforts) has maintained the LibreOffice packages in Fedora for years as part of our work to support LibreOffice for Red Hat Enterprise Linux. We are adjusting our engineering priorities for RHEL for Workstations and focusing on gaps in Wayland, building out HDR support, building out what’s needed for color-sensitive work, and a host of other refinements required by Workstation users. This is work that will improve the workstation experience for Fedora as well as RHEL users, and which, we hope, will be positively received by the entire Linux community.
The tradeoff is that we are pivoting away from work we had been doing on desktop applications and will cease shipping LibreOffice as part of RHEL starting in a future RHEL version. This also limits our ability to maintain it in future versions of Fedora.
We will continue to maintain LibreOffice in currently supported versions of RHEL (RHEL 7, 8 and 9) with needed CVEs and similar for the lifetime of those releases (as published on the Red Hat website). As part of that, the engineers doing that work will contribute some fixes upstream to ensure LibreOffice works better as a Flatpak, which we expect to be the way that most people consume LibreOffice in the long term.
Any community member is of course free to take over maintenance, both for the RPMS in Fedora and the Fedora LibreOffice Flatpak, but be aware that this is a sizable block of packages and dependencies and a significant amount of work to keep up with.
Matthias _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
Terry,
I appreciate and am empathetic to all of those carrying the burden of this and the thousands of other RPM packages. As a users of Fedora + RPM Fusion + Cinnamon Desktop as my daily laptop driver since 2011, I love Fedora and am a heavy user of Flatpacks. So thank you all.
That said, I will point out that I have heard of at least 4 enterprise customers who use libreoffice as a headless file conversion utility. I have seen it used in customer facing production workflows, such as a financial user support website to handle file uploads provided by end users, as well as medical health records systems used by hospitals and doctors offices. https://www.libreofficehelp.com/batch-convert-writer-documents-pdf-libreoffi...
I am not asking for a change in strategy. I understand our resource challenges. I only wanted to share this perspective. Packaging the RPMS in EPEL could alleviate the pain for these customers in the RHEL 10 timeframe, as well as a container image (maybe built from the rpms pulled from EPEL?).
That is a Red Hat problem, and whether it's in RHEL proper or EPEL someone has to do the work. It's not fair of you to ask the community to shoulder that burden, that is a problem for Red Hat to deal with internally to work out how to resource that whether it's it's in EPEL or elsewhere. From the customer's perspective there's other commercial vendors that provide support for LibreOffice too. But what ever way that is done this is completely off topic for Fedora.
Hope this is helpful. And again, THANK YOU!
Terry Bowling Sr. Product Manager - RHEL Installation & Build Services Experience Red Hat, Inc.
On Thu, Jun 1, 2023 at 2:31 PM Matthias Clasen mclasen@redhat.com wrote:
Hey,
as you've probably seen, the LibreOffice RPMS have recently been orphaned, and I thought it would be good to explain the reasons behind this.
The Red Hat Display Systems team (the team behind most of Red Hat’s desktop efforts) has maintained the LibreOffice packages in Fedora for years as part of our work to support LibreOffice for Red Hat Enterprise Linux. We are adjusting our engineering priorities for RHEL for Workstations and focusing on gaps in Wayland, building out HDR support, building out what’s needed for color-sensitive work, and a host of other refinements required by Workstation users. This is work that will improve the workstation experience for Fedora as well as RHEL users, and which, we hope, will be positively received by the entire Linux community.
The tradeoff is that we are pivoting away from work we had been doing on desktop applications and will cease shipping LibreOffice as part of RHEL starting in a future RHEL version. This also limits our ability to maintain it in future versions of Fedora.
We will continue to maintain LibreOffice in currently supported versions of RHEL (RHEL 7, 8 and 9) with needed CVEs and similar for the lifetime of those releases (as published on the Red Hat website). As part of that, the engineers doing that work will contribute some fixes upstream to ensure LibreOffice works better as a Flatpak, which we expect to be the way that most people consume LibreOffice in the long term.
Any community member is of course free to take over maintenance, both for the RPMS in Fedora and the Fedora LibreOffice Flatpak, but be aware that this is a sizable block of packages and dependencies and a significant amount of work to keep up with.
Matthias _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On 6/2/23 8:49 AM, Terry Bowling wrote:
I appreciate and am empathetic to all of those carrying the burden of this and the thousands of other RPM packages. As a users of Fedora + RPM Fusion + Cinnamon Desktop as my daily laptop driver since 2011, I love Fedora and am a heavy user of Flatpacks. So thank you all.
That said, I will point out that I have heard of at least 4 enterprise customers who use libreoffice as a headless file conversion utility. I have seen it used in customer facing production workflows, such as a financial user support website to handle file uploads provided by end users, as well as medical health records systems used by hospitals and doctors offices. https://www.libreofficehelp.com/batch-convert-writer-documents-pdf-libreoffi... https://www.libreofficehelp.com/batch-convert-writer-documents-pdf-libreoffice/
I am not asking for a change in strategy. I understand our resource challenges. I only wanted to share this perspective. Packaging the RPMS in EPEL could alleviate the pain for these customers in the RHEL 10 timeframe, as well as a container image (maybe built from the rpms pulled from EPEL?).
Hope this is helpful. And again, THANK YOU!
People using LibreOffice for a backend document conversions can use Collabora Online (supported or self build one), it not only has a web frontend for LibreOffice, it provides REST endpoints for doing conversions.
The flatpak replacement is a solution for desktop user that need the application, but don't forget that LibreOffice not only provides applications but an entire programmatic AP (UNO) where nearly everything can be automated. We use it at work to "embed" a document editor in desktop applications. To be fair, that is being migrated to the online version and everything done via web. But there are business apps interacting with a supported LibreOffice API provided by RHEL, that change will not be very welcomed. They will need to move to another enterprise distribution or pay extra for a enterprise supported version of LO.
But that is a RHEL problem. On the Fedora side, shipping Fedora without a desktop suite will make more people to jump ship. Live editions will be crippled because they will not include external flatpaks.
I say thanks to the maintainers that worked hard on packaging LO and hope they advance a lot on the infrastructure work they are doing, like color management in Wayland. Seriously I wish they find a way for Wayland applications are able to save their windows positions (there was a cookie proposal a long time ago that never advanced IIRC). The random window placement of GNOME Shell is the most irritating misfeature of the entire Fedora Workstation for me.
Terry Bowling Sr. Product Manager - RHEL Installation & Build Services Experience Red Hat, Inc.
On Thu, Jun 1, 2023 at 2:31 PM Matthias Clasen <mclasen@redhat.com mailto:mclasen@redhat.com> wrote:
Hey, as you've probably seen, the LibreOffice RPMS have recently been orphaned, and I thought it would be good to explain the reasons behind this. The Red Hat Display Systems team (the team behind most of Red Hat’s desktop efforts) has maintained the LibreOffice packages in Fedora for years as part of our work to support LibreOffice for Red Hat Enterprise Linux. We are adjusting our engineering priorities for RHEL for Workstations and focusing on gaps in Wayland, building out HDR support, building out what’s needed for color-sensitive work, and a host of other refinements required by Workstation users. This is work that will improve the workstation experience for Fedora as well as RHEL users, and which, we hope, will be positively received by the entire Linux community. The tradeoff is that we are pivoting away from work we had been doing on desktop applications and will cease shipping LibreOffice as part of RHEL starting in a future RHEL version. This also limits our ability to maintain it in future versions of Fedora. We will continue to maintain LibreOffice in currently supported versions of RHEL (RHEL 7, 8 and 9) with needed CVEs and similar for the lifetime of those releases (as published on the Red Hat website). As part of that, the engineers doing that work will contribute some fixes upstream to ensure LibreOffice works better as a Flatpak, which we expect to be the way that most people consume LibreOffice in the long term. Any community member is of course free to take over maintenance, both for the RPMS in Fedora and the Fedora LibreOffice Flatpak, but be aware that this is a sizable block of packages and dependencies and a significant amount of work to keep up with. Matthias _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org <mailto:devel@lists.fedoraproject.org> To unsubscribe send an email to devel-leave@lists.fedoraproject.org <mailto:devel-leave@lists.fedoraproject.org> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ <https://docs.fedoraproject.org/en-US/project/code-of-conduct/> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines <https://fedoraproject.org/wiki/Mailing_list_guidelines> List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org <https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue <https://pagure.io/fedora-infrastructure/new_issue>
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
This is a stupid bonehead idea, libreoffice is just too big to reliably run in flatpak. Plus what about java integration, guess the languagetool plugin wont work now and I will have to use its stupud online version where you havwe to pay to add words. Oh well, back to debian.
Look its not like I have not tried libreoffice as a flat but as of now it looks out of place, I can't even see the icons even when I use the default adwaita or breeze themes. How is this an improvement? I wanted to leave ubuntu because of crap like this, where they forced snaps down my throat now I will be out shopping for another distro. Arch is too unstable so debian it is, MX Linux 23 cant come out soon enough.
Am 03.06.2023 um 05:11 schrieb Ralph Bromley dancingmadrb3@gmail.com:
Look its not like I have not tried libreoffice as a flat but as of now it looks out of place, I can't even see the icons even when I use the default adwaita or breeze themes. How is this an improvement? I wanted to leave ubuntu because of crap like this, where they forced snaps down my throat now I will be out shopping for another distro. Arch is too unstable so debian it is, MX Linux 23 cant come out soon enough.
Did you check out OpenSuSE? The current Tumbleweed as well as Leap 15.4 seem to include LibreOffice (https://en.opensuse.org/Features_15.4) Would be probably an alternative more similar to Fedora.
-- Peter Boy https://fedoraproject.org/wiki/User:Pboy PBoy@fedoraproject.org
Timezone: CET (UTC+1) / CEST /UTC+2)
Fedora Server Edition Working Group member Fedora Docs team contributor and board member Java developer and enthusiast
On 6/2/23 19:50, Ralph Bromley wrote:
This is a stupid bonehead idea, libreoffice is just too big to reliably run in flatpak. Plus what about java integration, guess the languagetool plugin wont work now and I will have to use its stupud online version where you havwe to pay to add words. Oh well, back to debian.
Did you read the whole thread? It's not going anywhere. People have stepped up to maintain it.
On 03/06/2023 09:51, Samuel Sieb wrote:
Did you read the whole thread? It's not going anywhere. People have stepped up to maintain it.
LibreOffice is a complex project. It will be very difficult to maintain it. It's not just a trivial Version+Release bump, no. They will need to backport patches, fix issues with non-x86 architectures, etc.
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.
On Sat, Jun 3 2023 at 10:26:07 AM -0000, John Iliopoulos jxftw2424@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?)
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.) I'd rather focus on the OS bits where we actually add real serious value. But I also do want the office suite to remain preinstalled in Workstation because the office apps are "killer apps" for desktop users and being able to handle office documents out-of-the-box is very important for users who are new to Linux and unfamiliar with how to do this with nothing installed; most people have probably never even heard of LibreOffice and wouldn't know to look for it, and I doubt online alternatives like Google Docs will be acceptable to users who need to work on local documents.
So it comes down to maintenance. If people help Gwyn keep LibreOffice building, updated, and working with a reasonable level of quality, then I'm personally happy to keep it preinstalled, and I hope the Workstation Working Group will agree. Probably the most important first step is to keep track of orphaned dependencies and make sure they do not get retired. Of course, this is much easier said than done....
Michael
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
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.
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.
On Mon, Jun 5 2023 at 01:13:50 PM -0400, Demi Marie Obenour demiobenour@gmail.com 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
On Mon, 5 Jun 2023 at 13:32, Michael Catanzaro mcatanzaro@redhat.com wrote:
On Mon, Jun 5 2023 at 01:13:50 PM -0400, Demi Marie Obenour demiobenour@gmail.com 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.
Once upon a time, Stephen Smoogen ssmoogen@redhat.com said:
- 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.
On 6/5/23 2:05 PM, Chris Adams wrote:
Once upon a time, Stephen Smoogen ssmoogen@redhat.com said:
- 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.
On Mon, 2023-06-05 at 13:05 -0500, Chris Adams wrote:
Once upon a time, Stephen Smoogen ssmoogen@redhat.com said:
- 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.Platform 38 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.
Once upon a time, Adam Williamson adamwill@fedoraproject.org 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.
On Mon, Jun 5 2023 at 01:05:25 PM -0500, Chris Adams linux@cmadams.net 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) * Application maintainers are responsible for updating components that are bundled into the application (including base apps)
The Flatpak security model assumes that application code is bad and riddled with security vulnerabilities, so updating dependencies is not as important as it is for host applications. In theory, vulnerable applications are not the end of the world, because a compromised app is heavily sandboxed with extremely limited access to the host system and no ability to do harmful stuff. In practice, this does not yet work very well at all; see [2] for more info on that.
Michael
[1] https://github.com/orgs/flathub/repositories?language=&q=base&sort=&... [2] https://theevilskeleton.gitlab.io/2023/05/11/overview-of-flatpaks-permission...
On Monday, June 5, 2023 1:37:24 PM EDT Stephen Smoogen wrote:
On Mon, 5 Jun 2023 at 13:32, Michael Catanzaro mcatanzaro@redhat.com
wrote:
On Mon, Jun 5 2023 at 01:13:50 PM -0400, Demi Marie Obenour
demiobenour@gmail.com 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:
- 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
On Mon, 5 Jun 2023 at 14:10, Steve Grubb sgrubb@redhat.com wrote:
On Monday, June 5, 2023 1:37:24 PM EDT Stephen Smoogen wrote:
On Mon, 5 Jun 2023 at 13:32, Michael Catanzaro mcatanzaro@redhat.com
wrote:
On Mon, Jun 5 2023 at 01:13:50 PM -0400, Demi Marie Obenour
demiobenour@gmail.com 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:
- 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
On Mon, Jun 5 2023 at 02:09:58 PM -0400, Steve Grubb sgrubb@redhat.com 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...
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
On 6/5/23 16:35, Michael Catanzaro wrote:
On Mon, Jun 5 2023 at 02:09:58 PM -0400, Steve Grubb sgrubb@redhat.com 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...
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.
On Mon, Jun 5 2023 at 04:46:42 PM -0400, Demi Marie Obenour demiobenour@gmail.com 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
On Mon, Jun 5 2023 at 01:37:24 PM -0400, Stephen Smoogen ssmoogen@redhat.com wrote:
- 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.
- 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/fla...
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.
On Mon, 5 Jun 2023 at 16:14, Michael Catanzaro mcatanzaro@redhat.com wrote:
On Mon, Jun 5 2023 at 01:37:24 PM -0400, Stephen Smoogen ssmoogen@redhat.com wrote:
- 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.
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.
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/Every...
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. (Although note that this is the devel list, so arguably it's kinda expected that discussions here happen with our Fedora Contributor hats on, not our Fedora User hats on). As a user, if Fedora's nature changes, it's totally reasonable to re- evaluate if Fedora is the thing you want to use any more, and as Fedora developers we should keep that in mind when having discussions and making decisions like this.
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.
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.
On Mon, Jun 5 2023 at 04:49:07 PM -0400, Demi Marie Obenour demiobenour@gmail.com 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-deduplicat...
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.
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
On Sat, Jun 3, 2023 at 2:43 PM Michael Catanzaro mcatanzaro@redhat.com 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.
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
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.libre...) 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
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
On 6/3/23 08:42, Michael Catanzaro wrote:
On Sat, Jun 3 2023 at 10:26:07 AM -0000, John Iliopoulos jxftw2424@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.
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.
On Sun, Jul 2 2023 at 04:59:39 PM -0400, Demi Marie Obenour demiobenour@gmail.com 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-deduplicat...
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... )
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
On 7/2/23 19:28, Michael Catanzaro wrote:
On Sun, Jul 2 2023 at 04:59:39 PM -0400, Demi Marie Obenour demiobenour@gmail.com 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-deduplicat...
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... )
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 sense, thanks!
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--
Sincerely, Demi Marie Obenour (she/her/hers)
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-L7...); - Signal (DEB repack: https://github.com/flathub/org.signal.Signal/blob/master/org.signal.Signal.y...); - Blender (static binary repack: https://github.com/flathub/org.blender.Blender/blob/master/org.blender.Blend...); - VS Codium (DEB repack: https://github.com/flathub/com.vscodium.codium/blob/master/com.vscodium.codi...); - 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).
On Sun, Jul 2, 2023 at 5:01 PM Demi Marie Obenour demiobenour@gmail.com wrote:
On 6/3/23 08:42, Michael Catanzaro wrote:
On Sat, Jun 3 2023 at 10:26:07 AM -0000, John Iliopoulos <
jxftw2424@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...). 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
-
Adam Williamson -
Artur Frenszek-Iwicki -
Ben Cotton -
blinxen -
Chris Adams -
Christian Schaller -
Dan Horák -
Daniel P. Berrangé -
Demi Marie Obenour -
Dominik 'Rathann' Mierzejewski -
Fabio Valentini -
Gwyn Ciesla -
Ivan Chavero -
Jiri Eischmann -
Jiri Vanek -
John Iliopoulos -
Josh Boyer -
Kamil Paral -
Kevin Kofler -
Leon Fauster -
Leslie Satenstein -
Matthew Miller -
Matthias Clasen -
Mattia Verga -
Michael Catanzaro -
Michael J Gruber -
Miro Hrončok -
Neal H. Walfield -
Owen Taylor -
Peter Boy -
Peter Robinson -
PGNet Dev -
Ralph Bromley -
Robert Marcano -
Roberto Ragusa -
Samuel Sieb -
Sandro -
stan -
Stephan Bergmann -
Stephen Smoogen -
Steve Grubb -
Terry Bowling -
Vitaly Zaitsev