Re: Orphaning packages (was LibreOffice packages)

[Leon Fauster via devel]

Am 03.07.23 um 18:07 schrieb Simon de Vlieger:

On 7/3/23 13:46, Ralf Corsépius wrote:


It is the core of the problem esp. big US companies tend to ignore.

May-be you guys are not aware of there are tendencies to legally 
prohibit such "cloud solutions" in many countries?


It's generally not so much 'legally prohibit' as 'data has to be kept 
within $jurisdiction and is not to be shared outside of it'. If 
$jurisdiction is large enough cloud operators tend to offer that solution.



Its not a cloud provider its a software vendor. Further more a couple of
authoritative entities have proven that such solutions do not comply 
with data protection requirements. Its of value having a standalone 
package (to getting back to the topic). If not now, for sure in the near 
future.


--
Leon

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Owen Taylor]

On Sun, Jul 2, 2023 at 5:01 PM Demi Marie Obenour 
wrote:

> On 6/3/23 08:42, Michael Catanzaro wrote:
> > On Sat, Jun 3 2023 at 10:26:07 AM -, John Iliopoulos <
> jxftw2...@gmail.com> wrote:
> >> Hello,
> >>
> >> While i completely understand why you do this i do think that it is
> >> important for desktop/workstation oriented devices to have some
> >> optional access to Office directly from the image file. Have you
> >> considered shipping the LibreOffice flatpak via the ISO much like
> >> Fedora Silverblue does with various other applications?
> >>
> >> This is the first time i reply to a mailing list so i hope i have not
> >> done anything wrong.
> >
> > Hi. Welcome to the list. You haven't done anything wrong.
> >
> > For Fedora Workstation, the mid-term plan is to ship all preinstalled
> > apps as Fedora Flatpaks. We cannot ship anything from Flathub because
> > FESCo will not allow it. I don't *like* this FESCo requirement, but I
> > also don't expect that to change. Accordingly, since Fedora Flatpaks
> > are built from Fedora RPMs, maintaining the LibreOffice RPMs is
> > essential to keep LibreOffice preinstalled. (I think that applies to
> > Silverblue as well?)
>
> Fedora Flatpaks are also a security disaster: they are shipped in OCI
> format instead of OSTree format, but they aren’t signed by anyone.
> I’ve disabled the Fedora remote and recommend that others do the same.
>

I think the words "security disaster" are painting a  too strong picture
here. When you install a Fedora Flatpak, the digest of the content being
installed is checked against the checksums embedded in the index downloaded
from (e.g.
https://registry.fedoraproject.org/index/static?label:org.flatpak.ref:exists=1=linux=amd64=latest).
These indexes are statically generated from data queried from Bodhi and
Koji and downloaded from a static web server directly from Fedora bypassing
the CDN.

The most obvious way to get malicious content into this index would be to
inject it at build time, by adding it upstream, infiltrating the Fedora
project, hacking a Fedora contributor, etc. In all of these cases, if we
had container signatures, robosignatory would happily sign it when the
update was created.

Yes, someone could hack the server hosting the index, get write-access to
the mount hosting the indexes, or find some specific way to exploit the
indexing process. And in those cases, having checked signatures would help.
The first two cases would seem to imply a widespread breach of Fedora
infrastructure that would likely affect security of builds as well.

What would be needed to implement signatures would be roughly:
 - Implement container signatures in robosignatory/sigul
 - Implement distribution of signatures (probably easiest if we move
registry.fedoraproject.org to quay.io as planned for a while)
 - Implement checkingo of container signatures in the Flatpak client

 One thing that helps now is that for a long time there was a lot of
uncertainty in where signatures were going in the container world, but at
this point, at least Red Hat parts of the container world seems to be
solidly behind the approach of https://github.com/sigstore/cosign. (Still a
lot of details / moving parts that would have to be researched.)

- Owen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Orphaning packages (was LibreOffice packages)

[Simon de Vlieger]

On 7/3/23 13:46, Ralf Corsépius wrote:


It is the core of the problem esp. big US companies tend to ignore.

May-be you guys are not aware of there are tendencies to legally 
prohibit such "cloud solutions" in many countries?


It's generally not so much 'legally prohibit' as 'data has to be kept 
within $jurisdiction and is not to be shared outside of it'. If 
$jurisdiction is large enough cloud operators tend to offer that solution.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Orphaning packages (was LibreOffice packages)

[Ralf Corsépius]

Am 01.07.23 um 14:28 schrieb Peter Robinson:

On Sat, Jul 1, 2023 at 12:50 PM Vitaly Zaitsev via devel
 wrote:


On 01/07/2023 13:36, Chris Adams wrote:

A lot of the corporate world has gone to the "cloud"



don't have to worry about local backups of important documents and
spreadsheets, they get sharing with minimal effort, they can access
things from their mobile devices, etc.


And voluntarily hand over all the corporate secrets to Google and
Microsoft. Brilliant idea.


This sort of comment is off topic, 

It definitely is not off-topic.

It is the core of the problem esp. big US companies tend to ignore.

May-be you guys are not aware of there are tendencies to legally 
prohibit such "cloud solutions" in many countries?



Ralf
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Orphaning packages (was LibreOffice packages)

[Kalev Lember]

On 7/3/23 09:23, Victor Toso wrote:

On Sat, Jul 01, 2023 at 10:09:15PM +0200, Kalev Lember wrote:

Victor (CC'd), do you want to pick up grilo and grilo-plugins?


Sure, I'll keep maintaining both in Fedora.


Excellent! Can you click on the "Take" button at
https://src.fedoraproject.org/rpms/grilo and
https://src.fedoraproject.org/rpms/grilo-plugins ? Bastien was the
package owner before and now they are orphaned.

--
Kalev
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Vitaly Zaitsev via devel]

On 03/07/2023 01:28, Michael Catanzaro wrote:
OK, host shared libraries and flatpaked libraries will be loaded at the 
same time, but I really doubt that's going to be at all significant.


Include dozens of bundled libraries here too. Only runtimes can use 
shared memory.



They do consume significant disk space if your disk is really small. ostree 
deduplication is pretty good, though (and OCI images are deduplicated too)


Many Flatpaks from Flathub still use the old runtimes. Each runtime 
consumes approximately 1 GB of disk space.


They need to start doing mass rebuilds with every new major release of 
the runtime.



As a matter of strategy, packaging applications is fine, but nowadays it is 
*optional*.


I don't think so.


Our most popular applications are nowadays available from Flathub or other 
third-party sources, and users are going to install them regardless of whether 
we package them.


Sorry, but I can't trust them since they allow uploading pre-built blobs 
and DEB repacks for popular and even for security-focused applications:


- Firefox (uploaded as ostree blob without sources, has disabled ASLR 
and hardening);

