[EPEL-devel] Re: Cannot run fedpkg mockbuild for epel9 on f38

[Todd Zullinger]

bradb...@seanet.com wrote:
> I misspelled centos as contos  Now fedpkg mockbuild works  with the proper 
> links:
> 
>>ls -l $HOME/.config/mock
> total 8
> lrwxrwxrwx. 1 bradbell bradbell 41 Jun  3 19:09 epel-8-x86_64.cfg -> 
> /etc/mock/centos-stream+epel-8-x86_64.cfg
> lrwxrwxrwx. 1 bradbell bradbell 41 Jun  3 19:09 epel-9-x86_64.cfg -> 
> /etc/mock/centos-stream+epel-9-x86_64.cfg

That's not what you want for epel though.  It will build
against centos-stream rather than rhel/alma/rocky, i.e. the
stable EL.  While it might appear to work, it will
inevitably build packages which link against the wrong
versions of libraries, pick up bogus dependencies, etc.

You want to pick one of the *+epel-[89]-x86_64.cfg config
files.

I thought that previous fedpkg or mock releases printed a
large banner which explained this a bit and linked to
further details?  I would have thought that was still in
place, but perhaps not.

-- 
Todd


signature.asc
Description: PGP signature
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[EPEL-devel] Re: Cannot run fedpkg mockbuild for epel9 on f38

[bradbell]

I misspelled centos as contos  Now fedpkg mockbuild works  with the proper 
links:

>ls -l $HOME/.config/mock
total 8
lrwxrwxrwx. 1 bradbell bradbell 41 Jun  3 19:09 epel-8-x86_64.cfg -> 
/etc/mock/centos-stream+epel-8-x86_64.cfg
lrwxrwxrwx. 1 bradbell bradbell 41 Jun  3 19:09 epel-9-x86_64.cfg -> 
/etc/mock/centos-stream+epel-9-x86_64.cfg
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[EPEL-devel] Fedora EPEL 9 updates-testing report

[updates]

The following Fedora EPEL 9 Security updates need testing:
 Age  URL
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-eacf1a60fb   
python-flask-restx-1.1.0-1.el9
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-5b5f974a90   
sympa-6.2.72-2.el9
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-867723f541   
cpp-httplib-0.12.5-2.el9


The following builds have been pushed to Fedora EPEL 9 updates-testing

bgpq4-1.10-1.el9
python-chai-1.1.2-25.el9
python-pyside2-5.15.7-2.el9
rust-base64ct-1.6.0-1.el9
rust-hex-literal-0.4.1-1.el9
rust-hex-literal0.3-0.3.4-1.el9
rust-password-hash-0.5.0-1.el9
rust-password-hash0.3-0.3.2-1.el9
rust-password-hash0.4-0.4.2-1.el9
rust-pbkdf2-0.12.1-1.el9
rust-pbkdf2_0.10-0.10.1-1.el9
rust-pbkdf2_0.11-0.11.0-1.el9
rust-pem-rfc7468-0.7.0-1.el9
rust-pem-rfc7468_0.2-0.2.4-1.el9
rust-salsa20-0.10.2-1.el9
rust-salsa20_0.9-0.9.0-1.el9
rust-scrypt-0.11.0-1.el9
rust-scrypt0.8-0.8.1-1.el9

Details about builds:



 bgpq4-1.10-1.el9 (FEDORA-EPEL-2023-186a2e63e1)
 Automate BGP filter generation based on routing database information

Update Information:

# bgpq4 1.10   - Add GitHub workflow for basic unit tests  - Add macOS to CI
builds  - Accept `-3` as a no-op for `bgpq3` compatibility  - Add support for
Nokia SR Linux IP prefix lists / ACL filters  - Add a line to usage for SR Linux
`-n2` option  - Added container build GitHub workflow

ChangeLog:

* Sun Jun  4 2023 Robert Scheck  1.10-1
- Upgrade to 1.10 (#2212107)

References:

  [ 1 ] Bug #2212107 - bgpq4-1.10 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2212107




 python-chai-1.1.2-25.el9 (FEDORA-EPEL-2023-de5528be1c)
 Easy to use mocking/stub/spy framework

Update Information:

Initial version for epel9

ChangeLog:

* Fri Jan 20 2023 Fedora Release Engineering  - 
1.1.2-25
- Rebuilt for https://fedoraproject.org/wiki/Fedora_38_Mass_Rebuild
* Fri Jul 22 2022 Fedora Release Engineering  - 
1.1.2-24
- Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild
* Mon Jun 13 2022 Python Maint  - 1.1.2-23
- Rebuilt for Python 3.11
* Fri Jan 21 2022 Fedora Release Engineering  - 
1.1.2-22
- Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild
* Fri Jul 23 2021 Fedora Release Engineering  - 
1.1.2-21
- Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild
* Thu Jun  3 2021 Python Maint  - 1.1.2-20
- Rebuilt for Python 3.10
* Wed Jan 27 2021 Fedora Release Engineering  - 
1.1.2-19
- Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild

References:

  [ 1 ] Bug #2208062 - Please backport python-chai to EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2208062




 python-pyside2-5.15.7-2.el9 (FEDORA-EPEL-2023-a0e8ad600a)
 Python bindings for the Qt 5 cross-platform application and UI framework

Update Information:

Rebuild for updated clang.

ChangeLog:

* Fri Jun  2 2023 Richard Shaw  - 1:5.15.7-2
- Rebuild for Clang.




 rust-base64ct-1.6.0-1.el9 (FEDORA-EPEL-2023-ce7e56b35d)
 Pure Rust, constant-time implementation of Base64 (RFC 4648)

Update Information:

- Update the hex-literal crate to version 0.4.1. - Add a compat package for
version 0.3 of the hex-literal crate. - Import more RustCrypto packages into
EPEL 9.

ChangeLog:

* Sat Mar 11 2023 Fabio Valentini  - 1.6.0-1
- Update to version 1.6.0; Fixes RHBZ#2173450
* Fri Jan 20 2023 Fedora Release Engineering  - 
1.5.3-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_38_Mass_Rebuild
* Sat Dec 10 2022 Fabio Valentini  - 1.5.3-1
- Update to version 1.5.3; Fixes 

[EPEL-devel] Re: Cannot run fedpkg mockbuild for epel9 on f38

[bradbell]

I both suggestions above and they did not work. It is as if fedpkg is checking  
for the file and not accepting a link:

>ls -l $HOME/.config/mock/
total 8
lrwxrwxrwx. 1 bradbell bradbell 41 Jun  3 18:13 epel-8-x86_64.cfg -> 
/etc/mock/contos-stream+epel-8-x86_64.cfg
lrwxrwxrwx. 1 bradbell bradbell 41 Jun  3 18:13 epel-9-x86_64.cfg -> 
/etc/mock/contos-stream+epel-9-x86_64.cfg

>fedpkg mockbuild
Not downloading already downloaded CppAD-2023.0.tar.gz

setting SOURCE_DATE_EPOCH=1674950400
Wrote: /home/bradbell/fedora/cppad/cppad-2023.0-1.el9.src.rpm
ERROR: Could not find required config file: /etc/mock/epel-9-x86_64.cfg
ERROR: There are those alternatives:
ERROR: 
ERROR: [1] alma+epel-9-x86_64
ERROR: Use instead: mock -r alma+epel-9-x86_64 --resultdir 
/home/bradbell/fedora/cppad/results_cppad/2023.0/1.el9 --rebuild 
/home/bradbell/fedora/cppad/cppad-2023.0-1.el9.src.rpm 
ERROR: Builds against AlmaLinux 9 repositories, together with the official 
EPEL repositories.
ERROR: Project page: https://almalinux.org/
ERROR: Enable permanently by:
ERROR: $ ln -s /etc/mock/alma+epel-9-x86_64.cfg 
/home/bradbell/.config/mock/epel-9-x86_64.cfg
ERROR: 
ERROR: [2] centos-stream+epel-9-x86_64
ERROR: Use instead: mock -r centos-stream+epel-9-x86_64 --resultdir 
/home/bradbell/fedora/cppad/results_cppad/2023.0/1.el9 --rebuild 
/home/bradbell/fedora/cppad/cppad-2023.0-1.el9.src.rpm 
ERROR: Builds against CentOS Stream 9 repositories (some packages may be a 
bit ahead the Red Hat Enterprise Linux 9) together with the official EPEL 
repositories.
ERROR: Project page: https://www.centos.org/centos-stream/
ERROR: Enable permanently by:
ERROR: $ ln -s /etc/mock/centos-stream+epel-9-x86_64.cfg 
/home/bradbell/.config/mock/epel-9-x86_64.cfg
ERROR: 
ERROR: [3] rhel+epel-9-x86_64
ERROR: Use instead: mock -r rhel+epel-9-x86_64 --resultdir 
/home/bradbell/fedora/cppad/results_cppad/2023.0/1.el9 --rebuild 
/home/bradbell/fedora/cppad/cppad-2023.0-1.el9.src.rpm 
ERROR: Builds against Red Hat Enterprise Linux 9 repositories, together 
with the official EPEL repositories.
ERROR: This mimics what is done in the official EPEL build system, but you 
need a Red Hat subscription:
ERROR: https://rpm-software-management.github.io/mock/Feature-rhelchroots
ERROR: Enable permanently by:
ERROR: $ ln -s /etc/mock/rhel+epel-9-x86_64.cfg 
/home/bradbell/.config/mock/epel-9-x86_64.cfg
ERROR: 
ERROR: [4] rocky+epel-9-x86_64
ERROR: Use instead: mock -r rocky+epel-9-x86_64 --resultdir 
/home/bradbell/fedora/cppad/results_cppad/2023.0/1.el9 --rebuild 
/home/bradbell/fedora/cppad/cppad-2023.0-1.el9.src.rpm 
ERROR: Builds against Rocky Linux 9 repositories, together with the 
official EPEL repositories.
ERROR: Project page: https://rockylinux.org/
ERROR: Enable permanently by:
ERROR: $ ln -s /etc/mock/rocky+epel-9-x86_64.cfg 
/home/bradbell/.config/mock/epel-9-x86_64.cfg
ERROR: Mock config 'epel-9-x86_64' not found, see errors above.
Could not execute mockbuild: Failed to execute command.

___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[EPEL-devel] Fedora EPEL 7 updates-testing report

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-03b316a546   
qemu-2.0.0-5.el7
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-64b282dfaf   
sympa-6.2.72-2.el7


The following builds have been pushed to Fedora EPEL 7 updates-testing

bgpq4-1.10-1.el7
rust-1.70.0-1.el7

Details about builds:



 bgpq4-1.10-1.el7 (FEDORA-EPEL-2023-096ee6945f)
 Automate BGP filter generation based on routing database information

Update Information:

# bgpq4 1.10   - Add GitHub workflow for basic unit tests  - Add macOS to CI
builds  - Accept `-3` as a no-op for `bgpq3` compatibility  - Add support for
Nokia SR Linux IP prefix lists / ACL filters  - Add a line to usage for SR Linux
`-n2` option  - Added container build GitHub workflow

ChangeLog:

* Sun Jun  4 2023 Robert Scheck  1.10-1
- Upgrade to 1.10 (#2212107)

References:

  [ 1 ] Bug #2212107 - bgpq4-1.10 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2212107




 rust-1.70.0-1.el7 (FEDORA-EPEL-2023-eb7659144c)
 The Rust Programming Language

Update Information:

Update to Rust 1.70.0:  * Sparse by default for crates.io * `OnceCell` and
`OnceLock` * `IsTerminal` * Named levels of debug information * Enforced
stability in the `test` CLI * Stabilized APIs  See the [blog
post](https://blog.rust-lang.org/2023/06/01/Rust-1.70.0.html) and [release
notes](https://github.com/rust-lang/rust/releases/tag/1.70.0) for more details.

ChangeLog:

* Thu Jun  1 2023 Josh Stone  - 1.70.0-1
- Update to 1.70.0.
* Fri May  5 2023 Josh Stone  - 1.69.0-3
- Fix debuginfo with LLVM 16
* Mon May  1 2023 Josh Stone  - 1.69.0-2
- Build with LLVM 15 on Fedora 38+

References:

  [ 1 ] Bug #2211780 - rust-1.70.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2211780


___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Question regarding setuptools automatic discovery (pyproject.toml)

[Sandro]

Hi,

I ran into a build failure for a Python package that dropped setup.py in 
the latest update and uses pyproject.toml for metadata and setuptools.


The build failed due to 'error: Installed (but unpackaged) file(s) 
found' [1]. However, all the erroneously installed modules should be 
excluded by default, if I understand the setuptools automatic discovery 
documentation [2] correctly. They are listed in 
'FlatLayoutPackageFinder.DEFAULT_EXCLUDE'. In this case 'docs', 
'scripts' and 'test'.


Since this is still beta when using pyproject.toml, I was wondering if 
someone else has come across this misbehavior. Or, maybe, it's something 
I failed to spot in pyproject.toml, that's causing it.


I can make it work by adding a 'include = ["palettable"]' in the 
tool.setuptools.packages.find table [3]. But I'd like a second opinion 
before submitting a PR upstream.


[1] https://kojipkgs.fedoraproject.org//work/tasks/5770/101775770/build.log
[2] 
https://setuptools.pypa.io/en/latest/userguide/package_discovery.html#flat-layout

[3] https://copr.fedorainfracloud.org/coprs/gui1ty/neuro-sig/build/6000976/

Cheers,
--
Sandro
FAS: gui1ty
IRC: Penguinpee
Elsewhere: [Pp]enguinpee
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Self Introduction: Daniel Milnes

[Daniel Milnes via devel]

Hey all, I'm Daniel Milnes.

By day I'm a CyberSecurity Engineer at LMAX Group, part of the team responsible 
for running ~2k Rocky Linux servers, and by night I'm head of Infrastructure 
for RACTF, an open-source framework for hosting Cyber Security Capture-The-Flag 
events. This means I've got a professional and personal interest in the health 
of the Fedora ecosystem, directly on my personal workstations, and indirectly 
on servers running distros which are downstream from Fedora.

I'm responsible for maintaining several RPMs as part of my job, and am hoping 
to be able to transfer that experience over to Fedora. I've submitted an RPM 
for an open source tool I developed (bugzilla#2210561), and plan to use the 
experience from there to help maintain other packages.

Also in case it's ever needed, my GPG key is on https://beano.dev/gpg (follow 
redirects).

Thank you all for what you do for the Linux ecosystem!

--
Daniel Milnes
___
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

[Test-Announce] Fedora 39 Rawhide 20230603.n.1 nightly compose nominated for testing

[rawhide]

Announcing the creation of a new nightly release validation test event
for Fedora 39 Rawhide 20230603.n.1. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test_plan

Notable package version changes:
python-blivet - 20230526.n.0: python-blivet-3.7.1-3.fc39.src, 20230603.n.1: 
python-blivet-3.7.1-4.fc39.src
lorax - 20230526.n.0: lorax-39.0-1.fc39.src, 20230603.n.1: lorax-39.1-1.fc39.src

Test coverage information for the current release can be seen at:
https://openqa.fedoraproject.org/testcase_stats/39

You can see all results, find testing instructions and image download
locations, and enter results on the Summary page:

https://fedoraproject.org/wiki/Test_Results:Fedora_39_Rawhide_20230603.n.1_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_39_Rawhide_20230603.n.1_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_39_Rawhide_20230603.n.1_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_39_Rawhide_20230603.n.1_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_39_Rawhide_20230603.n.1_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_39_Rawhide_20230603.n.1_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_39_Rawhide_20230603.n.1_Security_Lab

Thank you for testing!
-- 
Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-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/test-annou...@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

Using AI/Machine Learning with rpmautospec?

[Reon Beon via devel]

How far along is this? Possible in the next 5-10 years or so?
___
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

[EPEL-devel] Re: Cannot run fedpkg mockbuild for epel9 on f38

[Scott Talbert]

On Sat, 3 Jun 2023, Brad Bell wrote:

I am getting the error message below in response to a `fedpkg mockbuild` 
command. What am I doing wrong ?



fedpkg mockbuild

... snip ...
ERROR: Mock config 'epel-9-x86_64' not found, see errors above.


Here is my system information:


git branch

* epel9
  rawhide


uname -a
Linux brad-mobile 6.2.15-300.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Thu May 11 
17:37:39 UTC 2023 x86_64 GNU/Linux



ls /etc/mock | grep epel-9

alma+epel-9-aarch64.cfg
alma+epel-9-ppc64le.cfg
alma+epel-9-s390x.cfg
alma+epel-9-x86_64.cfg
centos-stream+epel-9-aarch64.cfg
centos-stream+epel-9-ppc64le.cfg
centos-stream+epel-9-s390x.cfg
centos-stream+epel-9-x86_64.cfg
oraclelinux+epel-9-aarch64.cfg
oraclelinux+epel-9-x86_64.cfg
rhel+epel-9-aarch64.cfg
rhel+epel-9-ppc64le.cfg
rhel+epel-9-s390x.cfg
rhel+epel-9-x86_64.cfg
rocky+epel-9-aarch64.cfg
rocky+epel-9-ppc64le.cfg
rocky+epel-9-s390x.cfg
rocky+epel-9-x86_64.cfg


You have to pick which one of those mock configs you want to use for epel9 
and symlink it.  For example:


$ ls -l ~/.config/mock/
lrwxrwxrwx. 1 talbert talbert  41 Jun  3  2022 epel-9-x86_64.cfg -> 
/etc/mock/centos-stream+epel-9-x86_64.cfg

Scott___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-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/ 


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


Hey,

as you've probably seen, the LibreOffice RPMS have recently been
orphaned, and I thought it would be good to explain the reasons
behind this.

The Red Hat Display Systems team (the team behind most of Red Hat’s
desktop efforts) has maintained the LibreOffice packages in Fedora
for years as part of our work to support LibreOffice for Red Hat
Enterprise Linux. We are adjusting our engineering priorities for
RHEL for Workstations and focusing on gaps in Wayland, building out
HDR support, building out what’s needed for color-sensitive work,
and a host of other refinements required by Workstation users. This
is work that will improve the workstation experience for Fedora as
well as RHEL users, and which, we hope, will be positively received
by the entire Linux community.

The tradeoff is that we are pivoting away from work we had been
doing on desktop applications and will cease shipping LibreOffice as
part of RHEL starting in a future RHEL version. This also limits our
ability to maintain it in future versions of Fedora.

We will continue to maintain LibreOffice in currently supported
versions of RHEL (RHEL 7, 8 and 9) with needed CVEs and similar for
the lifetime of those releases (as published on the Red Hat
website). As part of that, the engineers doing that work will
contribute some fixes upstream to ensure LibreOffice works better as
a Flatpak, which we expect to be the way that most people consume
LibreOffice in the long term.

Any community member is of course free to take over maintenance,
both for the RPMS in Fedora and the Fedora LibreOffice Flatpak, but
be aware that this is a sizable block of packages and dependencies
and a significant amount of work to keep up with.

Matthias
___
devel mailing list -- devel@lists.fedoraproject.org

To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: Cannot run fedpkg mockbuild for epel9 on f38

[Neal Gompa]

On Sat, Jun 3, 2023 at 12:03 PM Stephen Smoogen  wrote:
>
>
>
> On Sat, 3 Jun 2023 at 11:57, Brad Bell  wrote:
>>
>> I am getting the error message below in response to a `fedpkg mockbuild` 
>> command. What am I doing
>> wrong ?
>>
>>  >fedpkg mockbuild
>> ... snip ...
>> ERROR: Mock config 'epel-9-x86_64' not found, see errors above.
>>
>>
>> Here is my system information:
>>
>>  >git branch
>> * epel9
>>rawhide
>>
>>  >uname -a
>> Linux brad-mobile 6.2.15-300.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Thu May 11 
>> 17:37:39 UTC 2023 x86_64
>> GNU/Linux
>>
>>  >ls /etc/mock | grep epel-9
>> alma+epel-9-aarch64.cfg
>> alma+epel-9-ppc64le.cfg
>> alma+epel-9-s390x.cfg
>> alma+epel-9-x86_64.cfg
>> centos-stream+epel-9-aarch64.cfg
>> centos-stream+epel-9-ppc64le.cfg
>> centos-stream+epel-9-s390x.cfg
>> centos-stream+epel-9-x86_64.cfg
>> oraclelinux+epel-9-aarch64.cfg
>> oraclelinux+epel-9-x86_64.cfg
>> rhel+epel-9-aarch64.cfg
>> rhel+epel-9-ppc64le.cfg
>> rhel+epel-9-s390x.cfg
>> rhel+epel-9-x86_64.cfg
>> rocky+epel-9-aarch64.cfg
>> rocky+epel-9-ppc64le.cfg
>> rocky+epel-9-s390x.cfg
>> rocky+epel-9-x86_64.cfg
>>
>
> You need to choose a distribution to build against and set the configs for it
>
> ln -s /etc/mock/foobar+epel-9-x86_64.cfg /etc/mock/epel-9-x86_64.cfg
> ln -s /etc/mock/foobar+epel-8-x86_64.cfg /etc/mock/epel-8-x86_64.cfg
>

I recommend not doing it in /etc, and instead doing it in
~/.config/mock, like so:

ngompa@fedora ~> ls -hal ~/.config/mock/
total 16K
drwxr-xr-x. 1 ngompa ngompa  140 Jun 16  2022 ./
drwxrwxr-x. 1 ngompa ngompa 3.7K Jun  3 12:14 ../
lrwxrwxrwx. 1 ngompa ngompa   33 Feb 12  2022 epel-8-aarch64.cfg ->
/etc/mock/eldistro+epel-8-aarch64.cfg
lrwxrwxrwx. 1 ngompa ngompa   32 Feb 12  2022 epel-8-x86_64.cfg ->
/etc/mock/eldistro+epel-8-x86_64.cfg
lrwxrwxrwx. 1 ngompa ngompa   33 Jun 16  2022 epel-9-aarch64.cfg ->
/etc/mock/eldistro+epel-9-aarch64.cfg
lrwxrwxrwx. 1 ngompa ngompa   32 Jun 16  2022 epel-9-x86_64.cfg ->
/etc/mock/eldistro+epel-9-x86_64.cfg

(I changed my choice to the non-existent "eldistro" intentionally,
substitute with your preferred variant)



--
真実はいつも一つ！/ Always, there's only one truth!
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[EPEL-devel] Re: Cannot run fedpkg mockbuild for epel9 on f38

[Stephen Smoogen]

On Sat, 3 Jun 2023 at 11:57, Brad Bell  wrote:

> I am getting the error message below in response to a `fedpkg mockbuild`
> command. What am I doing
> wrong ?
>
>  >fedpkg mockbuild
> ... snip ...
> ERROR: Mock config 'epel-9-x86_64' not found, see errors above.
>
>
> Here is my system information:
>
>  >git branch
> * epel9
>rawhide
>
>  >uname -a
> Linux brad-mobile 6.2.15-300.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Thu May 11
> 17:37:39 UTC 2023 x86_64
> GNU/Linux
>
>  >ls /etc/mock | grep epel-9
> alma+epel-9-aarch64.cfg
> alma+epel-9-ppc64le.cfg
> alma+epel-9-s390x.cfg
> alma+epel-9-x86_64.cfg
> centos-stream+epel-9-aarch64.cfg
> centos-stream+epel-9-ppc64le.cfg
> centos-stream+epel-9-s390x.cfg
> centos-stream+epel-9-x86_64.cfg
> oraclelinux+epel-9-aarch64.cfg
> oraclelinux+epel-9-x86_64.cfg
> rhel+epel-9-aarch64.cfg
> rhel+epel-9-ppc64le.cfg
> rhel+epel-9-s390x.cfg
> rhel+epel-9-x86_64.cfg
> rocky+epel-9-aarch64.cfg
> rocky+epel-9-ppc64le.cfg
> rocky+epel-9-s390x.cfg
> rocky+epel-9-x86_64.cfg
>
>
You need to choose a distribution to build against and set the configs for
it

ln -s /etc/mock/foobar+epel-9-x86_64.cfg /etc/mock/epel-9-x86_64.cfg
ln -s /etc/mock/foobar+epel-8-x86_64.cfg /etc/mock/epel-8-x86_64.cfg




>  >dnf info fedpkg
> Name : fedpkg
> Version  : 1.44
> Release  : 4.fc38
> Architecture : noarch
> Size : 333 k
> Source   : fedpkg-1.44-4.fc38.src.rpm
> Repository   : @System
>  From repo: updates
> Summary  : Fedora utility for working with dist-git
> URL  : https://pagure.io/fedpkg
> License  : GPLv2+
> Description  : Provides the fedpkg command for working with dist-git
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>


-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[EPEL-devel] Cannot run fedpkg mockbuild for epel9 on f38

[Brad Bell]

I am getting the error message below in response to a `fedpkg mockbuild` command. What am I doing 
wrong ?


>fedpkg mockbuild
... snip ...
ERROR: Mock config 'epel-9-x86_64' not found, see errors above.


Here is my system information:

>git branch
* epel9
  rawhide

>uname -a
Linux brad-mobile 6.2.15-300.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Thu May 11 17:37:39 UTC 2023 x86_64 
GNU/Linux


>ls /etc/mock | grep epel-9
alma+epel-9-aarch64.cfg
alma+epel-9-ppc64le.cfg
alma+epel-9-s390x.cfg
alma+epel-9-x86_64.cfg
centos-stream+epel-9-aarch64.cfg
centos-stream+epel-9-ppc64le.cfg
centos-stream+epel-9-s390x.cfg
centos-stream+epel-9-x86_64.cfg
oraclelinux+epel-9-aarch64.cfg
oraclelinux+epel-9-x86_64.cfg
rhel+epel-9-aarch64.cfg
rhel+epel-9-ppc64le.cfg
rhel+epel-9-s390x.cfg
rhel+epel-9-x86_64.cfg
rocky+epel-9-aarch64.cfg
rocky+epel-9-ppc64le.cfg
rocky+epel-9-s390x.cfg
rocky+epel-9-x86_64.cfg

>dnf info fedpkg
Name : fedpkg
Version  : 1.44
Release  : 4.fc38
Architecture : noarch
Size : 333 k
Source   : fedpkg-1.44-4.fc38.src.rpm
Repository   : @System
From repo    : updates
Summary  : Fedora utility for working with dist-git
URL  : https://pagure.io/fedpkg
License  : GPLv2+
Description  : Provides the fedpkg command for working with dist-git
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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: python macros inconsistency between Fedora and EPEL9

[Mattia Verga]

> On 03. 06. 23 13:29, Mattia Verga wrote:
> 
> It's not in epel because it is in RHEL.
> 
> 
> I have no idea. What makes you suspect this problem is related to *Python* 
> macros at all? %ctest is defined in /usr/lib/rpm/macros.d/macros.cmake which 
> is 
> shipped by cmake-rpm-macros, a subpackage of cmake.

... I'll ask that question to my brain when I reach out it... ;-)
The only answer I have at the moment is that today I'm more dumb than usual.
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: python macros inconsistency between Fedora and EPEL9

[Miro Hrončok]

On 03. 06. 23 13:29, Mattia Verga wrote:

In the test section of libindi package I use this to run tests:
%ctest --test-dir %_vpath_builddir/test

This translates in Fedora as:
+ /usr/bin/ctest --test-dir redhat-linux-build --output-on-failure 
--force-new-ctest-process -j6 --test-dir redhat-linux-build/test
Internal ctest changing into directory: 
/builddir/build/BUILD/indi-2.0.2/redhat-linux-build/test

While on EPEL (at least, in COPR):
+ /usr/bin/ctest --output-on-failure --force-new-ctest-process -j2 --test-dir 
redhat-linux-build/test
Internal ctest changing into directory: 
/builddir/build/BUILD/indi-2.0.2/redhat-linux-build/redhat-linux-build/test
Failed to change working directory to 
"/builddir/build/BUILD/indi-2.0.2/redhat-linux-build/redhat-linux-build/test" : 
No such file or directory

I'm not sure against what package I should report this. Python-rpm-macros seems 
a Fedora package only, I don't see any epel9 build there.


It's not in epel because it is in RHEL.


And, most important, I don't know if I'm doing something wrong or if is indeed 
something to report.
Can anyone clarify me these two things?


I have no idea. What makes you suspect this problem is related to *Python* 
macros at all? %ctest is defined in /usr/lib/rpm/macros.d/macros.cmake which is 
shipped by cmake-rpm-macros, a subpackage of cmake.




--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

python macros inconsistency between Fedora and EPEL9

[Mattia Verga]

In the test section of libindi package I use this to run tests:
%ctest --test-dir %_vpath_builddir/test

This translates in Fedora as:
+ /usr/bin/ctest --test-dir redhat-linux-build --output-on-failure 
--force-new-ctest-process -j6 --test-dir redhat-linux-build/test
Internal ctest changing into directory: 
/builddir/build/BUILD/indi-2.0.2/redhat-linux-build/test

While on EPEL (at least, in COPR):
+ /usr/bin/ctest --output-on-failure --force-new-ctest-process -j2 --test-dir 
redhat-linux-build/test
Internal ctest changing into directory: 
/builddir/build/BUILD/indi-2.0.2/redhat-linux-build/redhat-linux-build/test
Failed to change working directory to 
"/builddir/build/BUILD/indi-2.0.2/redhat-linux-build/redhat-linux-build/test" : 
No such file or directory

I'm not sure against what package I should report this. Python-rpm-macros seems 
a Fedora package only, I don't see any epel9 build there.
And, most important, I don't know if I'm doing something wrong or if is indeed 
something to report.
Can anyone clarify me these two things?

Thanks
Mattia
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-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/python-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