Re: Non-responsive maintainer check for Michal Ambroz a.k.a. rebus

[Mattia Verga via devel]

Il 23/08/22 22:36, zonexpertconsult...@outlook.com ha scritto:

> Does anyone know how to contact Michal Ambroz a.k.a. rebus?
>
> https://bugzilla.redhat.com/show_bug.cgi?id=2120834
>
> This is blocking the ZoneMinder package in RPMFusion:
> https://bugzilla.redhat.com/show_bug.cgi?id=2115572
>
> Thanks,
> Andy

Accordingly to src.fp.o stats they are active:

https://src.fedoraproject.org/api/0/user/rebus/activity/stats

It's August, so people could be on vacation... the relevant bug was opened on 
4th August, so a non-responsive maintainer ticket seems a bit premature to me...

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

[Bug 1934532] EPEL8 Request: perl-Astro-FITS-CFITSIO

[bugzilla]

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



--- Comment #2 from Orion Poplawski  ---
https://pagure.io/releng/fedora-scm-requests/issue/46777


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1934532
___
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

abipkgdiff - indirect sub-type changes

[Orion Poplawski]

Not sure what to make of this abipkgdiff report:

 changes of 'libcfitsio.so.9.4.0.0'===
  Functions changes summary: 0 Removed, 239 Changed, 0 Added functions
  Variables changes summary: 0 Removed, 0 Changed, 0 Added variable

  239 functions with some indirect sub-type change:

[C] 'function void ftasfm_(char*, int*, int*, int*, int*, unsigned 
int)' at f77_wrap1.c:340:1 has some indirect sub-type changes:

  parameter 6 of type 'unsigned int' changed:
entity changed from 'unsigned int' to compatible type 'typedef 
size_t' at stddef.h:214:1

  type name changed from 'unsigned int' to 'unsigned long int'
  type size changed from 32 to 64 (in bits)

[C] 'function void ftbnfm_(char*, int*, int*, int*, int*, unsigned 
int)' at f77_wrap1.c:341:1 has some indirect sub-type changes:


[C] 'function void ftc2d_(char*, double*, int*, unsigned int)' at 
f77_wrap4.c:420:1 has some indirect sub-type changes:

  parameter 4 of type 'unsigned int' changed:
entity changed from 'unsigned int' to compatible type 'typedef 
size_t' at stddef.h:214:1

  type name changed from 'unsigned int' to 'unsigned long int'
  type size changed from 32 to 64 (in bits)

[C] 'function void ftc2dd_(char*, double*, int*, unsigned int)' at 
f77_wrap4.c:415:1 has some indirect sub-type changes:


[C] 'function void ftc2i_(char*, int*, int*, unsigned int)' at 
f77_wrap4.c:418:1 has some indirect sub-type changes:


[C] 'function void ftc2ii_(char*, int*, int*, unsigned int)' at 
f77_wrap4.c:412:1 has some indirect sub-type changes:


[C] 'function void ftc2l_(char*, int*, int*, unsigned int)' at 
f77_wrap4.c:421:1 has some indirect sub-type changes:


[C] 'function void ftc2ll_(char*, int*, int*, unsigned int)' at 
f77_wrap4.c:413:1 has some indirect sub-type changes:


[C] 'function void ftc2r_(char*, float*, int*, unsigned int)' at 
f77_wrap4.c:419:1 has some indirect sub-type changes:


[C] 'function void ftc2rr_(char*, float*, int*, unsigned int)' at 
f77_wrap4.c:414:1 has some indirect sub-type changes:


[C] 'function void ftc2s_(char*, char*, int*, unsigned int, 
unsigned int)' at f77_wrap4.c:417:1 has some indirect sub-type changes:

  parameter 5 of type 'unsigned int' changed:
entity changed from 'unsigned int' to compatible type 'typedef 
size_t' at stddef.h:214:1

  type name changed from 'unsigned int' to 'unsigned long int'
  type size changed from 32 to 64 (in bits)

[C] 'function void ftc2x_(char*, char*, int*, int*, char*, double*, 
int*, unsigned int, unsigned int, unsigned int)' at f77_wrap4.c:416:1 
has some indirect sub-type changes:

  parameter 8 of type 'unsigned int' changed:
entity changed from 'unsigned int' to compatible type 'typedef 
size_t' at stddef.h:214:1

  type name changed from 'unsigned int' to 'unsigned long int'
  type size changed from 32 to 64 (in bits)
  parameter 9 of type 'unsigned int' changed:
entity changed from 'unsigned int' to compatible type 'typedef 
size_t' at stddef.h:214:1

  type name changed from 'unsigned int' to 'unsigned long int'
  type size changed from 32 to 64 (in bits)
  parameter 10 of type 'unsigned int' changed:
entity changed from 'unsigned int' to compatible type 'typedef 
size_t' at stddef.h:214:1

  type name changed from 'unsigned int' to 'unsigned long int'
  type size changed from 32 to 64 (in bits)

[C] 'function void ftcalc_(int*, char*, int*, char*, char*, int*, 
unsigned int, unsigned int, unsigned int)' at f77_wrap4.c:549:1 has some 
indirect sub-type changes:

  parameter 7 of type 'unsigned int' changed:
entity changed from 'unsigned int' to compatible type 'typedef 
size_t' at stddef.h:214:1

  type name changed from 'unsigned int' to 'unsigned long int'
  type size changed from 32 to 64 (in bits)

[C] 'function void ftcalc_rng_(int*, char*, int*, char*, char*, 
int*, int*, int*, int*, unsigned int, unsigned int, unsigned int)' at 
f77_wrap4.c:553:1 has some indirect sub-type changes:

  parameter 11 of type 'unsigned int' changed:
entity changed from 'unsigned int' to compatible type 'typedef 
size_t' at stddef.h:214:1

  type name changed from 'unsigned int' to 'unsigned long int'
  type size changed from 32 to 64 (in bits)
  parameter 12 of type 'unsigned int' changed:
entity changed from 'unsigned int' to compatible type 'typedef 
size_t' at stddef.h:214:1

  type name changed from 'unsigned int' to 'unsigned long int'
  type size changed from 32 to 64 (in bits)

[C] 'function void ftcell2im_(int*, int*, char*, int*, int*, 
unsigned int)' at f77_wrap3.c:783:1 has some indirect sub-type changes:


[C] 'function void ftcmps_(char*, char*, int*, int*, int*, unsigned 
int, unsigned int)' at f77_wrap1.c:328:1 has some 

Re: F38 proposal: Pcre Deprecation (System-Wide Change proposal)

[Gary Buhrmaster]

On Wed, Aug 24, 2022 at 3:14 AM Kevin Kofler via devel
 wrote:

...
> This is simply a non-starter.
...
> PCRE 1 needs to remain as a fully supported compatibility library for the
> foreseeable future.
...
> In the end, my suggestion if you are unable to deal with the security
> vulnerabilities is to simply orphan the library and let someone else pick it
> up. (If nobody else does, I will, because at least 3 of my packages depend
> on it.)

And thank you for volunteering.  This is the obvious way forward
in a volunteer community.

I would, of course, recommend you request upstream commit
access to support PCRE1 going forward, as (clearly) more
than just Fedora will benefit from someone willing to take on
such support.

Thanks!
___
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: F38 proposal: Pcre Deprecation (System-Wide Change proposal)

[Kevin Kofler via devel]

Ben Cotton wrote:
> == Summary ==
> Upstream stopped the support for the old 'pcre' package. It only
> supports the new 'pcre2' version, so Fedora should deprecate it so it
> could later be retired and removed from Fedora entirely.
> 
> == Owner ==
> * Name: [[User:ljavorsk| Lukas Javorsky]]
> * Email: ljavo...@redhat.com

This is simply a non-starter.

You yourself list dozens of packages using this compatibility library. Some 
of those are themselves compatibility libraries (e.g., kdelibs 3 and 4) and 
will never be fixed by upstream. It is entirely impractical to port them to 
a completely different API. But even current leaf packages such as rkward 
are in the list.

PCRE 1 needs to remain as a fully supported compatibility library for the 
foreseeable future.

> == Detailed Description ==
> Upstream stopped supporting the old 'pcre' package. The 8.45 is marked
> as a final release and nothing else will be added/fixed in it. This
> may lead to some unresolved CVEs, which would have to be resolved by
> the maintainers. Unfortunately, due to our limited capacity, we
> wouldn't have the time and experience to solve this by ourselves, so
> we need to deprecate this package. After the deprecation is done, the
> very next step would be starting the [[PcreRetirement|retirement
> change]], so the package is removed from Fedora entirely.

How different is the code from the pcre2 code? If it is completely 
different, then CVEs found in pcre2 will typically not affect the legacy 
code, and you can expect a steep drop in found CVEs with the upstream drop 
of support. If, on the other hand, it is sufficiently similar for the CVEs 
to apply, then the fixes can also be backported.

In the end, my suggestion if you are unable to deal with the security 
vulnerabilities is to simply orphan the library and let someone else pick it 
up. (If nobody else does, I will, because at least 3 of my packages depend 
on it.)

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

Re: GNOME's Icon Development Kit icons potentially causing implicit conflicts

[Maxwell G via devel]

On Tuesday, August 23, 2022 Elliott Sales de Andrade wrote:
> > The CC0 has been banned for new packages in Fedora.
> 
> Banned for code, not content. Icons are not code.

Good point! Thanks for the correction.

-- 
Maxwell G (@gotmax23)
Pronouns: He/Him/His

signature.asc
Description: This is a digitally signed message part.
___
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: GNOME's Icon Development Kit icons potentially causing implicit conflicts

[Elliott Sales de Andrade]

On Tue, Aug 23, 2022 at 10:59 PM Maxwell G via devel
 wrote:
>
> On Tuesday, August 23, 2022 Lyes Saadi wrote:
> > Fortunately, Icon Development Kit is under CC0, so we're kinda saved
> > from a Licensing apocalypse (although, I have to admit that this is not
> > ideal).
>
> The CC0 has been banned for new packages in Fedora.
>

Banned for code, not content. Icons are not code.


--
Elliott
___
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: GNOME's Icon Development Kit icons potentially causing implicit conflicts

[Maxwell G via devel]

On Tuesday, August 23, 2022 Lyes Saadi wrote:
> Fortunately, Icon Development Kit is under CC0, so we're kinda saved
> from a Licensing apocalypse (although, I have to admit that this is not
> ideal).

The CC0 has been banned for new packages in Fedora.

-- 
Maxwell G (@gotmax23)
Pronouns: He/Him/His

signature.asc
Description: This is a digitally signed message part.
___
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: F37 side tag after branching point

[Maxwell G via devel]

On Tuesday, August 23, 2022 1:16:00 PM CDT Iñaki Ucar wrote:
> We have a new R version sitting on a side tag (f37-build-side-55653)
> for a few weeks now, where packages are being rebuilt as time permits.

Can this perhaps be handled differently next time? I admit that I'm not 
familiar with the R ecosystem, so the answer may be no. Side tags are not 
meant to be open for this long. So far, this R rebuild has caused a lot of 
problems (see "The R stack in Rawhide is on fire"). What are the issues that 
prevent the rebuild from happening all at once? Can it be staged in COPR to 
make sure nothing will break? Can the packages be built all at once with a 
script?

> Unfortunately, F37 is not rawhide anymore, so the question is whether
> this side tag could be safely merged both in F37 and rawhide when it
> is ready.

I'll defer to the releng folks, but I think you should be able to merge the 
sidetag normally through the Bodhi interface, though it will be for f37 and 
not rawhide. You'll have to rebuild everything in rawhide.

-- 
Thanks,

Maxwell G (@gotmax23)
Pronouns: He/Him/His

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

[EPEL-devel] Re: Orphaning EPEL Branches

[Neal Gompa]

On Tue, Aug 23, 2022 at 9:00 PM Maxwell G  wrote:
>
> On Tuesday, August 23, 2022 7:49:15 PM CDT Neal Gompa wrote:
> > > * The Pagure API does not allow tagging existing issues. I had planned to
> > > liberally use tags to manage the issues.
> >
> > What? You can do this with the "update issue information" API call:
> > https://pagure.io/api/0/#issues-tab
>
> According to the documentation, the only valid inputs to "Update issue
> information" are "title" and "issue_content". https://pagure.io/pagure/issue/
> 4761 was opened for this and never closed. Is there some undocumented
> parameter?
>

Nope, I misread this. Sorry.



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

[EPEL-devel] Re: Orphaning EPEL Branches

[Maxwell G via epel-devel]

On Tuesday, August 23, 2022 7:49:15 PM CDT Neal Gompa wrote:
> > * The Pagure API does not allow tagging existing issues. I had planned to
> > liberally use tags to manage the issues.
> 
> What? You can do this with the "update issue information" API call:
> https://pagure.io/api/0/#issues-tab

According to the documentation, the only valid inputs to "Update issue 
information" are "title" and "issue_content". https://pagure.io/pagure/issue/
4761 was opened for this and never closed. Is there some undocumented 
parameter?

-- 
Thanks,

Maxwell G (@gotmax23)
Pronouns: He/Him/His

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

GNOME's Icon Development Kit icons potentially causing implicit conflicts

[Lyes Saadi]

Hello devel,

I recently packaged blackbox-terminal, but, someone packaging another 
app, extension-manager noticed that his package conflicted with mine, 
and a `dnf whatprovides` later noticed that it also conflicted with 
cozy*. I soon discovered that all those apps shared icons from the Icon 
Development Kit[1] app, mostly known thanks to Icon Library[2].


Icon Library instruct developers to include these icons in a gresource 
file, basically hard coding them into the app. But, it seems that this 
is not followed by all app developers, and that some install them 
directly in `/usr/share/icons/hicolor/`.


There are multiple other apps packaged in Fedora out there using these 
icons. And it is likely that some of them are causing implicit conflicts 
we haven't caught (Note: fortunately, that does not seem to be the case, 
look at the end note). And, this problem will only worsen with time.


So, if you are a maintainer of a GNOME app, please check if your app is 
concerned. Especially since most packagers "glob" icons in the %files 
section.


Fortunately, Icon Development Kit is under CC0, so we're kinda saved 
from a Licensing apocalypse (although, I have to admit that this is not 
ideal).


From there, packagers who have noticed the conflict have three options 
at their disposal:


1- Using gresource files, or
2- Renaming the icons by appending the app's name or uuid, or
3- Install them somewhere else, like in /usr/share/%{name}/icons

Both require patching the source code of the app, and quite a bit of effort.

Another option would be to package those icons, and delete all icons 
concerned from what the app installs (maybe using a macro to simplify 
things), and make the app depend on the package containing these icons.


Another question we should ask ourselves is how to prevent those 
conflicts from slipping by in the distribution in the Future.


Regards,
Lyes Saadi

---
Note:
I've decided before sending this e-mail to check which packages have 
installed in /usr/share/icons/hicolor an icon for which an icon with a 
similar name exists in Icon Development Kit. My script seems to have 
some errors, I thus might have missed some, but it already took me 1h30 
to execute it, so I'll try to fix it another day. Anyway, here is the list:


cozy
gnome-system-monitor
geary
notejot
gnome-control-center

Fortunately, the number of affected packages is limited, but the fact 
that some core apps are there show that no package is immune from this 
problem.

---

* not all of them are from the Icon Development Kit.

[1]: https://gitlab.gnome.org/Teams/Design/icon-development-kit
[2]: https://apps.gnome.org/fr/app/org.gnome.design.IconLibrary/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[EPEL-devel] Re: Orphaning EPEL Branches

[Neal Gompa]

On Tue, Aug 23, 2022 at 8:42 PM Maxwell G via epel-devel
 wrote:
>
> On Wednesday, August 10, 2022 4:07:29 PM CDT Troy Dawson wrote:
> > On Sun, Aug 7, 2022 at 12:31 PM Kevin Fenzi  wrote:
> > > On Sat, Aug 06, 2022 at 10:05:40PM +0200, Maxwell G via epel-devel wrote:
> > > > We could create an issue tracker for this. Packagers would have to
> > > > submit a ticket requesting to orphan a certain package's EPEL branch(es)
> > > > and set the EPEL Bugzilla assignee to "orphan" if they're orphaning all
> > > > active EPEL branches. epel-devel@ could be CC'd on all issues. Then, we
> > > > could have a provenpackager in the SIG go through and manually retire
> > > > the packages that haven't been picked up after six weeks. The later will
> > > > be difficult if we have a large volume, but I don't expect that. We
> > > > could script this if necessary or just ask the submitter to do it
> > > > themself.
> > > >
> > > > This doesn't allow picking up packages in a self-service manner, but I
> > > > don't think that's a huge deal for our case.
> >
> > After some discussion in our weekly EPEL Steering Committee meeting
> > Maxwell's idea seems to lead the way.
> > Maxwell has setup of pagure repo, to track these orphan issues.
> > A pagure repo gives us the opportunity to have a nice README that people
> > can see if they are unsure of the process.
> > A pagure issue also seems more user friendly than a bugzilla.  Both for the
> > person creating the issue, and for others tracking it.
> >
> > https://pagure.io/epel/package-orphan-requests
>
>
> So, I've started working on this. So far, I have a structured issue template,
> and I've started writing a tool to go through the issues and act on them
> (creating an announcement, etc.
> While I had originally wanted to use a Pagure issue tracker, I decided to
> switch to Gitlab half way through. There were three reasons:
>
> * The Pagure API does not allow tagging existing issues. I had planned to
> liberally use tags to manage the issues.

What? You can do this with the "update issue information" API call:
https://pagure.io/api/0/#issues-tab

This is done by the CentOS Hyperscale folks for the package-updates
tracker: https://pagure.io/centos-sig-hyperscale/package-updates

The automation for it is present in that repo.


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

[EPEL-devel] Re: Orphaning EPEL Branches

[Maxwell G via epel-devel]

On Wednesday, August 10, 2022 4:07:29 PM CDT Troy Dawson wrote:
> On Sun, Aug 7, 2022 at 12:31 PM Kevin Fenzi  wrote:
> > On Sat, Aug 06, 2022 at 10:05:40PM +0200, Maxwell G via epel-devel wrote:
> > > We could create an issue tracker for this. Packagers would have to
> > > submit a ticket requesting to orphan a certain package's EPEL branch(es)
> > > and set the EPEL Bugzilla assignee to "orphan" if they're orphaning all
> > > active EPEL branches. epel-devel@ could be CC'd on all issues. Then, we
> > > could have a provenpackager in the SIG go through and manually retire
> > > the packages that haven't been picked up after six weeks. The later will
> > > be difficult if we have a large volume, but I don't expect that. We
> > > could script this if necessary or just ask the submitter to do it
> > > themself.
> > > 
> > > This doesn't allow picking up packages in a self-service manner, but I
> > > don't think that's a huge deal for our case.
>
> After some discussion in our weekly EPEL Steering Committee meeting
> Maxwell's idea seems to lead the way.
> Maxwell has setup of pagure repo, to track these orphan issues.
> A pagure repo gives us the opportunity to have a nice README that people
> can see if they are unsure of the process.
> A pagure issue also seems more user friendly than a bugzilla.  Both for the
> person creating the issue, and for others tracking it.
> 
> https://pagure.io/epel/package-orphan-requests


So, I've started working on this. So far, I have a structured issue template, 
and I've started writing a tool to go through the issues and act on them 
(creating an announcement, etc. 
While I had originally wanted to use a Pagure issue tracker, I decided to 
switch to Gitlab half way through. There were three reasons:

* The Pagure API does not allow tagging existing issues. I had planned to 
liberally use tags to manage the issues.
* Gitlab already has a nice Python wrapper (python-gitlab), which is much 
easier to work with.
* It's more future proof, as the state of Pagure in Fedora is a bit up in the 
air.

I really appreciate Pagure, and I wanted to make it work, but I'm trying to be 
pragmatic. Currently, the plan for identity verification is to make sure the 
sure the user is a member of the Fedora group on Gitlab. For non-matching 
usernames, I should be able to provide a dedicated field for that and cross 
reference the custom username with the FAS Gitlab field. Does anybody know if 
it's possible to limit issue submissions to only Fedora members while keeping 
the issue tracker public? That would make this easier.


I have one question: who should be able to orphan EPEL branches? In Fedora, 
it's only the main 
admin. Do we also want to open this up to people with other privileges? 
Currently, anybody with any type of write permissions on a repository can 
retire the package. If the actual people who maintain the EPEL branches don't 
have permissions to orphan EPEL branches, I worry it will make the policy 
ineffective.

> The policy isn't setup yet, but we are moving in the right direction.

Indeed :).

-- 
Thanks,

Maxwell G (@gotmax23)
Pronouns: He/Him/His

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

Re: Advice needed: Pantheon desktop broken on Fedora 37 (yes, worse than usual)

[Miro Hrončok]

On 23. 08. 22 23:46, Fabio Valentini wrote:

even if the advice is: "yes, retire the packages, rather
than leave them broken, they can be added back once they have been
fixed"


Knowing nothing about Pantheon or GObject C, I do think this is always better 
than noninstallable packages. So if all other efforts fail, I would retire the 
packages before Final Freeze and only introduce them back if ever fixed.


Yes, it may be emotionally a bit painful, but IMHO it gives a clearer message 
to our users if the package is missing rather than utterly broken.


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

Re: Advice needed: Pantheon desktop broken on Fedora 37 (yes, worse than usual)

[Michael Catanzaro]

On Tue, Aug 23 2022 at 11:46:26 PM +0200, Fabio Valentini 
 wrote:

- elementary-mail: https://github.com/elementary/mail/issues/793
broken because it uses webkit2gtk-4.0, but also evolution-data-server,
which has moved to libsoup3
fails to build / install on Fedora 37+


If this one does not directly use libsoup2, then you can probably save 
it by just patching the pkg-config API version from webkit2gtk-4.0 -> 
webkit2gtk-4.1. The only difference between -4.0 and -4.1 is the 
libsoup version.


I'm afraid that won't be enough for the other applications that use 
both libsoup and evolution-data-server, though. :/


Michael

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

Advice needed: Pantheon desktop broken on Fedora 37 (yes, worse than usual)

[Fabio Valentini]

Hello all,

I'm not quite sure how to approach this problem, but as it stands, the
packages for the Pantheon DE and associated "elementary" applications
will probably be mostly broken when Fedora 37 will be released.

Every major GNOME update comes with problems for Pantheon (especially
due to mutter API changes), but this time is *much* worse due to the
additional libsoup 2 -> 3 transition.

Upstream development of the Pantheon / elementary projects is now
focused on finally getting elementary OS 7 out the door (which was
already supposed to have happened, it will be based on ubuntu 22.04
LTS, after all). Support for things that are in the far-off future
(like libsoup3, webkit2gtk-4.1, etc.) are low priority for them,
especially given their diminished manpower.

(The list of currently broken or "in danger of being broken on Fedora
38+" applications and components is included below, including links to
upstream tickets.)

I am already at my limit with the time that I can invest into Fedora,
and GObject C is the bane of my existence - so I can't really help
with these porting efforts, and upstream development is (rightfully
so) focused on their own, more important problems right now.

I doubt that these problems will be fixed in time for the release of
Fedora 37. And because many of these problems result in outdated,
crashing, failing-to-install or failing-to-build packages, I don't
think this is a good outcome at all, least for my users. Rather than
leave the DE available, but in an utterly broken and useless state,
I'd rather remove it from Fedora 37 altogether.

This set of packages also has at least some sentimental value to me,
because they were my first contributions to Fedora - first in COPR,
then getting them through package review (my first review request was
for the granite GTK widget library for elementary applications, which
was reviewed by rathann and ngompa).

The Pantheon components and elementary apps are also probably the
packages with the biggest number of actual users (the combination of
"Pantheon on Fedora" is quite popular for something that's not
available as an official Spin), maybe except for Syncthing, among all
the packages that I maintain.

So, I don't see any "good" way to handle this right now. If somebody
can give me any advice for what to do in this situation, I would be
grateful (even if the advice is: "yes, retire the packages, rather
than leave them broken, they can be added back once they have been
fixed").

Thanks,
Fabio



Some critical Pantheon DE components that are currently broken:

- gala (window manager): https://github.com/elementary/gala/issues/1447
broken due to mutter API changes between 43.alpha and 43.beta
fails to build + fails to install on Fedora 37+

- elementary-greeter (LightDM greeter):
https://github.com/elementary/greeter/issues/617
broken due to mutter API changes
fails to build + fails to install on Fedora 37+

- wingpanel (top panel, application launcher, indicators, etc.):
https://github.com/elementary/wingpanel/issues/462
broken due to broken gala, and also because of mutter API changes
fails to build + fails to install on Fedora 37+

Creating a compat package for older versions of mutter has previously
worked to work around the worst problems, but it comes with its own
can of worms (i.e. you need to backport upstream patches for
compatibility with the latest gnome-settings-daemon version, etc.),
and this is not something that I can commit to doing again.

Additionally, some applications are broken:

- elementary-calendar: https://github.com/elementary/calendar/issues/756
broken because it directly links libsoup2, but also
evolution-data-server, which has transitioned to libsoup3, and
geocode-glib-1.0, which is the libsoup-2 version
fails to build / install on Fedora 37+

- elementary-mail: https://github.com/elementary/mail/issues/793
broken because it uses webkit2gtk-4.0, but also evolution-data-server,
which has moved to libsoup3
fails to build / install on Fedora 37+

- elementary-tasks: https://github.com/elementary/tasks/issues/340
broken because it uses libsoup2, but also evolution-data-server, and
geocode-glib-1.0, which is the libsoup-2 versionfails to build /
install on Fedora 37+
fails to build / install on Fedora 37+

Other applications aren't broken *yet*, but they will need to be
ported to new library versions at some point (for Fedora 38, or Fedora
39 at the latest, according to current plans for the removal of
libsoup2):

- elementary-photos: https://github.com/elementary/photos/issues/718
needs to be ported to webkit2gtk-4.1 / rest-1 / libsoup-3

- elementary-capnet-assist:
https://github.com/elementary/capnet-assist/issues/84 and 85
needs to be ported to webkit2gtk-4.1 and gcr-4.0

- switchboard-plug-onlineaccounts:
https://github.com/elementary/switchboard-plug-onlineaccounts/issues/243
needs to be ported evolution-data-server 3.45+ / libsoup-3

Non-responsive maintainer check for Michal Ambroz a.k.a. rebus

[zonexpertconsulting]

Does anyone know how to contact Michal Ambroz a.k.a. rebus?

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

This is blocking the ZoneMinder package in RPMFusion:
https://bugzilla.redhat.com/show_bug.cgi?id=2115572


Thanks,
Andy

___
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 2120834] Non-responsive maintainer check for rebus

[bugzilla]

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

Andrew Bauer  changed:

   What|Removed |Added

   Assignee|lys...@gmail.com|re...@seznam.cz
   Doc Type|--- |If docs needed, set a value
Product|Fedora  |Fedora EPEL
Version|rawhide |epel9
  Component|perl-Number-Bytes-Human |perl-Number-Bytes-Human




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2120834
___
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 2115572] Please build perl-Number-Bytes-Human for EPEL 9

[bugzilla]

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



--- Comment #3 from Andrew Bauer  ---
Non responsive maintainer check has been filed:
https://bugzilla.redhat.com/show_bug.cgi?id=2120834


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2115572
___
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 2120834] New: Non-responsive maintainer check for rebus

[bugzilla]

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

Bug ID: 2120834
   Summary: Non-responsive maintainer check for rebus
   Product: Fedora
   Version: rawhide
  Hardware: All
OS: Linux
Status: NEW
 Component: perl-Number-Bytes-Human
  Severity: medium
  Priority: medium
  Assignee: lys...@gmail.com
  Reporter: zonexpertconsult...@outlook.com
QA Contact: extras...@fedoraproject.org
CC: lys...@gmail.com, m...@fabian-affolter.ch,
perl-devel@lists.fedoraproject.org, re...@seznam.cz
  Target Milestone: ---
Classification: Fedora



This bug is part of the non-responsive maintainer procedure for rebus,
following
https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/.

Please respond if you are still active in Fedora and want to maintain the EPEL
branches of perl-Number-Bytes-Human.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2120834
___
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

F39 proposal: libsoup 3: Part two (System-Wide Change proposal)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/libsoup_3:_Part_Two

This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.


== Summary ==

libsoup 3 is a new API version of libsoup that provides support for
HTTP/2. We will remove libsoup 2 and all packages that still depend on
it.

== Owner ==
* Name: [[User:catanzaro|Michael Catanzaro]]
* Email: 


== Detailed Description ==

[[Changes/libsoup_3:_Part_One|We previously introduced libsoup 3 to
Fedora 37.]] Because applications will crash on startup if linked to
both libsoup 2 and libsoup 3 at the same time, and because many
libraries depend on libsoup, and because applications therefore have
limited control over which libsoup they link to transitively, this
transition was quite tricky and caused several serious problems during
the Fedora 37 development cycle. Fortunately, the trickiest part of
the migration to libsoup 3 is now behind us.

The next step is to remove libsoup 2 from Fedora. We propose to do
this for Fedora 39. This should happen sooner rather than later
because libsoup is a security-sensitive networking library and
maintaining an old version in Fedora indefinitely is inadvisable. We
know from experience that a deadline will be required in order to
ensure applications and libraries make the transition; otherwise, we
will wind up maintaining libsoup 2 indefinitely. Removing libsoup 2
from Fedora 38 seems too soon: applications need a little more time to
smoothly transition. Accordingly, we propose to remove libsoup 2 from
Fedora 39. The package will be retired in rawhide shortly after Fedora
38 is branched in February 2023. At this point, all packages that
still depend on it will break in rawhide. This  rest of the year will
be available to fix broken packages before Fedora 39 is released to
users in October 2023.

This will likely cause some temporary problems and force some
compromises. E.g. we may have to drop software like ABRT or geoclue
from composes if not ported in time.


== Benefit to Fedora ==

Removing libsoup 2 ensures Fedora does not package an obsolete version
of a security-sensitive networking library. It will also eliminate the
possibility of linkage conflicts between libsoup 2 and libsoup 3,
which have been extremely annoying during the Fedora 37 development
cycle and will continue to plague us during Fedora 38 development.

== Scope ==
* Proposal owners: we will ensure the package is retired

* Other developers: software must be ported from libsoup 2 to libsoup
3. This may require substantial upstream effort.

* Release engineering: [https://pagure.io/releng/issue/10985 #10985]

* Policies and guidelines: no new policies needed

* Trademark approval: N/A (not needed for this Change)

* Alignment with Objectives: no alignment with objectives

== Upgrade/compatibility impact ==

Software that still depends on libsoup 2 will break.

== How To Test ==

Fortunately not much testing is needed. The main challenge of the
transition to libsoup 3 was testing applications to ensure they do not
crash on startup due to libsoup 2 vs. libsoup 3 conflicts. Such
conflicts will no longer occur once this change is implemented,
because libsoup 2 won't exist anymore. Of course, it's also good to
test applications to ensure they still work properly after being
ported to libsoup 3.

== User Experience ==

Applications that use libsoup 3 will support HTTP/2, which multiplexes
multiple HTTP requests over a single connection. Users may notice
significant performance improvements.

== Dependencies ==

 $ dnf repoquery --whatdepends libsoup --latest-limit 1 --arch
'noarch,x86_64' --disablerepo='*' --enablerepo=rawhide
 Fedora - Rawhide - Developmental packages for t  18 MB/s |  64 MB 00:03
 Last metadata expiration check: 0:00:15 ago on Tue 23 Aug 2022 11:17:32 AM CDT.
 abrt-retrace-client-0:2.15.1-4.fc37.x86_64
 badwolf-0:1.2.2-3.fc37.x86_64
 bookworm-0:1.1.3-0.8.20200414git.c7c3643.fc37.x86_64
 cawbird-0:1.4.2-4.fc37.x86_64
 cinnamon-0:5.4.11-1.fc38.x86_64
 claws-mail-plugins-fancy-0:4.1.0-5.fc37.x86_64
 claws-mail-plugins-gdata-0:4.1.0-5.fc37.x86_64
 coin-0:1.3.0-7.fc37.x86_64
 cutter-0:1.2.7-7.fc37.x86_64
 darktable-0:4.0.0-3.fc37.x86_64
 dino-0:0.3.0-4.fc37.x86_64
 dleyna-renderer-0:0.6.0-15.fc37.x86_64
 dleyna-server-0:0.6.0-14.fc37.x86_64
 dmapd-0:0.0.91-4.fc37.x86_64
 elementary-calendar-0:6.1.1-1.fc37.x86_64
 elementary-code-0:6.2.0-2.fc37.x86_64
 elementary-mail-0:6.4.0-1.fc36.x86_64
 elementary-photos-0:2.7.5-2.fc37.x86_64
 elementary-planner-1:3.0.7-1.fc37.x86_64
 elementary-tasks-0:6.3.0-1.fc37.x86_64
 emacs-1:28.1-3.fc37.x86_64
 ephemeral-0:7.1.0-4.fc37.x86_64
 exfalso-0:4.5.0-3.fc37.noarch
 flatpak-builder-0:1.2.2-4.fc37.x86_64
 fondo-0:1.6.1-3.fc37.x86_64
 frogr-0:1.6-5.fc35.x86_64
 gajim-0:1.4.7-1.fc37.noarch
 

F38 proposal: Pcre Deprecation (System-Wide Change proposal)

[Ben Cotton]

https://fedoraproject.org/wiki/PcreDeprecation

This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.


== Summary ==
Upstream stopped the support for the old 'pcre' package. It only
supports the new 'pcre2' version, so Fedora should deprecate it so it
could later be retired and removed from Fedora entirely.

== Owner ==
* Name: [[User:ljavorsk| Lukas Javorsky]]
* Email: ljavo...@redhat.com


== Detailed Description ==
Upstream stopped supporting the old 'pcre' package. The 8.45 is marked
as a final release and nothing else will be added/fixed in it. This
may lead to some unresolved CVEs, which would have to be resolved by
the maintainers. Unfortunately, due to our limited capacity, we
wouldn't have the time and experience to solve this by ourselves, so
we need to deprecate this package. After the deprecation is done, the
very next step would be starting the [[PcreRetirement|retirement
change]], so the package is removed from Fedora entirely.

The new 'pcre2' package is out for more than 7 years now and most of
the packages have already been ported to its redefined API.
[https://lists.exim.org/lurker/message/20150105.162835.0666407a.en.html
Mail] about the changes in the pcre2.

=== Plan ===
1) File the BZ trackers for all of the dependent packages.