- OBS Studio (uploaded as ostree blob);
- Element (DEB repack: 
https://github.com/flathub/im.riot.Riot/blob/master/im.riot.Riot.yaml#L69-L70);
- Signal (DEB repack: 
https://github.com/flathub/org.signal.Signal/blob/master/org.signal.Signal.yaml#L65-L66);
- Blender (static binary repack: 
https://github.com/flathub/org.blender.Blender/blob/master/org.blender.Blender.json#L150-L151);
- VS Codium (DEB repack: 
https://github.com/flathub/com.vscodium.codium/blob/master/com.vscodium.codium.yaml#L98-L99);

- many others: https://github.com/search?q=org%3Aflathub+.deb=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=code
- https://github.com/search?q=org%3Aflathub+--filesystem%3Dhome=code

They need to restrict such holes. Snap already did this a few years ago 
(classic snaps are only allowed in exceptional cases).


--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Demi Marie Obenour]

On 7/2/23 19:28, Michael Catanzaro wrote:
> On Sun, Jul 2 2023 at 04:59:39 PM -0400, Demi Marie Obenour 
>  wrote:
>>>
>> Fedora Flatpaks are also a security disaster: they are shipped in OCI
>> format instead of OSTree format, but they aren’t signed by anyone.
>> I’ve disabled the Fedora remote and recommend that others do the 
>> same.
> 
> I didn't know about this problem. I agree that sounds pretty bad. I'm 
> going to ask some colleagues to comment on this.

Thank you.  As an aside, Fedora container images are also unsigned, and
inasmuch as they are both shipped in OCI format, it might be possible
to fix both at once.

> There are, frankly, many other serious problems with Fedora Flatpaks, 
> most notably lack of regular updates when the app or bundled 
> dependencies are updated in Fedora. I think of them as a tech preview 
> that we shipped too early.

That sounds accurate.  I recommend turning them off by default _for now_,
but hopefully they can be turned back on again in the future.

> But these problems are not insurmountable, 
> and if we can get it right, building Flatpaks from RPMs will allow 
> Fedora to deliver applications packaged at Fedora's high level of 
> quality in a modern and safer format.

I 100% support this.

>>>  My $0.02: maintaining complex desktop applications as part of the
>>>  operating system requires significant effort and produces low value 
>>> for
>>>  users when you can easily install that app from Flathub instead. (It
>>>  *especially* doesn't make sense to do in RHEL, but let's focus on
>>>  Fedora here.)
>>
>> What is your reasoning here?  I’m not saying I disagree with you, 
>> but
>> I want to know *why* you believe this, especially since flatpaks 
>> consume
>> additional memory and disk space compared to RPMs.
> 
> I do not believe that Flatpaks consume significant additional memory. 
> OK, host shared libraries and flatpaked libraries will be loaded at the 
> same time, but I really doubt that's going to be at all significant. 
> They do consume significant disk space if your disk is really small. 
> ostree deduplication is pretty good, though (and OCI images are 
> deduplicated too):
> 
> https://blogs.gnome.org/wjjt/2021/11/24/on-flatpak-disk-usage-and-deduplication/
> 
> So I don't think many users will seriously care about additional memory 
> use or disk space.
> 
> As a matter of strategy, packaging applications is fine, but nowadays 
> it is *optional*. 15 years ago, if Fedora did not ship an application, 
> you had to compile it yourself or, more likely, switch to Ubuntu or 
> Debian because they have more applications available. That is not the 
> case today. Our most popular applications are nowadays available from 
> Flathub or other third-party sources, and users are going to install 
> them regardless of whether we package them. Having Fedora packages 
> provides users with another way to use applications they would use on 
> Fedora anyway. So for the most complex applications, where packaging is 
> difficult or time-consuming, Fedora packagers will have to decide for 
> themselves whether it still makes sense to do that work as opposed to 
> other possible Fedora work.

That makes total sense.  If there are N distributions and M applications,
traditional packaging takes O(N * M) time, whereas Flatpaks take O(N + M)
time.  Needless to say, the latter is a lot more sustainable as N and M
get bigger.

> (Flatpaks without sandbox holes are also dramatically more secure than 
> Fedora RPMs, which is why I'm *really* interested in Flatpaks. But 
> currently application declare too many holes: 
> https://theevilskeleton.gitlab.io/2023/05/11/overview-of-flatpaks-permission-models.html
>  
> )

Sandboxing is also my main interest in Flatpaks.  The current state of
non-macOS desktop security is honestly rather embarrassing and sandboxing
applications is a necessary first step in fixing that.  Furthermore,
sandboxed applications have well-defined interfaces with the rest of the
system, which makes isolation techniques like SELinux, Landlock, or even
virtualization much easier to apply.

> Anyway, I don't mean to suggest we should stop packaging applications 
> or that the work to keep the LibreOffice packages maintained is not 
> valuable (thank you to everyone working on that). Being able to 
> continue shipping LibreOffice by default is especially important for 
> users who do not already know about LibreOffice and would otherwise not 
> realize that Linux has an office suite available. What I really meant 
> there was that packaging applications is not the most valuable way for 
> Red Hat to contribute to Fedora.

That makes total sense, thanks!

> Contrast the LibreOffic

Re: LibreOffice packages

[Michael Catanzaro]

On Sun, Jul 2 2023 at 04:59:39 PM -0400, Demi Marie Obenour 
 wrote:



Fedora Flatpaks are also a security disaster: they are shipped in OCI
format instead of OSTree format, but they aren’t signed by anyone.
I’ve disabled the Fedora remote and recommend that others do the 
same.


I didn't know about this problem. I agree that sounds pretty bad. I'm 
going to ask some colleagues to comment on this.


There are, frankly, many other serious problems with Fedora Flatpaks, 
most notably lack of regular updates when the app or bundled 
dependencies are updated in Fedora. I think of them as a tech preview 
that we shipped too early. But these problems are not insurmountable, 
and if we can get it right, building Flatpaks from RPMs will allow 
Fedora to deliver applications packaged at Fedora's high level of 
quality in a modern and safer format.



 My $0.02: maintaining complex desktop applications as part of the
 operating system requires significant effort and produces low value 
for

 users when you can easily install that app from Flathub instead. (It
 *especially* doesn't make sense to do in RHEL, but let's focus on
 Fedora here.)


What is your reasoning here?  I’m not saying I disagree with you, 
but
I want to know *why* you believe this, especially since flatpaks 
consume

additional memory and disk space compared to RPMs.


I do not believe that Flatpaks consume significant additional memory. 
OK, host shared libraries and flatpaked libraries will be loaded at the 
same time, but I really doubt that's going to be at all significant. 
They do consume significant disk space if your disk is really small. 
ostree deduplication is pretty good, though (and OCI images are 
deduplicated too):


https://blogs.gnome.org/wjjt/2021/11/24/on-flatpak-disk-usage-and-deduplication/

So I don't think many users will seriously care about additional memory 
use or disk space.


As a matter of strategy, packaging applications is fine, but nowadays 
it is *optional*. 15 years ago, if Fedora did not ship an application, 
you had to compile it yourself or, more likely, switch to Ubuntu or 
Debian because they have more applications available. That is not the 
case today. Our most popular applications are nowadays available from 
Flathub or other third-party sources, and users are going to install 
them regardless of whether we package them. Having Fedora packages 
provides users with another way to use applications they would use on 
Fedora anyway. So for the most complex applications, where packaging is 
difficult or time-consuming, Fedora packagers will have to decide for 
themselves whether it still makes sense to do that work as opposed to 
other possible Fedora work.


(Flatpaks without sandbox holes are also dramatically more secure than 
Fedora RPMs, which is why I'm *really* interested in Flatpaks. But 
currently application declare too many holes: 
https://theevilskeleton.gitlab.io/2023/05/11/overview-of-flatpaks-permission-models.html 
)


Anyway, I don't mean to suggest we should stop packaging applications 
or that the work to keep the LibreOffice packages maintained is not 
valuable (thank you to everyone working on that). Being able to 
continue shipping LibreOffice by default is especially important for 
users who do not already know about LibreOffice and would otherwise not 
realize that Linux has an office suite available. What I really meant 
there was that packaging applications is not the most valuable way for 
Red Hat to contribute to Fedora. Contrast the LibreOffice announcement 
to Bastien's announcement that Red Hat is orphaning a large number of 
core desktop packages that are not applications and cannot be replaced 
by Flatpaks. This one will be much more challenging for Fedora deal 
with. :/


Michael

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Orphaning packages (was LibreOffice packages)

[Kevin Kofler via devel]

Peter Robinson wrote:
> Someone doing work in EPEL is quite a bit different to my point of a
> corporate organisation downstream of RHEL adding value and
> differentiation that Red Hat doesn't provide as part of RHEL.

The discussion was about people being able or unable to obtain the 
LibreOffice packages in some parts of the world. Since EPEL is widely 
mirrored, and mirrors (especially non-US ones) tend to not enforce US export 
control, people should be able to get the EPEL packages, along with some 
RHEL rebuild on which to install them, basically everywhere on the world. 
Whether the packaging work is done in EPEL or specifically in one of the 
rebuilds does not really matter for that purpose.

And I do not really see a good reason why a rebuild should be doing that 
packaging on their own in their own repositories when it can be done within 
the EPEL infrastructure that benefits everyone. It is the same as for KDE 
Plasma really. What the rebuilds can do though is, e.g., to include the 
LibreOffice EPEL packages on their live images, as they are already doing 
with the KDE EPEL packages.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Orphaning packages (was LibreOffice packages)

[Peter Robinson]

On Sun, Jul 2, 2023 at 10:27 PM Kevin Kofler via devel
 wrote:
>
> Peter Robinson wrote:
> > Assuming those "binary compatible distributions" choose to add
> > LibreOffice back in and support it, given what they actually do in
> > terms of actual development it's actually pretty unlikely they're
> > going to do all the extra work to add back an office suite and all the
> > dependencies it requires.
>
> If LibreOffice remains maintained in Fedora (and I sure hope so, because
> otherwise that would definitely make Fedora useless for me), there is a good
> chance that somebody will request and maintain EPEL branches for it, as has
> already been done for the KDE Plasma and KDE Gear applications stack.

Someone doing work in EPEL is quite a bit different to my point of a
corporate organisation downstream of RHEL adding value and
differentiation that Red Hat doesn't provide as part of RHEL.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Orphaning packages (was LibreOffice packages)

[Kevin Kofler via devel]

Peter Robinson wrote:
> Assuming those "binary compatible distributions" choose to add
> LibreOffice back in and support it, given what they actually do in
> terms of actual development it's actually pretty unlikely they're
> going to do all the extra work to add back an office suite and all the
> dependencies it requires.

If LibreOffice remains maintained in Fedora (and I sure hope so, because 
otherwise that would definitely make Fedora useless for me), there is a good 
chance that somebody will request and maintain EPEL branches for it, as has 
already been done for the KDE Plasma and KDE Gear applications stack.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Demi Marie Obenour]

On 6/3/23 08:42, Michael Catanzaro wrote:
> On Sat, Jun 3 2023 at 10:26:07 AM -, John Iliopoulos 
>  wrote:
>> Hello,
>>
>> While i completely understand why you do this i do think that it is 
>> important for desktop/workstation oriented devices to have some 
>> optional access to Office directly from the image file. Have you 
>> considered shipping the LibreOffice flatpak via the ISO much like 
>> Fedora Silverblue does with various other applications?
>>
>> This is the first time i reply to a mailing list so i hope i have not 
>> done anything wrong.
> 
> Hi. Welcome to the list. You haven't done anything wrong.
> 
> For Fedora Workstation, the mid-term plan is to ship all preinstalled 
> apps as Fedora Flatpaks. We cannot ship anything from Flathub because 
> FESCo will not allow it. I don't *like* this FESCo requirement, but I 
> also don't expect that to change. Accordingly, since Fedora Flatpaks 
> are built from Fedora RPMs, maintaining the LibreOffice RPMs is 
> essential to keep LibreOffice preinstalled. (I think that applies to 
> Silverblue as well?)

Fedora Flatpaks are also a security disaster: they are shipped in OCI
format instead of OSTree format, but they aren’t signed by anyone.
I’ve disabled the Fedora remote and recommend that others do the same.

> My $0.02: maintaining complex desktop applications as part of the 
> operating system requires significant effort and produces low value for 
> users when you can easily install that app from Flathub instead. (It 
> *especially* doesn't make sense to do in RHEL, but let's focus on 
> Fedora here.)

What is your reasoning here?  I’m not saying I disagree with you, but
I want to know *why* you believe this, especially since flatpaks consume
additional memory and disk space compared to RPMs.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Orphaning packages (was LibreOffice packages)

[Michael Catanzaro]

On Fri, Jun 30 2023 at 05:40:33 AM +0200, Kevin Kofler via devel 
 wrote:
So Red Hat is essentially killing all work on desktop packages, not 
just on

LibreOffice?


No. Losing Bastien is extremely unfortunate and demoralizing, but we 
are not killing all work on desktop packages.


Michael

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Orphaning packages (was LibreOffice packages)

[Peter Robinson]

On Sun, Jul 2, 2023 at 11:01 AM Vitaly Zaitsev via devel
 wrote:
>
> On 02/07/2023 10:51, Simon de Vlieger wrote:
> > The suppliers for these enterprise distributions and the support they
> > offer also abide by political lines.
>
> Indeed. That's why having RHEL repacks (Alma, Rocky, Oracle Linux) is good.
>
> > While your data won't be gone in an instant you still end up in the same 
> > situation with using an unsupported office suite.
>
> You can simply switch to one of these RHEL binary compatible distributions.

Assuming those "binary compatible distributions" choose to add
LibreOffice back in and support it, given what they actually do in
terms of actual development it's actually pretty unlikely they're
going to do all the extra work to add back an office suite and all the
dependencies it requires.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Orphaning packages (was LibreOffice packages)

[Vitaly Zaitsev via devel]

On 02/07/2023 10:51, Simon de Vlieger wrote:
The suppliers for these enterprise distributions and the support they 
offer also abide by political lines.


Indeed. That's why having RHEL repacks (Alma, Rocky, Oracle Linux) is good.

While your data won't be gone in an instant you still end up in the same situation with using an unsupported office suite. 


You can simply switch to one of these RHEL binary compatible distributions.

--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Orphaning packages (was LibreOffice packages)

[Simon de Vlieger]

On 7/2/23 08:56, Vitaly Zaitsev via devel wrote:

On 01/07/2023 14:28, Peter Robinson wrote:

This sort of comment is off topic, various companies are free to do
with their data as they wish, just as you are free to do with it as
you please.


This is not offtopic. What I mean is that a distribution targeted at 
enterprise use should have a standalone office suite in their 
repositories, because most enterprise users will won't use Flathub or 
any other third party repositories due to their internal security 
policy. They will simply migrate from RHEL to Ubuntu LTS or another 
enterprise distribution with LO.


These two situations can co-exist. Some companies will use cloud-based 
solutions because of the benefits they offer and some companies prefer 
to keep everything close to their chest.



Frankly it's often more secure with cloud providers than
on corporate networks.


And they can easily dump you and all your data. Russian Federation is a 
good example. Both Microsoft and Google have disabled all paid accounts 
for users and organizations from this country.




The suppliers for these enterprise distributions and the support they 
offer also abide by political lines. While your data won't be gone in an 
instant you still end up in the same situation with using an unsupported 
office suite.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Orphaning packages (was LibreOffice packages)

[Vitaly Zaitsev via devel]

On 01/07/2023 14:28, Peter Robinson wrote:

This sort of comment is off topic, various companies are free to do
with their data as they wish, just as you are free to do with it as
you please.


This is not offtopic. What I mean is that a distribution targeted at 
enterprise use should have a standalone office suite in their 
repositories, because most enterprise users will won't use Flathub or 
any other third party repositories due to their internal security 
policy. They will simply migrate from RHEL to Ubuntu LTS or another 
enterprise distribution with LO.



Frankly it's often more secure with cloud providers than
on corporate networks.


And they can easily dump you and all your data. Russian Federation is a 
good example. Both Microsoft and Google have disabled all paid accounts 
for users and organizations from this country.


--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Orphaning packages (was LibreOffice packages)

[Smith, Stewart via devel]

On Jun 29, 2023, at 7:47 AM, Bastien Nocera  wrote:
> Here is a list of Fedora packages which I maintained or co-maintained which I 
> won't be able to contribute to anymore:
> 
> sloccount

I grabbed sloccount as I’ve found it useful over the years.

It looks the right level of incredibly low maintenance to add to the pile.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Orphaning packages (was LibreOffice packages)

[Kalev Lember]

On 6/29/23 16:47, Bastien Nocera wrote:

Hello,

As part of the same process outlined in Matthias Clasen's "LibreOffice 
packages" email, my upstream and downstream work on desktop Bluetooth, multimedia 
applications (namely totem, rhythmbox and sound-juicer) and libfprint/fprintd is being 
stopped, and all the rest of my upstream and downstream work will be reassigned depending 
on Red Hat's own priorities, as I am transferred to another team.

While it's possible that some of the maintenance will stay with me in the new 
team, I've not yet been told which team I would be joining.

Here is a list of Fedora packages which I maintained or co-maintained which I 
won't be able to contribute to anymore:
apfs-fuse
bluez
codespell
eosrei-emojione-fonts
geocode-glib
gnome-bluetooth
gnome-epub-thumbnailer
gnome-kra-ora-thumbnailer
gnome-user-share
gom
grilo
grilo-plugins
ifuse
iio-sensor-proxy
libfprint
libglib-testing
libimobiledevice
libpeas
libplist
libportal
libusbmuxd
low-memory-monitor
malcontent
power-profiles-daemon
sloccount
switcheroo-control
totem
totem-pl-parser
umockdev
usbmuxd


I went ahead and picked up some of the GNOME packages from the list:

gnome-bluetooth
gnome-user-share
gom
libglib-testing
libpeas
libportal
totem
totem-pl-parser

Victor (CC'd), do you want to pick up grilo and grilo-plugins?

--
Kalev
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Orphaning packages (was LibreOffice packages)

[Leon Fauster via devel]

Am 01.07.23 um 14:28 schrieb Peter Robinson:

On Sat, Jul 1, 2023 at 12:50 PM Vitaly Zaitsev via devel
 wrote:


On 01/07/2023 13:36, Chris Adams wrote:

A lot of the corporate world has gone to the "cloud"



don't have to worry about local backups of important documents and
spreadsheets, they get sharing with minimal effort, they can access
things from their mobile devices, etc.


And voluntarily hand over all the corporate secrets to Google and
Microsoft. Brilliant idea.


This sort of comment is off topic, various companies are free to do
with their data as they wish, just as you are free to do with it as
you please. Frankly it's often more secure with cloud providers than
on corporate networks. Either way that comment doesn't provide useful
discourse in this discussion.



No really, it defines requirements that a non-cloud solution addresses.
Just to rephrase it; "it's often more secure (confidential) on corporate 
networks than with cloud providers". So a legitimately contribution to

the discourse in having a functional desktop (office) environment.
Whether its being flatpaked, rpmish, immutable packaged or what ever the
future brings ...

--
Leon

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Orphaning packages (was LibreOffice packages)

[Peter Robinson]

On Sat, Jul 1, 2023 at 12:50 PM Vitaly Zaitsev via devel
 wrote:
>
> On 01/07/2023 13:36, Chris Adams wrote:
> > A lot of the corporate world has gone to the "cloud"
>
> > don't have to worry about local backups of important documents and
> > spreadsheets, they get sharing with minimal effort, they can access
> > things from their mobile devices, etc.
>
> And voluntarily hand over all the corporate secrets to Google and
> Microsoft. Brilliant idea.

This sort of comment is off topic, various companies are free to do
with their data as they wish, just as you are free to do with it as
you please. Frankly it's often more secure with cloud providers than
on corporate networks. Either way that comment doesn't provide useful
discourse in this discussion.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Orphaning packages (was LibreOffice packages)

[Vitaly Zaitsev via devel]

On 01/07/2023 13:36, Chris Adams wrote:

A lot of the corporate world has gone to the "cloud"



don't have to worry about local backups of important documents and
spreadsheets, they get sharing with minimal effort, they can access
things from their mobile devices, etc.


And voluntarily hand over all the corporate secrets to Google and 
Microsoft. Brilliant idea.


--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Orphaning packages (was LibreOffice packages)

[Chris Adams]

Once upon a time, Kevin Kofler  said:
> Peter Robinson wrote:
> > I would hardly say Libreoffice, bluetooth on the desktop and certain
> > iDevice pieces is "killing all work on the desktop" it's more focusing
> > on things that are important to their customers in those contexts.
> 
> What corporate desktop customers do not use LibreOffice? If RH considers 
> LibreOffice unimportant to their customers, it is obvious that they only 
> care about server customers.

A lot of the corporate world has gone to the "cloud" (Google Docs or
O365) for their office needs, enough that even where Windows is the
predominant desktop OS, they don't get MS Office licenses either.  They
don't have to worry about local backups of important documents and
spreadsheets, they get sharing with minimal effort, they can access
things from their mobile devices, etc.

-- 
Chris Adams 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Orphaning packages (was LibreOffice packages)

[Peter Robinson]

On Sat, Jul 1, 2023 at 12:30 PM Peter Robinson  wrote:
>
> On Sat, Jul 1, 2023 at 12:00 AM Kevin Kofler via devel
>  wrote:
> >
> > Peter Robinson wrote:
> > > I would hardly say Libreoffice, bluetooth on the desktop and certain
> > > iDevice pieces is "killing all work on the desktop" it's more focusing
> > > on things that are important to their customers in those contexts.
> >
> > What corporate desktop customers do not use LibreOffice? If RH considers
> > LibreOffice unimportant to their customers, it is obvious that they only
> > care about server customers.
>
> Well if the customer gets it via Flatpak they still have it, it also
> means it doesn't need to be upgraded in lockstep with the OS so they
> can go to newer versions while keeping the same rev of the desktop or
> vica versa.
>
> But then there's also "desktop usecases like retail point of sale and
> a whole lot of other single use UX graphical like display boards,
> ticket machines, places where they're technical workstations and the
> user has a separate windows device for email/office etc. There's a
> vast array.

Also a lot use online docs like Office365 or Google docs. I personally
used to use Libreoffice a lot but now I mostly use gDocs.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Orphaning packages (was LibreOffice packages)

[Peter Robinson]

On Sat, Jul 1, 2023 at 12:00 AM Kevin Kofler via devel
 wrote:
>
> Peter Robinson wrote:
> > I would hardly say Libreoffice, bluetooth on the desktop and certain
> > iDevice pieces is "killing all work on the desktop" it's more focusing
> > on things that are important to their customers in those contexts.
>
> What corporate desktop customers do not use LibreOffice? If RH considers
> LibreOffice unimportant to their customers, it is obvious that they only
> care about server customers.

Well if the customer gets it via Flatpak they still have it, it also
means it doesn't need to be upgraded in lockstep with the OS so they
can go to newer versions while keeping the same rev of the desktop or
vica versa.

But then there's also "desktop usecases like retail point of sale and
a whole lot of other single use UX graphical like display boards,
ticket machines, places where they're technical workstations and the
user has a separate windows device for email/office etc. There's a
vast array.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Orphaning packages (was LibreOffice packages)

[Arthur Bols]

On 29/06/2023 16:47, Bastien Nocera wrote:

Hello,

As part of the same process outlined in Matthias Clasen's "LibreOffice 
packages" email, my upstream and downstream work on desktop Bluetooth, multimedia 
applications (namely totem, rhythmbox and sound-juicer) and libfprint/fprintd is being 
stopped, and all the rest of my upstream and downstream work will be reassigned depending 
on Red Hat's own priorities, as I am transferred to another team.

While it's possible that some of the maintenance will stay with me in the new 
team, I've not yet been told which team I would be joining.

Here is a list of Fedora packages which I maintained or co-maintained which I 
won't be able to contribute to anymore:
apfs-fuse
bluez
codespell
eosrei-emojione-fonts
geocode-glib
gnome-bluetooth
gnome-epub-thumbnailer
gnome-kra-ora-thumbnailer
gnome-user-share
gom
grilo
grilo-plugins
ifuse
iio-sensor-proxy
libfprint
libglib-testing
libimobiledevice
libpeas
libplist
libportal
libusbmuxd
low-memory-monitor
malcontent
power-profiles-daemon
sloccount
switcheroo-control
totem
totem-pl-parser
umockdev
usbmuxd

I've picked up power-profiles-daemon

--
Arthur Bols
fas/irc: principis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Orphaning packages (was LibreOffice packages)

[Alexander Ploumistos]

On Sat, Jul 1, 2023 at 1:00 AM Kevin Kofler via devel
 wrote:
>
> What corporate desktop customers do not use LibreOffice?

I know two big-name scientific instrument manufacturers that offer
RHEL workstations on which to run the control software. I suspect
there are other domains with similar use cases, i.e. dedicated
computers that only run a certain piece of software or software suite.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Orphaning packages (was LibreOffice packages)

[Kevin Kofler via devel]

Peter Robinson wrote:
> I would hardly say Libreoffice, bluetooth on the desktop and certain
> iDevice pieces is "killing all work on the desktop" it's more focusing
> on things that are important to their customers in those contexts.

What corporate desktop customers do not use LibreOffice? If RH considers 
LibreOffice unimportant to their customers, it is obvious that they only 
care about server customers.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Orphaning packages (was LibreOffice packages)

[Peter Robinson]

On Fri, Jun 30, 2023 at 4:41 AM Kevin Kofler via devel
 wrote:
>
> Bastien Nocera wrote:
> > As part of the same process outlined in Matthias Clasen's "LibreOffice
> > packages" email, my upstream and downstream work on desktop Bluetooth,
> > multimedia applications (namely totem, rhythmbox and sound-juicer) and
> > libfprint/fprintd is being stopped, and all the rest of my upstream and
> > downstream work will be reassigned depending on Red Hat's own priorities,
> > as I am transferred to another team.
>
> So Red Hat is essentially killing all work on desktop packages, not just on
> LibreOffice? Also considering that several of those packages are libraries
> that cannot just be put on Flathub as LibreOffice can (which was their
> excuse for terminating all work on LibreOffice packaging).

I would hardly say Libreoffice, bluetooth on the desktop and certain
iDevice pieces is "killing all work on the desktop" it's more focusing
on things that are important to their customers in those contexts.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Orphaning packages (was LibreOffice packages)

[Kevin Kofler via devel]

Bastien Nocera wrote:
> As part of the same process outlined in Matthias Clasen's "LibreOffice
> packages" email, my upstream and downstream work on desktop Bluetooth,
> multimedia applications (namely totem, rhythmbox and sound-juicer) and
> libfprint/fprintd is being stopped, and all the rest of my upstream and
> downstream work will be reassigned depending on Red Hat's own priorities,
> as I am transferred to another team.

So Red Hat is essentially killing all work on desktop packages, not just on 
LibreOffice? Also considering that several of those packages are libraries 
that cannot just be put on Flathub as LibreOffice can (which was their 
excuse for terminating all work on LibreOffice packaging).

With the layoff and the destruction of the position of the Fedora Program 
Manager, the termination of public RHEL source releases, and this move, Red 
Hat is really turning into an unfriendly company, and I really have to 
wonder whether Fedora is going to be of any use to me in the long run.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Orphaning packages (was LibreOffice packages)

[Davide Cavalca]

On 2023-06-29 18:09, Bastien Nocera wrote:

Do you want to pick up the rest of the libimobiledevice stack as well?
That's ifuse, libplist, libusbmuxd and usbmuxd.


I've just picked these up, thanks! Will work together with Neal on this 
stack as part of the Fedora Asahi SIG.


Cheers
Davide
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Orphaning packages (was LibreOffice packages)

[Bastien Nocera]

Do you want to pick up the rest of the libimobiledevice stack as well? That's 
ifuse, libplist, libusbmuxd and usbmuxd.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Orphaning packages (was LibreOffice packages)

[Stephen Smoogen]

On Thu, 29 Jun 2023 at 10:48, Bastien Nocera  wrote:

> Hello,
>
> As part of the same process outlined in Matthias Clasen's "LibreOffice
> packages" email, my upstream and downstream work on desktop Bluetooth,
> multimedia applications (namely totem, rhythmbox and sound-juicer) and
> libfprint/fprintd is being stopped, and all the rest of my upstream and
> downstream work will be reassigned depending on Red Hat's own priorities,
> as I am transferred to another team.
>
>
1. Thank you for all the work you have done on these and other packages in
Fedora. The Bluetooth stack is not easy.
2. Thank you for announcing this early and allowing a quick transfer.
3. Good luck with the new team, they are lucky to have you.


-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Orphaning packages (was LibreOffice packages)

[Jeffrey Stewart]

I've picked up low-memory-monitor

On 6/29/23 08:46, Neal Gompa wrote:

On Thu, Jun 29, 2023 at 10:48 AM Bastien Nocera  wrote:

Hello,

As part of the same process outlined in Matthias Clasen's "LibreOffice 
packages" email, my upstream and downstream work on desktop Bluetooth, multimedia 
applications (namely totem, rhythmbox and sound-juicer) and libfprint/fprintd is being 
stopped, and all the rest of my upstream and downstream work will be reassigned depending 
on Red Hat's own priorities, as I am transferred to another team.

While it's possible that some of the maintenance will stay with me in the new 
team, I've not yet been told which team I would be joining.

Here is a list of Fedora packages which I maintained or co-maintained which I 
won't be able to contribute to anymore:
apfs-fuse
bluez
codespell
eosrei-emojione-fonts
geocode-glib
gnome-bluetooth
gnome-epub-thumbnailer
gnome-kra-ora-thumbnailer
gnome-user-share
gom
grilo
grilo-plugins
ifuse
iio-sensor-proxy
libfprint
libglib-testing
libimobiledevice
libpeas
libplist
libportal
libusbmuxd
low-memory-monitor
malcontent
power-profiles-daemon
sloccount
switcheroo-control
totem
totem-pl-parser
umockdev
usbmuxd


I've picked up libimobiledevice as I need it for Fedora Asahi work.




___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Orphaning packages (was LibreOffice packages)

[Neal Gompa]

On Thu, Jun 29, 2023 at 10:48 AM Bastien Nocera  wrote:
>
> Hello,
>
> As part of the same process outlined in Matthias Clasen's "LibreOffice 
> packages" email, my upstream and downstream work on desktop Bluetooth, 
> multimedia applications (namely totem, rhythmbox and sound-juicer) and 
> libfprint/fprintd is being stopped, and all the rest of my upstream and 
> downstream work will be reassigned depending on Red Hat's own priorities, as 
> I am transferred to another team.
>
> While it's possible that some of the maintenance will stay with me in the new 
> team, I've not yet been told which team I would be joining.
>
> Here is a list of Fedora packages which I maintained or co-maintained which I 
> won't be able to contribute to anymore:
> apfs-fuse
> bluez
> codespell
> eosrei-emojione-fonts
> geocode-glib
> gnome-bluetooth
> gnome-epub-thumbnailer
> gnome-kra-ora-thumbnailer
> gnome-user-share
> gom
> grilo
> grilo-plugins
> ifuse
> iio-sensor-proxy
> libfprint
> libglib-testing
> libimobiledevice
> libpeas
> libplist
> libportal
> libusbmuxd
> low-memory-monitor
> malcontent
> power-profiles-daemon
> sloccount
> switcheroo-control
> totem
> totem-pl-parser
> umockdev
> usbmuxd
>

I've picked up libimobiledevice as I need it for Fedora Asahi work.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Orphaning packages (was LibreOffice packages)

[Bastien Nocera]

Hello,

As part of the same process outlined in Matthias Clasen's "LibreOffice 
packages" email, my upstream and downstream work on desktop Bluetooth, 
multimedia applications (namely totem, rhythmbox and sound-juicer) and 
libfprint/fprintd is being stopped, and all the rest of my upstream and 
downstream work will be reassigned depending on Red Hat's own priorities, as I 
am transferred to another team.

While it's possible that some of the maintenance will stay with me in the new 
team, I've not yet been told which team I would be joining.

Here is a list of Fedora packages which I maintained or co-maintained which I 
won't be able to contribute to anymore:
apfs-fuse
bluez
codespell
eosrei-emojione-fonts
geocode-glib
gnome-bluetooth
gnome-epub-thumbnailer
gnome-kra-ora-thumbnailer
gnome-user-share
gom
grilo
grilo-plugins
ifuse
iio-sensor-proxy
libfprint
libglib-testing
libimobiledevice
libpeas
libplist
libportal
libusbmuxd
low-memory-monitor
malcontent
power-profiles-daemon
sloccount
switcheroo-control
totem
totem-pl-parser
umockdev
usbmuxd

Regards
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Gwyn Ciesla via devel]

I built it successfully in the side tag by disabling tests. There's a new 
release; I'll see if that fixes things.



-- 
Gwyn Ciesla
she/her/hers
 
in your fear, seek only peace 
in your fear, seek only love
-d. bowie


Sent with Proton Mail secure email.

--- Original Message ---
On Friday, June 16th, 2023 at 2:34 AM, Dan Horák  wrote:


> On Thu, 15 Jun 2023 18:40:39 +0200
> Miro Hrončok mhron...@redhat.com wrote:
> 

> > On 01. 06. 23 22:16, Gwyn Ciesla via devel wrote:
> > 

> > > I've taken ownership of libreoffice for the time being, at least to keep 
> > > the lights on. Co-maintainers, as always, welcome.
> > 

> > Thanks.
> > 

> > Could you please prioritize making it build? The LibreOffice package fails 
> > to
> > build in rawhide for months. It's now blocking the Python 3.12 rebuild:
> > 

> > https://bugzilla.redhat.com/show_bug.cgi?id=2215352
> > 

> > This is not directed only at Gwyn, but all the other folks who offered help.
> 

> 

> for the record, the build failure is caused by a failing test, but it
> doesn't show if it's the only problem there
> 

> ...
> Test name: DesktopLOKTest::testSignDocument_PEM_PDF
> assertion failed
> - Expression: bResult
> Failures !!!
> 

> I believe we need a shared document to track who is doing what and
> generally coordinate the actions.
> 

> 

> Dan
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue

signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Dan Horák]

On Thu, 15 Jun 2023 18:40:39 +0200
Miro Hrončok  wrote:

> On 01. 06. 23 22:16, Gwyn Ciesla via devel wrote:
> > I've taken ownership of libreoffice for the time being, at least to keep 
> > the lights on. Co-maintainers, as always, welcome.
> 
> Thanks.
> 
> Could you please prioritize making it build? The LibreOffice package fails to 
> build in rawhide for months. It's now blocking the Python 3.12 rebuild:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=2215352
> 
> This is not directed only at Gwyn, but all the other folks who offered help.

for the record, the build failure is caused by a failing test, but it
doesn't show if it's the only problem there

...
Test name: DesktopLOKTest::testSignDocument_PEM_PDF
assertion failed
- Expression: bResult
Failures !!!

I believe we need a shared document to track who is doing what and
generally coordinate the actions.


Dan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Miro Hrončok]

