[Bug 2177932] perl-Net-DNS-1.38 is available

[bugzilla]

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



--- Comment #16 from Fedora Update System  ---
FEDORA-2023-e38e484771 has been pushed to the Fedora 37 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh
--advisory=FEDORA-2023-e38e484771`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2023-e38e484771

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2177932
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 1937653] Upgrade perl-HTTP-OAI to 4.12

[bugzilla]

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



--- Comment #7 from Fedora Update System  ---
FEDORA-2023-a5147703b6 has been pushed to the Fedora 37 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh
--advisory=FEDORA-2023-a5147703b6`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2023-a5147703b6

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1937653
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-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

[Bug 2209937] [EPEL9] Please build and EPEL9 build for perl-Term-Shell

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA
   Fixed In Version||perl-Term-Shell-0.13-8.el9
Last Closed||2023-06-03 03:02:24



--- Comment #3 from Fedora Update System  ---
FEDORA-EPEL-2023-284c7b1747 has been pushed to the Fedora EPEL 9 stable
repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2209937
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-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

[Bug 2177932] perl-Net-DNS-1.38 is available

[bugzilla]

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



--- Comment #15 from Fedora Update System  ---
FEDORA-2023-ae600320ff has been pushed to the Fedora 38 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh
--advisory=FEDORA-2023-ae600320ff`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2023-ae600320ff

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2177932
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 1937653] Upgrade perl-HTTP-OAI to 4.12

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #6 from Fedora Update System  ---
FEDORA-2023-acaea55b63 has been pushed to the Fedora 38 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh
--advisory=FEDORA-2023-acaea55b63`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2023-acaea55b63

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1937653
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Trying to strip a library automatically

[Paul Grosu]

Hi Orion,

Glad objdump helped -- the second approach I meant to write objcopy, which
actually strips the symbols.

Regarding how the symbols might show up in the library automatically,
here's how it might happen.  When I took a look at one of the build.log
files from koji at the following link:

https://kojipkgs.fedoraproject.org//packages/Lmod/8.7.25/2.fc38/data/logs/x86_64/build.log

I see your CFLAGS variable contains the -g flag, which forces debug symbols
to be included.  For example, for the tcl2lua it has it as part of the
build (which contains the -g flag):

make[1]: Entering directory '/builddir/build/BUILD/Lmod-8.7.25/pkgs/tcl2lua'
gcc -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches
-pipe -Wall -Werror=format-security
-Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64  -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer  -DLUA_COMPAT_MODULE
-fPIC -I/usr/include -I/usr/include/   -c -o tcl2lua.o tcl2lua.c

The way this seems to happen could be as follows:

1) I took a look at the source code from here:

https://kojipkgs.fedoraproject.org//packages/Lmod/8.7.25/2.fc38/src/Lmod-8.7.25-2.fc38.src.rpm

When I looked at the Makefile for tcl2lua under Lmod-8.7.25/pkgs/tcl2lua,
it inherits it from a previous file:

override CFLAGS   := $(CFLAGS) -DLUA_COMPAT_MODULE -fPIC $(LUA_INC)
$(TCL_INCLUDE)

2) When I traverse the inheritance, it seems to come from the configure
script Lmod-8.7.25/configure:

I see a bunch of CFLAGS="-g there.

If I then look at the build.log it seems to be run at the beginning of the
build:

+ ./configure --build=x86_64-redhat-linux-gnu
--host=x86_64-redhat-linux-gnu --program-prefix=
--disable-dependency-tracking --prefix=/usr --exec-prefix=/usr
--bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc
--datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64
--libexecdir=/usr/libexec --localstatedir=/var --runstatedir=/run
--sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info
--prefix=/usr/share PS=/usr/bin/ps
configure: WARNING: unrecognized options: --disable-dependency-tracking

I then looked at the Lmod.spec file, and I see this, which confirms it:

%build
%if 0%{?rhel} && 0%{?rhel} <= 6
%configure --prefix=%{_datadir} PS=/bin/ps
%else
%configure --prefix=%{_datadir} PS=/usr/bin/ps
%endif
%make_build

So debug symbols seem to get triggered through the configure script.

Hope it helps,
Paul

On Fri, Jun 2, 2023 at 7:42 PM Orion Poplawski  wrote:

> On 6/1/23 23:00, Paul Grosu wrote:
> > Hi Orion,
> >
> > There are two ways to remove the debugging symbols:
> >
> > 1) strip --strip-debug your_library.so
> >
> > 2) objcopy --strip-debug your_library.so
> >
> > Below is an example of both approaches:
> >
> > 1) Method using strip:
> >
> > paul$ objdump --syms libfoo.so | grep debug
> >  ld  .debug_aranges 
> >   .debug_aranges
> >  ld  .debug_info
> >   .debug_info
> >  ld  .debug_abbrev  
> >   .debug_abbrev
> >  ld  .debug_line
> >   .debug_line
> >  ld  .debug_str 
> >   .debug_str
> > paul$ strip --strip-debug libfoo.so
> > paul$ objdump --syms libfoo.so | grep debug
> > paul$
> >
> > 2) Method using objdump:
> >
> > paul$ objdump --syms libfoo.so | grep debug
> >  ld  .debug_aranges 
> >   .debug_aranges
> >  ld  .debug_info
> >   .debug_info
> >  ld  .debug_abbrev  
> >   .debug_abbrev
> >  ld  .debug_line
> >   .debug_line
> >  ld  .debug_str 
> >   .debug_str
> > paul$ objcopy --strip-debug libfoo.so
> > paul$ objdump --syms libfoo.so | grep debug
> > paul$
> >
> > Are there other symbols you are looking to strip?
> >
> > Hope it helps,
> > Paul
>
> So I'm afraid my subject isn't the best - I'm really wondering why the
> library isn't being stripped automatically and debug info collected by
> RPM as I would expect.
>
> But your answer pointed me towards using objdump --syms to verify that
> the debug info has been removed, not the output of "file".  Thanks!
>
> >
> > On Fri, Jun 2, 2023 at 12:11 AM Orion Poplawski  > > wrote:
> >
> > I'm trying to resolve this packaging issue with Lmod:
> >
> >
> https://artifacts.dev.testing-farm.io/4d7bee41-8d21-42fb-8c57-e5ffbf58119f/
> <
> https://artifacts.dev.testing-farm.io/4d7bee41-8d21-42fb-8c57-e5ffbf58119f/
> >
> >
> > debuginfo
> > BAD /usr/share/lmod/8.7.25/lib/tcl2lua.so in Lmod-8.7.25-2.fc38 on
> i686
> > contains debugging symbols
> 

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