2) Document the deprecation.

3) Start the [[PcreRetirement|new change]] with the pcre retirement.

== Feedback ==
The early feedback from the community is in
[https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/K3BUC6T5VIG7LXOV4RVFO7IUPE2LGA2J/#OPHSKMRJ4W6IX4KMLRF27K2JMSQQ2GCB
this mailing thread]

== Benefit to Fedora ==
Fedora shouldn't support unsupported packages. When the future RHEL
versions fork from Fedora, it could lead to less secure RHEL as well.
By deprecating this package, we will send the message to the
maintainers that their packages should port to new pcre2 package and
any new package would have to use only new and supported pcre2
version.

== Scope ==
* Proposal owners: 3 steps mentioned in the
[https://fedoraproject.org/wiki/PcreDeprecation#Plan Plan].

* Other developers: Port their package to support the new pcre2.
* Release engineering:
 * Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:


== Upgrade/compatibility impact ==
The old pcre package will be deprecated, so the new packages are not
able to require it and have to require the new pcre2 version of this
package.


== User Experience ==
Users will not be exposed to the possible vulnerable pcre package,
because the pcre2 is supported by the upstream community.

== Dependencies ==
This list is obtained by using and combining the output of the
following commands:

dnf repoquery --disablerepo='*' --enablerepo=rawhide --whatrequires
'libpcre.so.1()(64bit)' --whatrequires 'libpcreposix.so.0()(64bit)' -s
| pkgname

dnf repoquery --disablerepo='*' --enablerepo=rawhide-source
--whatrequires pcre-devel | pkgname

=== List ===

*389-ds-base
*adanaxisgpl
*aide
*aircrack-ng
*anope
*apachetop
*bti
*ccze
*cegui
*cegui06
*clamav
*ClanLib
*clisp
*clover2
*coccinelle
*collada-dom
*compton
*condor
*cppcheck
*cyrus-imapd
*deepin-file-manager
*dogtag-pki
*EMBOSS
*eterm
*Falcon
*freeradius
*gambas3
*ganglia
*ghc-highlighting-kate
*ghc-pcre-light
*ghc-regex-pcre
*GMT
*gnote
*golang
*gource
*grep
*groonga
*gsmartcontrol
*haxe
*hydra
*hyperscan
*i3
*i3-gaps
*imapfilter
*Io-language
*kdelibs
*kdelibs3
*kdevelop
*kf5-kjs
*kf5-kplotting
*libast
*liblognorm
*libmodsecurity
*lnav
*logstalgia
*lumail
*medusa
*mle
*mod_auth_openid
*mod_auth_openidc
*mod_qos
*mod_security
*monotone
*ncid
*nekovm
*ngrep
*nmap
*ocaml-pcre
*oci-umount
*octave
*openCOLLADA
*openscap
*opensips
*pads
*pcre
*pdfgrep
*perl-re-engine-PCRE
*petsc
*php-pecl-apcu
*php-pecl-http
*php-pecl-oauth
*picom
*pl
*poco
*postgis
*powwow
*prelude-lml
*privoxy
*proxysql
*python-qutepart
*python-scss
*R
*rasqal
*regexxer
*remctl
*renderdoc
*rkward
*root
*rudiments
*sigil
*slang
*sord
*sslh
*suricata
*sway
*swig
*syncevolution
*syslog-ng
*the_foundation
*the_silver_searcher
*Thunar
*tin
*tintin
*tinyfugue
*trafficserver
*uwsgi
*vdr-epgfixer
*watchman
*wireshark
*wmweather+
*xastir
*xfce4-verve-plugin
*xgrep
*xmlcopyeditor
*zsh


== Contingency Plan ==
* Contingency mechanism: (What to do?  Who will do it?) N/A (not
needed for this Change)
* Contingency deadline: N/A (not needed for this Change)
* Blocks release? No

== Documentation ==

There should be documentation of this change, so the users know that
the pcre is no longer supported and cannot be required by any Fedora
package. If an existing package requires the pcre package, it is
considered as a bug.

== Release Notes ==
Release notes should contain the information about the pcre
deprecation 

F39 proposal: libsoup 3: Part two (System-Wide Change proposal)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/libsoup_3:_Part_Two

This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.


== Summary ==

libsoup 3 is a new API version of libsoup that provides support for
HTTP/2. We will remove libsoup 2 and all packages that still depend on
it.

== Owner ==
* Name: [[User:catanzaro|Michael Catanzaro]]
* Email: 


== Detailed Description ==

[[Changes/libsoup_3:_Part_One|We previously introduced libsoup 3 to
Fedora 37.]] Because applications will crash on startup if linked to
both libsoup 2 and libsoup 3 at the same time, and because many
libraries depend on libsoup, and because applications therefore have
limited control over which libsoup they link to transitively, this
transition was quite tricky and caused several serious problems during
the Fedora 37 development cycle. Fortunately, the trickiest part of
the migration to libsoup 3 is now behind us.

The next step is to remove libsoup 2 from Fedora. We propose to do
this for Fedora 39. This should happen sooner rather than later
because libsoup is a security-sensitive networking library and
maintaining an old version in Fedora indefinitely is inadvisable. We
know from experience that a deadline will be required in order to
ensure applications and libraries make the transition; otherwise, we
will wind up maintaining libsoup 2 indefinitely. Removing libsoup 2
from Fedora 38 seems too soon: applications need a little more time to
smoothly transition. Accordingly, we propose to remove libsoup 2 from
Fedora 39. The package will be retired in rawhide shortly after Fedora
38 is branched in February 2023. At this point, all packages that
still depend on it will break in rawhide. This  rest of the year will
be available to fix broken packages before Fedora 39 is released to
users in October 2023.

This will likely cause some temporary problems and force some
compromises. E.g. we may have to drop software like ABRT or geoclue
from composes if not ported in time.


== Benefit to Fedora ==

Removing libsoup 2 ensures Fedora does not package an obsolete version
of a security-sensitive networking library. It will also eliminate the
possibility of linkage conflicts between libsoup 2 and libsoup 3,
which have been extremely annoying during the Fedora 37 development
cycle and will continue to plague us during Fedora 38 development.

== Scope ==
* Proposal owners: we will ensure the package is retired

* Other developers: software must be ported from libsoup 2 to libsoup
3. This may require substantial upstream effort.

* Release engineering: [https://pagure.io/releng/issue/10985 #10985]

* Policies and guidelines: no new policies needed

* Trademark approval: N/A (not needed for this Change)

* Alignment with Objectives: no alignment with objectives

== Upgrade/compatibility impact ==

Software that still depends on libsoup 2 will break.

== How To Test ==

Fortunately not much testing is needed. The main challenge of the
transition to libsoup 3 was testing applications to ensure they do not
crash on startup due to libsoup 2 vs. libsoup 3 conflicts. Such
conflicts will no longer occur once this change is implemented,
because libsoup 2 won't exist anymore. Of course, it's also good to
test applications to ensure they still work properly after being
ported to libsoup 3.

== User Experience ==

Applications that use libsoup 3 will support HTTP/2, which multiplexes
multiple HTTP requests over a single connection. Users may notice
significant performance improvements.

== Dependencies ==

 $ dnf repoquery --whatdepends libsoup --latest-limit 1 --arch
'noarch,x86_64' --disablerepo='*' --enablerepo=rawhide
 Fedora - Rawhide - Developmental packages for t  18 MB/s |  64 MB 00:03
 Last metadata expiration check: 0:00:15 ago on Tue 23 Aug 2022 11:17:32 AM CDT.
 abrt-retrace-client-0:2.15.1-4.fc37.x86_64
 badwolf-0:1.2.2-3.fc37.x86_64
 bookworm-0:1.1.3-0.8.20200414git.c7c3643.fc37.x86_64
 cawbird-0:1.4.2-4.fc37.x86_64
 cinnamon-0:5.4.11-1.fc38.x86_64
 claws-mail-plugins-fancy-0:4.1.0-5.fc37.x86_64
 claws-mail-plugins-gdata-0:4.1.0-5.fc37.x86_64
 coin-0:1.3.0-7.fc37.x86_64
 cutter-0:1.2.7-7.fc37.x86_64
 darktable-0:4.0.0-3.fc37.x86_64
 dino-0:0.3.0-4.fc37.x86_64
 dleyna-renderer-0:0.6.0-15.fc37.x86_64
 dleyna-server-0:0.6.0-14.fc37.x86_64
 dmapd-0:0.0.91-4.fc37.x86_64
 elementary-calendar-0:6.1.1-1.fc37.x86_64
 elementary-code-0:6.2.0-2.fc37.x86_64
 elementary-mail-0:6.4.0-1.fc36.x86_64
 elementary-photos-0:2.7.5-2.fc37.x86_64
 elementary-planner-1:3.0.7-1.fc37.x86_64
 elementary-tasks-0:6.3.0-1.fc37.x86_64
 emacs-1:28.1-3.fc37.x86_64
 ephemeral-0:7.1.0-4.fc37.x86_64
 exfalso-0:4.5.0-3.fc37.noarch
 flatpak-builder-0:1.2.2-4.fc37.x86_64
 fondo-0:1.6.1-3.fc37.x86_64
 frogr-0:1.6-5.fc35.x86_64
 gajim-0:1.4.7-1.fc37.noarch
 

F38 proposal: Pcre Deprecation (System-Wide Change proposal)

[Ben Cotton]

https://fedoraproject.org/wiki/PcreDeprecation

This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.


== Summary ==
Upstream stopped the support for the old 'pcre' package. It only
supports the new 'pcre2' version, so Fedora should deprecate it so it
could later be retired and removed from Fedora entirely.

== Owner ==
* Name: [[User:ljavorsk| Lukas Javorsky]]
* Email: ljavo...@redhat.com


== Detailed Description ==
Upstream stopped supporting the old 'pcre' package. The 8.45 is marked
as a final release and nothing else will be added/fixed in it. This
may lead to some unresolved CVEs, which would have to be resolved by
the maintainers. Unfortunately, due to our limited capacity, we
wouldn't have the time and experience to solve this by ourselves, so
we need to deprecate this package. After the deprecation is done, the
very next step would be starting the [[PcreRetirement|retirement
change]], so the package is removed from Fedora entirely.

The new 'pcre2' package is out for more than 7 years now and most of
the packages have already been ported to its redefined API.
[https://lists.exim.org/lurker/message/20150105.162835.0666407a.en.html
Mail] about the changes in the pcre2.

=== Plan ===
1) File the BZ trackers for all of the dependent packages.

2) Document the deprecation.

3) Start the [[PcreRetirement|new change]] with the pcre retirement.

== Feedback ==
The early feedback from the community is in
[https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/K3BUC6T5VIG7LXOV4RVFO7IUPE2LGA2J/#OPHSKMRJ4W6IX4KMLRF27K2JMSQQ2GCB
this mailing thread]

== Benefit to Fedora ==
Fedora shouldn't support unsupported packages. When the future RHEL
versions fork from Fedora, it could lead to less secure RHEL as well.
By deprecating this package, we will send the message to the
maintainers that their packages should port to new pcre2 package and
any new package would have to use only new and supported pcre2
version.