On 01. 06. 23 22:16, Gwyn Ciesla via devel wrote:

I've taken ownership of libreoffice for the time being, at least to keep the 
lights on. Co-maintainers, as always, welcome.


Thanks.

Could you please prioritize making it build? The LibreOffice package fails to 
build in rawhide for months. It's now blocking the Python 3.12 rebuild:


https://bugzilla.redhat.com/show_bug.cgi?id=2215352

This is not directed only at Gwyn, but all the other folks who offered help.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Jiri Eischmann]

Michael Catanzaro píše v St 07. 06. 2023 v 08:15 -0500:
> 
> Ideally all bundled dependencies should be hooked up to some sort of 
> automation that notices when there are upstream updates available, 
> comparable to upstream release monitoring. On Flathub this is done by
> flathub-external-data-checker [1], but using it is optional and it's 
> not useful if it's not used. For Fedora Flatpaks, I don't think any 
> comparable mechanism exists, but it should be as simple as "update 
> whenever any component RPM is updated."
> 
> [1] https://github.com/flathub/flatpak-external-data-checker
> 

I used that for flatpaks I maintain for a while, but then removed it
because it was rather adding work than reducing it. But it could be
just my workflow.
I recommend anyone use https://release-monitoring.org/ which can send
you notifications of new versions of specified projects. Could be used
for any component maintenance including RPMs. I get notified and then
it's up to me when and how I act on it. You can build automation based
on it, too.