Making systemd-boot option available for installation?

[Luya Tshimbalanga]

Hello team,

I would like to bring back the topic related to the selection of 
bootloader notably either GRUB2 and systemd-boot. With the recent 
adoption on UKI kernel, it would be great to get systemd-boot ready for 
at least Fedora 39 which is useful for devices like laptops. Currently, 
some methods allow to install systemd-boot with extra step to keep 
supporting secure boot while preserving GRUB2 [1]. What is the missing 
step to enable secure boot for systemd-boot without at least keeping GRUB 2?


Thanks in advance.

[1] 
https://medium.com/@umglurf/full-uefi-secure-boot-on-fedora-using-signed-initrd-and-systemd-boot-3ff2054593ab


--
Luya Tshimbalanga
Fedora Design Team
Fedora Design Suite maintainer
___
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

Re: Trying to strip a library automatically

[Orion Poplawski]

On 6/1/23 23:00, Paul Grosu wrote:

Hi Orion,

There are two ways to remove the debugging symbols:

1) strip --strip-debug your_library.so

2) objcopy --strip-debug your_library.so

Below is an example of both approaches:

1) Method using strip:

paul$ objdump --syms libfoo.so | grep debug
 l    d  .debug_aranges  
  .debug_aranges
 l    d  .debug_info     
  .debug_info
 l    d  .debug_abbrev   
  .debug_abbrev
 l    d  .debug_line     
  .debug_line
 l    d  .debug_str      
  .debug_str

paul$ strip --strip-debug libfoo.so
paul$ objdump --syms libfoo.so | grep debug
paul$

2) Method using objdump:

paul$ objdump --syms libfoo.so | grep debug
 l    d  .debug_aranges  
  .debug_aranges
 l    d  .debug_info     
  .debug_info
 l    d  .debug_abbrev   
  .debug_abbrev
 l    d  .debug_line     
  .debug_line
 l    d  .debug_str      
  .debug_str

paul$ objcopy --strip-debug libfoo.so
paul$ objdump --syms libfoo.so | grep debug
paul$

Are there other symbols you are looking to strip?

Hope it helps,
Paul


So I'm afraid my subject isn't the best - I'm really wondering why the 
library isn't being stripped automatically and debug info collected by 
RPM as I would expect.


But your answer pointed me towards using objdump --syms to verify that 
the debug info has been removed, not the output of "file".  Thanks!




On Fri, Jun 2, 2023 at 12:11 AM Orion Poplawski > wrote:


I'm trying to resolve this packaging issue with Lmod:

https://artifacts.dev.testing-farm.io/4d7bee41-8d21-42fb-8c57-e5ffbf58119f/ 


debuginfo
BAD /usr/share/lmod/8.7.25/lib/tcl2lua.so in Lmod-8.7.25-2.fc38 on i686
contains debugging symbols

I've dealt with a couple of issues here:

https://src.fedoraproject.org/rpms/Lmod/pull-request/2


but despite all of my attempts the library does not appear to get
stripped.

In fact:

]$ strip -g

/home/orion/BUILDROOT/Lmod-8.7.25-3.fc39.x86_64/usr/lib64/lmod/tcl2lua.so.1.0.1

$ file

/home/orion/BUILDROOT/Lmod-8.7.25-3.fc39.x86_64/usr/lib64/lmod/tcl2lua.so.1.0.1

/home/orion/BUILDROOT/Lmod-8.7.25-3.fc39.x86_64/usr/lib64/lmod/tcl2lua.so.1.0.1:
ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically
linked, BuildID[sha1]=aa1ea44979190d0cf530d350f8151ffafeab0f36, not
stripped

?


-- 
Orion Poplawski

he/him/his  - surely the least important thing about me
IT Systems Manager                         720-772-5637
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane or...@nwra.com 
Boulder, CO 80301 https://www.nwra.com/ 
___
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


--
Orion Poplawski
he/him/his  - surely the least important thing about me
IT Systems Manager 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/



smime.p7s
Description: S/MIME 

[rpms/perl-Text-CharWidth] PR #2: Update license to SPDX format

[Michal Josef Špaček]

mspacek opened a new pull-request against the project: `perl-Text-CharWidth` 
that you are following:
``
Update license to SPDX format
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Text-CharWidth/pull-request/2
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[rpms/perl-Scalar-List-Utils] PR #4: Update license to SPDX format

[Michal Josef Špaček]

mspacek opened a new pull-request against the project: `perl-Scalar-List-Utils` 
that you are following:
``
Update license to SPDX format
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Scalar-List-Utils/pull-request/4
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[rpms/perl-Sys-CPU] PR #2: Update license to SPDX format

[Michal Josef Špaček]

mspacek opened a new pull-request against the project: `perl-Sys-CPU` that you 
are following:
``
Update license to SPDX format
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Sys-CPU/pull-request/2
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[rpms/perl-XML-RegExp] PR #2: Update license to SPDX format

[Michal Josef Špaček]

mspacek opened a new pull-request against the project: `perl-XML-RegExp` that 
you are following:
``
Update license to SPDX format
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-XML-RegExp/pull-request/2
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[rpms/perl-XML-DOM] PR #2: Update license to SPDX format

[Michal Josef Špaček]

mspacek opened a new pull-request against the project: `perl-XML-DOM` that you 
are following:
``
Update license to SPDX format
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-XML-DOM/pull-request/2
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [Fedocal] Reminder meeting : ELN SIG

[Stephen Gallagher]