== Scope ==
* Proposal owners: 3 steps mentioned in the
[https://fedoraproject.org/wiki/PcreDeprecation#Plan Plan].

* Other developers: Port their package to support the new pcre2.
* Release engineering:
 * Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:


== Upgrade/compatibility impact ==
The old pcre package will be deprecated, so the new packages are not
able to require it and have to require the new pcre2 version of this
package.


== User Experience ==
Users will not be exposed to the possible vulnerable pcre package,
because the pcre2 is supported by the upstream community.

== Dependencies ==
This list is obtained by using and combining the output of the
following commands:

dnf repoquery --disablerepo='*' --enablerepo=rawhide --whatrequires
'libpcre.so.1()(64bit)' --whatrequires 'libpcreposix.so.0()(64bit)' -s
| pkgname

dnf repoquery --disablerepo='*' --enablerepo=rawhide-source
--whatrequires pcre-devel | pkgname

=== List ===

*389-ds-base
*adanaxisgpl
*aide
*aircrack-ng
*anope
*apachetop
*bti
*ccze
*cegui
*cegui06
*clamav
*ClanLib
*clisp
*clover2
*coccinelle
*collada-dom
*compton
*condor
*cppcheck
*cyrus-imapd
*deepin-file-manager
*dogtag-pki
*EMBOSS
*eterm
*Falcon
*freeradius
*gambas3
*ganglia
*ghc-highlighting-kate
*ghc-pcre-light
*ghc-regex-pcre
*GMT
*gnote
*golang
*gource
*grep
*groonga
*gsmartcontrol
*haxe
*hydra
*hyperscan
*i3
*i3-gaps
*imapfilter
*Io-language
*kdelibs
*kdelibs3
*kdevelop
*kf5-kjs
*kf5-kplotting
*libast
*liblognorm
*libmodsecurity
*lnav
*logstalgia
*lumail
*medusa
*mle
*mod_auth_openid
*mod_auth_openidc
*mod_qos
*mod_security
*monotone
*ncid
*nekovm
*ngrep
*nmap
*ocaml-pcre
*oci-umount
*octave
*openCOLLADA
*openscap
*opensips
*pads
*pcre
*pdfgrep
*perl-re-engine-PCRE
*petsc
*php-pecl-apcu
*php-pecl-http
*php-pecl-oauth
*picom
*pl
*poco
*postgis
*powwow
*prelude-lml
*privoxy
*proxysql
*python-qutepart
*python-scss
*R
*rasqal
*regexxer
*remctl
*renderdoc
*rkward
*root
*rudiments
*sigil
*slang
*sord
*sslh
*suricata
*sway
*swig
*syncevolution
*syslog-ng
*the_foundation
*the_silver_searcher
*Thunar
*tin
*tintin
*tinyfugue
*trafficserver
*uwsgi
*vdr-epgfixer
*watchman
*wireshark
*wmweather+
*xastir
*xfce4-verve-plugin
*xgrep
*xmlcopyeditor
*zsh


== Contingency Plan ==
* Contingency mechanism: (What to do?  Who will do it?) N/A (not
needed for this Change)
* Contingency deadline: N/A (not needed for this Change)
* Blocks release? No

== Documentation ==

There should be documentation of this change, so the users know that
the pcre is no longer supported and cannot be required by any Fedora
package. If an existing package requires the pcre package, it is
considered as a bug.

== Release Notes ==
Release notes should contain the information about the pcre
deprecation 

F37 Change complete (100% complete) deadline today

[Ben Cotton]

Today we reached the Code Complete (100% complete) milestone on the
F37 schedule: https://fedorapeople.org/groups/schedule/f-37/f-37-key-tasks.html

At this time, all F37 Changes should be 100% complete. You can
indicate this by setting the Bugzilla tracker to the ON_QA status. If
you need to defer a Change to F38 please NEEDINFO me.

Note that we are entering the Beta freeze. Additional package changes
to complete this Change will need an approved blocker or freeze
exception. See https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
and https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process
for more information.

Changes that have not reached the ON_QA status will be given to FESCo
for evaluation of contingency plans.


-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

F37 Change complete (100% complete) deadline today

[Ben Cotton]

Today we reached the Code Complete (100% complete) milestone on the
F37 schedule: https://fedorapeople.org/groups/schedule/f-37/f-37-key-tasks.html

At this time, all F37 Changes should be 100% complete. You can
indicate this by setting the Bugzilla tracker to the ON_QA status. If
you need to defer a Change to F38 please NEEDINFO me.

Note that we are entering the Beta freeze. Additional package changes
to complete this Change will need an approved blocker or freeze
exception. See https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
and https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process
for more information.

Changes that have not reached the ON_QA status will be given to FESCo
for evaluation of contingency plans.


-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: gsl soversion bump

[Miro Hrončok]

On 23. 08. 22 18:16, Mamoru TASAKA wrote:


Remainder : 1 package
1  asymptote-2.81-2.fc37.src.rpm
https://koji.fedoraproject.org/koji/buildinfo?buildID=2050712
   - Previous asymptote build was successful, but now build fails also for f38.
     Looks like pdfetex is segfaulting.


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

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

F37 side tag after branching point

[Iñaki Ucar]

Hi all,

We have a new R version sitting on a side tag (f37-build-side-55653)
for a few weeks now, where packages are being rebuilt as time permits.
Unfortunately, F37 is not rawhide anymore, so the question is whether
this side tag could be safely merged both in F37 and rawhide when it
is ready.

Thanks,
-- 
Iñaki Úcar
___
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: gsl soversion bump

[Adam Williamson]

On Wed, 2022-08-24 at 01:16 +0900, Mamoru TASAKA wrote:
> Mamoru TASAKA wrote on 2022/08/23 16:58:
> > Kevin Fenzi wrote on 2022/08/23 10:12:
> > > On Tue, Aug 23, 2022 at 09:23:51AM +0900, Mamoru TASAKA wrote:
> > > > Elliott Sales de Andrade wrote on 2022/08/23 5:54:
> > > > > On Thu, Aug 11, 2022 at 12:08 PM Susi Lehtola
> > > > >  wrote:
> > > > > > 
> > > > > > Hello,
> > > > > > 
> > > > > > 
> > > > > > gsl will be updated from version 2.6 to 2.7.1 which changes the
> > > > > > soversion from .25 to .27 in one week. List of dependent packages
> > > > > > 
> > > > > > $ for rpm in $(repoquery --disablerepo=* --enablerepo=rawhide
> > > > > > --whatrequires "libgsl.so.25()(64bit)"); do repoquery 
> > > > > > --disablerepo=*
> > > > > > --enablerepo=rawhide --source $rpm;done|sort|uniq
> > > > > > 
> > > > > 
> > > > > Did you just build directly in Rawhide after listing *61* packages
> > > > > that would break from the update?
> > > > > Please please use a side tag next time.
> > > > > 
> > > > 
> > > > Untagging requested.
> > > > https://pagure.io/releng/issue/10984
> > > 
> > > Untagged. You can make a side tag and tag it into there...
> > > 
> > > kevin
> > 
> > Thank you for untagging.
> > 
> > Side tag created: f38-build-side-57264
> > https://koji.fedoraproject.org/koji/builds?inherited=0=57264=-build_id=1
> > 
> > Now I am trying to rebuild all depending packages mechanically..
> > 
> 
> Rebuilt with 1 pkg build failure, side tag is now goint to be merged into f38 
> tree.
> https://bodhi.fedoraproject.org/updates/FEDORA-2022-87a33f4948

Thanks a lot for taking care of this!
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

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

Summary/Minutes from today's FESCo Meeting (2022-08-23)

[Major Hayden]

===
#fedora-meeting: FESCO (2022-08-23)
===


Meeting started by mhayden at 17:00:00 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/fedora-meeting/2022-08-23/fesco.2022-08-23-17.00.log.html
.



Meeting summary
---
* init process  (mhayden, 17:00:21)

* #2853 Reduce default service timeout to 15s  (mhayden, 17:05:29)
  * ACTION: mhayden to update 2853 with a request to submit a change for
F38 instead  (mhayden, 17:09:51)

* #2855 Improve package orphaning process  (mhayden, 17:10:22)
  * LINK: https://pagure.io/fesco/issue/2852#comment-811351   (mhayden,
17:15:30)
  * LINK: https://pagure.io/fesco/issue/2856#comment-812124   (mhayden,
17:15:37)
  * ACTION: mhroncok to share script output or the script that does the
unresponsive maintainer work at the end  (mhayden, 17:20:54)
  * LINK:
https://pagure.io/releng/blob/main/f/scripts/distgit/retire_packagers.py
(mhroncok, 17:25:29)
  * LINK:
https://pagure.io/releng/blob/main/f/scripts/distgit/retire_packagers.py
(mhayden, 17:26:00)

* #2849 enable systemd preset for waagent.service (WALinuxAgent)
  (mhayden, 17:31:50)
  * ACTION: mhayden to update #2849 and ask for a devel thread and how
walinuxagent communicates w/azure's cloud  (mhayden, 17:38:09)

* Next week's chair  (mhayden, 17:38:58)
  * ACTION: mhayden to chair the next meeting and he will actually
follow the instructions  (mhayden, 17:41:04)

* Open Floor  (mhayden, 17:41:13)
  * LINK: https://pagure.io/fesco/fesco-docs/pull-request/69   (mhayden,
17:42:29)
  * LINK: https://pagure.io/fesco/fesco-docs/pull-request/68   (mhayden,
17:42:34)
  * ACTION: everyone go vote on both FESCo PRs (#68 and #69) please
(mhayden, 17:45:02)

Meeting ended at 17:46:52 UTC.




Action Items

* mhayden to update 2853 with a request to submit a change for F38
  instead
* mhroncok to share script output or the script that does the
  unresponsive maintainer work at the end
* mhayden to update #2849 and ask for a devel thread and how
  walinuxagent communicates w/azure's cloud
* mhayden to chair the next meeting and he will actually follow the
  instructions
* everyone go vote on both FESCo PRs (#68 and #69) please




Action Items, by person
---
* mhayden
  * mhayden to update 2853 with a request to submit a change for F38
instead
  * mhayden to update #2849 and ask for a devel thread and how
walinuxagent communicates w/azure's cloud
  * mhayden to chair the next meeting and he will actually follow the
instructions
* mhroncok
  * mhroncok to share script output or the script that does the
unresponsive maintainer work at the end
* **UNASSIGNED**
  * everyone go vote on both FESCo PRs (#68 and #69) please




People Present (lines said)
---
* mhayden (96)
* mhroncok (49)
* zodbot (22)
* nirik (19)
* zbyszek (19)
* bcotton (8)
* music[m] (7)
* kalev (7)
* decathorpe (6)
* Eighth_Doctor (6)
* salimma (2)
* sgallagh (0)
* dcantrell (0)
* music (0)
* Conan_Kudo (0)
* Pharaoh_Atem (0)
* Son_Goku (0)
* King_InuYasha (0)
* Sir_Gallantmon (0)




Generated by `MeetBot`_ 0.4

.. _`MeetBot`: https://fedoraproject.org/wiki/Zodbot#Meeting_Functions

OpenPGP_0x737051E0C1011FB1.asc
Description: OpenPGP public key


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

Re: Fedora rawhide compose report: 20220823.n.0 changes

[Kevin Fenzi]

On Tue, Aug 23, 2022 at 11:07:26AM +, Fedora Rawhide Report wrote:
> OLD: Fedora-Rawhide-20220822.n.0
> NEW: Fedora-Rawhide-20220823.n.0

...snip...

> = DROPPED IMAGES =
> Image: Kinoite dvd-ostree aarch64
> Path: 
> Kinoite/aarch64/iso/Fedora-Kinoite-ostree-aarch64-Rawhide-20220822.n.0.iso
> Image: Silverblue dvd-ostree aarch64
> Path: 
> Silverblue/aarch64/iso/Fedora-Silverblue-ostree-aarch64-Rawhide-20220822.n.0.iso
> Image: Silverblue dvd-ostree ppc64le
> Path: 
> Silverblue/ppc64le/iso/Fedora-Silverblue-ostree-ppc64le-Rawhide-20220822.n.0.iso
> Image: Kinoite dvd-ostree ppc64le
> Path: 
> Kinoite/ppc64le/iso/Fedora-Kinoite-ostree-ppc64le-Rawhide-20220822.n.0.iso
> Image: Kinoite dvd-ostree x86_64
> Path: Kinoite/x86_64/iso/Fedora-Kinoite-ostree-x86_64-Rawhide-20220822.n.0.iso
> Image: Container_Minimal_Base docker ppc64le
> Path: 
> Container/ppc64le/images/Fedora-Container-Minimal-Base-Rawhide-20220822.n.0.ppc64le.tar.xz
> Image: Silverblue dvd-ostree x86_64
> Path: 
> Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-Rawhide-20220822.n.0.iso

These appear to be related to the systemd-nspawn change. ;( 

Running the ostree post: 

DEBUG util.py:445:  error: Writing content object: Setting xattrs: 
fsetxattr(security.selinux): Invalid argument

Hopefully we can figure a solution soon. 

kevin


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

Re: glibc 2.36 and DT_HASH (preserving it for F37+)

[Zbigniew Jędrzejewski-Szmek]

On Mon, Aug 22, 2022 at 10:31:03AM +0100, Sérgio Basto wrote:
> On Mon, 2022-08-22 at 08:43 +0200, Christoph Erhardt wrote:
> > Hi all,
> > 
> > On Sunday, 21 August 2022 17:29:56 CEST Neal Gompa wrote:
> > > I don't disagree that glibc should respect what distros set, I'm
> > > just
> > > asking us to build glibc with a DT_HASH table added until a formal
> > > deprecation/retirement cycle is done with all stakeholders aware of
> > > the change and everyone aware of the consequences of such a
> > > breakage.
> > +1. Deprecations of this sort should follow a proper process with
> > sufficient 
> > formal advance notice.
> 
> +1. Such breakage will just harm the reputation Linux (IMO).

A bit late to the game (I saw the email from Florian that an update
is being worked on), but +1 from me too.

Zbyszek
___
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: gsl soversion bump

[Mamoru TASAKA]

Mamoru TASAKA wrote on 2022/08/23 16:58:

Kevin Fenzi wrote on 2022/08/23 10:12:

On Tue, Aug 23, 2022 at 09:23:51AM +0900, Mamoru TASAKA wrote:

Elliott Sales de Andrade wrote on 2022/08/23 5:54:

On Thu, Aug 11, 2022 at 12:08 PM Susi Lehtola
 wrote:


Hello,


gsl will be updated from version 2.6 to 2.7.1 which changes the
soversion from .25 to .27 in one week. List of dependent packages

$ for rpm in $(repoquery --disablerepo=* --enablerepo=rawhide
--whatrequires "libgsl.so.25()(64bit)"); do repoquery --disablerepo=*
--enablerepo=rawhide --source $rpm;done|sort|uniq



Did you just build directly in Rawhide after listing *61* packages
that would break from the update?
Please please use a side tag next time.



Untagging requested.
https://pagure.io/releng/issue/10984


Untagged. You can make a side tag and tag it into there...

kevin


Thank you for untagging.

Side tag created: f38-build-side-57264
https://koji.fedoraproject.org/koji/builds?inherited=0=57264=-build_id=1

Now I am trying to rebuild all depending packages mechanically..



Rebuilt with 1 pkg build failure, side tag is now goint to be merged into f38 
tree.
https://bodhi.fedoraproject.org/updates/FEDORA-2022-87a33f4948

Rebuilt:
 1  3Depict-0.0.22-13.fc38.src.rpm
 2  GoldenCheetah-3.6-0.21.RC2.fc38.src.rpm
 3  LabPlot-2.8.1-9.fc38.src.rpm
 4  R-gsl-2.1.7.1-2.fc38.src.rpm
 5  algol68g-3.0.3-4.fc38.src.rpm
 6  astrometry-0.89-4.fc38.src.rpm
 7  bcftools-1.15.1-2.fc38.src.rpm
 8  bogofilter-1.2.5-10.fc38.src.rpm
 9  calligra-3.2.1-20.fc38.src.rpm
10  cocoalib-0.99800-4.fc38.src.rpm
11  dieharder-3.31.1-33.fc38.src.rpm
12  enblend-4.2-24.fc38.src.rpm
13  espresso-4.2.0-4.fc38.src.rpm
14  freefem++-4.11-4.fc38.src.rpm
15  gambas3-3.17.3-3.fc38.src.rpm
16  gdl-1.0.1-9.fc38.src.rpm
17  getdp-3.5.0-4.fc38.src.rpm
18  giac-1.9.0.19-2.fc38.src.rpm
19  gnuradio-3.10.3.0-5.fc38.src.rpm
20  igt-gpu-tools-1.26-3.20220508gitcffa5ff.fc38.src.rpm
21  inkscape-1.2.1-4.fc38.src.rpm
22  ipe-7.2.26-3.fc38.src.rpm
23  krita-5.0.8-5.fc38.src.rpm
24  kst-2.0.8-39.fc38.src.rpm
25  kstars-3.5.9-4.fc38.src.rpm
26  libindi-1.9.7-2.fc38.src.rpm
27  luminance-hdr-2.6.1.1-48.fc38.src.rpm
28  mathgl-2.4.4-18.fc38.src.rpm
29  milia-1.0.0-35.fc38.src.rpm
30  mmseq-1.0.11-13.fc38.src.rpm
31  moose-3.1.5-15.fc38.src.rpm
32  morse2txt-1.0.0-35.fc38.src.rpm
33  mp-3.1.0-40.20200303git7fd4828.fc38.src.rpm
34  ncl-6.6.2-30.fc38.src.rpm
35  nco-5.1.0-4.fc38.src.rpm
36  nest-3.2-7.fc38.src.rpm
37  nip2-8.7.1-13.fc38.src.rpm
38  ocaml-gsl-1.19.1-43.fc38.src.rpm
39  octave-gsl-2.1.1-8.fc38.src.rpm
40  opengrm-ngram-1.3.14-4.fc38.src.rpm
41  orsa-0.7.0-58.fc38.src.rpm
42  perl-PDL-2.80.0-4.fc38.src.rpm
43  pfstools-2.2.0-6.fc38.src.rpm
44  player-3.1.0-43.fc38.src.rpm
45  pspp-1.6.2-3.fc38.src.rpm
46  pygsl-2.3.0-19.fc38.src.rpm
47  python-cvxopt-1.3.0-4.fc38.src.rpm
48  python-pynn-0.10.0-5.fc38.src.rpm
49  qgis-3.26.2-2.fc38.src.rpm
50  root-6.26.06-4.fc38.src.rpm
51  sagemath-9.6-5.fc38.src.rpm
52  scidavis-2.9.0-5.fc38.src.rpm
53  siril-1.0.3-3.fc38.src.rpm
54  sourcextractor++-0.18-3.fc38.src.rpm
55  stellarsolver-2.4-3.fc38.src.rpm
56  step-22.08.0-2.fc38.src.rpm
57  vfrnav-20201231-32.fc38.src.rpm
58  xaos-3.6-18.fc38.src.rpm
59  xsnow-3.5.1-2.fc38.src.rpm

With some modification for the below:

* nco  - Restrict BR: antlr and result binary ncap2 to %%java_arches
* nip2 - Avoid using bool keyword (was FTBFS since nip2-8.7.1-10.fc36)
* player - Change to BR: libphidget22-devel
   
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/43PW2O6ASEWBV4YN5ARGPAD33JUMQ4EY/
* vfrnav - Restrict BR: antlr to %%java_arches

Also, to rebuild sourcextractor++ , due to another reason not related to gsl,
rebuild of elements , elements-alexandria was needed.

Remainder : 1 package
1  asymptote-2.81-2.fc37.src.rpm
   https://koji.fedoraproject.org/koji/buildinfo?buildID=2050712
  - Previous asymptote build was successful, but now build fails also for f38.
Looks like pdfetex is segfaulting.

Regards,
Mamoru
___
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

liburing update

[Richard W.M. Jones]

io_uring (https://en.wikipedia.org/wiki/Io_uring) is an important
kernel facility, essentially an alternate way of dispatching system
calls more efficiently.  It's used in a lot of high performance
situations.  Although you can talk to it directly, most users should
be using liburing, a C library.

We haven't updated liburing for "a while", since April 2021 to
liburing 2.0.  There have been several upstream versions since then,
the latest is liburing 2.2, released in June.

In theory this version is compatible and uses symbol versions:

$ rpm -q --provides liburing
liburing = 2.2-1.fc38
liburing(x86-64) = 2.2-1.fc38
liburing.so.2()(64bit)
liburing.so.2(LIBURING_2.0)(64bit)
liburing.so.2(LIBURING_2.1)(64bit)
liburing.so.2(LIBURING_2.2)(64bit)

so in theory this is not an ABI break.  In practice I'm told that the
API of liburing is not very stable.

TBH I don't really know how best to test this except to just do it.
The packages that depend on liburing shouldn't have any RPM dependency
problems (I already installed the update on my Rawhide machine), but
it's possible they might break in subtle ways, which is in a way
worse.  They are:

- ceph
- folly
- glusterfs
- plocate
- qemu
- raft
- rocksdb
- root
- samba

(so nothing important!)

I have the update prepared and ready to push to Rawhide, but open to
suggestions if there is a better way to do this.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
___
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: percona-xtrabackup bundling the kitchen sink in static libs

[Paul Wouters]

On Tue, 23 Aug 2022, Otto Liljalaakso wrote:

The relevant policy is Bundled software policy [1]. Unlike in the past, a 
package does not need a FESCo exception to bundle dependencies. However, the 
requirements of that policy are not being met here: The reason for bundling 
should be recorded in the specfile, and Provides: bundled(x) = 1.2.3 should 
be included.


[1]: https://docs.fedoraproject.org/en-US/fesco/Bundled_Software_policy/


Thanks for the link. Sadly, the justification would be "because upstream
hardcoded this an errors on any other version", which in itself is
pretty weak. And since it includes boost, which can't easilly be
upgraded between fedora releases, all the older stuff lingers forever.

If the maintainer is not responding, you should invoke the Non-responsive 
maintainer policy [2]. This package has CVE bugs open [3], so most probably 
it should eith be retired, or somebody should start caring for it.


Miro started the non-responsive maintainer process and woke up the
maintainer, but they themselves are also thinking it might be better
to kick it out of fedora.

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

Paul
___
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: [Fedora-legal-list] Updating the Python license tag to SPDX and adjusting the license of Python documentation

[Miro Hrončok]

On 23. 08. 22 15:17, Richard Fontana wrote:

On Tue, Aug 23, 2022 at 6:58 AM Miro Hrončok  wrote:


Unfortunately, Python-2.0.1 is still not listed at
https://docs.fedoraproject.org/en-US/legal/allowed-licenses/


I've attempted to update the files used to generate the two lists so
hopefully this change will show up in the generated documentation
shortly.


Thanks, it is there.

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

Re: liburing update

[Kaleb Keithley]

On Tue, Aug 23, 2022 at 9:24 AM Richard W.M. Jones 
wrote:

> On Tue, Aug 23, 2022 at 02:03:57PM +0100, Richard W.M. Jones wrote:
> > >
> > > ceph also uses rocksdb, so I think I'd want rocksdb to be rebuilt
> before ceph
> > > (i.e. before I rebuild ceph).
> >
> > AFAIK nothing should need to be rebuilt, but I'll issue a
> > scratch build of both once liburing is ready just to check.
>
> rocksdb: https://koji.fedoraproject.org/koji/taskinfo?taskID=91172939
> ceph:https://koji.fedoraproject.org/koji/taskinfo?taskID=91172999
> samba:   https://koji.fedoraproject.org/koji/taskinfo?taskID=91172960


I just checked ceph's and rocksdb's NEEDED and they all look good.

-- 

Kaleb
___
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 2119963] perl-Prima-1.66 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

Link ID||CPAN 144080




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2119963
___
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 2119963] perl-Prima-1.66 is available

[bugzilla]

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



--- Comment #4 from Petr Pisar  ---
(gdb) bt
#0  0x77451203 in XCopyGC () at /lib64/libX11.so.6
#1  0x7736c6e2 in apc_gp_push (self=93825005492864,
destructor=, user_data=0x0, user_data_size=) at
unix/graphics.c:2311
#2  0x7736c8e6 in prima_prepare_drawable_for_painting
(self=93825005492864, inside_on_paint=0) at unix/graphics.c:165
#3  0x7737f800 in apc_menu_item_begin_paint (self=,
event=) at unix/menu.c:2439
#4  0x772a4155 in AbstractMenu_handle_event (self=93825005133536,
event=0x7fffd830) at class/AbstractMenu.c:1468
#5  0x772b1d23 in Component_message (self=93825005133536,
event=0x7fffd830) at class/Component.c:307
#6  0x773799dd in menuitem_draw_custom
(m=, draw=0x7fffd7f0, param=0x0, rgn=0x5618e050,
ix=0x561f1490, x=0, y=100, str_size=, str_ptr=, vertical=1, descent=4, clr=0, rgb=0, index=,
selected=0, w=, win=50331706, self=93825005133536) at
unix/menu.c:1230
#7  handle_menu_expose (ev=, win=50331706, self=93825005133536)
at unix/menu.c:1355
#8  0x7735a0a6 in prima_handle_event (ev=0x7fffdca0,
next_event=0x0) at unix/event.c:1169
#9  0x7735baeb in send_queued_x_events
(careOfApplication=careOfApplication@entry=1) at unix/event.c:2063
#10 0x7735ca5e in handle_queued_events
(careOfApplication=careOfApplication@entry=1) at unix/event.c:2225
#11 0x7735ce94 in prima_one_loop_round (wait=1, careOfApplication=1) at
unix/event.c:2246
#12 0x7734d5ef in apc_application_go (self=) at
unix/app.c:1052
#13 apc_application_go (self=) at unix/app.c:1045
#14 0x7728e151 in template_xs_Bool_Handle (cv=,
subName=0x773a3e5e "Prima::Application::go", func=0x7734d590
) at include/generic/thunks.tinc:3559
#15 0x77d1eed0 in Perl_pp_entersub () at /lib64/libperl.so.5.36
#16 0x77d10850 in Perl_runops_standard () at /lib64/libperl.so.5.36
#17 0x77c80fa1 in perl_run () at /lib64/libperl.so.5.36
#18 0x534a in main ()

