Fedora 40 mass rebuild has begun

2024-01-19 Thread Samyak Jain
Hi all,

Per the Fedora Linux f40 schedule [1] we started a mass rebuild on
2024-01-17 for Fedora f40 but due to various reasons such as dnf
issues, and other side-tags not getting merged we had to stop it.
But we finally managed to overcome those, and we fired the mass rebuild today
We are running this mass rebuild for the changes listed in:

https://pagure.io/releng/issues?status=Open=mass+rebuild=f40=changes

This mass rebuild is done in a side tag (f40-rebuild) and merged
when completed.

Failures can be seen
https://kojipkgs.fedoraproject.org/mass-rebuild/f40-failures.html


Things still need rebuilding
https://kojipkgs.fedoraproject.org/mass-rebuild/f40-need-rebuild.html


FTBFS (Fails To Build From Source) bugs will be filed after the
mass rebuild is complete.

Please let releng know if you see any bugs in the reporting.
You can contact releng in the #releng:fedoraproject.org room on Matrix,
by dropping an email to our list [2] or filing an issue in pagure [3].

This email template is also in https://pagure.io/releng if you wish to
propose improvements or changes to it.

Regards,
Samyak Jain
Fedora Release Engineering

[1] https://fedorapeople.org/groups/schedule/f-40/f-40-key-tasks.html
[2] https://lists.fedoraproject.org/admin/lists/rel-eng.lists.fedoraproject.org/
[3] https://pagure.io/releng/
--
___
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


Fedora 40 mass rebuild has begun

2024-01-19 Thread Samyak Jain
Hi all,

Per the Fedora Linux f40 schedule [1] we started a mass rebuild on
2024-01-17 for Fedora f40 but due to various reasons such as dnf
issues, and other side-tags not getting merged we had to stop it.
But we finally managed to overcome those, and we fired the mass rebuild today
We are running this mass rebuild for the changes listed in:

https://pagure.io/releng/issues?status=Open=mass+rebuild=f40=changes

This mass rebuild is done in a side tag (f40-rebuild) and merged
when completed.

Failures can be seen
https://kojipkgs.fedoraproject.org/mass-rebuild/f40-failures.html


Things still need rebuilding
https://kojipkgs.fedoraproject.org/mass-rebuild/f40-need-rebuild.html


FTBFS (Fails To Build From Source) bugs will be filed after the
mass rebuild is complete.

Please let releng know if you see any bugs in the reporting.
You can contact releng in the #releng:fedoraproject.org room on Matrix,
by dropping an email to our list [2] or filing an issue in pagure [3].

This email template is also in https://pagure.io/releng if you wish to
propose improvements or changes to it.

Regards,
Samyak Jain
Fedora Release Engineering

[1] https://fedorapeople.org/groups/schedule/f-40/f-40-key-tasks.html
[2] https://lists.fedoraproject.org/admin/lists/rel-eng.lists.fedoraproject.org/
[3] https://pagure.io/releng/
--
___
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


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

2024-01-19 Thread updates
The following Fedora EPEL 8 Security updates need testing:
 Age  URL
  16  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-3a29f0d349   
python-paramiko-2.12.0-2.el8
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-30bbfa1b75   
python3.11-jinja2-epel-3.1.3-1.el8
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-3f8d0039e7   
mongo-c-driver-1.24.3-2.el8
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-2ff3ef3512   
python-templated-dictionary-1.4-1.el8
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-be7448f09b   
monit-5.33.0-1.el8
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-2f5bf56806   
chromium-120.0.6099.224-1.el8


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

python-specfile-0.27.0-1.el8
simdjson-3.6.3-1.el8

Details about builds:



 python-specfile-0.27.0-1.el8 (FEDORA-EPEL-2024-aa26468452)
 A library for parsing and manipulating RPM spec files

Update Information:

Automatic update for python-specfile-0.27.0-1.el8.

ChangeLog:

* Fri Jan 19 2024 Packit  - 0.27.0-1
- Improved handling of commented-out macro definitions and fixed related logic 
in `Specfile.update_value()`. (#338)




 simdjson-3.6.3-1.el8 (FEDORA-EPEL-2024-1611649f82)
 Parsing gigabytes of JSON per second

Update Information:

Build for EPEL

ChangeLog:

* Mon Dec 11 2023 Ali Erdinc Koroglu  - 3.6.3-1
- Update to 3.6.3
* Wed Nov  1 2023 Ali Erdinc Koroglu  - 3.6.0-1
- Update to 3.6.0
* Sat Jul 22 2023 Fedora Release Engineering  - 
3.1.0-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild
* Wed Jan 25 2023 aekoroglu  - 3.1.0-1
- update to 3.1.0
* Sat Jan 21 2023 Fedora Release Engineering  - 
3.0.1-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_38_Mass_Rebuild
* Tue Nov 29 2022 aekoroglu  - 3.0.1-1
- update to 3.0.1
* Tue Aug  9 2022 aekoroglu  - 2.2.2-1
- initial package

References:

  [ 1 ] Bug #2255538 - Please build simdjson for EPEL8 and EPEL9
https://bugzilla.redhat.com/show_bug.cgi?id=2255538


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


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

2024-01-19 Thread updates
The following Fedora EPEL 9 Security updates need testing:
 Age  URL
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-b707739993   
mongo-c-driver-1.24.3-2.el9
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-8a05d0e402   
python-templated-dictionary-1.4-1.el9
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-0d11a63127   
chromium-120.0.6099.224-1.el9
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-601a7ad770   
vorbis-tools-1.4.2-10.el9


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

packit-0.89.0-1.el9
python-specfile-0.27.0-1.el9
python-xrst-2024.0.0-2.el9
rust-constant_time_eq-0.3.0-2.el9
rust-dunce-1.0.4-3.el9
rust-procs-0.14.4-1.el9
rust-sequoia-sq-0.33.0-1.el9
rust-tendril-0.4.3-7.el9
rust-url1-1.7.2-14.el9
rust-which-5.0.0-1.el9
rust-which4-4.4.2-1.el9
simdjson-3.6.3-1.el9

Details about builds:



 packit-0.89.0-1.el9 (FEDORA-EPEL-2024-815110fd46)
 A tool for integrating upstream projects with Fedora operating system

Update Information:

Automatic update for packit-0.89.0-1.el9.  # **Changelog for packit**  ``` *
Fri Jan 19 2024 Packit  - 0.89.0-1 - We have fixed a bug in
handling chroot-specific configuration once the chroots themselves are updated.
(#2194)  ```

ChangeLog:

* Fri Jan 19 2024 Packit  - 0.89.0-1
- We have fixed a bug in handling chroot-specific configuration once the 
chroots themselves are updated. (#2194)




 python-specfile-0.27.0-1.el9 (FEDORA-EPEL-2024-eb833bc7d2)
 A library for parsing and manipulating RPM spec files

Update Information:

Automatic update for python-specfile-0.27.0-1.el9.  # **Changelog for
python-specfile**  ``` * Fri Jan 19 2024 Packit  - 0.27.0-1 -
Improved handling of commented-out macro definitions and fixed related logic in
`Specfile.update_value()`. (#338)  ```

ChangeLog:

* Fri Jan 19 2024 Packit  - 0.27.0-1
- Improved handling of commented-out macro definitions and fixed related logic 
in `Specfile.update_value()`. (#338)




 python-xrst-2024.0.0-2.el9 (FEDORA-EPEL-2024-81fc1ba101)
 Extract Sphinx RST Files

Update Information:

Advance to upstream source xrst-2024.0.0.

ChangeLog:

* Fri Jan 19 2024 Brad Bell  - 2024.0.0-2
- Advance to new upstream source.
- Remove patches that were fixed upstream.
* Sat Jan  6 2024 Brad Bell  - 2024.0.0-1
- New upstream source.
- pyspellchecker is now available as a fedora package.
- Remove some extra blank lines.
* Fri Jul 21 2023 Fedora Release Engineering  - 
2023.1.22-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild
* Thu Jun 29 2023 Python Maint  - 2023.1.22-2
- Rebuilt for Python 3.12




 rust-constant_time_eq-0.3.0-2.el9 (FEDORA-EPEL-2024-7b1555896b)
 Compares two equal-sized byte strings in constant time

Update Information:

Remove the "CC0-1.0" license option from packages where it is not the only
option.

ChangeLog:

* Fri Jan 19 2024 Fabio Valentini  - 0.3.0-2
- Remove CC0-1.0 from license metadata (not acceptable for code in Fedora)




 rust-dunce-1.0.4-3.el9 (FEDORA-EPEL-2024-7b1555896b)
 Normalize Windows paths to the most compatible format

Update Information:

Remove the "CC0-1.0" license option from packages where it is not the only
option.

ChangeLog:

* Fri Jan 19 2024 Fabio Valentini  - 1.0.4-3
- Remove CC0-1.0 from license metadata (not acceptable for code in Fedora)
* Fri Jul 21 2023 Fedora Release Engineering  - 
1.0.4-2
- Rebuilt for 

Do you see any recent/new Segmentation faults when building your packages?

2024-01-19 Thread Miro Hrončok
I have *just* started seeing Segmentation faults when building Python in 
rawhide Koji. They weren't happening 2 hours ago.


I bisected the problem to:

Upgrading:
 binutils x86_64 2.41-28.fc40 local   26.4 MiB
   replacing binutils x86_64 2.41-26.fc40 fedora  26.4 MiB

And I reported https://bugzilla.redhat.com/2259285

However, is anything else impacted?

--
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: Cancel build from mass rebuild?

2024-01-19 Thread Miro Hrončok

On 19. 01. 24 20:39, David Bold wrote:

I noticed a while ago that bout++ is currently FTBFS, and one of the tests with 
mpich on s390x seems to get stuck in a dead lock, openmpi and other arches are 
having no issues.
I haven't managed to find a fix, and forgot to push a workaround that disables 
the tests. It seems I cannot cancel the build from the mass rebuild [1].

Can some one cancel the build for me? I think the timeout is quite late, and I 
do not want a stuck build waste all the compute time ...


Done.

--
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: Vala workaround for C type errors now in rawhide

2024-01-19 Thread Florian Weimer
* Florian Weimer:

> I patched the Vala compiler to generate pragmata to turn C type errors
> into warnings again, basically restoring the GCC 13 behavior.  If Vala
> packages regenerate their C sources using the Vala compiler, they should
> now build again.
>
> I submitted this patch upstream:
>
>   codegen: Emit GCC diagnostics pragmata for GCC 14 compatibility
>   
>
> The pragma kludge isn't ideal, but I don't see an alternative.

I had to disable int-conversion errors as well, via vala-0.56.14-3.fc40.
They occur when enums are used with generic types.

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


Cancel build from mass rebuild?

2024-01-19 Thread David Bold
I noticed a while ago that bout++ is currently FTBFS, and one of the tests with 
mpich on s390x seems to get stuck in a dead lock, openmpi and other arches are 
having no issues.
I haven't managed to find a fix, and forgot to push a workaround that disables 
the tests. It seems I cannot cancel the build from the mass rebuild [1].

Can some one cancel the build for me? I think the timeout is quite late, and I 
do not want a stuck build waste all the compute time ...

Any hints on how to debug mpich related issues on s390x would of course also be 
appreciated :-)

Best,
David

[1] https://koji.fedoraproject.org/koji/buildinfo?buildID=2348630
--
___
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-distro-aliases - The easiest way to get numbers of active Fedora releases

2024-01-19 Thread Stephen Gallagher
On Thu, Jan 18, 2024 at 10:32 AM Stephen Gallagher  wrote:
>
> On Wed, Jan 17, 2024 at 5:58 AM Jakub Kadlcik  wrote:
> >
> > Hello,
> > I just wanted to quickly announce a small project I did in collaboration 
> > with the Packit folks.
> >
> > Do you have some tools or services that perform actions on all currently 
> > active Fedora releases? And do you have to manually update their list every 
> > time a new Fedora release is branched or EOLed? The fedora-distro-aliases 
> > will make your life easier.
> >
> > https://github.com/rpm-software-management/fedora-distro-aliases
> >
> > It defines aliases such as `fedora-stable`, `epel-all`, `fedora-latest`, 
> > etc. To evaluate them, it queries Bodhi, so they are always up-to-date (but 
> > the tradeoff is that it requires an internet connection). There are 
> > multiple examples in the project README but the usage is simple, e.g.:
> >
> > >>> from fedora_distro_aliases import get_distro_aliases
> > >>> aliases = get_distro_aliases()
> > >>> [x.namever for x in aliases["fedora-all"]]
> > ['fedora-38', 'fedora-39', 'fedora-rawhide']
> >
> > The package is already in Fedora, give it a shot,
>
> Thanks! I'll look into updating
> https://github.com/sgallagher/get-fedora-releases-action with this.

Scratch that, it appears that `pip3 install fedora_distro_aliases`
requires installing krb5 devel packages (and compiling it) on the
target system before it can be used. This had the effect in my testing
of increasing the time spent running my Action from ~10s to ~240s,
which is too big of an increase. Is there a good reason why you're
using the complete BodhiClient interface instead of just doing simple
HTTP requests against https://bodhi.fedoraproject.org/releases ?
--
___
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: F40 Change Proposal: Optimized Binaries for the AMD64 Architecture (System-Wide)

2024-01-19 Thread Robert Marcano via devel

On 1/19/24 12:58 PM, Robert Marcano wrote:

On 12/28/23 1:25 PM, Robert Marcano wrote:

On 12/28/23 12:58 PM, Chris Adams wrote:

Once upon a time, Aoife Moloney  said:

Systemd will be modified to insert the additional directories into the
`$PATH` environment variable (affecting all programs on the system)


Anything that depends on PATH entries is IMHO doomed to failure.  There
are way too many things that explicitly set PATH to "known" values (for
good and bad reasons) to be able to depend on extending it.  Heck, it
took a long time to get sudo just to include /usr/local/{bin,sbin}.



Maybe replacing the /usr/bin related entries with a generic wrapper 
that launch the best binary from the per architecture directories.


Note: This may affect a few programs that use argv[0] for something 
meaningful.


The more I think about this, I am more convinced that /usr/bin installed 
binaries must do this redirection too even in the case the PATH is 
modified as this proposal states.


What about programs intentionally use absolute paths? These programs 
will not take advantage of the optimizations of the binary they are 
trying to start.


There many reasons for sometimes using an absolute path is agood idea, 
like:


1. Security: avoid depending on a PATH that can be user manipulated.
2. Configuration files that allow to switch to alternate implementation 
of the tool they call. I found a few on my installation, and their 
defaults include /usr/bin absolute paths.
3. Programs that run inside PATH is reset for security like sudo, 
CGI-BIN, etc.


Notice this PATH based optimization will only work when callers invoke 
the program by name only, relative paths will not get optimized either, 
a rare case but it could happen.


I have a counter proposal without modifying $PATH:

With the already defined directories 
/usr/bin/glibc-hwcaps/x86-64-v{2,3,4}/ add two new ones:


  /usr/bin/glibc-hwcaps/x86-64
  /usr/bin/glibc-hwcaps/x86-64-dynamic

Applications with optimized binaries will continue to install them on 
/usr/bin/glibc-hwcaps/x86-64-v{2,3,4}/ but the non optimized version 
isn't installed on /usr/bin but on /usr/bin/glibc-hwcaps/x86-64.


/usr/bin/glibc-hwcaps/x86-64-dynamic will be a read only overlayfs 
mounted by systemd, stacked with x86-64v4 on top and x86-64 on the bottom.


There will not be /usr/bin binaries for the optimized packages but 
symlinks to /usr/bin/glibc-hwcaps/x86-64-dynamic


Advantages for systemd based environment:

1. The optimized binaries are available to all the system, without 
worrying about applications that reset $PATH, or executions by relative 
or absolute paths and not only by name.


2. Imagine if and application like Firefox (only an example) get a boost 
by having the main binary optimized. /usr/bin/firefox currently is a 
shell script, there is no way optimize it with the current proposal, 
only if the script duplicates the microachitecture selection logic. With 
this proposal, modifying /usr/lib64/firefox/firefox to point to 
/usr/bin/glibc-hwcaps/x86-64-dynamic/firefox could work to. In reality 
it can work for all binaries outside of $PATH.


There are two downsides I could find:

1. Fedora Container images must be build with 
/usr/bin/glibc-hwcaps/x86-64-dynamic being a symlink to 
/usr/bin/glibc-hwcaps/x86-64 in order to non optimized binaries to be 
the default. This current proposal doesn't optimize either for 
containers runtimes that don't run systemd inside the container. Maybe 
in the future if this kind of layout get adoption on other 
distributions, container runtimes could do the overlay mount by themselves


2. In the case of trying to rescue the system, the process to create a 
chroot from the installation media will need and extra bind mount for 
/usr/bin/glibc-hwcaps/x86-64-dynamic pointing to 
/usr/bin/glibc-hwcaps/x86-64


Note aside: I think that the Live CD image should get an script 
available that do the same rescue boot option when trying to build the 
disk tree on /mnt/sysimage, if that script were available on LiveCD, 
rescue operations would be easier.

--
___
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 2258287] perl-libwww-perl-6.73 is available

2024-01-19 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=2258287

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



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

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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2258287

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202258287%23c3
--
___
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: F40 Change Proposal: Optimized Binaries for the AMD64 Architecture (System-Wide)

2024-01-19 Thread Robert Marcano via devel

On 12/28/23 1:25 PM, Robert Marcano wrote:

On 12/28/23 12:58 PM, Chris Adams wrote:

Once upon a time, Aoife Moloney  said:

Systemd will be modified to insert the additional directories into the
`$PATH` environment variable (affecting all programs on the system)


Anything that depends on PATH entries is IMHO doomed to failure.  There
are way too many things that explicitly set PATH to "known" values (for
good and bad reasons) to be able to depend on extending it.  Heck, it
took a long time to get sudo just to include /usr/local/{bin,sbin}.



Maybe replacing the /usr/bin related entries with a generic wrapper that 
launch the best binary from the per architecture directories.


Note: This may affect a few programs that use argv[0] for something 
meaningful.


The more I think about this, I am more convinced that /usr/bin installed 
binaries must do this redirection too even in the case the PATH is 
modified as this proposal states.


What about programs intentionally use absolute paths? These programs 
will not take advantage of the optimizations of the binary they are 
trying to start.


There many reasons for sometimes using an absolute path is agood idea, like:

1. Security: avoid depending on a PATH that can be user manipulated.
2. Configuration files that allow to switch to alternate implementation 
of the tool they call. I found a few on my installation, and their 
defaults include /usr/bin absolute paths.
3. Programs that run inside PATH is reset for security like sudo, 
CGI-BIN, etc.


Notice this PATH based optimization will only work when callers invoke 
the program by name only, relative paths will not get optimized either, 
a rare case but it could happen.

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


SPDX Statistics - Lisa edition

2024-01-19 Thread Miroslav Suchý

Hot news:

https://fedoraproject.org/wiki/Changes/SPDX_Licenses_Phase_3 was approved.

I generated license analysis using scancode-toolkit for all remaining packages 
http://miroslav.suchy.cz/fedora/spdx-reports/

Now lets dive into numbers:

Two weeks ago we had:


* 23542 spec files in Fedora

* 30058license tags in all spec files

* 11715 tags have not been converted to SPDX yet

* 5266tags can be trivially converted using `license-fedora2spdx`

* Progress: 61,03% ░░ 100%

ELN subset:

290 out of 2457 packages are not converted yet (progress 88.20%)



Today we have:

* 23681 spec files in Fedora

* 30232license tags in all spec files

* 11697 tags have not been converted to SPDX yet

* 5264tags can be trivially converted using `license-fedora2spdx`

* Progress: 61,31% ░░ 100%

ELN subset:

250 out of 2439 packages are not converted yet (progress 89.75%)

Graph of these data with the burndown chart:

https://docs.google.com/spreadsheets/d/1QVMEzXWML-6_Mrlln02axFAaRKCQ8zE807rpCjus-8s/edit?usp=sharing

The list of packages needed to be converted is here:

https://pagure.io/copr/license-validate/blob/main/f/packages-without-spdx-final.txt

List by package maintainers is here

https://pagure.io/copr/license-validate/blob/main/f/packages-without-spdx-final-maintainers.txt

List of packages from ELN subset that needs to be converted:

https://pagure.io/copr/license-validate/blob/main/f/eln-not-migrated.txt

New version of fedora-license-data has been released. With 9 new licenses (plus some public domain declarations). 22 
licenses are waiting to be review by SPDX.org (and then to be added to fedora-license-data) 
https://gitlab.com/fedora/legal/fedora-license-data/-/issues/?label_name%5B%5D=SPDX%3A%3Ablocked


Legal docs and especially

https://docs.fedoraproject.org/en-US/legal/allowed-licenses/

was updated too.


New projection when we will be finished is 2024-12-21 (+21 days from last 
report).  Pure linear approximation.

If your package does not have neither git-log entry nor spec-changelog entry mentioning SPDX and you know your license 
tag matches SPDX formula, you can put your package on ignore list


https://pagure.io/copr/license-validate/blob/main/f/ignore-packages.txt

Either pull-request or direct email to me is fine.


Why Lisa edition? On this day, in 1983 Apple released Apple Lisa - first personal computer with a GUI. Read about it on 
https://en.wikipedia.org/wiki/Apple_Lisa It is reminder that Apple was not always successful. And that revolutionary 
products does not mean economical success and can be obsoleted by products that are "good-enough".


Miroslav


--
___
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: Vala workaround for C type errors now in rawhide

2024-01-19 Thread Michael Catanzaro


Thank you!

--
___
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: Vala workaround for C type errors now in rawhide

2024-01-19 Thread Florian Weimer
* Florian Weimer:

> I patched the Vala compiler to generate pragmata to turn C type errors
> into warnings again, basically restoring the GCC 13 behavior.  If Vala
> packages regenerate their C sources using the Vala compiler, they should
> now build again.
>
> I submitted this patch upstream:
>
>   codegen: Emit GCC diagnostics pragmata for GCC 14 compatibility
>   
>
> The pragma kludge isn't ideal, but I don't see an alternative.

It has come to my attention that not all packages build from source even
if BuildRequires: vala is present.  You may have to add something like
this

  find -name '*.vala' -exec touch {} \;

to %prep to trigger recompilation.

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: HEADSUP boost and tbb rebuilds starting in a side tag

2024-01-19 Thread Jonathan Wakely
On Fri, 19 Jan 2024 at 01:27, Sérgio Basto  wrote:
>
> On Fri, 2024-01-19 at 00:21 +, Jonathan Wakely wrote:
> > On Fri, 19 Jan 2024 at 00:10, Jonathan Wakely 
> > wrote:
> > >
> > > On Wed, 17 Jan 2024 at 19:07, Jonathan Wakely 
> > > wrote:
> > > >
> > > > I'll be building boost, tbb, and the packages that depend on them
> > > > in
> > > > the f40-build-side-81691
> > > > side tag over the next few hours (in advance of the mass rebuild
> > > > tomorrow).
> > > >
> > > > If your package gets a "Rebuilt for Boost 1.83.0" comment, please
> > > > don't rebuild it in rawhide, we're building it in the side tag
> > > > and
> > > > will merge it back to rawhide. If you need to update your package
> > > > before the mass rebuild, please let me and Patrick (CC'd) know
> > > > and
> > > > your changes can be built in the side tag too.
> > >
> > > Please DO NOT build your package in rawhide if we're rebuilding it
> > > in
> > > the boost side tag. It will require another rebuild in the side tag
> > > and another bodhi update and delay the mass rebuild by several more
> > > hours while the gating tests run.
> >
> > OK, the side tag has been merged. Builds can be done in rawhide again
> > now.
>
>
> not yet , ttps://bodhi.fedoraproject.org/updates/FEDORA-2024-7c21b7afa2
> needs pass in all "Test Gating" or is running again "Test Gating" for
> new build(s)

(The new build that I think you caused btw!)

I'm not sure what's going on with the waiting status, but it's in
stable, and the new packages are in the buildroot and being used by
the mass rebuild.
--
___
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


Vala workaround for C type errors now in rawhide

2024-01-19 Thread Florian Weimer
I patched the Vala compiler to generate pragmata to turn C type errors
into warnings again, basically restoring the GCC 13 behavior.  If Vala
packages regenerate their C sources using the Vala compiler, they should
now build again.

I submitted this patch upstream:

  codegen: Emit GCC diagnostics pragmata for GCC 14 compatibility
  

The pragma kludge isn't ideal, but I don't see an alternative.

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


Fedora rawhide compose report: 20240119.n.0 changes

2024-01-19 Thread Fedora Rawhide Report
OLD: Fedora-Rawhide-20240117.n.0
NEW: Fedora-Rawhide-20240119.n.0

= SUMMARY =
Added images:9
Dropped images:  8
Added packages:  21
Dropped packages:6
Upgraded packages:   251
Downgraded packages: 0

Size of added packages:  133.25 MiB
Size of dropped packages:144.45 MiB
Size of upgraded packages:   16.39 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =
Image: Sericea ociarchive aarch64
Path: Sericea/aarch64/images/Fedora-Sericea-Rawhide.20240119.n.0.ociarchive
Image: Silverblue ociarchive ppc64le
Path: 
Silverblue/ppc64le/images/Fedora-Silverblue-Rawhide.20240119.n.0.ociarchive
Image: Onyx ociarchive x86_64
Path: Onyx/x86_64/images/Fedora-Onyx-Rawhide.20240119.n.0.ociarchive
Image: Kinoite ociarchive x86_64
Path: Kinoite/x86_64/images/Fedora-Kinoite-Rawhide.20240119.n.0.ociarchive
Image: Silverblue ociarchive aarch64
Path: 
Silverblue/aarch64/images/Fedora-Silverblue-Rawhide.20240119.n.0.ociarchive
Image: Sericea ociarchive x86_64
Path: Sericea/x86_64/images/Fedora-Sericea-Rawhide.20240119.n.0.ociarchive
Image: LXDE live x86_64
Path: Spins/x86_64/iso/Fedora-LXDE-Live-x86_64-Rawhide-20240119.n.0.iso
Image: Silverblue ociarchive x86_64
Path: Silverblue/x86_64/images/Fedora-Silverblue-Rawhide.20240119.n.0.ociarchive
Image: Kinoite ociarchive aarch64
Path: Kinoite/aarch64/images/Fedora-Kinoite-Rawhide.20240119.n.0.ociarchive

= DROPPED IMAGES =
Image: Astronomy_KDE live x86_64
Path: Labs/x86_64/iso/Fedora-Astronomy_KDE-Live-x86_64-Rawhide-20240117.n.0.iso
Image: Sericea dvd-ostree x86_64
Path: Sericea/x86_64/iso/Fedora-Sericea-ostree-x86_64-Rawhide-20240117.n.0.iso
Image: Silverblue dvd-ostree ppc64le
Path: 
Silverblue/ppc64le/iso/Fedora-Silverblue-ostree-ppc64le-Rawhide-20240117.n.0.iso
Image: Design_suite live x86_64
Path: Labs/x86_64/iso/Fedora-Design_suite-Live-x86_64-Rawhide-20240117.n.0.iso
Image: KDE live aarch64
Path: Spins/aarch64/iso/Fedora-KDE-Live-aarch64-Rawhide-20240117.n.0.iso
Image: Silverblue dvd-ostree aarch64
Path: 
Silverblue/aarch64/iso/Fedora-Silverblue-ostree-aarch64-Rawhide-20240117.n.0.iso
Image: Kinoite dvd-ostree ppc64le
Path: Kinoite/ppc64le/iso/Fedora-Kinoite-ostree-ppc64le-Rawhide-20240117.n.0.iso
Image: Onyx dvd-ostree x86_64
Path: Onyx/x86_64/iso/Fedora-Onyx-ostree-x86_64-Rawhide-20240117.n.0.iso

= ADDED PACKAGES =
Package: foonathan-memory-0.7.3-1.fc40
Summary: STL compatible C++ memory allocator library
RPMs:foonathan-memory foonathan-memory-devel foonathan-memory-doc 
foonathan-memory-tools
Size:894.74 KiB

Package: python-snakemake-executor-plugin-cluster-generic-1.0.7-1.fc40
Summary: Generic cluster executor for Snakemake
RPMs:python3-snakemake-executor-plugin-cluster-generic
Size:22.78 KiB

Package: python-snakemake-interface-executor-plugins-8.1.3-2.fc40~bootstrap
Summary: Stable interface for interactions between Snakemake and its executor 
plugins
RPMs:python3-snakemake-interface-executor-plugins
Size:62.22 KiB

Package: python-snakemake-interface-storage-plugins-3.0.0-2.fc40~bootstrap
Summary: Stable interface for interactions between Snakemake and its storage 
plugins
RPMs:python3-snakemake-interface-storage-plugins
Size:42.76 KiB

Package: python-snakemake-storage-plugin-http-0.2.3-1.fc40
Summary: Snakemake storage plugin for downloading input files from HTTP(s)
RPMs:python3-snakemake-storage-plugin-http
Size:20.37 KiB

Package: python-snakemake-storage-plugin-s3-0.2.8-1.fc40
Summary: A Snakemake storage plugin for S3 API storage (AWS S3, MinIO, etc.)
RPMs:python3-snakemake-storage-plugin-s3
Size:22.06 KiB

Package: rocfft-6.0.0-2.fc40
Summary: ROCm Fast Fourier Transforms (FFT) library
RPMs:rocfft rocfft-devel rocfft-test
Size:2.46 MiB

Package: rocsolver-6.0.0-2.fc40
Summary: Next generation LAPACK implementation for ROCm platform
RPMs:rocsolver rocsolver-devel
Size:122.94 MiB

Package: rust-base32-0.4.0-1.fc40
Summary: Encoder/decoder for Rust
RPMs:rust-base32+default-devel rust-base32-devel
Size:22.21 KiB

Package: rust-bitfield0.13-0.13.2-1.fc40
Summary: Macros to generate bitfield-like struct
RPMs:rust-bitfield0.13+default-devel rust-bitfield0.13-devel
Size:31.08 KiB

Package: rust-fend-core-1.4.1-1.fc40
Summary: Arbitrary-precision unit-aware calculator
RPMs:rust-fend-core+default-devel rust-fend-core-devel
Size:120.36 KiB

Package: rust-mock_instant-0.3.1-1.fc40
Summary: Simple way to mock an std::time::Instant
RPMs:rust-mock_instant+default-devel rust-mock_instant+once_cell-devel 
rust-mock_instant+sync-devel rust-mock_instant-devel
Size:33.22 KiB

Package: rust-notify-debouncer-full-0.3.1-1.fc40
Summary: Notify event debouncer optimized for ease of use
RPMs:rust-notify-debouncer-full+crossbeam-channel-devel 
rust-notify-debouncer-full+crossbeam-devel 
rust-notify-debouncer-full+default-devel rust-notify

[Bug 2259172] New: perl-Tk-804.036-12.fc40 FTBFS: objGlue.c: In function ‘Tcl_GetByteArrayFromObj’: /usr/lib64/perl5/CORE/sv.h:1952:31: error: passing argument 3 of ‘Perl_SvPV_helper’ from incompatibl

2024-01-19 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=2259172

Bug ID: 2259172
   Summary: perl-Tk-804.036-12.fc40 FTBFS: objGlue.c: In function
‘Tcl_GetByteArrayFromObj’:
/usr/lib64/perl5/CORE/sv.h:1952:31: error: passing
argument 3 of ‘Perl_SvPV_helper’ from incompatible
pointer type
   Product: Fedora
   Version: rawhide
   URL: https://koschei.fedoraproject.org/package/perl-Tk
Status: NEW
 Component: perl-Tk
  Assignee: xav...@bachelot.org
  Reporter: ppi...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org,
xav...@bachelot.org
Blocks: 2231791 (F40FTBFS,RAWHIDEFTBFS)
  Target Milestone: ---
Classification: Fedora



perl-Tk-804.036-12.fc40 fails to build in Fedora 40:

gcc -c  -I/usr/include/freetype2 -D_REENTRANT -D_GNU_SOURCE -O2 -flto=auto
-ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall
-Wno-complain-wrong-lang -Werror=format-security
-Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -fwrapv
-fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -g   -DVERSION=\"804.036\" -DXS_VERSION=\"804.036\"
-fPIC "-I/usr/lib64/perl5/CORE"objGlue.c
[...]
In file included from /usr/lib64/perl5/CORE/perl.h:4530:
objGlue.c: In function ‘Tcl_GetByteArrayFromObj’:
/usr/lib64/perl5/CORE/sv.h:1952:31: error: passing argument 3 of
‘Perl_SvPV_helper’ from incompatible pointer type
[-Wincompatible-pointer-types]
 1952 |Perl_SvPV_helper(aTHX_ sv, , flags, SvPVnormal_type_,   
\
/usr/lib64/perl5/CORE/sv.h:1972:37: note: in expansion of macro ‘SvPV_flags’
 1972 | #define SvPV(sv, len)   SvPV_flags(sv, len, SV_GMAGIC)
  | ^~
objGlue.c:630:29: note: in expansion of macro ‘SvPV’
  630 |return (unsigned char *) SvPV(objPtr, *lengthPtr);
  | ^~~~

A difference between passing and failing build roots is at
. This failure is probably
triggered by upgrading gcc from 13.2.1-6.fc40 to 14.0.1-0.1.fc40.



Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=2231791
[Bug 2231791] Fedora 40 FTBFS Tracker
-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2259172

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202259172%23c0
--
___
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 2259171] New: perl-CGI-SpeedyCGI-2.22-52.fc40 FTBFS: speedy_perl.c:918:29: error: passing argument 2 of ‘perl_parse’ from incompatible pointer type

2024-01-19 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=2259171

Bug ID: 2259171
   Summary: perl-CGI-SpeedyCGI-2.22-52.fc40 FTBFS:
speedy_perl.c:918:29: error: passing argument 2 of
‘perl_parse’ from incompatible pointer type
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-CGI-SpeedyCGI
  Assignee: redhat-bugzi...@linuxnetz.de
  Reporter: ppi...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: cleaver-red...@terabithia.org,
perl-devel@lists.fedoraproject.org,
redhat-bugzi...@linuxnetz.de
Blocks: 2231791 (F40FTBFS,RAWHIDEFTBFS)
  Target Milestone: ---
Classification: Fedora



perl-CGI-SpeedyCGI-2.22-52.fc40 fails to build in Fedora 40:

gcc -c  -I../src -I. -D_REENTRANT -D_GNU_SOURCE -O2 -flto=auto
-ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall
-Wno-complain-wrong-lang -Werror=format-security
-Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -fwrapv
-fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -O2 -flto=auto -ffat-lto-objects -fexceptions -g
-grecord-gcc-switches -pipe -Wall -Wno-complain-wrong-lang
-Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3
-Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64  
-mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection
-fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer  
-DVERSION=\"2.22\" -DXS_VERSION=\"2.22\" -fPIC "-I/usr/lib64/perl5/CORE" 
-DSPEEDY_PROGNAME=\"speedy_backend\" -DSPEEDY_VERSION=\"2.22\" -DSPEEDY_BACKEND
speedy_perl.c
speedy_perl.c: In function ‘speedy_perl_init’:
speedy_perl.c:918:29: error: passing argument 2 of ‘perl_parse’ from
incompatible pointer type [-Wincompatible-pointer-types]
  918 | if (perl_parse(my_perl, xs_init,
  | ^~~
  | |
  | void (*)(void)
In file included from /usr/lib64/perl5/CORE/perl.h:6188,
 from ../src/speedy_inc_perl.h:25,
 from speedy.h:1,
 from speedy_perl.c:20:
/usr/lib64/perl5/CORE/proto.h:3472:47: note: expected ‘XSINIT_t’ {aka ‘void
(*)(struct interpreter *)’} but argument is of type ‘void (*)(void)’
 3472 | perl_parse(PerlInterpreter *my_perl, XSINIT_t xsinit, int argc, char
**argv, char **env);
  |  ~^~

A difference between passing and failing build root is at
. This failure is probably
triggered by upgrading gcc from 13.2.1-6.fc40 to 14.0.1-0.1.fc40.



Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=2231791
[Bug 2231791] Fedora 40 FTBFS Tracker
-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2259171

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202259171%23c0
--
___
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 2259168] New: perl-re-engine-PCRE-0.17-37.fc40 FTBFS: PCRE.h:22:5: error: initialization of ‘REGEXP * (*)(PerlInterpreter *, SV * const, U32)’ {aka ‘struct p5rx * (*)(struct interpreter *, struc

2024-01-19 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=2259168

Bug ID: 2259168
   Summary: perl-re-engine-PCRE-0.17-37.fc40 FTBFS: PCRE.h:22:5:
error: initialization of ‘REGEXP * (*)(PerlInterpreter
*, SV * const,  U32)’ {aka ‘struct p5rx * (*)(struct
interpreter *, struct sv * const,  unsigned int)’}
from incompatible pointer type
   Product: Fedora
   Version: rawhide
   URL: https://koschei.fedoraproject.org/package/perl-re-engi
ne-PCRE
Status: NEW
 Component: perl-re-engine-PCRE
  Assignee: ppi...@redhat.com
  Reporter: ppi...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com
Blocks: 2231791 (F40FTBFS,RAWHIDEFTBFS)
  Target Milestone: ---
Classification: Fedora



perl-re-engine-PCRE-0.17-37.fc40 fails to build in Fedora 40:

gcc -c   -D_REENTRANT -D_GNU_SOURCE -O2 -flto=auto -ffat-lto-objects
-fexceptions -g -grecord-gcc-switches -pipe -Wall -Wno-complain-wrong-lang
-Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3
-Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64
-mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection
-fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -fwrapv
-fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -O2 -flto=auto -ffat-lto-objects -fexceptions -g
-grecord-gcc-switches -pipe -Wall -Wno-complain-wrong-lang
-Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3
-Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64  
-mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection
-fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer  
-DVERSION=\"0.17\" -DXS_VERSION=\"0.17\" -fPIC "-I/usr/lib64/perl5/CORE"  
PCRE.c
In file included from PCRE.xs:7:
PCRE.h:5:44: warning: duplicate ‘const’ declaration specifier
[-Wduplicate-decl-specifier]
5 | EXTERN_C REGEXP * PCRE_comp(pTHX_ const SV const *, const U32);
  |^
PCRE.h:22:5: error: initialization of ‘REGEXP * (*)(PerlInterpreter *, SV *
const,  U32)’ {aka ‘struct p5rx * (*)(struct interpreter *, struct sv * const, 
unsigned int)’} from incompatible pointer type ‘REGEXP * (*)(PerlInterpreter *,
const SV *, const U32)’ {aka ‘struct p5rx * (*)(struct interpreter *, const
struct sv *, const unsigned int)’} [-Wincompatible-pointer-types]
   22 | PCRE_comp,
  | ^
PCRE.h:22:5: note: (near initialization for ‘pcre_engine.comp’)
PCRE.h:23:5: error: initialization of ‘I32 (*)(PerlInterpreter *, REGEXP *
const,  char *, char *, char *, ssize_t,  SV *, void *, U32)’ {aka ‘int
(*)(struct interpreter *, struct p5rx * const,  char *, char *, char *, long
int,  struct sv *, void *, unsigned int)’} from incompatible pointer type ‘I32
(*)(PerlInterpreter *, REGEXP * const,  char *, char *, char *, I32,  SV *,
void *, U32)’ {aka ‘int (*)(struct interpreter *, struct p5rx * const,  char *,
char *, char *, int,  struct sv *, void *, unsigned int)’}
[-Wincompatible-pointer-types]
   23 | PCRE_exec,
  | ^
PCRE.h:23:5: note: (near initialization for ‘pcre_engine.exec’)
PCRE.h:24:5: error: initialization of ‘char * (*)(PerlInterpreter *, REGEXP *
const,  SV *, const char * const,  char *, char *, const U32, 
re_scream_pos_data *)’ {aka ‘char * (*)(struct interpreter *, struct p5rx *
const,  struct sv *, const char * const,  char *, char *, const unsigned int, 
struct re_scream_pos_data_s *)’} from incompatible pointer type ‘char *
(*)(PerlInterpreter *, REGEXP * const,  SV *, char *, char *, U32, 
re_scream_pos_data *)’ {aka ‘char * (*)(struct interpreter *, struct p5rx *
const,  struct sv *, char *, char *, unsigned int,  struct re_scream_pos_data_s
*)’} [-Wincompatible-pointer-types]
   24 | PCRE_intuit,
  | ^~~

A difference between passing and failing build roots is at
. This failure is probably
triggered by upgrading gcc from 13.2.1-6.fc40 to 14.0.1-0.1.fc40.



Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=2231791
[Bug 2231791] Fedora 40 FTBFS Tracker
-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2259168

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202259168%23c0
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 2259166] New: perl-PDF-Haru-1.00-42.fc40 FTBFS: Haru.xs:1195:44: error: passing argument 2 of ‘HPDF_Page_SetDash’ from incompatible pointer type

2024-01-19 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=2259166

Bug ID: 2259166
   Summary: perl-PDF-Haru-1.00-42.fc40 FTBFS: Haru.xs:1195:44:
error: passing argument 2 of ‘HPDF_Page_SetDash’ from
incompatible pointer type
   Product: Fedora
   Version: rawhide
   URL: https://koschei.fedoraproject.org/package/perl-PDF-Har
u
Status: NEW
 Component: perl-PDF-Haru
  Assignee: robinlee.s...@gmail.com
  Reporter: ppi...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org,
robinlee.s...@gmail.com
Blocks: 2231791 (F40FTBFS,RAWHIDEFTBFS)
  Target Milestone: ---
Classification: Fedora



perl-PDF-Haru-1.00-42.fc40 fails to build in Fedora 40:

gcc -c  -I. -D_REENTRANT -D_GNU_SOURCE -O2 -flto=auto -ffat-lto-objects
-fexceptions -g -grecord-gcc-switches -pipe -Wall -Wno-complain-wrong-lang
-Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3
-Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64
-mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection
-fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -fwrapv
-fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -O2 -flto=auto -ffat-lto-objects -fexceptions -g
-grecord-gcc-switches -pipe -Wall -Wno-complain-wrong-lang
-Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3
-Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64  
-mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection
-fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer  
-DVERSION=\"1.00\" -DXS_VERSION=\"1.00\" -fPIC "-I/usr/lib64/perl5/CORE"  
Haru.c
Haru.xs: In function ‘XS_PDF__Haru__Page_SetDash’:
Haru.xs:1195:44: error: passing argument 2 of ‘HPDF_Page_SetDash’ from
incompatible pointer type [-Wincompatible-pointer-types]
 1195 | RETVAL = HPDF_Page_SetDash  (page, ptn, num_elem + 1, phase);
  |^~~
  ||
  |HPDF_UINT16 * {aka short
unsigned int *}
In file included from Haru.xs:5:
/usr/include/hpdf.h:1192:39: note: expected ‘const HPDF_REAL *’ {aka ‘const
float *’} but argument is of type ‘HPDF_UINT16 *’ {aka ‘short unsigned int *’}
 1192 | const HPDF_REAL  *dash_ptn,
  | ~~^~~~

A difference between passing and failing build roots is at
. This failure is probably
triggered by upgrading gcc from 13.2.1-6.fc40 to 14.0.1-0.1.fc40.



Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=2231791
[Bug 2231791] Fedora 40 FTBFS Tracker
-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2259166

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202259166%23c0
--
___
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: -fcf-protection dropped from i686 compiler flags

2024-01-19 Thread Florian Weimer
* Michael Catanzaro:

> Unfortunately this is causing gating tests to fail for rawhide builds,
> e.g.:
>
> https://artifacts.dev.testing-farm.io/081ad2a3-76cd-4aa0-b95e-e870ff75a65c/
>
> Hardened: /usr/bin/pkcon: FAIL: cf-protection test because
> .note.gnu.property section did not contain the necessary flags

As Adam said, these reports should not alter the automatically
determined outcome of the gating process.  Updates for annobin are on
their way, to reduce confusion.

The -fcf-protection change did not change this because the markup was
gone before the change due to upstream glibc changes, which impact all
newly linked binaries due to their dependency on the statically linked
glibc startup code.

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: Mass rebuild: git push --no-verify

2024-01-19 Thread Michael J Gruber
Am Do., 18. Jan. 2024 um 17:14 Uhr schrieb Jerry James :
>
> On Tue, Jan 16, 2024 at 3:32 PM Sérgio Basto  wrote:
> > You got mass rebuild script here [1] in massrebuildsinfo.py [2] you may
> > define what packages you are going to rebuild ,  in line 93 of mass-
> > rebuild.py [3] you got the list of packages that you go rebuild
> > and since line 132 [4] you have the commands that will run .
> > Is rpmdev-bumpspec that fails ?
>
> Thank you for the pointer, Sérgio.  I have opened
> https://pagure.io/releng/pull-request/11897.
>
> It is not rpmdev-bumpspec that fails.  That works just fine.  But any
> package that uses the %{fontpkgname1}, %{fontpkgname2}, ... macros
> requires --no-verify today when pushing to git, due to the referenced
> bug.  That's merely annoying for a human, but fatal to an automated
> build script that doesn't pass --noverify.

No, that's not the case. Please re-read the bug.

For *some* of the packages among those which use these macros (but
definitely not all), the python bindings to rpm do not expand that
macro whereas rpm itself does.

Since `spectool` uses the bindings, its check for the presence of all
source files fails if the source macro contains an unexpanded macro.
The packages build fine.

Whether it's the bindings' fault, or the spec files', or the
rpm-font-macros' is unclear at this point. In any case the check
*wrongly* indicates FTBFS.

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


[Bug 2259131] perl-gettext-1.07-28.fc40 FTBFS: tests fail

2024-01-19 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=2259131



--- Comment #2 from Petr Pisar  ---
I recommend build-requiring glibc-langpack-en and setting locale to en_US.UTF-8
as a fix.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2259131

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202259131%23c2
--
___
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 2259131] perl-gettext-1.07-28.fc40 FTBFS: tests fail

2024-01-19 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=2259131

Petr Pisar  changed:

   What|Removed |Added

Link ID||Github
   ||vandry/Perl-Locale-gettext/
   ||pull/4




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2259131
--
___
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 2259131] perl-gettext-1.07-28.fc40 FTBFS: tests fail

2024-01-19 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=2259131



--- Comment #1 from Petr Pisar  ---
The tests depends on a locale. It fails in C.UTF-8 locale, it passes in
en_US.UTF-8 locale. This is probably triggered by upgrading
glibc-minimal-langpack from 2.38.9000-28.fc40 to 2.38.9000-29.fc40.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2259131

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202259131%23c1
--
___
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 2259131] New: perl-gettext-1.07-28.fc40 FTBFS: tests fail

2024-01-19 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=2259131

Bug ID: 2259131
   Summary: perl-gettext-1.07-28.fc40 FTBFS: tests fail
   Product: Fedora
   Version: rawhide
   URL: https://koschei.fedoraproject.org/package/perl-gettext
Status: NEW
 Component: perl-gettext
  Assignee: rc040...@freenet.de
  Reporter: ppi...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: d...@danny.cz, lxt...@gmail.com,
perl-devel@lists.fedoraproject.org,
rc040...@freenet.de
Blocks: 2231791 (F40FTBFS,RAWHIDEFTBFS)
  Target Milestone: ---
Classification: Fedora



perl-gettext-1.07-28.fc40 fails to build in Fedora 40 because the tests fail
like this:

t/bind.t ... ok
# Failed test 1 in t/frconvert.t at line 22
#  t/frconvert.t line 22 is:ok(0);
t/frconvert.t .. 
Failed 1/1 subtests 
# Failed test 1 in t/jaconvert.t at line 23
#  t/jaconvert.t line 23 is:ok(0);
t/jaconvert.t .. 
Failed 1/1 subtests 
# Failed test 1 in t/raw.t at line 14
#  t/raw.t line 14 is:  ok(0);
t/raw.t  
Failed 1/1 subtests 
t/use.t  ok
Test Summary Report
---
t/frconvert.t (Wstat: 0 Tests: 1 Failed: 1)
  Failed test:  1
t/jaconvert.t (Wstat: 0 Tests: 1 Failed: 1)
  Failed test:  1
t/raw.t  (Wstat: 0 Tests: 1 Failed: 1)
  Failed test:  1
Files=5, Tests=5,  1 wallclock secs ( 0.02 usr  0.01 sys +  0.14 cusr  0.03
csys =  0.20 CPU)
Result: FAIL

A difference between passing and failing build root is at
.



Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=2231791
[Bug 2231791] Fedora 40 FTBFS Tracker
-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2259131

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202259131%23c0
--
___
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: HEADSUP boost and tbb rebuilds starting in a side tag

2024-01-19 Thread Dan Horák
On Thu, 18 Jan 2024 22:15:18 +
Jonathan Wakely  wrote:

> On Wed, 17 Jan 2024 at 19:07, Jonathan Wakely  wrote:
> >
> > I'll be building boost, tbb, and the packages that depend on them in
> > the f40-build-side-81691
> > side tag over the next few hours (in advance of the mass rebuild tomorrow).
> >
> > If your package gets a "Rebuilt for Boost 1.83.0" comment, please
> > don't rebuild it in rawhide, we're building it in the side tag and
> > will merge it back to rawhide. If you need to update your package
> > before the mass rebuild, please let me and Patrick (CC'd) know and
> > your changes can be built in the side tag too.
> >
> > (Since there is overlap between the packages that depend on boost and
> > tbb I'm doing them all at once)
> > https://fedoraproject.org/wiki/Changes/F40Boost183
> > https://fedoraproject.org/wiki/Changes/F39TBB2020.3  
> 
> Most of the packages have now been rebuilt and will be merged to
> rawhide soon (I hope!).
> See https://bodhi.fedoraproject.org/updates/FEDORA-2024-7c21b7afa2
> 
> The following packages failed to build, for the reasons shown. Some
> other packages that depend on these ones couldn't be built due to
> these failures. There are some others that weren't rebuild, like
> OpenImageIO and python-graph-tool, but the maintainers are aware.
> 
> 
> codeblocks
> needs non-existent squirrel-devel.i686

ah, we should have removed the dep after switching to the bundled
patched squirrel, fix in progress


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