On Thu, Jun 1, 2023 at 3:16 PM Stephen Gallagher  wrote:
>
> On Thu, Jun 1, 2023 at 8:00 AM  wrote:
> >
> > Dear all,
> >
> > You are kindly invited to the meeting:
> >ELN SIG on 2023-06-02 from 12:00:00 to 13:00:00 US/Eastern
> >At fedora-meet...@irc.libera.chat
> >
> > The meeting will be about:
>
> This week we will have a discussion about recent changes to x86_64,
> specifically the adjustment to the x86_64-v3 baseline and dropping
> i686 multilib.
>
> > Source: https://calendar.fedoraproject.org//meeting/10449/


=
#fedora-meeting: ELN (2023-06-02)
=


Meeting started by sgallagh at 16:00:12 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/fedora-meeting/2023-06-02/eln.2023-06-02-16.00.log.html
.



Meeting summary
---
* init process  (sgallagh, 16:00:12)

* x86_64 baseline and multiarch support  (sgallagh, 16:10:08)
  * ACTION: bstinson to create Discourse discussion threads for the
x86_64-v3 and 32-bit multilib topics.  (sgallagh, 17:04:46)

Meeting ended at 17:04:55 UTC.




Action Items

* bstinson to create Discourse discussion threads for the x86_64-v3 and
  32-bit multilib topics.




Action Items, by person
---
* bstinson
  * bstinson to create Discourse discussion threads for the x86_64-v3
and 32-bit multilib topics.
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* davide (49)
* bstinson (46)
* Eighth_Doctor (35)
* sgallagh (31)
* smooge (14)
* zodbot (11)
* yselkowitz[m] (5)
* tdawson (2)




Generated by `MeetBot`_ 0.4

.. _`MeetBot`: https://fedoraproject.org/wiki/Zodbot#Meeting_Functions
___
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

[Christian Schaller]

On Fri, Jun 2, 2023 at 9:40 AM Peter Robinson  wrote:

> On Fri, Jun 2, 2023 at 2:28 PM Stephen Smoogen 
> wrote:
> >
> >
> >
> > On Fri, 2 Jun 2023 at 07:20, Matthias Clasen  wrote:
> >>
> >> Lets not make this a drama.
> >>
> >> Package maintenance changes have never gone through change proposals.
> >>
> >
> > I am  sorry, but this was made into a drama by the way this was
> executed. Surprise is the opposite of engagement and dropping a ton of
> packages and their dependencies and then announcing it is absolute surprise.
> >
> > This isn't just package maintenance. This is a major change in what is
> expected to be included in the next workstation editions with the removal
> of expected functionality. If the packages are not picked up within a
> certain amount of time or can be rebuilt it means many packages will need
> to be edited. Those changes need to be researched, announced, and pushed
> through.
> >
> > It is also drama because people in the community have no idea what else
> will take place? When uncertainty and doubt are allowed into the
> conversation, people jump to the extremes so they can feel ready to deal
> with it.
> >
> > Could we try something different for future changes?
> > 1. Announce that Red Hat will be moving from owning said packages and
> dependencies on X date.
> > 2. Let people grieve about things for a short while but make it clear
> its happening. See if community members or other companies will take up the
> burden
> > 3. Do the orphan or hand over of packages to the new group.
> >
> > Instead of 3,1,2?
>
> That may not always be possible, sometimes it involves departure or
> changes of roles for people and those can be delicate and are not
> always notifiable. I'm not sure that is the case here but I do know,
> from a blog post [1], that the previous maintainer is no longer at Red
> Hat.
>
> Peter
>
> [1] https://meeksfamily.uk/~michael/blog/2023-05-15-caolan.html


Yeah, Matthias posting this email was us trying to give the community
proper notice. Caolan leaving accelerated things a lot here and also since
we felt it correct to inform people about how our plans around RHEL
informed this decision in Fedora we needed to spend some time getting
internal approval for that, as engineers we don't have the authority to
share what could be seen as Red Hat product plans publicly.

So while I understand that people like things to be announced with longer
horizons it is simply not always possible. We got this message out as soon
as we could.

Christian
___
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

[rpms/perl-Scalar-List-Utils] PR #3: Update license to SPDX format

[Michal Josef Špaček]

mspacek closed without merging a pull-request against the project: 
`perl-Scalar-List-Utils` that you
are following.

Closed pull-request:

``
Update license to SPDX format
``

https://src.fedoraproject.org/rpms/perl-Scalar-List-Utils/pull-request/3
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[rpms/perl-Sys-CPU] PR #1: Update license to SPDX format

[Michal Josef Špaček]

mspacek closed without merging a pull-request against the project: 
`perl-Sys-CPU` that you
are following.

Closed pull-request:

``
Update license to SPDX format
``

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

[rpms/perl-Text-CharWidth] PR #1: Update license to SPDX format

[Michal Josef Špaček]

mspacek closed without merging a pull-request against the project: 
`perl-Text-CharWidth` that you
are following.

Closed pull-request:

``
Update license to SPDX format
``

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

[rpms/perl-XML-DOM] PR #1: Update license to SPDX format

[Michal Josef Špaček]

mspacek closed without merging a pull-request against the project: 
`perl-XML-DOM` that you
are following.

Closed pull-request:

``
Update license to SPDX format
``

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

[rpms/perl-XML-RegExp] PR #1: Update license to SPDX format

[Michal Josef Špaček]

mspacek closed without merging a pull-request against the project: 
`perl-XML-RegExp` that you
are following.

Closed pull-request:

``
Update license to SPDX format
``

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

[Bug 2211942] New: perl-Sys-Virt-9.4.0 is available

[bugzilla]

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

Bug ID: 2211942
   Summary: perl-Sys-Virt-9.4.0 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Sys-Virt
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: berra...@redhat.com, crobi...@redhat.com,
jples...@redhat.com,
perl-devel@lists.fedoraproject.org, st...@silug.org
  Target Milestone: ---
Classification: Fedora



Releases retrieved: 9.4.0
Upstream release that is considered latest: 9.4.0
Current version/release in rawhide: 9.2.0-1.fc39
URL: https://metacpan.org/release/Sys-Virt/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at:
https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from Anitya:
https://release-monitoring.org/project/3355/