(gdb) frame 1
#1  0x7736c6e2 in apc_gp_push (self=93825005492864,
destructor=, user_data=0x0, user_data_size=) at
unix/graphics.c:2311
2311XCopyGC( DISP, state->paint.gc, (1 << (GCLastBit + 1))
- 1, XX->gc);
(gdb) p state->paint
$1 = {fore = {primary = 0, secondary = 0, color = 0, balance = 0 '\000'}, back
= {primary = 0, secondary = 0, color = 0, balance = 0 '\000'}, gc = 0x0, gcl =
0x0, gc_pool = 0x773ff0b8 , 
  region = 0x0, tile = 0, stipple = 0, kill_tile = 0, kill_stipple = 0}

This looks like a NULL pointer (state->paint.gc) dereference in XCopyGC(). But
the apc_gp_push() part is fishy:

state->paint.gc  = XX-> gc;
state->paint.gcl = XX-> gcl;
XX->gcl = NULL;
XX->gc = NULL;
state->paint.gc_pool = prima_get_gc(XX);
XCopyGC( DISP, state->paint.gc, (1 << (GCLastBit + 1)) - 1, XX->gc);

What's the point of XCopyGC( DISP, NULL, ALL_GC_COMPONENTS, NULL)?


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2119963
___
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 2119963] perl-Prima-1.66 is available

[bugzilla]

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



--- Comment #3 from Petr Pisar  ---
The crash is a regression in 1.66. Both gtk2 and gkt3 builds crash. This does
not happen in 1.65.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2119963
___
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

Adoption of flare package

[Sandro]

Hi,

I am interested in adopting the orphaned flare package[1]. It doesn't 
appear to have any complicated requirements. My local build on a recent 
git clone succeeded without effort.


As I'm not in the packagers group, yet, I will have to complete the 
sponsoring process first. For that I am looking for a sponsor, too.


If I understand the process correctly, I will need to file a request in 
Pagure[2].


[1] https://src.fedoraproject.org/rpms/flare
[2] https://pagure.io/packager-sponsors/issues

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

[EPEL-devel] Re: [new / help wanted] fence-agents-epel package

[Alex Talaran]

attached a new spec using 4.10 which should match el9 (desired distro 
version) as you noted.
srpm and rpm still seem to build fine without man pages, still not sure 
how to generate them.


On 2022-08-08 17:22, Troy Dawson wrote:

Hi Alex,
I've been looking into this some.

What distribution do you want this for?
I haven't seen anywhere in your emails saying if this is for RHEL 8 or 
RHEL 9?
The spec file you have attached is for fence-agents-4.11, which is only 
in Fedora, so that doesn't let me know either.


The major problem is that the fence-agents-pve version has to match the 
fence-agents that is in your version of RHEL.
So for RHEL8 (or compatible) it needs to be version 4.2.1.  For RHEL 9 
it needs to be 4.10.0


We need to start with the correct version of fence-agents and work from 
there.


Troy

On Wed, Jul 27, 2022 at 10:03 AM Alex Talaran > wrote:


i was able to get this built and installable if anyone wants to help
test or maintain it.
an issue exists with the man pages not being built still but im not
sure
how the makefile target works for these so they are excluded for now.

maybe some other small tweaks are still needed too since its just a
(first for me) stripped down and modified upstream spec file.

On 2022-07-20 08:47, Andrew C Aitchison wrote:
 > On Wed, 20 Jul 2022, Alex Talaran wrote:
 >
 >> i ended up with the same error with that change.
 >
 > I am sorry my suggestion did not help.
 > I don't have a Red Hat compatible machine newer that RHEL6
 > (I moved to Ubuntu for work-related reasons)
 > so I am unable to test things myself.
 >
 >> is it possible its getting confused because the dirname in the
tarball
 >> is different than the package name and looking in the wrong spot?
 >
 > The -n fence-agents-%{version} in
 >  %prep
 >  %setup -q -n fence-agents-%{version}
 > is supposed to resolve that, but that setup line might need tweaking
 > to match the contents of the tarball.
 >
 > It is old and may be somewhat dated, but my bible for rewriting
.spec
 > files was the book
 >     Maximum RPM - Taking the Red Hat Package Manager to the Limit
 > a version of which is available at
 > http://ftp.rpm.org/max-rpm/index.html

 >
 >> On 2022-07-19 23:32, Andrew C Aitchison wrote:
 >>> On Tue, 19 Jul 2022, Alex Talaran wrote:
 >>>
  per a previous thread i took a shot at cleaning up the
fence-agents
  rpm to only include the missing agents and make a new package.
i am
  having some issues with the source url and getting it to
build. the
  srpm is ok, but when i try to rebuild it into a proper rpm i
get the
  following (output truncated):
 
  ---
  + py39_byte_compile /usr/bin/python3
 

/builddir/build/BUILDROOT/fence-agents-epel-4.11.0-1.el9.x86_64/usr/share/fence
  + python_binary='env PYTHONHASHSEED=0 /usr/bin/python3'
  +
 

bytecode_compilation_path=/builddir/build/BUILDROOT/fence-agents-epel-4.11.0-1.el9.x86_64/usr/share/fence
  + env PYTHONHASHSEED=0 /usr/bin/python3 -s -B -m compileall -o
0 -o
  1 -s
/builddir/build/BUILDROOT/fence-agents-epel-4.11.0-1.el9.x86_64
  -p /
 

/builddir/build/BUILDROOT/fence-agents-epel-4.11.0-1.el9.x86_64/usr/share/fence
  Listing
 

'/builddir/build/BUILDROOT/fence-agents-epel-4.11.0-1.el9.x86_64/usr/share/fence'...
  Can't list
 

'/builddir/build/BUILDROOT/fence-agents-epel-4.11.0-1.el9.x86_64/usr/share/fence'
  + chmod 0755
 

/builddir/build/BUILDROOT/fence-agents-epel-4.11.0-1.el9.x86_64/usr/share/fence/fence_pve.py
 
/builddir/build/BUILDROOT/fence-agents-epel-4.11.0-1.el9.x86_64/usr/share/fence/fence_raritan.py
 
/builddir/build/BUILDROOT/fence-agents-epel-4.11.0-1.el9.x86_64/usr/share/fence/fence_rcd_serial.py
 
/builddir/build/BUILDROOT/fence-agents-epel-4.11.0-1.el9.x86_64/usr/share/fence/fence_virsh.py
  chmod: cannot access
 

'/builddir/build/BUILDROOT/fence-agents-epel-4.11.0-1.el9.x86_64/usr/share/fence/fence_pve.py':
 No such file or directory
  chmod: cannot access
 

'/builddir/build/BUILDROOT/fence-agents-epel-4.11.0-1.el9.x86_64/usr/share/fence/fence_raritan.py':
 No such file or directory
  chmod: cannot access
 

'/builddir/build/BUILDROOT/fence-agents-epel-4.11.0-1.el9.x86_64/usr/share/fence/fence_rcd_serial.py':
 No such file or directory
  chmod: cannot access
 

'/builddir/build/BUILDROOT/fence-agents-epel-4.11.0-1.el9.x86_64/usr/share/fence/fence_virsh.py':
 No such file or directory
  error: Bad exit status from /var/tmp/rpm-tmp.S10L6D (%install)
  ---
 
  i even tried 

Re: liburing update

[Richard W.M. Jones]

On Tue, Aug 23, 2022 at 02:03:57PM +0100, Richard W.M. Jones wrote:
> On Tue, Aug 23, 2022 at 08:50:48AM -0400, Kaleb Keithley wrote:
> > 
> > 
> > On Tue, Aug 23, 2022 at 8:47 AM Richard W.M. Jones  
> > wrote:
> > 
> > On Tue, Aug 23, 2022 at 10:24:50AM +0100, Richard W.M. Jones wrote:
> > > - ceph
> > > ...
> > > - rocksdb
> > 
> > 
> > I built ceph, qemu, samba & plocate with the new liburing 2.2 and
> > there didn't seem to be any problem with liburing.  Samba however
> > failed to build with what seems like an unrelated error.
> > 
> > 
> > ceph also uses rocksdb, so I think I'd want rocksdb to be rebuilt before 
> > ceph
> > (i.e. before I rebuild ceph).
> 
> AFAIK nothing should need to be rebuilt, but I'll issue a
> scratch build of both once liburing is ready just to check.

rocksdb: https://koji.fedoraproject.org/koji/taskinfo?taskID=91172939
ceph:https://koji.fedoraproject.org/koji/taskinfo?taskID=91172999
samba:   https://koji.fedoraproject.org/koji/taskinfo?taskID=91172960

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: [Fedora-legal-list] Updating the Python license tag to SPDX and adjusting the license of Python documentation

[Richard Fontana]

On Tue, Aug 23, 2022 at 6:58 AM Miro Hrončok  wrote:

> Unfortunately, Python-2.0.1 is still not listed at
> https://docs.fedoraproject.org/en-US/legal/allowed-licenses/

I've attempted to update the files used to generate the two lists so
hopefully this change will show up in the generated documentation
shortly.

Richard
___
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: liburing update

[Richard W.M. Jones]

On Tue, Aug 23, 2022 at 08:50:48AM -0400, Kaleb Keithley wrote:
> 
> 
> On Tue, Aug 23, 2022 at 8:47 AM Richard W.M. Jones  wrote:
> 
> On Tue, Aug 23, 2022 at 10:24:50AM +0100, Richard W.M. Jones wrote:
> > - ceph
> > ...
> > - rocksdb
> 
> 
> I built ceph, qemu, samba & plocate with the new liburing 2.2 and
> there didn't seem to be any problem with liburing.  Samba however
> failed to build with what seems like an unrelated error.
> 
> 
> ceph also uses rocksdb, so I think I'd want rocksdb to be rebuilt before ceph
> (i.e. before I rebuild ceph).

AFAIK nothing should need to be rebuilt, but I'll issue a
scratch build of both once liburing is ready just to check.

Rich.

> --
> 
> Kaleb

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


-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
___
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: liburing update

[Richard W.M. Jones]