My biggest flatpak has 15 modules. Maybe if it had dozens like
LibreOffice I'd appreciate more automation.

Jiri

> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Stephan Bergmann]

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, 
 "Add 
metadata for flatpak-external-data-checker".

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Michael J Gruber]

The main difference is that Fedora - be it rpms, flatpaks from module rpms 
(current state), flatpaks from whatever - comes with the promise of all the 
four F's, including freedom from legal issues as outlined in our guidelines. 
That enables RedHat to make the guarantees which they make for their offerings.

Flatpaks from third party sources such as flathub come with no promise 
whatsover (AFAICT) - unless you track a specific flatpak's provider and figure 
out their promises/guarantees per flatpak. And without that neither Fedora nor 
RedHat can ship any app on live media and such.

A different question is shipping configuration for third party rpm repos (such 
as rpmfusion) or flatpak hubs (such flathub). Here, the issue is:
- Shipping a Fedora/RHEL specific (enabled) repo/hub config might be considered 
redistribution, or at least RH legal may consider that a risk too high to take.
- Shipping a non-specific (enabled) hub config can hardly be considered 
redistribution, or at least RH legal does not seem to fear that risk (since 
unfiltered flathub).

From a customer perspective: Your on your own with anything you pull in from 
third party sources.

Michael
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Michael Catanzaro]

Ideally all bundled dependencies should be hooked up to some sort of 
automation that notices when there are upstream updates available, 
comparable to upstream release monitoring. On Flathub this is done by 
flathub-external-data-checker [1], but using it is optional and it's 
not useful if it's not used. For Fedora Flatpaks, I don't think any 
comparable mechanism exists, but it should be as simple as "update 
whenever any component RPM is updated."


[1] https://github.com/flathub/flatpak-external-data-checker

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Neal H. Walfield]

On Tue, 06 Jun 2023 18:07:04 +0200,
Fabio Valentini wrote:
> On the other hand, the libreoffice flatpak bundles ~80 projects:
> - gpgme (huh?)

This...

> - openldap (huh?)

and perhaps this are probably because it is possible to sign and
encrypt ODF documents using OpenPGP.  Some details are here:

  https://help.libreoffice.org/latest/en-US/text/shared/guide/openpgp.html

Neal
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Dominik 'Rathann' Mierzejewski]

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., 
> ):
> 
> * 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 
> 
> "Re-enable GIO support") and krb5 (see 
> 
> "Add krb5" and 
> 
> "Introduce optional krb5 support for internal PostgreSQL") "on its
> own":  If there are any (security) issues with their upstream sources, we
> need to notice that and adapt the LibreOffice flatpak accordingly.
> 
> * It bundles another 83 packages (from pdfium-5408.tar.bz2 to 
> f543e6e2d7275557a839a164941c0a86e5f2c3f2a0042bfc434c88c6dde9e140-opens___.ttf)
> that are "managed" by upstream LibreOffice:  These are also used for other
> upstream LibreOffice builds (e.g., on macOS and Windows), and if there are
> any relevant (security) issues, upstream LibreOffice takes care of that and
> provides a new upstream LibreOffice version (and thus a new LibreOffice
> flatpak version).

And this is exactly where the value of Linux distribution lies. Upstream
does not have to "manage" their dependencies and can rely on
distributions instead. There are package management solutions for
Windows and MacOS, so upstreams could make a one-time effort to support
those and delegate instead of the constant time investment to manage
dependency bundling for all platforms on their own. I realize this
would not happen overnight, but I wish this were the direction in which
upstreams are moving instead of bundling everything.

Regards,
Dominik
-- 
Fedora   https://fedoraproject.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Fabio Valentini]

On Wed, Jun 7, 2023 at 8:51 AM Stephan Bergmann  wrote:
>
> If you are talking about the LibreOffice upstream flatpak on Flathub
> (i.e.,
> ):

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
> 
> "Re-enable GIO support") and krb5 (see
> 
> "Add krb5" and
> 
> "Introduce optional krb5 support for internal PostgreSQL") "on
> its own":  If there are any (security) issues with their upstream
> sources, we need to notice that and adapt the LibreOffice flatpak
> accordingly.
>
> * It bundles another 83 packages (from pdfium-5408.tar.bz2 to
> f543e6e2d7275557a839a164941c0a86e5f2c3f2a0042bfc434c88c6dde9e140-opens___.ttf)
> that are "managed" by upstream LibreOffice:  These are also used for
> other upstream LibreOffice builds (e.g., on macOS and Windows), and if
> there are any relevant (security) issues, upstream LibreOffice takes
> care of that and provides a new upstream LibreOffice version (and thus a
> new LibreOffice flatpak version).
>
> * It includes ant as a build-time--only dependency.

Thank you for the explanation, but still, I would argue that it is not
the LibreOffice project's job to do those things, and I don't
necessarily trust them to do this right (other people might have a
different opinion here).

Basically, I'm wondering how this is different from the "don't
(re)package everything as RPMs if upstream already provides flatpaks!
don't reinvent the wheel!" argument that's sometimes brought in favor
of flatpaks. Don't flatpaks do just the same thing, just not with the
applications themselves, but basically "reinventing the wheel" by
bundling / shipping / maintaining all their dependencies, which are
already provided by the underlying Linux distro in most cases?

Fabio
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Stephan Bergmann]

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


* 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 
 
"Re-enable GIO support") and krb5 (see 
 
"Add krb5" and 
 
"Introduce optional krb5 support for internal PostgreSQL") "on 
its own":  If there are any (security) issues with their upstream 
sources, we need to notice that and adapt the LibreOffice flatpak 
accordingly.


* It bundles another 83 packages (from pdfium-5408.tar.bz2 to 
f543e6e2d7275557a839a164941c0a86e5f2c3f2a0042bfc434c88c6dde9e140-opens___.ttf) 
that are "managed" by upstream LibreOffice:  These are also used for 
other upstream LibreOffice builds (e.g., on macOS and Windows), and if 
there are any relevant (security) issues, upstream LibreOffice takes 
care of that and provides a new upstream LibreOffice version (and thus a 
new LibreOffice flatpak version).


* It includes ant as a build-time--only dependency.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Fabio Valentini]

On Thu, Jun 1, 2023 at 10:00 PM Christian Schaller  wrote:
>
> On Thu, Jun 1, 2023 at 2:36 PM Demi Marie Obenour  
> wrote:
>>
>> Why is a Flatpak a better choice for LibreOffice?
>> --
>> Sincerely,
>> Demi Marie Obenour (she/her/hers)
>
> There are a lot of ways to answer this, but from any upstream the advantage 
> of Flatpak is that it means package once and then deploy everywhere. So it 
> saves them work.
>
> From a Fedora perspective there is of course nobody telling anyone to not 
> maintain LibreOffice as RPMS or as a Fedora flatpak going forward, but even 
> if nobody does we have a good option available in the Flathub package, 
> especially with the Flathub package not being verified as the official 
> package of upstream LibreOffice.

I wanted to add one thing here.
In general, I do like having software available as flatpaks,
especially if it's not available from Fedora repositories.
However, there's also the question of *trust* - do I trust the
software source and / or the people / projects providing them?

Let's take LibreOffice as an example, since it started this whole discussion.
The Fedora package appears to bundle only one "major" dependency,
hsqldb, and it's documented and justified why this is the case in the
spec file.