To change the monitoring settings for the project, please visit:
https://src.fedoraproject.org/rpms/perl-Sys-Virt


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2211942
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Managing multiple cross-dependent patches

[Dmitry Belyavskiy]

Dear Daniel,

On Fri, Jun 2, 2023 at 4:57 PM Daniel P. Berrangé  wrote:
>
> On Fri, Jun 02, 2023 at 04:27:37PM +0200, Dmitry Belyavskiy wrote:
> > Dear colleagues,
> >
> > I maintain OpenSSH that has a lot of heavy-interfering downstream
> > patches. I’d like to reduce the burden of rebase by combining some of
> > them.
>
> Trying to reduce the burden by combining patches won't help IMHO, and
> if anything make life worse, as any patch failing to apply will leave
> a bigger conflict mess to resolve. I always favour a larger number of
> small patches, over a small number of big patches.

I can easily identify some patches that would definitely better be
combined. I'd prefer to do it more or less automagically.

But of course, there are also ones that should stay separate.

> > So I wonder if there is software checking for cross-dependencies
> > between patches to see what are the natural candidates for combining?
> >
> > I’m aware of quilt and git-absorb but it looks like they don’t help me much.
>
> Are you primarily using dist-git and managing the patches manually ?
> It looks like it, since the paches I see in openssh.git aren't git
> commit exports.
>
> If so, I'd highly recommend switching to using a src-git model instead,
> where you manage a Fedora branch of commits directly against the upstream
> git repo. This lets you exploit the full power of git for rebasing and
> cherry-picking patches and resolving conflicts. dist-git largely becomes
> an export of patches from the src-git branch which is largely automatable.
> I'm not saying src-git is a magic bullet, just that it is much less painful
> that directly working on dist-git.

I consider it as an option for future.

-- 
Dmitry Belyavskiy
___
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: Managing multiple cross-dependent patches

[Dmitry Belyavskiy]

Dear Chris,

On Fri, Jun 2, 2023 at 4:42 PM Chris Adams  wrote:
>
> Once upon a time, Dmitry Belyavskiy  said:
> > I maintain OpenSSH that has a lot of heavy-interfering downstream
> > patches. I’d like to reduce the burden of rebase by combining some of
> > them.
>
> Wow that's a lot of patches.  Some appear to be Fedora specific, but a
> bunch seem like general fixes.  Has there been an attempt to upstream
> some of this?

Yes. Some of them were even accepted, but, for example, gss ones were
explicitly rejected.

-- 
Dmitry Belyavskiy
___
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

[rpms/perl-XML-TokeParser] PR #2: Update license to SPDX format

[Michal Josef Špaček]

mspacek opened a new pull-request against the project: `perl-XML-TokeParser` 
that you are following:
``
Update license to SPDX format
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-XML-TokeParser/pull-request/2
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[rpms/perl-XML-TokeParser] PR #1: Update license to SPDX format

[Michal Josef Špaček]

mspacek closed without merging a pull-request against the project: 
`perl-XML-TokeParser` that you
are following.

Closed pull-request:

``
Update license to SPDX format
``

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

Re: Managing multiple cross-dependent patches

[Daniel P . Berrangé]

On Fri, Jun 02, 2023 at 04:27:37PM +0200, Dmitry Belyavskiy wrote:
> Dear colleagues,
> 
> I maintain OpenSSH that has a lot of heavy-interfering downstream
> patches. I’d like to reduce the burden of rebase by combining some of
> them.

Trying to reduce the burden by combining patches won't help IMHO, and
if anything make life worse, as any patch failing to apply will leave
a bigger conflict mess to resolve. I always favour a larger number of
small patches, over a small number of big patches.

> So I wonder if there is software checking for cross-dependencies
> between patches to see what are the natural candidates for combining?
>
> I’m aware of quilt and git-absorb but it looks like they don’t help me much.

Are you primarily using dist-git and managing the patches manually ?
It looks like it, since the paches I see in openssh.git aren't git
commit exports.

If so, I'd highly recommend switching to using a src-git model instead,
where you manage a Fedora branch of commits directly against the upstream
git repo. This lets you exploit the full power of git for rebasing and
cherry-picking patches and resolving conflicts. dist-git largely becomes
an export of patches from the src-git branch which is largely automatable.
I'm not saying src-git is a magic bullet, just that it is much less painful
that directly working on dist-git.

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: Managing multiple cross-dependent patches

[Chris Adams]

Once upon a time, Dmitry Belyavskiy  said:
> I maintain OpenSSH that has a lot of heavy-interfering downstream
> patches. I’d like to reduce the burden of rebase by combining some of
> them.

Wow that's a lot of patches.  Some appear to be Fedora specific, but a
bunch seem like general fixes.  Has there been an attempt to upstream
some of this?

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

Managing multiple cross-dependent patches

[Dmitry Belyavskiy]

Dear colleagues,

I maintain OpenSSH that has a lot of heavy-interfering downstream
patches. I’d like to reduce the burden of rebase by combining some of
them.

So I wonder if there is software checking for cross-dependencies
between patches to see what are the natural candidates for combining?

I’m aware of quilt and git-absorb but it looks like they don’t help me much.

Many thanks!

-- 
Dmitry Belyavskiy
___
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: libnfs soname bump

[Richard W.M. Jones]

On Fri, Jun 02, 2023 at 04:02:35PM +0200, Xavier Bachelot wrote:
> Le 2023-06-02 10:40, Richard W.M. Jones a écrit :
> >On Thu, Jun 01, 2023 at 08:34:18AM +0100, Richard W.M. Jones wrote:
> >>qemu is building now:
> >>
> >>https://koji.fedoraproject.org/koji/taskinfo?taskID=101710059
> >
> >This failed because of the data center shutdown, second attempt:
> >
> >https://koji.fedoraproject.org/koji/taskinfo?taskID=101716211
> >
> >Rich.
> 
> Your second attempt failed too, but the s390 builders are back
> online now, so the next one should succeed.

Well third time lucky ... maybe:

https://koji.fedoraproject.org/koji/taskinfo?taskID=101719610

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.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

[Matthew Miller]

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


-- 
Matthew Miller