On Tue, Aug 23, 2022 at 08:51:12AM -0400, Stefan Hajnoczi wrote:
> On Tue, Aug 23, 2022 at 11:24:10AM +0100, Richard W.M. Jones wrote:
> > On Tue, Aug 23, 2022 at 11:38:26AM +0200, Dominik 'Rathann' Mierzejewski 
> > wrote:
> > > I'd suggest doing a mock, copr or scratch build and running abipkgdiff
> > > comparing current rawhide and the updated binary packages. It'll tell
> > > you if there are any subtle ABI differences.
> > 
> > Here's a scratch build:
> > 
> >   https://koji.fedoraproject.org/koji/taskinfo?taskID=91169327
> > 
> > The differences are:
> > 
> > $ abipkgdiff liburing-2.0-4.fc37.x86_64.rpm liburing-2.2-1.fc38.x86_64.rpm 
> > --devel-pkg1 liburing-devel-2.0-4.fc37.x86_64.rpm --devel-pkg2 
> > liburing-devel-2.2-1.fc38.x86_64.rpm --debug-info-pkg1 
> > liburing-debuginfo-2.0-4.fc37.x86_64.rpm --debug-info-pkg2 
> > liburing-debuginfo-2.2-1.fc38.x86_64.rpm
> 
> The changes look good to me. Thanks for posting this information!

It's building now:

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

Note that I had to add the following to the spec file:

  BuildRequires: gcc-c++

Also (we were discussing in a different thread) liburing really needs
a ./run script like we have in libvirt, libnbd etc. because
configuring another project to use upstream liburing from source is a
pain.

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: liburing update

[Kaleb Keithley]

On Tue, Aug 23, 2022 at 8:47 AM Richard W.M. Jones 
wrote:

> On Tue, Aug 23, 2022 at 10:24:50AM +0100, Richard W.M. Jones wrote:
> > - ceph
> > ...
> > - rocksdb
>
>
> I built ceph, qemu, samba & plocate with the new liburing 2.2 and
> there didn't seem to be any problem with liburing.  Samba however
> failed to build with what seems like an unrelated error.
>

ceph also uses rocksdb, so I think I'd want rocksdb to be rebuilt before
ceph (i.e. before I rebuild ceph).

-- 

Kaleb
___
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: liburing update

[Richard W.M. Jones]

On Tue, Aug 23, 2022 at 10:24:50AM +0100, Richard W.M. Jones wrote:
> - ceph
> - folly
> - glusterfs
> - plocate
> - qemu
> - raft
> - rocksdb
> - root
> - samba

I built ceph, qemu, samba & plocate with the new liburing 2.2 and
there didn't seem to be any problem with liburing.  Samba however
failed to build with what seems like an unrelated error.

So I will go ahead and push this to Fedora.  If there are problems
please let me know & I'll jump on and fix them.

Rich.

---

samba error:

In file included from ../../lib/util/debug.c:387:
../../lib/util/debug.c: In function ‘debug_lttng_log’:
../../lib/util/debug.c:395:29: error: format not a string literal and no format 
arguments [-Werror=format-security]
  395 | tracef(state.header_str_no_nl);
  |~^
../../lib/util/debug.c:400:21: error: format not a string literal and no format 
arguments [-Werror=format-security]
  400 | tracef(state.msg_no_nl);
  |~^~
cc1: some warnings being treated as errors


-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.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

Fedora 37 Bodhi updates-testing activation and Beta Freeze

[Tomas Hrcka]

Hi all,

Today's an important day on the Fedora 37 schedule[1], with several
significant cut-offs. First of all, today is the Bodhi updates-testing
activation point [2]. That means that from now all Fedora 37 packages must
be submitted to updates-testing and pass the relevant
requirements[3] before they will be marked as 'stable' and moved to
the fedora repository.

Today is also the Beta freeze[4]. This means that only packages which
fix accepted blocker or freeze exception bugs[5][6] will be marked as
'stable' and included in the Beta composes. Other builds will remain
in updates-testing until the Beta release is approved, at which point
the Beta freeze is lifted and packages can move to 'stable' as usual
until the Final freeze.

Today is also the Software String freeze[7], which means that strings
marked for translation in Fedora-translated projects should not now be
changed for Fedora 37.

Finally, today is the 'completion deadline' Change Checkpoint[8],
meaning that Fedora 37 Changes must now be 'feature complete or close
enough to completion that a majority of its functionality can be
tested'. All tracking bugs should be on ON_QA state or later to
reflect this.

Regards
Fedora Release Engineering

[1] https://fedorapeople.org/groups/schedule/f-37/f-37-key-tasks.html
[2] https://fedoraproject.org/wiki/Updates_Policy#Bodhi_enabling
[3] https://fedoraproject.org/wiki/Updates_Policy#Branched_release
[4] https://fedoraproject.org/wiki/Milestone_freezes
[5] https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
[6] https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process
[7] https://fedoraproject.org/wiki/ReleaseEngineering/StringFreezePolicy
[8] https://fedoraproject.org/wiki/Changes/Policy

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

Fedora 37 compose report: 20220823.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-37-20220822.n.0
NEW: Fedora-37-20220823.n.0

= SUMMARY =
Added images:1
Dropped images:  0
Added packages:  8
Dropped packages:8
Upgraded packages:   77
Downgraded packages: 0

Size of added packages:  60.84 MiB
Size of dropped packages:31.56 MiB
Size of upgraded packages:   2.53 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   1.11 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: Design_suite live x86_64
Path: Labs/x86_64/iso/Fedora-Design_suite-Live-x86_64-37-20220823.n.0.iso

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: blueprint-compiler-0.2.0-1.fc37
Summary: A markup language for GTK user interfaces
RPMs:blueprint-compiler
Size:164.76 KiB

Package: fastfetch-1.6.4-3.fc37
Summary: Like neofetch, but much faster because written in c
RPMs:fastfetch fastfetch-bash-completion
Size:645.81 KiB

Package: google-disk-expand-20220712.00-1.fc37
Summary: Expands root partition in Google Cloud instances
RPMs:google-disk-expand
Size:14.13 KiB

Package: hwk-0.6-3.fc37
Summary: Commandline text processing with Haskell functions
RPMs:hwk
Size:58.36 MiB

Package: perl-Data-Constraint-1.203-2.fc37
Summary: Prototypical value checking
RPMs:perl-Data-Constraint
Size:18.63 KiB

Package: perl-Role-Hooks-0.008-2.fc37
Summary: Role callbacks
RPMs:perl-Role-Hooks
Size:24.06 KiB

Package: python-colcon-rerun-0.0.1-1.fc37
Summary: Extension for colcon to quickly re-run a recently executed verb
RPMs:python3-colcon-rerun
Size:30.00 KiB

Package: ugrep-3.9.2-2.fc37
Summary: Faster, user-friendly, and compatible grep replacement
RPMs:ugrep
Size:1.60 MiB


= DROPPED PACKAGES =
Package: rust-js-sys-0.3.58-2.fc37
Summary: Bindings for all JS global objects and functions
RPMs:rust-js-sys+default-devel rust-js-sys-devel
Size:101.89 KiB

Package: rust-wasm-bindgen-0.2.81-2.fc37
Summary: Easy support for interacting between JS and Rust
RPMs:rust-wasm-bindgen+default-devel 
rust-wasm-bindgen+enable-interning-devel rust-wasm-bindgen+serde-devel 
rust-wasm-bindgen+serde-serialize-devel rust-wasm-bindgen+serde_json-devel 
rust-wasm-bindgen+spans-devel rust-wasm-bindgen+std-devel 
rust-wasm-bindgen+strict-macro-devel 
rust-wasm-bindgen+xxx_debug_only_print_generated_code-devel 
rust-wasm-bindgen-devel
Size:292.43 KiB

Package: rust-wasm-bindgen-backend-0.2.81-2.fc37
Summary: Backend code generation of the wasm-bindgen tool
RPMs:rust-wasm-bindgen-backend+default-devel 
rust-wasm-bindgen-backend+extra-traits-devel 
rust-wasm-bindgen-backend+spans-devel rust-wasm-bindgen-backend-devel
Size:60.74 KiB

Package: rust-wasm-bindgen-macro-0.2.81-2.fc37
Summary: Definition of the #[wasm_bindgen] attribute
RPMs:rust-wasm-bindgen-macro+default-devel 
rust-wasm-bindgen-macro+spans-devel rust-wasm-bindgen-macro+strict-macro-devel 
rust-wasm-bindgen-macro+xxx_debug_only_print_generated_code-devel 
rust-wasm-bindgen-macro-devel
Size:69.64 KiB

Package: rust-wasm-bindgen-macro-support-0.2.81-2.fc37
Summary: Part of the implementation of the #[wasm_bindgen] attribute
RPMs:rust-wasm-bindgen-macro-support+default-devel 
rust-wasm-bindgen-macro-support+extra-traits-devel 
rust-wasm-bindgen-macro-support+spans-devel 
rust-wasm-bindgen-macro-support+strict-macro-devel 
rust-wasm-bindgen-macro-support-devel
Size:62.29 KiB

Package: rust-wasm-bindgen-shared-0.2.81-2.fc37
Summary: Shared support between wasm-bindgen and wasm-bindgen cli
RPMs:rust-wasm-bindgen-shared+default-devel rust-wasm-bindgen-shared-devel
Size:25.53 KiB

Package: rust-web-sys-0.3.58-2.fc37
Summary: Bindings for all Web APIs, a procedurally generated crate from WebIDL
RPMs:rust-web-sys+AbortController-devel rust-web-sys+AbortSignal-devel 
rust-web-sys+AddEventListenerOptions-devel rust-web-sys+AesCbcParams-devel 
rust-web-sys+AesCtrParams-devel rust-web-sys+AesDerivedKeyParams-devel 
rust-web-sys+AesGcmParams-devel rust-web-sys+AesKeyAlgorithm-devel 
rust-web-sys+AesKeyGenParams-devel rust-web-sys+Algorithm-devel 
rust-web-sys+AlignSetting-devel rust-web-sys+AllowedBluetoothDevice-devel 
rust-web-sys+AllowedUsbDevice-devel rust-web-sys+AlphaOption-devel 
rust-web-sys+AnalyserNode-devel rust-web-sys+AnalyserOptions-devel 
rust-web-sys+AngleInstancedArrays-devel rust-web-sys+Animation-devel 
rust-web-sys+AnimationEffect-devel rust-web-sys+AnimationEvent-devel 
rust-web-sys+AnimationEventInit-devel rust-web-sys+AnimationPlayState-devel 
rust-web-sys+AnimationPlaybackEvent-devel 
rust-web-sys+AnimationPlaybackEventInit-devel 
rust-web-sys+AnimationPropertyDetails-devel 
rust-web-sys+AnimationPropertyValueDetails-devel 
rust-web-sys+AnimationTimeline-devel rust-web-sys+AssignedNodesOptions-devel 
rust-web-sys+AttestationConveyancePreference-devel rust-web-sys+Attr-devel 
rust-web-sys+AttributeNameValue-devel rust-web-sys+AudioBuffer-devel 
rust-web-sys

[Bug 2120625] New: perl-Config-Perl-V-0.34 is available

[bugzilla]

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

Bug ID: 2120625
   Summary: perl-Config-Perl-V-0.34 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Config-Perl-V
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com, mspa...@redhat.com,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com
  Target Milestone: ---
Classification: Fedora



Releases retrieved: 0.34
Upstream release that is considered latest: 0.34
Current version/release in rawhide: 0.33-490.fc37
URL: http://search.cpan.org/dist/Config-Perl-V/

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://fedoraproject.org/wiki/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/6976/


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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2120625
___
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

[Test-Announce] Fedora 37 Bodhi updates-testing activation and Beta Freeze

[Tomas Hrcka]

Hi all,

Today's an important day on the Fedora 37 schedule[1], with several
significant cut-offs. First of all, today is the Bodhi updates-testing
activation point [2]. That means that from now all Fedora 37 packages must
be submitted to updates-testing and pass the relevant
requirements[3] before they will be marked as 'stable' and moved to
the fedora repository.

Today is also the Beta freeze[4]. This means that only packages which
fix accepted blocker or freeze exception bugs[5][6] will be marked as
'stable' and included in the Beta composes. Other builds will remain
in updates-testing until the Beta release is approved, at which point
the Beta freeze is lifted and packages can move to 'stable' as usual
until the Final freeze.

Today is also the Software String freeze[7], which means that strings
marked for translation in Fedora-translated projects should not now be
changed for Fedora 37.

Finally, today is the 'completion deadline' Change Checkpoint[8],
meaning that Fedora 37 Changes must now be 'feature complete or close
enough to completion that a majority of its functionality can be
tested'. All tracking bugs should be on ON_QA state or later to
reflect this.

Regards
Fedora Release Engineering

[1] https://fedorapeople.org/groups/schedule/f-37/f-37-key-tasks.html
[2] https://fedoraproject.org/wiki/Updates_Policy#Bodhi_enabling
[3] https://fedoraproject.org/wiki/Updates_Policy#Branched_release
[4] https://fedoraproject.org/wiki/Milestone_freezes
[5] https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
[6] https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process
[7] https://fedoraproject.org/wiki/ReleaseEngineering/StringFreezePolicy
[8] https://fedoraproject.org/wiki/Changes/Policy

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

Re: liburing update

[Alexander Bokovoy]

On ti, 23 elo 2022, Richard W.M. Jones wrote:

On Tue, Aug 23, 2022 at 11:38:26AM +0200, Dominik 'Rathann' Mierzejewski wrote:

I'd suggest doing a mock, copr or scratch build and running abipkgdiff
comparing current rawhide and the updated binary packages. It'll tell
you if there are any subtle ABI differences.


Here's a scratch build:

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

The differences are:

$ abipkgdiff liburing-2.0-4.fc37.x86_64.rpm liburing-2.2-1.fc38.x86_64.rpm 
--devel-pkg1 liburing-devel-2.0-4.fc37.x86_64.rpm --devel-pkg2 
liburing-devel-2.2-1.fc38.x86_64.rpm --debug-info-pkg1 
liburing-debuginfo-2.0-4.fc37.x86_64.rpm --debug-info-pkg2 
liburing-debuginfo-2.2-1.fc38.x86_64.rpm

 changes of 'liburing.so.2.0.0'===
 Functions changes summary: 0 Removed, 1 Changed (24 filtered out), 16 Added 
functions
 Variables changes summary: 0 Removed, 0 Changed, 0 Added variable

 16 Added functions:

   [A] 'function ssize_t io_uring_mlock_size(unsigned int, unsigned int)'
{io_uring_mlock_size@@LIBURING_2.1}
   [A] 'function ssize_t io_uring_mlock_size_params(unsigned int, 
io_uring_params*)'{io_uring_mlock_size_params@@LIBURING_2.1}
   [A] 'function int io_uring_register_buf_ring(io_uring*, io_uring_buf_reg*, 
unsigned int)'{io_uring_register_buf_ring@@LIBURING_2.2}
   [A] 'function int io_uring_register_buffers_sparse(io_uring*, unsigned int)' 
   {io_uring_register_buffers_sparse@@LIBURING_2.2}
   [A] 'function int io_uring_register_buffers_tags(io_uring*, const iovec*, 
const __u64*, unsigned int)'{io_uring_register_buffers_tags@@LIBURING_2.1}
   [A] 'function int io_uring_register_buffers_update_tag(io_uring*, unsigned 
int, const iovec*, const __u64*, unsigned int)'
{io_uring_register_buffers_update_tag@@LIBURING_2.1}
   [A] 'function int io_uring_register_files_sparse(io_uring*, unsigned int)'   
 {io_uring_register_files_sparse@@LIBURING_2.2}
   [A] 'function int io_uring_register_files_tags(io_uring*, const int*, const 
__u64*, unsigned int)'{io_uring_register_files_tags@@LIBURING_2.1}
   [A] 'function int io_uring_register_files_update_tag(io_uring*, unsigned 
int, const int*, const __u64*, unsigned int)'
{io_uring_register_files_update_tag@@LIBURING_2.1}
   [A] 'function int io_uring_register_iowq_aff(io_uring*, size_t, const 
cpu_set_t*)'{io_uring_register_iowq_aff@@LIBURING_2.1}
   [A] 'function int io_uring_register_iowq_max_workers(io_uring*, unsigned 
int*)'{io_uring_register_iowq_max_workers@@LIBURING_2.1}
   [A] 'function int io_uring_register_ring_fd(io_uring*)'
{io_uring_register_ring_fd@@LIBURING_2.2}
   [A] 'function int io_uring_submit_and_wait_timeout(io_uring*, 
io_uring_cqe**, unsigned int, __kernel_timespec*, sigset_t*)'
{io_uring_submit_and_wait_timeout@@LIBURING_2.2}
   [A] 'function int io_uring_unregister_buf_ring(io_uring*, int)'
{io_uring_unregister_buf_ring@@LIBURING_2.2}
   [A] 'function int io_uring_unregister_iowq_aff(io_uring*)'
{io_uring_unregister_iowq_aff@@LIBURING_2.1}
   [A] 'function int io_uring_unregister_ring_fd(io_uring*)'
{io_uring_unregister_ring_fd@@LIBURING_2.2}

 1 function with some indirect sub-type change:

   [C] 'function int __io_uring_get_cqe(io_uring*, io_uring_cqe**, unsigned 