On the other hand, the libreoffice flatpak bundles ~80 projects:
- OpenJDK 17 (huh? is there no shared JDK flatpak runtime / SDK extension?)
- krb5 (huh?)
- xmlsec
- boost 1.80
- gpgme (huh?)
- mariadb-connector-c
- openldap (huh?)
- poppler
- PostgreSQL 13.10 (huh?)
- and about 70 more (but with less memorable names)

While I *do* trust the LibreOffice project (somewhat) to ship their
own software correctly, do I trust them regarding these ~80 bundled -
and partially security sensitive - libraries, as well? I'm not sure.
Do I trust the Fedora packages for these libraries? Probably. Many of
these libraries are installed by default on Fedora, and are not only
used by LibreOffice, so I basically placed implicit trust in these
when I first installed Fedora on my machine.

Fabio
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Owen Taylor]

On Tue, Jun 6, 2023 at 7:50 AM Leon Fauster via devel <
devel@lists.fedoraproject.org> wrote:

> Is the Fedora OCI flatpak approach not about the trust into the chain of
> flatpak creation? src -> signed rpm -> flatpak? So, even in an ideal world
> where RHEL is immutable and the best workstation experience is based on
> flatpaks - RPMs are the building block. This is completly different to the
> Flathub approach ...
> https://fedoraproject.org/wiki/Flatpak#Fedora_flatpaks
>

In both cases, the build is fixed to a cryptographic hash of the source
tarball. For Flathub, that is done in the manifest file.. (
https://github.com/flathub/org.libreoffice.LibreOffice/blob/master/org.libreoffice.LibreOffice.json)
In Fedora, by the SOURCES file. In both cases, the exact tools versions
used to build the binary from the source are recorded. For Flathub, that is
done by embedding an extended version of the manifest in the application
(at /app/manifest.json). For Fedora, that information is recorded by the
buildroot information saved by koji.

You could look for more - does the hash in the SOURCES file actually
correspond to the published upstream tarball? Is there a signature on that
tarball? Do you trust that signature? But I don't see much of a difference
in this aspect. Building an intermediate RPM doesn't make the source =>
Flatpak pipeline more secure.

- Owen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Leon Fauster via devel]

Is the Fedora OCI flatpak approach not about the trust into the chain of 
flatpak creation? src -> signed rpm -> flatpak? So, even in an ideal world 
where RHEL is immutable and the best workstation experience is based on 
flatpaks - RPMs are the building block. This is completly different to the 
Flathub approach ... https://fedoraproject.org/wiki/Flatpak#Fedora_flatpaks
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Stephen Smoogen]

On Mon, 5 Jun 2023 at 16:14, Michael Catanzaro 
wrote:

>
>
> On Mon, Jun 5 2023 at 01:37:24 PM -0400, Stephen Smoogen
>  wrote:
> >
> > 1. What is a flatpak and what does it mean to have an application in
> > it? Is it everything bundled in it or does it use layers?
>
> Two layers:
>
>  * Runtime (base platform, responsibility of runtime maintainers)
>  * Application (including bundled dependencies not present in the
> runtime)
>
> It's a compromise between traditional distribution-style dynamic
> linking for the most common dependencies (the runtime), plus bundling
> for the less-common dependencies the application needs that are not
> present in the runtime.
>
>
I just wanted to say thank you for taking the time to answer these
questions. It was very helpful.


-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Michael Catanzaro]

On Mon, Jun 5 2023 at 04:46:42 PM -0400, Demi Marie Obenour 
 wrote:

Fedora could, of course ship its own SELinux policy for Flatpak (and I
recommend this), but Flatpak will not (and cannot reasonably be 
expected

to) integrate with SELinux natively.


Well it would have to be a very permissive policy, because it would 
need to allow everything that any Flatpak app might ever want to do. 
Doesn't selinux work best when you have a good understanding of the 
software that you are trying to confine?


Could Flatpak be changed to use e.g. KVM + crosvm for isolation?  
Flatpak
does (via seccomp) prevent applications from creating _new_ user 
namespaces.


Maybe in theory, but in practice that won't work because (a) it would 
be a major breaking change, and (b) flatpaks are integrated with the 
host system via D-Bus APIs, and throwing a VM boundary into the middle 
would make D-Bus rather difficult to do.


For example, when you want to open a file, the application does not 
have any access to the host filesystem, so if it attempts to display 
its own file chooser, you'll see only a sad empty home directory. 
Instead, an application designed for Flatpak will use the 
org.freedesktop.portal.FileChooser D-Bus API to ask the portal running 
on the host system to show a file chooser instead. (The application's 
UI toolkit, e.g. GTK or Qt, will usually handle this.) Then the user 
interacts with the host file chooser, and the host mounts the selected 
file in the sandbox so that the application can only see the file that 
the user selected. That would need to somehow work across the VM 
boundary. No doubt it's possible somehow, but using a VM would 
certainly make that a lot more complicated.


Now that's just one of dozens of portal APIs that allow sandboxed apps 
to interact with the host system. Another example: 
org.freedesktop.portal.FileTransfer, which allows drag-and-drop to and 
from the sandboxed application. All the portals would need to be 
reimplemented to ensure they still work with virtual machines instead 
of containerized applications. I don't want to say "no don't ever 
attempt this" but it sounds like a huge undertaking. We have to balance 
isolation vs. functionality; adding so much isolation such that 
applications no longer function as expected is too much. (We also have 
to satisfy users who expect flatpak to add no overheard relative to 
host system applications, which isn't possible but would be especially 
not possible if using VMs.)


So I don't expect upstream to be interested in this.

Michael

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Michael Catanzaro]

On Mon, Jun 5 2023 at 04:49:07 PM -0400, Demi Marie Obenour 
 wrote:
“several hundred megabits a second on tap at all times” is 
completely
out of the question for the majority of the world’s population.  
I’m not
sure what the median bandwidth in the developing world is, but it is 
far

FAR less than that, not to mention often being metered.


My standard response to concerns about image size is to point to:

https://blogs.gnome.org/wjjt/2021/11/24/on-flatpak-disk-usage-and-deduplication/

Endless OS is designed for developing world users with metered 
connections or nonexistent connections, where updates have to be 
manually copied from a device that does have an internet connection to 
other devices via a USB stick. All the apps are Flatpaks.


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Adam Williamson]

On Mon, 2023-06-05 at 16:49 -0400, Demi Marie Obenour wrote:
> On 6/5/23 15:01, Adam Williamson wrote:
> > On Mon, 2023-06-05 at 19:51 +0200, Roberto Ragusa wrote:
> > > On 6/5/23 19:13, Demi Marie Obenour wrote:
> > > 
> > > > Are you willing to do the packaging work?  Asking upstream to create
> > > > packages for every distribution is not reasonable.
> > > 
> > > I would never want upstream to do packaging, as experience teaches,
> > > they would certainly do it wrong.
> > > Packaging and integration is a job for the distribution; it is their
> > > added value. Otherwise, what's the meaning of a distribution, if
> > > the system is composed by a minimal booting image on which you
> > > add upstream generated blobs?
> > 
> > This is really the heart of the question, and it's an interesting one.
> > 
> > The idea that the distribution's job is to package up everything you
> > might possibly want to use on your system is a very old one that goes
> > back to the days before having an internet connection was the norm, let
> > alone having several hundred megabits a second on tap at all times.
> 
> “several hundred megabits a second on tap at all times” is completely
> out of the question for the majority of the world’s population.  I’m not
> sure what the median bandwidth in the developing world is, but it is far
> FAR less than that, not to mention often being metered.

I knew someone was going to bring this up, but let's be realistic. The
majority of the world's population does not use Fedora and is not
involved in F/OSS development. I entirely support any and all efforts
to improve that, but practically speaking, the people who build and use
F/OSS mostly have very good internet connections. It is already,
realistically speaking, very hard to use Fedora without one.
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Demi Marie Obenour]

On 6/5/23 15:01, Adam Williamson wrote:
> On Mon, 2023-06-05 at 19:51 +0200, Roberto Ragusa wrote:
>> On 6/5/23 19:13, Demi Marie Obenour wrote:
>>
>>> Are you willing to do the packaging work?  Asking upstream to create
>>> packages for every distribution is not reasonable.
>>
>> I would never want upstream to do packaging, as experience teaches,
>> they would certainly do it wrong.
>> Packaging and integration is a job for the distribution; it is their
>> added value. Otherwise, what's the meaning of a distribution, if
>> the system is composed by a minimal booting image on which you
>> add upstream generated blobs?
> 
> This is really the heart of the question, and it's an interesting one.
> 
> The idea that the distribution's job is to package up everything you
> might possibly want to use on your system is a very old one that goes
> back to the days before having an internet connection was the norm, let
> alone having several hundred megabits a second on tap at all times.

“several hundred megabits a second on tap at all times” is completely
out of the question for the majority of the world’s population.  I’m not
sure what the median bandwidth in the developing world is, but it is far
FAR less than that, not to mention often being metered.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Demi Marie Obenour]

On 6/5/23 16:35, Michael Catanzaro wrote:
> On Mon, Jun 5 2023 at 02:09:58 PM -0400, Steve Grubb 
>  wrote:
>> Yes. And how does it's security model work?
> 
> The security model is that the application is assumed to be compromised 
> by malicious input and is trying to do evil things to the host system, 
> like read your home directory and send copies of your files to a 
> ransomware operator or nation state. Linux namespaces plus seccomp 
> filters are used to confine applications to prevent them from messing 
> with the host system, or reading your personal files, etc.
> 
> It's great in theory. Problem is, as a transition measure to encourage 
> developers to adopt Flatpak, you can give your application extra 
> permissions that totally break the security model, and this is 
> extremely common in practice. You should only trust applications that 
> don't do this, but most apps do. See [1] for a discussion of this.
> 
> [1] 
> https://theevilskeleton.gitlab.io/2023/05/11/overview-of-flatpaks-permission-models.html
> 
> There are different degrees of badness. E.g. Epiphany, which I 
> maintain, has a sandbox hole that allows it to read and write your 
> Downloads directory, and another hole that allows it to talk to 
> Geoclue. These are both unacceptable, but certainly not as bad as 
> allowing read/write access to the user's home directory or root 
> filesystem, which many apps actually do.
> 
> Flatpak could be pretty darn secure, but only if we stop allowing this, 
> and I fear that would likely result in applications abandoning the 
> platform. This is a major threat IMO. I'd love to see more effort 
> towards improving our portals so that applications don't need to use 
> static permissions anymore. We need to really clamp down on this so 
> that users can trust the Flatpak ecosystem.
> 
>> What is the root of trust?
> 
> I think there is no root. A GPG key is provided when installing a 
> runtime or application.
> 
>> Are they signed by a Fedora key that I already
>> have?
> 
> Nope (except presumably for Fedora Flatpaks).
> 
>> How can we verify it's integrity?
> 
> I think the GPG keys are trust-on-first-use.
> 
>> Once installed, how do I verify it's
>> integrity? How do I check if anything has been modified?
> 
> I don't know. Non-Fedora Flatpaks are stored using ostree, so people 
> familiar with ostree would be able to answer this question. Fedora 
> Flatpaks are OCI containers, so people familiar with OCI containers 
> would know about that.
> 
> ostree is a "git for binaries" and you can detect normal non-malicious 
> modification by looking at the history, e.g. `flatpak remote-info --log 
> flathub org.gnome.Platform//44`; however, this only tells you when 
> something changed, not what actually changed.
> 
>> Does it integrate
>> well with SE Linux,
> 
> No. selinux is entirely outside the Flatpak security model because 
> Flatpak is a cross-distro tool and selinux is not used outside Fedora 
> and Red Hat distros.

Fedora could, of course ship its own SELinux policy for Flatpak (and I
recommend this), but Flatpak will not (and cannot reasonably be expected
to) integrate with SELinux natively.

>> IMA, fapolicyd, or openscap?
> 
> I'm not familiar with these technologies, but I think the answer is: no.
> 
>> On a locked down system, are
>> there sysctls  that I have undo such as user namespaces?
> 
> Technically, Flatpak can work without user namespaces, but this is a 
> legacy configuration and it only works if bubblewrap (/usr/bin/bwrap) 
> is built to use suid root instead of user namespaces, which is not 
> recommend and which we do not do in Fedora. (I think Debian maybe still 
> does this?) So it will surely break if you disable user namespaces, but 
> you might be able to make it work by rebuilding your own bubblewrap 
> instead of using Fedora's.
> 
> The Flatpak sandbox does not attempt to guard against kernel bugs -- it 
> can't, because it has to allow access to all syscalls that applications 
> might reasonably want to use -- so if you don't trust the kernel to be 
> secure (including user namespaces), Flatpak is not the tool for you.

Could Flatpak be changed to use e.g. KVM + crosvm for isolation?  Flatpak
does (via seccomp) prevent applications from creating _new_ user namespaces.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Michael Catanzaro]