Fedora Project Leader
___
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: libnfs soname bump

[Xavier Bachelot via devel]

Le 2023-06-02 10:40, Richard W.M. Jones a écrit :

On Thu, Jun 01, 2023 at 08:34:18AM +0100, Richard W.M. Jones wrote:

qemu is building now:

https://koji.fedoraproject.org/koji/taskinfo?taskID=101710059


This failed because of the data center shutdown, second attempt:

https://koji.fedoraproject.org/koji/taskinfo?taskID=101716211

Rich.


Your second attempt failed too, but the s390 builders are back online 
now, so the next one should succeed.


Regards,
Xavier
___
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 Fri, 2 Jun 2023 at 09:40, Peter Robinson  wrote:

> On Fri, Jun 2, 2023 at 2:28 PM Stephen Smoogen 
> wrote:
> >
> >
> >
> > On Fri, 2 Jun 2023 at 07:20, Matthias Clasen  wrote:
> >>
> >> Lets not make this a drama.
> >>
> >> Package maintenance changes have never gone through change proposals.
> >>
> >
> > I am  sorry, but this was made into a drama by the way this was
> executed. Surprise is the opposite of engagement and dropping a ton of
> packages and their dependencies and then announcing it is absolute surprise.
> >
> > This isn't just package maintenance. This is a major change in what is
> expected to be included in the next workstation editions with the removal
> of expected functionality. If the packages are not picked up within a
> certain amount of time or can be rebuilt it means many packages will need
> to be edited. Those changes need to be researched, announced, and pushed
> through.
> >
> > It is also drama because people in the community have no idea what else
> will take place? When uncertainty and doubt are allowed into the
> conversation, people jump to the extremes so they can feel ready to deal
> with it.
> >
> > Could we try something different for future changes?
> > 1. Announce that Red Hat will be moving from owning said packages and
> dependencies on X date.
> > 2. Let people grieve about things for a short while but make it clear
> its happening. See if community members or other companies will take up the
> burden
> > 3. Do the orphan or hand over of packages to the new group.
> >
> > Instead of 3,1,2?
>
> That may not always be possible, sometimes it involves departure or
> changes of roles for people and those can be delicate and are not
> always notifiable. I'm not sure that is the case here but I do know,
> from a blog post [1], that the previous maintainer is no longer at Red
> Hat.
>
>
Yes, I did engage mouth before brain on this. It isn't alway possible, and
real life is messy. My apologies to Matthias in my wording makes it sound
like this dropping was his decision and the way it was executed was his
doing and fault.



> Peter
>
> [1] https://meeksfamily.uk/~michael/blog/2023-05-15-caolan.html
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-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
>


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

[Peter Robinson]

On Fri, Jun 2, 2023 at 2:28 PM Stephen Smoogen  wrote:
>
>
>
> On Fri, 2 Jun 2023 at 07:20, Matthias Clasen  wrote:
>>
>> Lets not make this a drama.
>>
>> Package maintenance changes have never gone through change proposals.
>>
>
> I am  sorry, but this was made into a drama by the way this was executed. 
> Surprise is the opposite of engagement and dropping a ton of packages and 
> their dependencies and then announcing it is absolute surprise.
>
> This isn't just package maintenance. This is a major change in what is 
> expected to be included in the next workstation editions with the removal of 
> expected functionality. If the packages are not picked up within a certain 
> amount of time or can be rebuilt it means many packages will need to be 
> edited. Those changes need to be researched, announced, and pushed through.
>
> It is also drama because people in the community have no idea what else will 
> take place? When uncertainty and doubt are allowed into the conversation, 
> people jump to the extremes so they can feel ready to deal with it.
>
> Could we try something different for future changes?
> 1. Announce that Red Hat will be moving from owning said packages and 
> dependencies on X date.
> 2. Let people grieve about things for a short while but make it clear its 
> happening. See if community members or other companies will take up the burden
> 3. Do the orphan or hand over of packages to the new group.
>
> Instead of 3,1,2?

That may not always be possible, sometimes it involves departure or
changes of roles for people and those can be delicate and are not
always notifiable. I'm not sure that is the case here but I do know,
from a blog post [1], that the previous maintainer is no longer at Red
Hat.

Peter

[1] https://meeksfamily.uk/~michael/blog/2023-05-15-caolan.html
___
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 Fri, 2 Jun 2023 at 07:20, Matthias Clasen  wrote:

> Lets not make this a drama.
>
> Package maintenance changes have never gone through change proposals.
>
>
I am  sorry, but this was made into a drama by the way this was executed.
Surprise is the opposite of engagement and dropping a ton of packages and
their dependencies and then announcing it is absolute surprise.

This isn't just package maintenance. This is a major change in what is
expected to be included in the next workstation editions with the removal
of expected functionality. If the packages are not picked up within a
certain amount of time or can be rebuilt it means many packages will need
to be edited. Those changes need to be researched, announced, and pushed
through.

It is also drama because people in the community have no idea what else
will take place? When uncertainty and doubt are allowed into the
conversation, people jump to the extremes so they can feel ready to deal
with it.

Could we try something different for future changes?
1. Announce that Red Hat will be moving from owning said packages and
dependencies on X date.
2. Let people grieve about things for a short while but make it clear its
happening. See if community members or other companies will take up the
burden
3. Do the orphan or hand over of packages to the new group.

Instead of 3,1,2?



> > However, it surprises me that for a package, that is part of the
> deliverables of Fedora releases, no coordination effort was made to
> transition the package from Red Hat maintenance to Fedora maintenance.
>
> My email is that effort.
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-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
>


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

[blinxen]

Hello


If you are still looking for co-maintainers, I can also help.


Hussein

Am 01.06.23 um 22:16 schrieb Gwyn Ciesla via devel:

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



--
Gwyn Ciesla
she/her/hers

in your fear, seek only peace
in your fear, seek only love
-d. bowie


Sent with Proton Mail secure email.

--- Original Message ---
On Thursday, June 1st, 2023 at 1:30 PM, Matthias Clasen  
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
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

___
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]

Terry,

> I appreciate and am empathetic to all of those carrying the burden of this 
> and the thousands of other RPM packages.  As a users of Fedora + RPM Fusion + 
> Cinnamon Desktop as my daily laptop driver since 2011, I love Fedora and am a 
> heavy user of Flatpacks.  So thank you all.
>
> That said, I will point out that I have heard of at least 4 enterprise 
> customers who use libreoffice as a headless file conversion utility.  I have 
> seen it used in customer facing production workflows, such as a financial 
> user support website to handle file uploads provided by end users, as well as 
> medical health records systems used by hospitals and doctors offices.  
> https://www.libreofficehelp.com/batch-convert-writer-documents-pdf-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?).

That is a Red Hat problem, and whether it's in RHEL proper or EPEL
someone has to do the work. It's not fair of you to ask the community
to shoulder that burden, that is a problem for Red Hat to deal with
internally to work out how to resource that whether it's it's in EPEL
or elsewhere. From the customer's perspective there's other commercial
vendors that provide support for LibreOffice too. But what ever way
that is done this is completely off topic for Fedora.

> Hope this is helpful.  And again, THANK YOU!
>
> Terry Bowling
> Sr. Product Manager - RHEL Installation & Build Services Experience
> Red Hat, Inc.
>
>
>
>
> On Thu, Jun 1, 2023 at 2:31 PM Matthias Clasen  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
>> 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
___
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 

Re: LibreOffice packages

[Terry Bowling]

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!

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

[Bug 1937653] Upgrade perl-HTTP-OAI to 4.12

[bugzilla]

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



--- Comment #5 from Fedora Update System  ---
FEDORA-2023-a5147703b6 has been submitted as an update to Fedora 37.
https://bodhi.fedoraproject.org/updates/FEDORA-2023-a5147703b6


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1937653
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 1937653] Upgrade perl-HTTP-OAI to 4.12

[bugzilla]

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



--- Comment #4 from Fedora Update System  ---
FEDORA-2023-acaea55b63 has been submitted as an update to Fedora 38.
https://bodhi.fedoraproject.org/updates/FEDORA-2023-acaea55b63


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1937653
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 1937653] Upgrade perl-HTTP-OAI to 4.12

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-HTTP-OAI-4.12-1.fc39



--- Comment #3 from Petr Pisar  ---
An enhancement release suitable for all Fedoras.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1937653
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Self Introduction: Herald Yu Betty Liu

[Betty Liu]

wow thank you so much!!! I will have a look of them~
___
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

[Matthias Clasen]

Lets not make this a drama.

Package maintenance changes have never gone through change proposals.

> However, it surprises me that for a package, that is part of the 
deliverables of Fedora releases, no coordination effort was made to 
transition the package from Red Hat maintenance to Fedora maintenance.

My email is that effort.

___
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

[rpms/perl-NetAddr-IP] PR #2: Update license to SPDX format

[Michal Josef Špaček]

mspacek opened a new pull-request against the project: `perl-NetAddr-IP` that 
you are following:
``
Update license to SPDX format
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-NetAddr-IP/pull-request/2
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 1937653] Upgrade perl-HTTP-OAI to 4.12

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 CC||ppi...@redhat.com
   Assignee|vano...@gmail.com   |ppi...@redhat.com
 Status|NEW |ASSIGNED




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1937653
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Old stalled bodhi updates

[Dominik 'Rathann' Mierzejewski]

On Wednesday, 31 May 2023 at 09:08, Mattia Verga via devel wrote:
> Il 30/05/23 22:15, Adam Williamson ha scritto:
> >
> > https://bodhi.fedoraproject.org/updates/FEDORA-2022-f563346d4d is
> > similar, but this time it was ejected from its push *to stable* (not to
> > testing), again allegedly for a missing tag. The builds have now
> > actually been deleted(!), so that update can never be pushed as-is, I
> > don't think. We would probably have to bump and rebuild both packages
> > and edit the new builds into the update, then try pushing it again.
> > CCing the maintainer of that one (Dan).
> 
> FEDORA-2022-f563346d4d can't be pushed to stable because the i3 build 
> was superseded by FEDORA-2023-6e1ee729b9, but the older update was not 
> obsoleted because it also has i3-gaps build which was not superseded by 
> anything.

i3-gaps was merged into i3 and is properly obsoleted:
https://src.fedoraproject.org/rpms/i3/c/d81eb788e22d69ffd697f6b00a4de07a978f6722?branch=f37

> So, I think the update needs to be unpushed.

Indeed, done using my PP access.

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

pyproject-rpm-macros 1.9.0: Support for passing config_settings to the build backend

[Miro Hrončok]

Hello Pythonistas,

Let me announce the release of pyproject-rpm-macros 1.9.0.

The new version is available in Rawhide+ELN Koji and updates are penfing for 
older Fedora releases. A sync to c9s is in progress but will require a review, 
so it might take longer.



The new version has the following changes compared to 1.8.0:


Allow passing config_settings to the build backend
==

Contributed by Maxwell G (@gotmax23), thank you!

From the README:

---
The %pyproject_buildrequires and %pyproject_wheel macros accept a -C flag to 
pass configuration settings [1] to the build backend. Options take the form of 
-C KEY, -C KEY=VALUE, or -C--option-with-dashes. Pass -C multiple times to 
specify multiple options. This option is equivalent to pip's --config-settings 
flag. These are passed on to PEP 517 hooks' config_settings argument as a 
Python dictionary.


The %pyproject_buildrequires macro passes these options to the 
get_requires_for_build_wheel and prepare_metadata_for_build_wheel hooks. 
Passing -C to %pyproject_buildrequires is incompatible with -N which does not 
call these hooks at all.


The %pyproject_wheel macro passes these options to the build_wheel hook.

Consult the project's upstream documentation and/or the corresponding build 
backend's documentation for more information. Note that some projects don't use 
config settings at all and other projects may only accept config settings for 
one of the two steps.


Note that the current implementation of the macros uses pip to build wheels. On 
some systems (notably on RHEL 9 with Python 3.9), pip is too old to understand 
--config-settings. Using the -C option for %pyproject_wheel (or 
%pyproject_buildrequires -w) is not supported there and will result to an error 
like:


Usage:
  /usr/bin/python3 -m pip wheel [options]  ...
  ...
no such option: --config-settings

[1] https://peps.python.org/pep-0517/#config-settings
---

Previously, packagers needed to patch for this:
https://src.fedoraproject.org/rpms/python-scikit-misc/c/3dda47b4b7



On Python older than 3.11, use tomli instead of deprecated toml
===

All currently supported Fedora releases have Python 3.11, so this has not a big 
effect except for EL 9. However, all packages had generated this BuildRequires:


(python3dist(toml) if python3-devel < 3.11)

This will now be:

(python3dist(tomli) if python3-devel < 3.11)

Such build requirements in Fedora manifests themselves in the results of dnf 
repoquery --wahtrequires python3-toml(i).




Fix literal % handling in %{pyproject_files} on RPM 4.19


If your package has files with literal % signs in the filenames, it was briefly 
broken on Fedora Rawhide, because RPM 4.19 now requires 2 % signs to escape 
them in the filelist (it was 8 in RPM 4.16 and 4.17). This has now been fixed.


Unfortunately, to support both RPM 4.19 and older ones, there is a conditional 
in %pyproject_save_files which checks the Fedora version. If you run old RPM on 
Fedora 39 or new RPM on older Fedoras and ahve literal % signs in filenames, it 
will break. I have requested an %rpmversion macro from RPM and it was added 
upstream. Once propagated to Fedora, the conditional will be replaced.




Happy packaging!
--
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

Re: Self Introduction: Herald Yu Betty Liu

[Benson Muite]

On 6/1/23 13:09, Betty Liu wrote:
> Hi I also come from China ~ I'm Betty and now I'm learning about how to 
> become a packager (so I think it's not the time to do a self-introduction in 
> devel now hhh)
> 
> Nice to have someone come from the same country! If you have the time maybe 
> you can teach me about packaging and community! You can find more about me 
> here https://acyanbird.com/ www
你好欢迎  (Hello! Welcome!). You may find it helpful to join a SIG[1], for
example Deepin[2] has a need for packagers and mandarin skills are
useful to co-ordinate with upstream. Kernel development and testing
might also be of interest[3].

1) https://fedoraproject.org/wiki/Category:SIGs
2) https://fedoraproject.org/wiki/SIGs/DeepinDE
3) https://docs.fedoraproject.org/en-US/quick-docs/kernel/overview/
___
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

[rpms/perl-Scalar-List-Utils] PR #3: Update license to SPDX format

[Michal Josef Špaček]

mspacek opened a new pull-request against the project: `perl-Scalar-List-Utils` 
that you are following:
``
Update license to SPDX format
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Scalar-List-Utils/pull-request/3
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[rpms/perl-Scalar-List-Utils] PR #2: Update license to SPDX format

[Michal Josef Špaček]

mspacek closed without merging a pull-request against the project: 
`perl-Scalar-List-Utils` that you
are following.

Closed pull-request:

``
Update license to SPDX format
``

https://src.fedoraproject.org/rpms/perl-Scalar-List-Utils/pull-request/2
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: libnfs soname bump

[Richard W.M. Jones]

On Thu, Jun 01, 2023 at 08:34:18AM +0100, Richard W.M. Jones wrote:
> qemu is building now:
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=101710059

This failed because of the data center shutdown, second attempt:

https://koji.fedoraproject.org/koji/taskinfo?taskID=101716211

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
nbdkit - Flexible, fast NBD server with plugins
https://gitlab.com/nbdkit/nbdkit
___
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]

> Il 02/06/23 01:55, Sandro ha scritto:
> I'm having a bad feeling about Fedora future lately, seeing all these RH 
> withdrawals from the project.

That escalated quickly, yes. More worryingly: It escalated non-openly and 
non-collaboratively.

> I hope to be wrong. But could Fedora survive the day RH says goodbye? 
> Shall we start thinking about having a structure (both government and 
> financial) like libreoffice foundation?

We depend quite a bit on infrastructure (both technical and staff-wise) which 
RedHat still provides generously to us. RH being a profit oriented company (or 
rather, part of an even more profit oriented company), "generous" probably is a 
naive description. They have to justify every investment, of course. 
Apparently, the terms for that justification changed with new stakeholders. I 
don't think that Fedora has changed a lot since. Maybe a governing structure 
outside of RedHat would make it easier for them to support Fedora, 
"lump-sum-wise" (money, man-years), because it would lift their requirement to 
justify each and every individual "item"?

> BTW dropping RPMs for Flatpaks makes the whole Fedora philosophy 
> useless. Flatpaks just bundles what they need, free software or not 
> (i.e. codecs support) so upstreams have no interest in find OSS solutions.

Exactly. To me that seems to be the bigger problem, and it has been developping 
in that direction for a while already:
- Fedora flatpaks never took off, both for technical reasons (it's still 
difficult for packagers) and ideological ones (marketing of flatpaks vs 
reality); both related to the way modules came upon us.
- Codecs/Multimedia were never easy in Fedora; using (and providing) rpmfusion 
is made difficult by feature-reduced versions in Fedora, and by the fact that 
we cannot even include disabled repo config for them in Fedora.
- Flathub flatpak config considered to be OK in Fedora by RH legal *because it 
is not Fedora specific* (as opposed to rpmfusion).

Taking all this together, the direction is: Sell the OS (that is, support and 
assurances) and let the customer be responsible for what "apps" they run on 
that OS (from flathub or wherever). Fedora flatpaks do not have any place there 
(and solve no problem).

I doubt whether that really is what customers want from RedHat. But I'm sure 
that is nothing which Fedora packagers want to be the upstream for. We'd flock 
elsewhere, be it distro A for its technical orientation, distro D for its 
stance on freedom, or some package upstreams to help with that flatpak, on 
whatsoever distro that will run on.
___
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 Vanek]

Damn thats a long list.

On 6/2/23 01:21, Kevin Kofler via devel wrote:

Gwyn Ciesla via devel wrote:

I've taken ownership of libreoffice for the time being, at least to keep
the lights on.


Also of the many dependencies?

As far as I can tell, from the list in the orphaned package report, all
these are part of the LibreOffice stack:

flute orphan   0 weeks ago
hunspell  alexl, gnome-sig, mbarnes,   0 weeks ago
   orphan, rhughes, rstrode
hunspell-af   orphan   0 weeks ago
hunspell-ak   orphan   0 weeks ago
hunspell-am   orphan   0 weeks ago
hunspell-ast  orphan   0 weeks ago
hunspell-az   orphan   0 weeks ago
hunspell-be   orphan   0 weeks ago
hunspell-ber  orphan   0 weeks ago
hunspell-bg   orphan   0 weeks ago
hunspell-br   orphan   0 weeks ago
hunspell-ca   orphan   0 weeks ago
hunspell-cop  orphan   0 weeks ago
hunspell-csb  orphan   0 weeks ago
hunspell-cv   orphan   0 weeks ago
hunspell-cy   orphan   0 weeks ago
hunspell-da   orphan   0 weeks ago
hunspell-dsb  orphan   0 weeks ago
hunspell-el   orphan   0 weeks ago
hunspell-en   alexl, gnome-sig, mbarnes,   0 weeks ago
   orphan, rhughes, rstrode
hunspell-eo   orphan   0 weeks ago
hunspell-es   olea, orphan 0 weeks ago
hunspell-et   orphan   0 weeks ago
hunspell-fa   orphan   0 weeks ago
hunspell-fj   orphan   0 weeks ago
hunspell-fo   orphan   0 weeks ago
hunspell-fr   orphan, remi 0 weeks ago
hunspell-fur  orphan   0 weeks ago
hunspell-fy   orphan   0 weeks ago
hunspell-ga   orphan   0 weeks ago
hunspell-gd   orphan   0 weeks ago
hunspell-gl   orphan   0 weeks ago
hunspell-grc  orphan   0 weeks ago
hunspell-gv   orphan   0 weeks ago
hunspell-haw  orphan   0 weeks ago
hunspell-hil  orphan   0 weeks ago
hunspell-hr   orphan   0 weeks ago
hunspell-hsb  orphan   0 weeks ago
hunspell-ht   orphan   0 weeks ago
hunspell-hu   orphan   0 weeks ago
hunspell-hy   orphan   0 weeks ago
hunspell-ia   orphan   0 weeks ago
hunspell-id   orphan   0 weeks ago
hunspell-is   orphan   0 weeks ago
hunspell-it   orphan   0 weeks ago
hunspell-kk   orphan   0 weeks ago
hunspell-km   orphan   0 weeks ago
hunspell-ko   orphan   0 weeks ago
hunspell-ku   orphan   0 weeks ago
hunspell-ky   orphan   0 weeks ago
hunspell-la   orphan   0 weeks ago
hunspell-lb   orphan   0 weeks ago
hunspell-ln   orphan   0 weeks ago
hunspell-lt   orphan   0 weeks ago
hunspell-mg   orphan   0 weeks ago
hunspell-mi   orphan   0 weeks ago
hunspell-mk   orphan   0 weeks ago
hunspell-mn   

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

[Jiri Vanek]

On 6/2/23 01:09, Kevin Kofler via devel wrote:

Demi Marie Obenour wrote:

I haven’t written Java in years, but my understanding is
that AOT compilation has three major advantages:

1. It reduces the size of total deliverables because the
final executable only includes the libraries it needs.


This may be true for real AOT compilation where the result is really
independent of a JRE (e.g., what GCJ, which is no longer maintained, used to
produce by default), but if the AOT compilation requires you to bundle the
whole JRE (and that is the only case where having a statically vs.
dynamically linked JRE matters), the total deliverable size is going to be
much larger.


Interesting discusson, indeed!

The aot should create portable minialistic image.
If you build it from dynamicaly linked JDK, iirc, the image will not be 
trasnferable (as it will still require those dynamicaly linked libraries).
As fot rhe size, werer the goal of minimalistic was there, it si proving to not 
be exactly true, and final iage is quite big.




2. It is the _only_ way to have decent performance on
platforms where JIT compilation is forbidden.


That is also irrelevant in this thread: If it matters how the JRE is linked,
the AOT-compiled output includes a bundled copy of the GNU/Linux JRE
(otherwise why would it matter?), so it will only run on GNU/Linux, which is
NOT a "platform where JIT compilation is forbidden". (There is only really
one such platform, iOS with Apple's totalitarian app store rules.)


Java without JIT is useles for anythingbigger then hello world:(



3. AOT-compiled apps start up faster and use less memory.


That part may be true, but there too, if we are talking about a solution
that includes bundling the JRE, I doubt it.



This is actually the only reason I'm finding as really valid. In world of micro 
services, which even run with epsilongc, this is saving enourmous resources.

> necessary because Java applications are NOT designed to be built like native
> applications (e.g., pure AOT compilation without a JIT and/or interpreter
> fallback cannot handle classes loaded at runtime, such as dynamically
> generated or downloaded class files). Many applications worked with GCJ only

I agree that java is not designed tobebuilt lilenative app, and that is why 
gaarl/mandrel and qaurkus are so terribly complicated. Future will show.



Thanx!
 J.
___
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 01:55, Sandro ha scritto:
>
> However, it surprises me that for a package, that is part of the
> deliverables of Fedora releases, no coordination effort was made to
> transition the package from Red Hat maintenance to Fedora maintenance. I
> would even go as far as that this should have been submitted as a change
> proposal, seeing that the package is in every (live) ISO Fedora ships.
>
> Instead the package is being dropped like a hot potato, without even the
> courtesy of an announcement beforehand [2].
>
I'm having a bad feeling about Fedora future lately, seeing all these RH 
withdrawals from the project.

I hope to be wrong. But could Fedora survive the day RH says goodbye? 
Shall we start thinking about having a structure (both government and 
financial) like libreoffice foundation?

BTW dropping RPMs for Flatpaks makes the whole Fedora philosophy 
useless. Flatpaks just bundles what they need, free software or not 
(i.e. codecs support) so upstreams have no interest in find OSS solutions.

Mattia

___
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