int, unsigned int, sigset_t*)' at queue.c:113:1 has some indirect sub-type 
changes:
 parameter 1 of type 'io_uring*' has sub-type changes:
   in pointed to type 'struct io_uring' at liburing.h:77:1:
 type size hasn't changed
 3 data member insertions:
   'int enter_ring_fd', at offset 1632 (in bits) at liburing.h:84:1
   '__u8 int_flags', at offset 1664 (in bits) at liburing.h:85:1
   'unsigned int pad2', at offset 1696 (in bits) at liburing.h:87:1
 2 data member changes (1 filtered):
   type of 'io_uring_sq sq' changed:
 type size hasn't changed
 1 data member change:
   type of 'io_uring_sqe* sqes' changed:
 in pointed to type 'struct io_uring_sqe' at io_uring.h:21:1:
   type size hasn't changed
   4 data member insertions:
 '__u16 personality', at offset 336 (in bits) at 
io_uring.h:63:1
 'union {__s32 splice_fd_in; __u32 file_index;}', at offset 
352 (in bits)
 '__u64 addr3', at offset 384 (in bits) at io_uring.h:68:1
 '__u64 __pad2[1]', at offset 448 (in bits) at 
io_uring.h:69:1
   1 data member changes (1 filtered):
 anonymous data member at offset 320 (in bits) changed from:
   union {struct {union {__u16 buf_index; __u16 
buf_group;}; __u16 personality; __s32 splice_fd_in;}; __u64 __pad2[3];}
 to:
   union {__u16 buf_index; __u16 buf_group;}
 and size changed from 192 to 16 (in bits) (by -176 bits)
   type of 

Fedora rawhide compose report: 20220823.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20220822.n.0
NEW: Fedora-Rawhide-20220823.n.0

= SUMMARY =
Added images:1
Dropped images:  7
Added packages:  8
Dropped packages:8
Upgraded packages:   90
Downgraded packages: 0

Size of added packages:  61.14 MiB
Size of dropped packages:31.56 MiB
Size of upgraded packages:   3.03 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   120.37 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: Design_suite live x86_64
Path: Labs/x86_64/iso/Fedora-Design_suite-Live-x86_64-Rawhide-20220823.n.0.iso

= DROPPED IMAGES =
Image: Kinoite dvd-ostree aarch64
Path: Kinoite/aarch64/iso/Fedora-Kinoite-ostree-aarch64-Rawhide-20220822.n.0.iso
Image: Silverblue dvd-ostree aarch64
Path: 
Silverblue/aarch64/iso/Fedora-Silverblue-ostree-aarch64-Rawhide-20220822.n.0.iso
Image: Silverblue dvd-ostree ppc64le
Path: 
Silverblue/ppc64le/iso/Fedora-Silverblue-ostree-ppc64le-Rawhide-20220822.n.0.iso
Image: Kinoite dvd-ostree ppc64le
Path: Kinoite/ppc64le/iso/Fedora-Kinoite-ostree-ppc64le-Rawhide-20220822.n.0.iso
Image: Kinoite dvd-ostree x86_64
Path: Kinoite/x86_64/iso/Fedora-Kinoite-ostree-x86_64-Rawhide-20220822.n.0.iso
Image: Container_Minimal_Base docker ppc64le
Path: 
Container/ppc64le/images/Fedora-Container-Minimal-Base-Rawhide-20220822.n.0.ppc64le.tar.xz
Image: Silverblue dvd-ostree x86_64
Path: 
Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-Rawhide-20220822.n.0.iso

= ADDED PACKAGES =
Package: blueprint-compiler-0.2.0-1.fc38
Summary: A markup language for GTK user interfaces
RPMs:blueprint-compiler
Size:164.74 KiB

Package: fastfetch-1.6.4-3.fc38
Summary: Like neofetch, but much faster because written in c
RPMs:fastfetch fastfetch-bash-completion
Size:645.58 KiB

Package: google-disk-expand-20220712.00-1.fc38
Summary: Expands root partition in Google Cloud instances
RPMs:google-disk-expand
Size:14.19 KiB

Package: hwk-0.6-3.fc38
Summary: Commandline text processing with Haskell functions
RPMs:hwk
Size:58.36 MiB

Package: perl-Data-Constraint-1.203-2.fc38
Summary: Prototypical value checking
RPMs:perl-Data-Constraint
Size:18.64 KiB

Package: perl-Role-Hooks-0.008-2.fc38
Summary: Role callbacks
RPMs:perl-Role-Hooks
Size:24.08 KiB

Package: twincam-0.5-3.fc38
Summary: A lightweight camera application
RPMs:twincam
Size:342.10 KiB

Package: ugrep-3.9.2-2.fc38
Summary: Faster, user-friendly, and compatible grep replacement
RPMs:ugrep
Size:1.60 MiB


= DROPPED PACKAGES =
Package: rust-js-sys-0.3.58-2.fc37
Summary: Bindings for all JS global objects and functions
RPMs:rust-js-sys+default-devel rust-js-sys-devel
Size:101.88 KiB

Package: rust-wasm-bindgen-0.2.81-2.fc37
Summary: Easy support for interacting between JS and Rust
RPMs:rust-wasm-bindgen+default-devel 
rust-wasm-bindgen+enable-interning-devel rust-wasm-bindgen+serde-devel 
rust-wasm-bindgen+serde-serialize-devel rust-wasm-bindgen+serde_json-devel 
rust-wasm-bindgen+spans-devel rust-wasm-bindgen+std-devel 
rust-wasm-bindgen+strict-macro-devel 
rust-wasm-bindgen+xxx_debug_only_print_generated_code-devel 
rust-wasm-bindgen-devel
Size:292.37 KiB

Package: rust-wasm-bindgen-backend-0.2.81-2.fc37
Summary: Backend code generation of the wasm-bindgen tool
RPMs:rust-wasm-bindgen-backend+default-devel 
rust-wasm-bindgen-backend+extra-traits-devel 
rust-wasm-bindgen-backend+spans-devel rust-wasm-bindgen-backend-devel
Size:60.74 KiB

Package: rust-wasm-bindgen-macro-0.2.81-2.fc37
Summary: Definition of the #[wasm_bindgen] attribute
RPMs:rust-wasm-bindgen-macro+default-devel 
rust-wasm-bindgen-macro+spans-devel rust-wasm-bindgen-macro+strict-macro-devel 
rust-wasm-bindgen-macro+xxx_debug_only_print_generated_code-devel 
rust-wasm-bindgen-macro-devel
Size:69.66 KiB

Package: rust-wasm-bindgen-macro-support-0.2.81-2.fc37
Summary: Part of the implementation of the #[wasm_bindgen] attribute
RPMs:rust-wasm-bindgen-macro-support+default-devel 
rust-wasm-bindgen-macro-support+extra-traits-devel 
rust-wasm-bindgen-macro-support+spans-devel 
rust-wasm-bindgen-macro-support+strict-macro-devel 
rust-wasm-bindgen-macro-support-devel
Size:62.29 KiB

Package: rust-wasm-bindgen-shared-0.2.81-2.fc37
Summary: Shared support between wasm-bindgen and wasm-bindgen cli
RPMs:rust-wasm-bindgen-shared+default-devel rust-wasm-bindgen-shared-devel
Size:25.53 KiB

Package: rust-web-sys-0.3.58-2.fc37
Summary: Bindings for all Web APIs, a procedurally generated crate from WebIDL
RPMs:rust-web-sys+AbortController-devel rust-web-sys+AbortSignal-devel 
rust-web-sys+AddEventListenerOptions-devel rust-web-sys+AesCbcParams-devel 
rust-web-sys+AesCtrParams-devel rust-web-sys+AesDerivedKeyParams-devel 
rust-web-sys+AesGcmParams-devel rust-web-sys+AesKeyAlgorithm-devel 
rust-web-sys+AesKeyGenParams-devel rust-web-sys+Algorithm-devel 
rust-web-sys+AlignSetting-devel rust-web-sys

Updating the Python license tag to SPDX and adjusting the license of Python documentation

[Miro Hrončok]

Hello.

I plan to update the license tag of Python interpreters in Fedora from "Python" 
to "Python-2.0.1".


See this PR which added it to fedora-license-data:
https://gitlab.com/fedora/legal/fedora-license-data/-/merge_requests/61

See this PR to Python 3.11 (to be backported to older Pythons later):
https://src.fedoraproject.org/rpms/python3.11/pull-request/78


I also plan to update the license of python3-docs to:
Python-2.0.1 AND (Python-2.0.1 OR 0BSD)

Because examples, recipes, and other code in the documentation are dual 
licensed under Python-2.0.1/0BSD. This was previously not reflected in the 
License tag.


See this PR:
https://src.fedoraproject.org/rpms/python3-docs/pull-request/82


Unfortunately, Python-2.0.1 is still not listed at 
https://docs.fedoraproject.org/en-US/legal/allowed-licenses/


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

Re: Retiring the pcre package from Fedora

[Lukas Javorsky]

Of course, only the deprecation will be moved to F38.

The removal is stalled until the deprecation is completed. Once done, the
new Fedora change will start from the beginning, containing the removal.

It looks like the community is okay with moving the deprecation to F38, so
I'll move it.

On Tue, Aug 23, 2022 at 12:22 PM Fabio Valentini 
wrote:

> On Tue, Aug 23, 2022 at 10:23 AM Lukas Javorsky 
> wrote:
> >
> > Hello Zbigniew,
> >
> > I would love to have it on F38, but I'm not sure it would be enough time
> for all of the maintainers whose packages depend on the old pcre.
> >
> > Ben, do you think we can make this to F38?
>
> Moving the *deprecation* to F38 should be fine (since that is a
> metadata-only change and an additional incentive to port packages to
> pcre2), but moving the *removal* to F38 is probably not.
>
> Fabio
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>


-- 
S pozdravom/ Best regards

Lukáš Javorský

Software Engineer, Core service - Databases

Red Hat 

Purkyňova 115 (TPB-C)

612 00 Brno - Královo Pole

ljavo...@redhat.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

Re: liburing update

[Richard W.M. Jones]

On Tue, Aug 23, 2022 at 11:24:10AM +0100, Richard W.M. Jones wrote:
> On Tue, Aug 23, 2022 at 11:38:26AM +0200, Dominik 'Rathann' Mierzejewski 
> wrote:
> > I'd suggest doing a mock, copr or scratch build and running abipkgdiff
> > comparing current rawhide and the updated binary packages. It'll tell
> > you if there are any subtle ABI differences.
> 
> Here's a scratch build:
> 
>   https://koji.fedoraproject.org/koji/taskinfo?taskID=91169327

Bleah ... (the tests below were done on my locally built copy)

Hopefully this will fix the missing dep:

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

Rich.

> The differences are:
> 
> $ abipkgdiff liburing-2.0-4.fc37.x86_64.rpm liburing-2.2-1.fc38.x86_64.rpm 
> --devel-pkg1 liburing-devel-2.0-4.fc37.x86_64.rpm --devel-pkg2 
> liburing-devel-2.2-1.fc38.x86_64.rpm --debug-info-pkg1 
> liburing-debuginfo-2.0-4.fc37.x86_64.rpm --debug-info-pkg2 
> liburing-debuginfo-2.2-1.fc38.x86_64.rpm
> 
>  changes of 'liburing.so.2.0.0'===
>   Functions changes summary: 0 Removed, 1 Changed (24 filtered out), 16 Added 
> functions
>   Variables changes summary: 0 Removed, 0 Changed, 0 Added variable
> 
>   16 Added functions:
> 
> [A] 'function ssize_t io_uring_mlock_size(unsigned int, unsigned int)'
> {io_uring_mlock_size@@LIBURING_2.1}
> [A] 'function ssize_t io_uring_mlock_size_params(unsigned int, 
> io_uring_params*)'{io_uring_mlock_size_params@@LIBURING_2.1}
> [A] 'function int io_uring_register_buf_ring(io_uring*, 
> io_uring_buf_reg*, unsigned int)'
> {io_uring_register_buf_ring@@LIBURING_2.2}
> [A] 'function int io_uring_register_buffers_sparse(io_uring*, unsigned 
> int)'{io_uring_register_buffers_sparse@@LIBURING_2.2}
> [A] 'function int io_uring_register_buffers_tags(io_uring*, const iovec*, 
> const __u64*, unsigned int)'{io_uring_register_buffers_tags@@LIBURING_2.1}
> [A] 'function int io_uring_register_buffers_update_tag(io_uring*, 
> unsigned int, const iovec*, const __u64*, unsigned int)'
> {io_uring_register_buffers_update_tag@@LIBURING_2.1}
> [A] 'function int io_uring_register_files_sparse(io_uring*, unsigned 
> int)'{io_uring_register_files_sparse@@LIBURING_2.2}
> [A] 'function int io_uring_register_files_tags(io_uring*, const int*, 
> const __u64*, unsigned int)'{io_uring_register_files_tags@@LIBURING_2.1}
> [A] 'function int io_uring_register_files_update_tag(io_uring*, unsigned 
> int, const int*, const __u64*, unsigned int)'
> {io_uring_register_files_update_tag@@LIBURING_2.1}
> [A] 'function int io_uring_register_iowq_aff(io_uring*, size_t, const 
> cpu_set_t*)'{io_uring_register_iowq_aff@@LIBURING_2.1}
> [A] 'function int io_uring_register_iowq_max_workers(io_uring*, unsigned 
> int*)'{io_uring_register_iowq_max_workers@@LIBURING_2.1}
> [A] 'function int io_uring_register_ring_fd(io_uring*)'
> {io_uring_register_ring_fd@@LIBURING_2.2}
> [A] 'function int io_uring_submit_and_wait_timeout(io_uring*, 
> io_uring_cqe**, unsigned int, __kernel_timespec*, sigset_t*)'
> {io_uring_submit_and_wait_timeout@@LIBURING_2.2}
> [A] 'function int io_uring_unregister_buf_ring(io_uring*, int)'
> {io_uring_unregister_buf_ring@@LIBURING_2.2}
> [A] 'function int io_uring_unregister_iowq_aff(io_uring*)'
> {io_uring_unregister_iowq_aff@@LIBURING_2.1}
> [A] 'function int io_uring_unregister_ring_fd(io_uring*)'
> {io_uring_unregister_ring_fd@@LIBURING_2.2}
> 
>   1 function with some indirect sub-type change:
> 
> [C] 'function int __io_uring_get_cqe(io_uring*, io_uring_cqe**, unsigned 
> int, unsigned int, sigset_t*)' at queue.c:113:1 has some indirect sub-type 
> changes:
>   parameter 1 of type 'io_uring*' has sub-type changes:
> in pointed to type 'struct io_uring' at liburing.h:77:1:
>   type size hasn't changed
>   3 data member insertions:
> 'int enter_ring_fd', at offset 1632 (in bits) at liburing.h:84:1
> '__u8 int_flags', at offset 1664 (in bits) at liburing.h:85:1
> 'unsigned int pad2', at offset 1696 (in bits) at liburing.h:87:1
>   2 data member changes (1 filtered):
> type of 'io_uring_sq sq' changed:
>   type size hasn't changed
>   1 data member change:
> type of 'io_uring_sqe* sqes' changed:
>   in pointed to type 'struct io_uring_sqe' at io_uring.h:21:1:
> type size hasn't changed
> 4 data member insertions:
>   '__u16 personality', at offset 336 (in bits) at 
> io_uring.h:63:1
>   'union {__s32 splice_fd_in; __u32 file_index;}', at 
> offset 352 (in bits)
>   '__u64 addr3', at offset 384 (in bits) at 
> io_uring.h:68:1
>   '__u64 __pad2[1]', at offset 448 (in bits) at 
> io_uring.h:69:1
> 1 data member changes 

Re: liburing update

[Richard W.M. Jones]

On Tue, Aug 23, 2022 at 11:38:26AM +0200, Dominik 'Rathann' Mierzejewski wrote:
> I'd suggest doing a mock, copr or scratch build and running abipkgdiff
> comparing current rawhide and the updated binary packages. It'll tell
> you if there are any subtle ABI differences.

Here's a scratch build:

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

The differences are:

$ abipkgdiff liburing-2.0-4.fc37.x86_64.rpm liburing-2.2-1.fc38.x86_64.rpm 
--devel-pkg1 liburing-devel-2.0-4.fc37.x86_64.rpm --devel-pkg2 
liburing-devel-2.2-1.fc38.x86_64.rpm --debug-info-pkg1 
liburing-debuginfo-2.0-4.fc37.x86_64.rpm --debug-info-pkg2 
liburing-debuginfo-2.2-1.fc38.x86_64.rpm

 changes of 'liburing.so.2.0.0'===
  Functions changes summary: 0 Removed, 1 Changed (24 filtered out), 16 Added 
functions
  Variables changes summary: 0 Removed, 0 Changed, 0 Added variable

  16 Added functions:

[A] 'function ssize_t io_uring_mlock_size(unsigned int, unsigned int)'
{io_uring_mlock_size@@LIBURING_2.1}
[A] 'function ssize_t io_uring_mlock_size_params(unsigned int, 
io_uring_params*)'{io_uring_mlock_size_params@@LIBURING_2.1}
[A] 'function int io_uring_register_buf_ring(io_uring*, io_uring_buf_reg*, 
unsigned int)'{io_uring_register_buf_ring@@LIBURING_2.2}
[A] 'function int io_uring_register_buffers_sparse(io_uring*, unsigned 
int)'{io_uring_register_buffers_sparse@@LIBURING_2.2}
[A] 'function int io_uring_register_buffers_tags(io_uring*, const iovec*, 
const __u64*, unsigned int)'{io_uring_register_buffers_tags@@LIBURING_2.1}
[A] 'function int io_uring_register_buffers_update_tag(io_uring*, unsigned 
int, const iovec*, const __u64*, unsigned int)'
{io_uring_register_buffers_update_tag@@LIBURING_2.1}
[A] 'function int io_uring_register_files_sparse(io_uring*, unsigned int)'  
  {io_uring_register_files_sparse@@LIBURING_2.2}
[A] 'function int io_uring_register_files_tags(io_uring*, const int*, const 
__u64*, unsigned int)'{io_uring_register_files_tags@@LIBURING_2.1}
[A] 'function int io_uring_register_files_update_tag(io_uring*, unsigned 
int, const int*, const __u64*, unsigned int)'
{io_uring_register_files_update_tag@@LIBURING_2.1}
[A] 'function int io_uring_register_iowq_aff(io_uring*, size_t, const 
cpu_set_t*)'{io_uring_register_iowq_aff@@LIBURING_2.1}
[A] 'function int io_uring_register_iowq_max_workers(io_uring*, unsigned 
int*)'{io_uring_register_iowq_max_workers@@LIBURING_2.1}
[A] 'function int io_uring_register_ring_fd(io_uring*)'
{io_uring_register_ring_fd@@LIBURING_2.2}
[A] 'function int io_uring_submit_and_wait_timeout(io_uring*, 
io_uring_cqe**, unsigned int, __kernel_timespec*, sigset_t*)'
{io_uring_submit_and_wait_timeout@@LIBURING_2.2}
[A] 'function int io_uring_unregister_buf_ring(io_uring*, int)'
{io_uring_unregister_buf_ring@@LIBURING_2.2}
[A] 'function int io_uring_unregister_iowq_aff(io_uring*)'
{io_uring_unregister_iowq_aff@@LIBURING_2.1}
[A] 'function int io_uring_unregister_ring_fd(io_uring*)'
{io_uring_unregister_ring_fd@@LIBURING_2.2}

  1 function with some indirect sub-type change:

[C] 'function int __io_uring_get_cqe(io_uring*, io_uring_cqe**, unsigned 
int, unsigned int, sigset_t*)' at queue.c:113:1 has some indirect sub-type 
changes:
  parameter 1 of type 'io_uring*' has sub-type changes:
in pointed to type 'struct io_uring' at liburing.h:77:1:
  type size hasn't changed
  3 data member insertions:
'int enter_ring_fd', at offset 1632 (in bits) at liburing.h:84:1
'__u8 int_flags', at offset 1664 (in bits) at liburing.h:85:1
'unsigned int pad2', at offset 1696 (in bits) at liburing.h:87:1
  2 data member changes (1 filtered):
type of 'io_uring_sq sq' changed:
  type size hasn't changed
  1 data member change:
type of 'io_uring_sqe* sqes' changed:
  in pointed to type 'struct io_uring_sqe' at io_uring.h:21:1:
type size hasn't changed
4 data member insertions:
  '__u16 personality', at offset 336 (in bits) at 
io_uring.h:63:1
  'union {__s32 splice_fd_in; __u32 file_index;}', at 
offset 352 (in bits)
  '__u64 addr3', at offset 384 (in bits) at io_uring.h:68:1
  '__u64 __pad2[1]', at offset 448 (in bits) at 
io_uring.h:69:1
1 data member changes (1 filtered):
  anonymous data member at offset 320 (in bits) changed 
from:
union {struct {union {__u16 buf_index; __u16 
buf_group;}; __u16 personality; __s32 splice_fd_in;}; __u64 __pad2[3];}
  to:
union {__u16 buf_index; __u16 buf_group;}
  and size changed from 192 to 16 (in bits) (by -176 bits)
type 

Re: Retiring the pcre package from Fedora

[Fabio Valentini]

On Tue, Aug 23, 2022 at 10:23 AM Lukas Javorsky  wrote:
>
> Hello Zbigniew,
>
> I would love to have it on F38, but I'm not sure it would be enough time for 
> all of the maintainers whose packages depend on the old pcre.
>
> Ben, do you think we can make this to F38?

Moving the *deprecation* to F38 should be fine (since that is a
metadata-only change and an additional incentive to port packages to
pcre2), but moving the *removal* to F38 is probably not.

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

Re: liburing update

[Daniel P . Berrangé]

On Tue, Aug 23, 2022 at 10:24:50AM +0100, Richard W.M. Jones wrote:
> io_uring (https://en.wikipedia.org/wiki/Io_uring) is an important
> kernel facility, essentially an alternate way of dispatching system
> calls more efficiently.  It's used in a lot of high performance
> situations.  Although you can talk to it directly, most users should
> be using liburing, a C library.
> 
> We haven't updated liburing for "a while", since April 2021 to
> liburing 2.0.  There have been several upstream versions since then,
> the latest is liburing 2.2, released in June.
> 
> In theory this version is compatible and uses symbol versions:
> 
> $ rpm -q --provides liburing
> liburing = 2.2-1.fc38
> liburing(x86-64) = 2.2-1.fc38
> liburing.so.2()(64bit)
> liburing.so.2(LIBURING_2.0)(64bit)
> liburing.so.2(LIBURING_2.1)(64bit)
> liburing.so.2(LIBURING_2.2)(64bit)
> 
> so in theory this is not an ABI break.  In practice I'm told that the
> API of liburing is not very stable.

Indeed, while it is perhaps ABI comaptible, it wasn't fully API
compatible, as the 2.2 changes broke QEMU builds when using -Werror
due to changed data type sizes. See this upstream QEMU fix (should
already be in version of QEMU in Fedora):

  commit 8a947c7a586e16a048894e1a0a73d154435e90ef
  Author: Haiyue Wang 
  Date:   Tue Feb 22 00:24:01 2022 +0800

aio-posix: fix build failure io_uring 2.2

The io_uring fixed "Don't truncate addr fields to 32-bit on 32-bit":

https://git.kernel.dk/cgit/liburing/commit/?id=d84c29b19ed0b13619cff40141bb1fc3615b

This leads to build failure:
../util/fdmon-io_uring.c: In function ‘add_poll_remove_sqe’:
../util/fdmon-io_uring.c:182:36: error: passing argument 2 of 
‘io_uring_prep_poll_remove’ makes integer from pointer without a cast 
[-Werror=int-conversion]
  182 | io_uring_prep_poll_remove(sqe, node);
  |^~~~
  ||
  |AioHandler *
In file included from /root/io/qemu/include/block/aio.h:18,
 from ../util/aio-posix.h:20,
 from ../util/fdmon-io_uring.c:49:
/usr/include/liburing.h:415:17: note: expected ‘__u64’ {aka ‘long long 
unsigned int’} but argument is of type ‘AioHandler *’
  415 |   __u64 user_data)
  |   ~~^
cc1: all warnings being treated as errors

Use LIBURING_HAVE_DATA64 to check whether the io_uring supports 64-bit
variants of the get/set userdata, to convert the paramter to the right
data type.

Signed-off-by: Haiyue Wang 
Message-Id: <20220221162401.45415-1-haiyue.w...@intel.com>
Signed-off-by: Stefan Hajnoczi 



> TBH I don't really know how best to test this except to just do it.
> The packages that depend on liburing shouldn't have any RPM dependency
> problems (I already installed the update on my Rawhide machine), but
> it's possible they might break in subtle ways, which is in a way
> worse.  They are:

I think the respective package maintainers just need to be aware of
the change and do whatever testing they feel is needed. Ideally the
respective upstream projects ought to already be doing CI covering
this kind of scenario. I don't think its reasonable to expect the
distro maintainers of liburing to do comprehensive testing of each
of these consumers, given their broad scope & complexity.

> - ceph
> - folly
> - glusterfs
> - plocate
> - qemu
> - raft
> - rocksdb
> - root
> - samba
> 
> (so nothing important!)
> 
> I have the update prepared and ready to push to Rawhide, but open to
> suggestions if there is a better way to do this.

At least with QEMU any usage of liburing is strictly opt-in per-VM
disk configuration, and I expect the number of people who've done
so is close to zero.

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

[Bug 2120413] perl-Locale-Maketext-1.32 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Resolution|--- |RAWHIDE
   Fixed In Version||perl-Locale-Maketext-1.32-1
   ||.fc38
   ||perl-Locale-Maketext-1.32-1
   ||.fc37
 Status|ASSIGNED|CLOSED
Last Closed||2022-08-23 09:51:46




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2120413
___
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: liburing update

[Dominik 'Rathann' Mierzejewski]

On Tuesday, 23 August 2022 at 11:24, Richard W.M. Jones wrote:
[...]
> We haven't updated liburing for "a while", since April 2021 to
> liburing 2.0.  There have been several upstream versions since then,
> the latest is liburing 2.2, released in June.
> 
> In theory this version is compatible and uses symbol versions:
> 
> $ rpm -q --provides liburing
> liburing = 2.2-1.fc38
> liburing(x86-64) = 2.2-1.fc38
> liburing.so.2()(64bit)
> liburing.so.2(LIBURING_2.0)(64bit)
> liburing.so.2(LIBURING_2.1)(64bit)
> liburing.so.2(LIBURING_2.2)(64bit)
> 
> so in theory this is not an ABI break.  In practice I'm told that the
> API of liburing is not very stable.
> 
> TBH I don't really know how best to test this except to just do it.
> The packages that depend on liburing shouldn't have any RPM dependency
> problems (I already installed the update on my Rawhide machine), but
> it's possible they might break in subtle ways, which is in a way
> worse.  They are:
> 
> - ceph
> - folly
> - glusterfs
> - plocate
> - qemu
> - raft
> - rocksdb
> - root
> - samba
> 
> (so nothing important!)

;)

> I have the update prepared and ready to push to Rawhide, but open to
> suggestions if there is a better way to do this.

I'd suggest doing a mock, copr or scratch build and running abipkgdiff
comparing current rawhide and the updated binary packages. It'll tell
you if there are any subtle ABI differences.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.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

liburing update

[Richard W.M. Jones]

io_uring (https://en.wikipedia.org/wiki/Io_uring) is an important
kernel facility, essentially an alternate way of dispatching system
calls more efficiently.  It's used in a lot of high performance
situations.  Although you can talk to it directly, most users should
be using liburing, a C library.

We haven't updated liburing for "a while", since April 2021 to
liburing 2.0.  There have been several upstream versions since then,
the latest is liburing 2.2, released in June.

In theory this version is compatible and uses symbol versions:

$ rpm -q --provides liburing
liburing = 2.2-1.fc38
liburing(x86-64) = 2.2-1.fc38
liburing.so.2()(64bit)
liburing.so.2(LIBURING_2.0)(64bit)
liburing.so.2(LIBURING_2.1)(64bit)
liburing.so.2(LIBURING_2.2)(64bit)

so in theory this is not an ABI break.  In practice I'm told that the
API of liburing is not very stable.

TBH I don't really know how best to test this except to just do it.
The packages that depend on liburing shouldn't have any RPM dependency
problems (I already installed the update on my Rawhide machine), but
it's possible they might break in subtle ways, which is in a way
worse.  They are:

- ceph
- folly
- glusterfs
- plocate
- qemu
- raft
- rocksdb
- root
- samba

(so nothing important!)

I have the update prepared and ready to push to Rawhide, but open to
suggestions if there is a better way to do this.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
___
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 2120413] perl-Locale-Maketext-1.32 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

   Doc Type|--- |If docs needed, set a value
 CC|jples...@redhat.com,|
   |mspa...@redhat.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=2120413
___
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: Retiring the pcre package from Fedora

[Lukas Javorsky]

Hello Zbigniew,

I would love to have it on F38, but I'm not sure it would be enough time
for all of the maintainers whose packages depend on the old pcre.

Ben, do you think we can make this to F38?

Thank you for answering.
Lukas

On Fri, Aug 19, 2022 at 3:33 PM Ben Cotton  wrote:

> On Thu, Aug 18, 2022 at 5:30 AM Zbigniew Jędrzejewski-Szmek
>  wrote:
> >
> > Why F39? Shouldn't the deprecation (and the work on porting) be already
> happening for F38?
>
> I'm going to wait to process the proposal until we have an answer to
> this question. (I believe Lukas is out of the office, so it may be a
> few days)
>
>
> --
> Ben Cotton
> He / Him / His
> Fedora Program Manager
> Red Hat
> TZ=America/Indiana/Indianapolis
>
>

-- 
S pozdravom/ Best regards

Lukáš Javorský

Software Engineer, Core service - Databases

Red Hat 

Purkyňova 115 (TPB-C)

612 00 Brno - Královo Pole

ljavo...@redhat.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

Re: glibc 2.36 and DT_HASH (preserving it for F37+)

[Florian Weimer]

We are working on this and hope to have an update soon.

Thanks,
Florian
___
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: gsl soversion bump

[Mamoru TASAKA]

Kevin Fenzi wrote on 2022/08/23 10:12:

On Tue, Aug 23, 2022 at 09:23:51AM +0900, Mamoru TASAKA wrote:

Elliott Sales de Andrade wrote on 2022/08/23 5:54:

On Thu, Aug 11, 2022 at 12:08 PM Susi Lehtola
 wrote:


Hello,


gsl will be updated from version 2.6 to 2.7.1 which changes the
soversion from .25 to .27 in one week. List of dependent packages

$ for rpm in $(repoquery --disablerepo=* --enablerepo=rawhide
--whatrequires "libgsl.so.25()(64bit)"); do repoquery --disablerepo=*
--enablerepo=rawhide --source $rpm;done|sort|uniq



Did you just build directly in Rawhide after listing *61* packages
that would break from the update?
Please please use a side tag next time.



Untagging requested.
https://pagure.io/releng/issue/10984


Untagged. You can make a side tag and tag it into there...

kevin


Thank you for untagging.

Side tag created: f38-build-side-57264
https://koji.fedoraproject.org/koji/builds?inherited=0=57264=-build_id=1

Now I am trying to rebuild all depending packages mechanically..

Regards,
Mamoru




___
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: SPDX migration progress

[Vít Ondruch]

Dne 23. 08. 22 v 0:36 Jilayne Lovejoy napsal(a):

That would be a bit hard since a large number of the SPDX ids are the same as 
the Fedora short names. That being said, some of the more commonly found 
licenses are not the same.



This is unfortunate. I still think it was mistake to not provide some 
mechanism to understand what license format is being used. It could have 
been empty macro such as `License: %{spdx:MIT}`.



Vít


  


It might be interesting to see how many packages have had a license update 
since this change, which could indicate updating to SPDX, as well as updating 
the license information more generally, as we've seen some cases of already.

To be honest, I've been thinking more about how to efficiently deal with some of the 
"category" Fedora short names specifically (need more brainstorming on that), 
than overall progress.
___
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


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

[Bug 2099988] Please branch and build perl-Parallel-ForkManager in epel9

[bugzilla]

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

Jason Tibbitts  changed:

   What|Removed |Added

   Doc Type|--- |If docs needed, set a value



--- Comment #2 from Jason Tibbitts  ---
I personally have no interest at all in EPEL.  If you are set up as a packager
and wish to maintain the package, let me know and I will give you the necessary
access.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2099988
___
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