On Mon, Jun 5 2023 at 02:09:58 PM -0400, Steve Grubb 
 wrote:

Yes. And how does it's security model work?


The security model is that the application is assumed to be compromised 
by malicious input and is trying to do evil things to the host system, 
like read your home directory and send copies of your files to a 
ransomware operator or nation state. Linux namespaces plus seccomp 
filters are used to confine applications to prevent them from messing 
with the host system, or reading your personal files, etc.


It's great in theory. Problem is, as a transition measure to encourage 
developers to adopt Flatpak, you can give your application extra 
permissions that totally break the security model, and this is 
extremely common in practice. You should only trust applications that 
don't do this, but most apps do. See [1] for a discussion of this.


[1] 
https://theevilskeleton.gitlab.io/2023/05/11/overview-of-flatpaks-permission-models.html


There are different degrees of badness. E.g. Epiphany, which I 
maintain, has a sandbox hole that allows it to read and write your 
Downloads directory, and another hole that allows it to talk to 
Geoclue. These are both unacceptable, but certainly not as bad as 
allowing read/write access to the user's home directory or root 
filesystem, which many apps actually do.


Flatpak could be pretty darn secure, but only if we stop allowing this, 
and I fear that would likely result in applications abandoning the 
platform. This is a major threat IMO. I'd love to see more effort 
towards improving our portals so that applications don't need to use 
static permissions anymore. We need to really clamp down on this so 
that users can trust the Flatpak ecosystem.



What is the root of trust?


I think there is no root. A GPG key is provided when installing a 
runtime or application.



Are they signed by a Fedora key that I already
have?


Nope (except presumably for Fedora Flatpaks).


How can we verify it's integrity?


I think the GPG keys are trust-on-first-use.


Once installed, how do I verify it's
integrity? How do I check if anything has been modified?


I don't know. Non-Fedora Flatpaks are stored using ostree, so people 
familiar with ostree would be able to answer this question. Fedora 
Flatpaks are OCI containers, so people familiar with OCI containers 
would know about that.


ostree is a "git for binaries" and you can detect normal non-malicious 
modification by looking at the history, e.g. `flatpak remote-info --log 
flathub org.gnome.Platform//44`; however, this only tells you when 
something changed, not what actually changed.



Does it integrate
well with SE Linux,


No. selinux is entirely outside the Flatpak security model because 
Flatpak is a cross-distro tool and selinux is not used outside Fedora 
and Red Hat distros.



IMA, fapolicyd, or openscap?


I'm not familiar with these technologies, but I think the answer is: no.


On a locked down system, are
there sysctls  that I have undo such as user namespaces?


Technically, Flatpak can work without user namespaces, but this is a 
legacy configuration and it only works if bubblewrap (/usr/bin/bwrap) 
is built to use suid root instead of user namespaces, which is not 
recommend and which we do not do in Fedora. (I think Debian maybe still 
does this?) So it will surely break if you disable user namespaces, but 
you might be able to make it work by rebuilding your own bubblewrap 
instead of using Fedora's.


The Flatpak sandbox does not attempt to guard against kernel bugs -- it 
can't, because it has to allow access to all syscalls that applications 
might reasonably want to use -- so if you don't trust the kernel to be 
secure (including user namespaces), Flatpak is not the tool for you.



If an app coredumps,
does a problem report get generated? Who gets it?


Nope, there's nothing. You have to manually create a backtrace using 
flatpak-coredumpctl and then create a bug report yourself. This is 
really bad. We need ABRT to handle this so we can generate crash 
reports like we do for Fedora's packaged software.


Michael

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Michael Catanzaro]

On Mon, Jun 5 2023 at 01:37:24 PM -0400, Stephen Smoogen 
 wrote:


1. What is a flatpak and what does it mean to have an application in 
it? Is it everything bundled in it or does it use layers?


Two layers:

* Runtime (base platform, responsibility of runtime maintainers)
* Application (including bundled dependencies not present in the 
runtime)


It's a compromise between traditional distribution-style dynamic 
linking for the most common dependencies (the runtime), plus bundling 
for the less-common dependencies the application needs that are not 
present in the runtime.


2. So there are these 'SDKs' that people mention? What is in them? 
How are they built? How are they updated? Who maintains them and how 
can we 'verify' in the 'trust and verify' method (aka source code, 
build flags, build system).


Confusingly, SDK has two meanings.

First, the SDK is an alternate version of the runtime intended for 
developers. The runtime normally used by users is the "platform" 
runtime and the runtime for developers is the SDK. The SDK adds 
developer tools like gdb, valgrind, etc. For example, GNOME 
applications usually run against the org.gnome.Platform runtimes, but 
you might need to tell them to use org.gnome.Sdk instead if you need to 
debug something.


Second, there is freedesktop-sdk, which is the name of the project that 
produces the base runtime that is the de facto default runtime that 
most Flatpak applications use. Both the GNOME and KDE runtimes are 
based on freedesktop-sdk. (The Fedora runtime is a notable exception in 
that it is mostly independent of freedesktop-sdk, with everything built 
from Fedora RPMs instead.)


The runtimes are maintained in places like [1] and [2] and [3] and [4] 
by friendly neighborhood open source people, so it's easy to check what 
they contain. They are built in different ways. [1] and [2] are built 
using Buildstream. [3] is built using flatpak-builder. [4] is built 
using modulemd (but that will have to change due to failure of Fedora 
modularity). So these are three quite different ways of building 
runtimes.


I'm familiar with the Buildstream runtimes. For source code, there are 
references to tarballs or git repos in each Buildstream element. For 
build flags, the freedesktop and GNOME runtimes use build flags based 
on Fedora's build flags [5] with some adjustments (there are no GCC 
specs, GCC is configured a bit differently than ours). As far as 
verification, I guess you want to look at build logs? Unfortunately I'm 
not smart enough to do this reliably anymore, as Buildstream likes to 
reuse cached builds and I don't know how to see logs for these builds. 
:( It's a problem. But for at least freedesktop-sdk and GNOME, you can 
see *some* build logs by looking at the CI artifacts.


[1] https://gitlab.com/freedesktop-sdk/freedesktop-sdk
[2] https://gitlab.gnome.org/GNOME/gnome-build-meta
[3] https://invent.kde.org/packaging/flatpak-kde-runtime
[4] https://src.fedoraproject.org/flatpaks/flatpak-runtime/
[5] 
https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/blob/master/include/flags.yml


I think a FAQ around these and others would probably cut down a lot 
of the uncertainty and doubt people feel.


Probably, but I'm not going to volunteer to help with that. :) There is 
[6], but it's pretty basic and doesn't answer your questions.


[6] https://flatpak.org/faq/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Michael Catanzaro]

On Mon, Jun 5 2023 at 01:05:25 PM -0500, Chris Adams 
 wrote:

It's layered, but from what I understand, an upper layer depends on a
specific build of a lower layer.  So using the up-thread example, if
there's a security update to zlib, the lower layer can rebuild to pick
it up, but until the upper layer (like say LO) also rebuilds on top of
the new lower layer, they'll be running on the old version.


Well, *generally* that is entirely untrue. But sometimes it really is 
true.


That's the simple answer. Apologies for turning this into an essay, but 
there's no simple way to explain this. There are two different 
considerations here.


Point 1:

TL;DR what Adam Williamson already said is correct.

Flatpak itself only knows about two layers: the runtime and the 
application. You do have to rebuild the application to use a new 
*major* version of the runtime (comparable to new major versions of 
Fedora), but not for normal updates of that runtime. Let's 
hypothetically say that your app is using the GNOME 44 runtime and 
there is a bug in the zlib provided by the runtime. You do not need to 
rebuild your app for users to get the new zlib. However, let's say your 
application is instead using the GNOME 42 runtime, which is end of life 
and won't receive any further updates. To get the updated zlib, the 
application has to update to the newer GNOME 44 or 43 runtime, and 
users will suffer from the zlib bug until it does so.


You can think of different versions of the runtimes as entirely 
different runtimes: org.gnome.Platform/x86_64/42, 
org.gnome.Platform/x86_64/43, org.gnome.Platform/x86_64/44. Each 
runtime receives regular updates independently from your application, 
but you have to update your application to switch between major 
versions. It's a compromise between updating too much and breaking your 
app, vs. updating too little and leaving users to suffer from bugs and 
security issues.


(Compromise is a theme of Flatpak: the split between runtime vs. 
application is also a compromise between which dependencies are updated 
by the runtime maintainers, comparable to traditional distribution 
maintenance, vs. which dependencies are bundled and have to be updated 
by application maintainers, at the mercy of the app developers' 
attentiveness.)


Point 2:

But now, to make things more complicated, sometimes runtimes and 
applications are *themselves* built from different layers. Flatpak 
itself doesn't know about these layers, and most Flatpak users don't 
know about it either, and I wouldn't have even mentioned it here except 
for your comment, but when you build things this way, you really do 
have to rebuild the upper layer to update the lower layer. This is why 
I couldn't say your comment was entirely incorrect.


Let's start with runtimes. For example, the GNOME runtimes 
org.gnome.Platform are based on the freedesktop-sdk runtimes 
org.freedesktop.Platform. zlib is actually maintained as part of the 
freedesktop-sdk, so we do not have our own GNOME packaging for zlib: 
it's all inherited from freedesktop-sdk. We do have to manually update 
the GNOME runtime to use a newer version of freedesktop-sdk. That is, 
when we update the zlib element in freedesktop-sdk, users do not 
actually receive the newer zlib until we update the freedesktop-sdk 
element in the GNOME runtime. That happens regularly, but it does 
introduce delay. The GNOME and KDE runtimes are both based on 
freedesktop-sdk, so these are layered runtimes. The freedesktop-sdk 
runtime is not based on anything else. Then the Fedora runtimes are the 
only runtimes I'm aware of that are not based on freedesktop-sdk. So 
some runtimes are layered, and some are not.


Now, most applications are just a single layer, but some include a 
"base app" which is basically a way for multiple applications to share 
the same set of bundled dependencies between themselves. Most 
applications do not use base apps, but if you do, then you do need to 
rebuild the application in order to update the dependencies from the 
base app. I think Flathub *could* theoretically do that for you 
automatically, but I've asked and I'm told it doesn't. What do base 
apps look like? I searched Flathub for "base" [1] and it looks like 
base apps are mostly used for web engines. For example, there is an 
io.qt.qtwebengine.BaseApp and that seems to be how Flathub applications 
are expected to use QtWebEngine. This means that apps using QtWebEngine 
need to be careful to monitor for updates and rebuild as required, or 
else users will wind up using old versions. This is not great, but at 
least it's somewhat better than manually bundling your own QtWebEngine. 
(In contrast, WebKitGTK is part of the GNOME runtime, so applications 
don't have to worry about updating it and can trust that the runtime 
maintainers will handle that.)


Conclusion:

* Runtime maintainers are responsible for updating dependencies that 
are components of the runtime (including freedesktop-sdk)
* 

Re: LibreOffice packages

[Mattia Verga via devel]

Il 05/06/23 19:51, Roberto Ragusa ha scritto:
> On 6/5/23 19:13, Demi Marie Obenour wrote:
>
>> Are you willing to do the packaging work?  Asking upstream to create
>> packages for every distribution is not reasonable.
> I would never want upstream to do packaging, as experience teaches,
> they would certainly do it wrong.
> Packaging and integration is a job for the distribution; it is their
> added value. Otherwise, what's the meaning of a distribution, if
> the system is composed by a minimal booting image on which you
> add upstream generated blobs?
>
> Sorry, but the common "why do not do it yourself?" objection is not
> the correct way to address my point. As a "consumer" (even if,
> not paying) I am just expressing my idea about what I would like or not.
> The "producers" (Fedora/RH) can take note, or ignore the feedback.
> Their luck will, at the end of the day, depend on the merit of
> their choices.
> Anyway, yes, I've considered becoming a Fedora packager, I've started
> the process and then got discouraged by the abundant bureaucracy.
> And these kinds of threads do not help in regaining some enthusiasm in
> resuming the process.
>
> Regards.
>
Hey Roberto, let me know if there's something specific where I can help 
you in becoming a Fedora packager, if you're interested. It's a little 
hard at the beginning, but then you'll find out that once you get the 
basis it's really easy (if the software you're trying to package doesn't 
require some weird thing to be built, of course). Feel free to write me 
directly or to chat with me in Matrix (I'm not often in chat, though).

Mattia

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Chris Adams]

Once upon a time, Adam Williamson  said:
> On Mon, 2023-06-05 at 13:05 -0500, Chris Adams wrote:
> > It's layered, but from what I understand, an upper layer depends on a
> > specific build of a lower layer.  So using the up-thread example, if
> > there's a security update to zlib, the lower layer can rebuild to pick
> > it up, but until the upper layer (like say LO) also rebuilds on top of
> > the new lower layer, they'll be running on the old version.
> 
> No, I don't believe that's accurate. It's more of a major/minor thing.
> The 'lower layer' can be updated with bug and security fixes without
> any rebuild or change needed to 'upper layers'. You only need a rebuild
> if the 'lower layer' is doing a "major" incompatible update (this is
> something the lower layer is in charge of defining).

Okay, that's good to know.  I thought I got the layer description from
this list, but maybe I just misread (or read someone else's mistaken
understanding).  Sorry for any confusion.

-- 
Chris Adams 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Adam Williamson]

On Mon, 2023-06-05 at 19:51 +0200, Roberto Ragusa wrote:
> On 6/5/23 19:13, Demi Marie Obenour wrote:
> 
> > Are you willing to do the packaging work?  Asking upstream to create
> > packages for every distribution is not reasonable.
> 
> I would never want upstream to do packaging, as experience teaches,
> they would certainly do it wrong.
> Packaging and integration is a job for the distribution; it is their
> added value. Otherwise, what's the meaning of a distribution, if
> the system is composed by a minimal booting image on which you
> add upstream generated blobs?

This is really the heart of the question, and it's an interesting one.

The idea that the distribution's job is to package up everything you
might possibly want to use on your system is a very old one that goes
back to the days before having an internet connection was the norm, let
alone having several hundred megabits a second on tap at all times.

It's a good model that has served us well for a long time and helped us
produce something which a lot of people like and enjoy using, which is
a great thing. But it's also a model that's showing stress in several
ways, and which we can feasibly re-evaluate. Here are some of them that
I can think of:

1. There's a lot more software out there. Here's absolutely everything
in the first combined Fedora release (after the core/extras split
ended):

https://archives.fedoraproject.org/pub/archive/fedora/linux/releases/7/Everything/x86_64/os/Fedora/

there are, by my count, 9330 binary packages there. That's a lot! But,
per https://github.com/asamalik/counting-fedora-packages , even in 2019
we had 49,464 binary packages, and probably the number has gone up
further since then. We're now packaging 5x as much stuff as we did in
the olde days. Yet, arguably, it's *less* likely than it was in the
Fedora 7 days that you can find everything you actually need in the
distribution repository. So, to me, that's one indication of strain in
the model.

2. There's less buy-in to the distribution model throughout the F/OSS
ecosystem. This is indicated by the existence of flatpaks and snaps,
and upstreams which indicate a preference for those. It's also
indicated by the existence and popularity of non-distribution software
repositories (often tied to languages): pypi, rubygems and so on (and,
again, upstreams which express no interest in supporting the downstream
distribution model).

3. The model is less directly in the interests of our corporate
sponsor. Red Hat's business model and goals have changed quite a lot
since the olde days. Even after the RHL -> RHEL/Fedora split that
created Fedora, RH was fundamentally still in the "everything-
distribution business". RH had a clear direct interest in Fedora being
an everything-distribution, because RHEL needed to be one too. That was
what customers were buying, though possibly with a slightly different
focus on what they actually wanted to do with it than Fedora users, and
RHEL was more or less the only thing Red Hat sold. Nowadays, the
picture is more complicated. RHEL is still a huge business for Red Hat,
but it has other lines of business too. RHEL has also been going more
aggressively down the "not an everything-distribution any more" path
than Fedora has. RHEL these days does not have anything like as much
stuff in it as Fedora does, and RHEL customers - AIUI - are
increasingly less likely than before to be buying an everything-OS for
traditional computers, and increasingly more likely to be doing
something more complicated and hybrid than that.

The case in point is a pretty solid example of that: it is fairly
inarguable that it's less directly important to RH that Fedora contains
an RPM-packaged traditional office suite in 2023 than it was in 2007.
This is a complicated reality to navigate, but it *is* a reality, and
it's one we're gonna have to figure out.

Fedora is still immensely valuable to Red Hat, but it's not necessarily
immensely valuable to Red Hat *as an everything-distribution*
(disclaimer: this is my personal interpretation, not RH policy, I'm not
a person who sets RH policy - ask Matt or Josh for that :>). So what
does that mean to us as Fedora? Does it mean we need to work out a
different way to be an everything-distribution, or does it mean we need
to figure out a different thing to be? I don't think RH wants to or can
dictate the outcome of that discussion, but at the same time, we have
to recognize RH does not have the same motivation to sponsor Fedora
maintenance of every possible thing you can deploy on a computer to the
same extent as it did in the past.

> Sorry, but the common "why do not do it yourself?" objection is not
> the correct way to address my point. As a "consumer" (even if,
> not paying) I am just expressing my idea about what I would like or not.
> The "producers" (Fedora/RH) can take note, or ignore the feedback.
> Their luck will, at the end of the day, depend on the merit of
> their choices.

Yup, and this is totally fair. 

Re: LibreOffice packages

[Adam Williamson]

On Mon, 2023-06-05 at 13:05 -0500, Chris Adams wrote:
> Once upon a time, Stephen Smoogen  said:
> > 1. What is a flatpak and what does it mean to have an application in it? Is
> > it everything bundled in it or does it use layers?
> 
> It's layered, but from what I understand, an upper layer depends on a
> specific build of a lower layer.  So using the up-thread example, if
> there's a security update to zlib, the lower layer can rebuild to pick
> it up, but until the upper layer (like say LO) also rebuilds on top of
> the new lower layer, they'll be running on the old version.

No, I don't believe that's accurate. It's more of a major/minor thing.
The 'lower layer' can be updated with bug and security fixes without
any rebuild or change needed to 'upper layers'. You only need a rebuild
if the 'lower layer' is doing a "major" incompatible update (this is
something the lower layer is in charge of defining).

For e.g., in my `flatpak list` right now, I have these:

Name  Application ID
Version Branch  Origin  Installation

Fedora Platform   org.fedoraproject.Platform38  
f38 fedora  system
Freedesktop Platform  org.freedesktop.Platform  
22.08.12.1  22.08   flathub system

the "branch" there is the 'major' version. App flatpaks will say they
require "f38" Fedora platform or "22.08" Freedesktop platform, and
there can be updates within those branches (e.g. maybe I'll get
22.08.12.2 or 22.08.13.1 of the Freedesktop platform as an update)
without the app flatpaks changing. But for an app flatpak to 'rebase'
to "f39" or "23.04" (or whatever the next version is gonna be, I don't
actually know), *that* would require a rebuild.
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Stephen Smoogen]

On Mon, 5 Jun 2023 at 14:10, Steve Grubb  wrote:

> On Monday, June 5, 2023 1:37:24 PM EDT Stephen Smoogen wrote:
> > On Mon, 5 Jun 2023 at 13:32, Michael Catanzaro 
> >
> > wrote:
> > > On Mon, Jun 5 2023 at 01:13:50 PM -0400, Demi Marie Obenour
> > >
> > >  wrote:
> > > > zlib should be added to the standard freedesktop.org runtime if it
> is
> > > > not
> > > > already included.
> > >
> > > zlib is included in both freedesktop-sdk and also GNOME runtimes, so
> > > nobody should need to bundle it.
> > >
> > > Michael
> >
> > The problem I see in these conversations are:
> >
> > 1. What is a flatpak and what does it mean to have an application in it?
> Is
> > it everything bundled in it or does it use layers?
> > 2. So there are these 'SDKs' that people mention? What is in them? How
> are
> > they built? How are they updated? Who maintains them and how can we
> > 'verify' in the 'trust and verify' method (aka source code, build flags,
> > build system).
> >
> > I think a FAQ around these and others would probably cut down a lot of
> the
> > uncertainty and doubt people feel.
>
> Yes. And how does it's security model work?
>
> What is the root of trust? Are they signed by a Fedora key that I already
> have? How can we verify it's integrity? Once installed, how do I verify
> it's
> integrity? How do I check if anything has been modified? Does it integrate
> well with SE Linux, IMA, fapolicyd, or openscap? On a locked down system,
> are
> there sysctls  that I have undo such as user namespaces? If an app
> coredumps,
> does a problem report get generated? Who gets it?
>
>
How can I tell what the security policy that the upstream chose to
implement for me.



> -Steve
>
>
>

-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Robert Marcano via devel]

On 6/5/23 2:05 PM, Chris Adams wrote:

Once upon a time, Stephen Smoogen  said:

1. What is a flatpak and what does it mean to have an application in it? Is
it everything bundled in it or does it use layers?


It's layered, but from what I understand, an upper layer depends on a
specific build of a lower layer.  So using the up-thread example, if
there's a security update to zlib, the lower layer can rebuild to pick
it up, but until the upper layer (like say LO) also rebuilds on top of
the new lower layer, they'll be running on the old version.



These layers (runtimes and addons) can be updated and applications take 
the changes after being restarted, no nee to rebuild. The rebuild is 
only needed if the library is bundled with the applications because it 
isn't part of the chosen runtime or addons.


Runtimes contains aren´t and entire Linux distribution, so applications 
frequently need  to bundle libraries. Sites like flathub should add a 
way to check bundled dependencies in order to notify packagers of 
updating an application. Like server container need security audit tools.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Steve Grubb]

On Monday, June 5, 2023 1:37:24 PM EDT Stephen Smoogen wrote:
> On Mon, 5 Jun 2023 at 13:32, Michael Catanzaro 
> 
> wrote:
> > On Mon, Jun 5 2023 at 01:13:50 PM -0400, Demi Marie Obenour
> > 
> >  wrote:
> > > zlib should be added to the standard freedesktop.org runtime if it is
> > > not
> > > already included.
> > 
> > zlib is included in both freedesktop-sdk and also GNOME runtimes, so
> > nobody should need to bundle it.
> > 
> > Michael
> 
> The problem I see in these conversations are:
> 
> 1. What is a flatpak and what does it mean to have an application in it? Is
> it everything bundled in it or does it use layers?
> 2. So there are these 'SDKs' that people mention? What is in them? How are
> they built? How are they updated? Who maintains them and how can we
> 'verify' in the 'trust and verify' method (aka source code, build flags,
> build system).
> 
> I think a FAQ around these and others would probably cut down a lot of the
> uncertainty and doubt people feel.

Yes. And how does it's security model work?

What is the root of trust? Are they signed by a Fedora key that I already 
have? How can we verify it's integrity? Once installed, how do I verify it's 
integrity? How do I check if anything has been modified? Does it integrate 
well with SE Linux, IMA, fapolicyd, or openscap? On a locked down system, are 
there sysctls  that I have undo such as user namespaces? If an app coredumps, 
does a problem report get generated? Who gets it?

-Steve

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Chris Adams]

Once upon a time, Stephen Smoogen  said:
> 1. What is a flatpak and what does it mean to have an application in it? Is
> it everything bundled in it or does it use layers?

It's layered, but from what I understand, an upper layer depends on a
specific build of a lower layer.  So using the up-thread example, if
there's a security update to zlib, the lower layer can rebuild to pick
it up, but until the upper layer (like say LO) also rebuilds on top of
the new lower layer, they'll be running on the old version.

-- 
Chris Adams 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Roberto Ragusa]

On 6/5/23 19:13, Demi Marie Obenour wrote:


Are you willing to do the packaging work?  Asking upstream to create
packages for every distribution is not reasonable.


I would never want upstream to do packaging, as experience teaches,
they would certainly do it wrong.
Packaging and integration is a job for the distribution; it is their
added value. Otherwise, what's the meaning of a distribution, if
the system is composed by a minimal booting image on which you
add upstream generated blobs?

Sorry, but the common "why do not do it yourself?" objection is not
the correct way to address my point. As a "consumer" (even if,
not paying) I am just expressing my idea about what I would like or not.
The "producers" (Fedora/RH) can take note, or ignore the feedback.
Their luck will, at the end of the day, depend on the merit of
their choices.
Anyway, yes, I've considered becoming a Fedora packager, I've started
the process and then got discouraged by the abundant bureaucracy.
And these kinds of threads do not help in regaining some enthusiasm in
resuming the process.

Regards.

--
   Roberto Ragusamail at robertoragusa.it
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Stephen Smoogen]

On Mon, 5 Jun 2023 at 13:32, Michael Catanzaro 
wrote:

> On Mon, Jun 5 2023 at 01:13:50 PM -0400, Demi Marie Obenour
>  wrote:
> > zlib should be added to the standard freedesktop.org runtime if it is
> > not
> > already included.
>
> zlib is included in both freedesktop-sdk and also GNOME runtimes, so
> nobody should need to bundle it.
>
> Michael
>
>
The problem I see in these conversations are:

1. What is a flatpak and what does it mean to have an application in it? Is
it everything bundled in it or does it use layers?
2. So there are these 'SDKs' that people mention? What is in them? How are
they built? How are they updated? Who maintains them and how can we
'verify' in the 'trust and verify' method (aka source code, build flags,
build system).

I think a FAQ around these and others would probably cut down a lot of the
uncertainty and doubt people feel.


-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Michael Catanzaro]

On Mon, Jun 5 2023 at 01:13:50 PM -0400, Demi Marie Obenour 
 wrote:
zlib should be added to the standard freedesktop.org runtime if it is 
not

already included.


zlib is included in both freedesktop-sdk and also GNOME runtimes, so 
nobody should need to bundle it.


Michael

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Demi Marie Obenour]

On 6/5/23 12:13, Roberto Ragusa wrote:
> On 6/5/23 09:35, Dominik 'Rathann' Mierzejewski wrote:
> 
>> "easily install from Flathub" brings us closer to Windows where you
>> "easily" install software from random places on the Internet and they
>> bring their own bundled outdated versions of libraries. Flatpaks have
>> the added downside of not integrating well with the OS on top of the
>> bloat they bring. No, thank you. I'd rather have proper well-integrated
>> RPMs installed from official distro repos.
> 
> Unfortunately very few people still understand the value of using
> system libraries instead of bundling one hundred of them in each package.
> The day a zlib vulnerability is discovered, instead of just updating
> a 50k lib rpm (and restart apps, or maybe reboot), you have to update
> 30 apps, each of them sized at 50MB, and including possibly badly patched
> versions of the lib etc. (good luck knowing which app is affected,
> when the fix will be available, ...).

zlib should be added to the standard freedesktop.org runtime if it is not
already included.

> There is a disturbing trend to bundling everything, which comes from
> environments with no shared libraries (Android) or from languages
> that do not do dynamic linking (golang).
Bundling is the norm on Windows and macOS, and is required on Android
and iOS.  Cross-platform projects like LibreOffice, Firefox, and OBS
already have to deal with updating bundled dependencies.

> Whatever is not in a rule-conforming rpm, is not correctly packaged,
> in my opinion.

Are you willing to do the packaging work?  Asking upstream to create
packages for every distribution is not reasonable.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Mattia Verga via devel]

Il 05/06/23 17:00, Michael J Gruber ha scritto:
> I've taken up hyphen and the orphaned hyphen-* packages. They don't appear to 
> be high maintenance, but co-admins welcome, of course. Similarly, feel free 
> to admin as co-admin to other hyphen-* in case something needs coordinations. 
> The language packages are basically a "cp" in "%install", though, and nothing 
> to build.

Yesterday I've taken hyphen-it, as well as mythes-it, and I've asked to 
be added as co-admin of hunspell-it.

I've also updated hyphen-it and mythes-it as the dictionaries were 
outdated. As far as I can see, every language points to different 
sources: I wonder if it would be easier to maintain if we switch to 
sources provided by LO at https://github.com/LibreOffice/dictionaries so 
that we'll have a single specfile and source tarball with multiple 
subpackages, one for each language.

The only problem is that in LO repository only the .dat file for 
thesaurus is provided, but the .idx file is missing. For italian 
language I had to generate the .idx file myself using 
http://proofingtoolgui.org/ and provide the sources in custom repository 
(https://pagure.io/dizionario_italiano). I couldn't find any CLI tool to 
do that.

Mattia
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Roberto Ragusa]

On 6/5/23 09:35, Dominik 'Rathann' Mierzejewski wrote:


"easily install from Flathub" brings us closer to Windows where you
"easily" install software from random places on the Internet and they
bring their own bundled outdated versions of libraries. Flatpaks have
the added downside of not integrating well with the OS on top of the
bloat they bring. No, thank you. I'd rather have proper well-integrated
RPMs installed from official distro repos.


Unfortunately very few people still understand the value of using
system libraries instead of bundling one hundred of them in each package.
The day a zlib vulnerability is discovered, instead of just updating
a 50k lib rpm (and restart apps, or maybe reboot), you have to update
30 apps, each of them sized at 50MB, and including possibly badly patched
versions of the lib etc. (good luck knowing which app is affected,
when the fix will be available, ...).

There is a disturbing trend to bundling everything, which comes from
environments with no shared libraries (Android) or from languages
that do not do dynamic linking (golang).

Whatever is not in a rule-conforming rpm, is not correctly packaged,
in my opinion.

Regards.

--
   Roberto Ragusamail at robertoragusa.it
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Michael J Gruber]

I've taken up hyphen and the orphaned hyphen-* packages. They don't appear to 
be high maintenance, but co-admins welcome, of course. Similarly, feel free to 
admin as co-admin to other hyphen-* in case something needs coordinations. The 
language packages are basically a "cp" in "%install", though, and nothing to 
build.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Peter Robinson]

On Mon, Jun 5, 2023 at 3:39 PM Vitaly Zaitsev via devel
 wrote:
>
> On 05/06/2023 13:54, Josh Boyer wrote:
> > I'm not sure what led you to the conclusion that IBM has anything to
> > do with this or that "they fired a lot of good engineers".  I don't
> > see evidence of either being the case.
> >
> > Please don't state your own assumptions as facts.
>
> https://news.ycombinator.com/item?id=35687687

HackerNews is not fact, also RH is a subsidiary not a unit with in IBM
so it has it's own management, CEO etc.

This thread is also widely off topic now.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Vitaly Zaitsev via devel]

On 05/06/2023 13:54, Josh Boyer wrote:

I'm not sure what led you to the conclusion that IBM has anything to
do with this or that "they fired a lot of good engineers".  I don't
see evidence of either being the case.

Please don't state your own assumptions as facts.


https://news.ycombinator.com/item?id=35687687

--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Kamil Paral]

On Sat, Jun 3, 2023 at 2:43 PM Michael Catanzaro 
wrote:

> We cannot ship anything from Flathub because
> FESCo will not allow it. I don't *like* this FESCo requirement, but I
> also don't expect that to change.


I haven't studied that ruling, but perhaps the assumption was that said
software is available both on Flathub and in Fedora? If LO disappears from
Fedora, I'd consider it a good argument for re-evaluating that decision.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[stan via devel]

On Sat, 03 Jun 2023 08:45:28 -0500
Michael Catanzaro  wrote:

> I'm not going to defend callous layoffs during a time when Red Hat is 
> earning big profits. And I have no clue what our corporate overloads 

It is a fact of corporate life that if you are a manager and want to be
promoted, cutting head count / costs, doing more with less resources, is
a great way to move up the ladder.  It shows the people above you that
you have the right attitude.  No one makes it to the executive level
without a certain ruthlessness.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Josh Boyer]

On Sat, Jun 3, 2023 at 3:56 AM Vitaly Zaitsev via devel
 wrote:
>
> On 03/06/2023 02:46, Leslie Satenstein via devel wrote:
> > No LibreOffice, no continuation with Fedora. LO better be there with
> > F39. Without it, all you have is Firefox. It is not enough to keep
> > Fedora Diehards from jumping to another popular distribution.
>
> Yes, Fedora is dying. Slow, but imminent. IBM doesn't want to keep it in
> a good condition, so they fired a lot of good engineers. It's very sad.
> I have been using it for years.

I'm not sure what led you to the conclusion that IBM has anything to
do with this or that "they fired a lot of good engineers".  I don't
see evidence of either being the case.

Please don't state your own assumptions as facts.

josh
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Artur Frenszek-Iwicki]

> I've taken ownership of libreoffice for the time being, at least to keep the 
> lights
> on. Co-maintainers, as always, welcome.

Don't know how much time I'll be able to contribute, but you can count me in.
As Mattia suggested, I think it might be a good idea to set up libreoffice-sig.

A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Daniel P . Berrangé]

On Sat, Jun 03, 2023 at 09:09:57AM +0200, Peter Boy wrote:
> > Am 03.06.2023 um 02:06 schrieb Sandro :
> > What will we ship in Fedora if we were to follow in Red Hat's
> > footsteps? LibreOffice Flatpak? That may prove to be the straw
> > that broke the camel's back. As I said before, I don't want to
> > to reiterate the Flatpak vs. RPM discussion. But maybe that
> > topic needs to be picked up and discussed, so we get a better
> > understanding of where this will leave us.
> 
> Instead of Flatpak I would prefer to pick up the software directly
> from the project.

The LibreOffice Flatpak *is* provided directly by the upstream
Document Foundation (LibreOffice) project.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Dominik 'Rathann' Mierzejewski]

On Saturday, 03 June 2023 at 14:42, Michael Catanzaro wrote:
[...]
> My $0.02: maintaining complex desktop applications as part of the operating
> system requires significant effort and produces low value for users when you
> can easily install that app from Flathub instead. (It *especially* doesn't

"easily install from Flathub" brings us closer to Windows where you
"easily" install software from random places on the Internet and they
bring their own bundled outdated versions of libraries. Flatpaks have
the added downside of not integrating well with the OS on top of the
bloat they bring. No, thank you. I'd rather have proper well-integrated
RPMs installed from official distro repos.

Regards,
Dominik
-- 
Fedora   https://fedoraproject.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Mattia Verga via devel]

Il 02/06/23 09:22, Jiri Vanek ha scritto:
> Damn thats a long list.
>
>
Indeed. I can help and pick up a couple of packages, but what about the 
hunspell*, hyphen*, mythes*? I think those will require more work than 
what a volunteer packager can bring. Yet, I suspect dropping them will 
blow up quite a few things.

Shall we set up a libreoffice-sig to coordinate community efforts in LO 
packaging?

Mattia

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[PGNet Dev]

On Fri, Jun 2, 2023, 9:09 AM Matthew Miller mailto:mat...@fedoraproject.org>> wrote:

I think this sentiment is getting ahead of things. This thread _is_ that

effort.


Yes, but. In general, a better approach is to say "we plan on orphaning the packages 
in $timeframe".


...


RH, for the moment is still represented as on the DocFoundation's Advisory 
Board,

  
https://wiki.documentfoundation.org/TDF/Advisory_Board#Composition_of_the_Advisory_Board
  https://www.documentfoundation.org/advisory-board/

Has there been any indication yet as to their withdrawal there? or not?

Dev comms with devs is one approach aspect of engagement with LO.

Engagement at the organizational level is another.
If RH's organizational support, or lack thereof, is now a risk -- existential or 
not -- then perhaps spreading that risk across other orgs' interests & support 
has possible value.

Do any of the Fedora Project guidelines -- particularly any restrictions by 
RH's legal -- prevent increased/direct engagement with the DF's 
governance/advisory groups?

Dev list is probly also not the right place for that discussion.
BUT, it's where the immediate, legitimate discussion IS being had.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Robert Marcano via devel]

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-libreoffice/ <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 <mailto:mcla...@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 

Re: LibreOffice packages

[Ben Cotton]

On Fri, Jun 2, 2023, 9:09 AM Matthew Miller 
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)

>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Michael Catanzaro]

On Sat, Jun 3 2023 at 09:56:40 AM +0200, Vitaly Zaitsev via devel 
 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.


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Michael Catanzaro]

On Sat, Jun 3 2023 at 10:26:07 AM -, John Iliopoulos 
 wrote:

Hello,

While i completely understand why you do this i do think that it is 
important for desktop/workstation oriented devices to have some 
optional access to Office directly from the image file. Have you 
considered shipping the LibreOffice flatpak via the ISO much like 
Fedora Silverblue does with various other applications?


This is the first time i reply to a mailing list so i hope i have not 
done anything wrong.


Hi. Welcome to the list. You haven't done anything wrong.

For Fedora Workstation, the mid-term plan is to ship all preinstalled 
apps as Fedora Flatpaks. We cannot ship anything from Flathub because 
FESCo will not allow it. I don't *like* this FESCo requirement, but I 
also don't expect that to change. Accordingly, since Fedora Flatpaks 
are built from Fedora RPMs, maintaining the LibreOffice RPMs is 
essential to keep LibreOffice preinstalled. (I think that applies to 
Silverblue as well?)


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


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[John Iliopoulos]

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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Peter Boy]

> Am 03.06.2023 um 09:56 schrieb Vitaly Zaitsev via devel 
> :
> 
> 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
p...@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


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Vitaly Zaitsev via devel]

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.


--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Vitaly Zaitsev via devel]

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.

--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Mattia Verga via devel]

> 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Samuel Sieb]

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.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Peter Boy]

> Am 03.06.2023 um 02:06 schrieb Sandro :
> 
> 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
p...@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


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Peter Boy]

> Am 03.06.2023 um 05:11 schrieb Ralph Bromley :
> 
> 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
p...@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


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Ralph Bromley]

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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Ralph Bromley]

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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Leslie Satenstein via devel]

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., Sandro 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-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue
  
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Sandro]

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-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue