[Bug 2253024] perl-Sub-Override-0.10 is available

2023-12-05 Thread bugzilla 
https://bugzilla.redhat.com/show_bug.cgi?id=2253024

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|emman...@seyman.fr, |
   |iarn...@gmail.com,  |
   |perl-devel@lists.fedoraproj |
   |ect.org |
   Doc Type|--- |If docs needed, set a value




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2253024
--
___
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 2252727] Upgrade perl-DBIx-SearchBuilder to 1.79

2023-12-05 Thread bugzilla 
https://bugzilla.redhat.com/show_bug.cgi?id=2252727

Jitka Plesnikova  changed:

   What|Removed |Added

   Fixed In Version||perl-DBIx-SearchBuilder-1.7
   ||9-1.fc40
   ||perl-DBIx-SearchBuilder-1.7
   ||9-1.fc39
 Resolution|--- |RAWHIDE
 Status|NEW |CLOSED
Last Closed||2023-12-06 07:47:54



--- Comment #1 from Jitka Plesnikova  ---
Built by corsepiu


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202252727%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 2252996] F39FailsToInstall: perl-PAR-Packer

2023-12-05 Thread bugzilla 
https://bugzilla.redhat.com/show_bug.cgi?id=2252996

Jitka Plesnikova  changed:

   What|Removed |Added

   Fixed In Version||perl-PAR-Packer-1.059-2.fc3
   ||9
 Status|NEW |CLOSED
   Doc Type|--- |If docs needed, set a value
 Resolution|--- |ERRATA
Last Closed||2023-12-06 07:36:29




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2252996
--
___
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 2074940] Remove usage of gethostbyname() and inet_addr() from perl-FCGI package

2023-12-05 Thread bugzilla 
https://bugzilla.redhat.com/show_bug.cgi?id=2074940

Jitka Plesnikova  changed:

   What|Removed |Added

 Resolution|EOL |---
 CC||jples...@redhat.com
Version|37  |rawhide
 Status|CLOSED  |ASSIGNED
   Keywords||Reopened



--- Comment #5 from Jitka Plesnikova  ---
Still valid.


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202074940%23c5
--
___
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

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

2023-12-05 Thread updates 
The following Fedora EPEL 7 Security updates need testing:
 Age  URL
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-46696cc30b   
chromium-119.0.6045.199-1.el7


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

R-qtl-1.66-1.el7
xrootd-5.6.3-3.el7

Details about builds:



 R-qtl-1.66-1.el7 (FEDORA-EPEL-2023-d0bbb14250)
 Tools for analyzing QTL experiments

Update Information:

R qtl 1.66

ChangeLog:

* Tue Dec  5 2023 Mattias Ellert  - 1.66-1
- Update to 1.66




 xrootd-5.6.3-3.el7 (FEDORA-EPEL-2023-6d102dc0c0)
 Extended ROOT file server

Update Information:

Fix include path in XRootDConfig.cmake Support big endian in XrdZip

ChangeLog:

* Tue Dec  5 2023 Mattias Ellert  - 1:5.6.3-3
- Avoid /tmp when running some tests
- Fail gracefully in case of unsupported extended file attributes
- Avoid null bytes in error message strings
- Fix include path in XRootDConfig.cmake
- Avoid dereferencing unaligned pointers
- Support big endian in XrdZip


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

[Bug 2251622] CVE-2023-47038 perl: Write past buffer end via illegal user-defined Unicode property [fedora-all]

2023-12-05 Thread bugzilla 
https://bugzilla.redhat.com/show_bug.cgi?id=2251622

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version||perl-5.38.2-502.fc39
 Resolution|--- |ERRATA
 Status|ON_QA   |CLOSED
Last Closed||2023-12-06 01:40:15



--- Comment #8 from Fedora Update System  ---
FEDORA-2023-c67f4dbf13 has been pushed to the Fedora 39 stable repository.
If problem still persists, please make note of it in this bug report.


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202251622%23c8
--
___
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

Fedora rawhide compose report: 20231205.n.1 changes

2023-12-05 Thread Fedora Rawhide Report 
OLD: Fedora-Rawhide-20231204.n.0
NEW: Fedora-Rawhide-20231205.n.1

= SUMMARY =
Added images:6
Dropped images:  6
Added packages:  6
Dropped packages:3
Upgraded packages:   148
Downgraded packages: 0

Size of added packages:  22.96 MiB
Size of dropped packages:7.35 MiB
Size of upgraded packages:   8.11 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =
Image: Silverblue dvd-ostree aarch64
Path: 
Silverblue/aarch64/iso/Fedora-Silverblue-ostree-aarch64-Rawhide-20231205.n.1.iso
Image: Kinoite dvd-ostree aarch64
Path: Kinoite/aarch64/iso/Fedora-Kinoite-ostree-aarch64-Rawhide-20231205.n.1.iso
Image: Onyx dvd-ostree x86_64
Path: Onyx/x86_64/iso/Fedora-Onyx-ostree-x86_64-Rawhide-20231205.n.1.iso
Image: Kinoite dvd-ostree x86_64
Path: Kinoite/x86_64/iso/Fedora-Kinoite-ostree-x86_64-Rawhide-20231205.n.1.iso
Image: Sericea dvd-ostree x86_64
Path: Sericea/x86_64/iso/Fedora-Sericea-ostree-x86_64-Rawhide-20231205.n.1.iso
Image: Silverblue dvd-ostree ppc64le
Path: 
Silverblue/ppc64le/iso/Fedora-Silverblue-ostree-ppc64le-Rawhide-20231205.n.1.iso

= DROPPED IMAGES =
Image: i3 live aarch64
Path: Spins/aarch64/iso/Fedora-i3-Live-aarch64-Rawhide-20231204.n.0.iso
Image: Scientific vagrant-virtualbox x86_64
Path: 
Labs/x86_64/images/Fedora-Scientific-Vagrant-Rawhide-20231204.n.0.x86_64.vagrant-virtualbox.box
Image: Kinoite dvd-ostree ppc64le
Path: Kinoite/ppc64le/iso/Fedora-Kinoite-ostree-ppc64le-Rawhide-20231204.n.0.iso
Image: Workstation live-osbuild aarch64
Path: 
Workstation/aarch64/iso/Fedora-Workstation-Live-osb-Rawhide-20231204.n.0.aarch64.iso
Image: Scientific vagrant-libvirt x86_64
Path: 
Labs/x86_64/images/Fedora-Scientific-Vagrant-Rawhide-20231204.n.0.x86_64.vagrant-libvirt.box
Image: Workstation live-osbuild x86_64
Path: 
Workstation/x86_64/iso/Fedora-Workstation-Live-osb-Rawhide-20231204.n.0.x86_64.iso

= ADDED PACKAGES =
Package: JUnitParams-1.1.1-1.fc40
Summary: Parameterized Java tests
RPMs:JUnitParams
Size:75.12 KiB

Package: goldendict-ng-23.11.08-3.fc40
Summary: The Next Generation GoldenDict
RPMs:goldendict-ng
Size:5.98 MiB

Package: libheinz-2.0.0-1.fc40
Summary: C++ base library of Heinz Maier-Leibnitz Zentrum
RPMs:libheinz-devel
Size:73.43 KiB

Package: libmamba-1.5.3-2.fc40
Summary: C++ API for mamba depsolving library
RPMs:libmamba libmamba-devel micromamba python3-libmambapy
Size:8.99 MiB

Package: python-conda-index-0.3.0-1.fc40~bootstrap
Summary: Create repodata.json for collections of conda packages
RPMs:python3-conda-index
Size:106.55 KiB

Package: vecgeom-1.2.6-1.fc40
Summary: A vectorized geometry library for particle-detector simulation
RPMs:vecgeom vecgeom-devel
Size:7.74 MiB


= DROPPED PACKAGES =
Package: kf6-kirigami2-5.245.0-2.fc40
Summary: QtQuick plugins to build user interfaces based on the KDE UX guidelines
RPMs:kf6-kirigami2 kf6-kirigami2-devel
Size:4.89 MiB

Package: kf6-kirigami2-addons-1:0.11.76-4.fc40
Summary: Convergent visual components ("widgets") for Kirigami-based 
applications
RPMs:kf6-kirigami2-addons kf6-kirigami2-addons-dateandtime 
kf6-kirigami2-addons-treeview
Size:2.43 MiB

Package: rust-inventory-impl-0.1.11-6.fc39
Summary: Implementation of macros for the inventory crate
RPMs:rust-inventory-impl+default-devel rust-inventory-impl-devel
Size:22.75 KiB


= UPGRADED PACKAGES =
Package:  Coin4-4.0.2-1.fc40
Old package:  Coin4-4.0.0-13.fc39
Summary:  High-level 3D visualization library
RPMs: Coin4 Coin4-devel Coin4-doc
Size: 52.42 MiB
Size change:  7.78 KiB
Changelog:
  * Mon Nov 20 2023 Richard Shaw  - 4.0.1-1
  - Update to 4.0.1.

  * Mon Dec 04 2023 Richard Shaw  - 4.0.2-1
  - Update to 4.0.2.


Package:  OpenColorIO-2.2.1-6.fc40
Old package:  OpenColorIO-2.2.1-5.fc39
Summary:  Enables color transforms and image display across graphics apps
RPMs: OpenColorIO OpenColorIO-devel OpenColorIO-doc OpenColorIO-tools
Size: 11.63 MiB
Size change:  189.44 KiB
Changelog:
  * Mon Dec 04 2023 Lukas Javorsky  - 2.2.1-6
  - Rebuilt for minizip-ng transition Fedora change
  - Fedora Change: https://fedoraproject.org/wiki/Changes/MinizipNGTransition


Package:  R-arules-1.7.7-1.fc40
Old package:  R-arules-1.7.6-3.fc39
Summary:  Mining Association Rules and Frequent Itemsets
RPMs: R-arules
Size: 10.52 MiB
Size change:  1.75 MiB
Changelog:
  * Mon Dec 04 2023 Iztok Fister Jr.  - 1.7.7-1
  - Update to 1.7.7


Package:  R-fontawesome-0.5.1-3.fc40
Old package:  R-fontawesome-0.5.1-2.fc39
Summary:  Easily work with 'Font Awesome' Icons
RPMs: R-fontawesome
Size: 704.58 KiB
Size change:  531 B
Changelog:
  * Mon Dec 04 2023 Jerry James  - 0.5.1-3
  - Fix upgrade issue (bz 2252701)
  - Add missing inconsolata BR


Package:  R-qtl-1.66-1.fc40
Old packa

[Bug 2113577] perl-IO-Async: FTBFS in Fedora rawhide/f37: t/70future-io.t fails: Nothing was ready after 10 second wait; called at /builddir/build/BUILD/IO-Async-0.801/blib/lib/IO/Async/Test.pm line 2

2023-12-05 Thread bugzilla 
https://bugzilla.redhat.com/show_bug.cgi?id=2113577

Aoife Moloney  changed:

   What|Removed |Added

 Resolution|--- |EOL
 Status|NEW |CLOSED
Last Closed||2023-12-05 23:21:59



--- Comment #7 from Aoife Moloney  ---
Fedora Linux 37 entered end-of-life (EOL) status on None.

Fedora Linux 37 is no longer maintained, which means that it
will not receive any further security or bug fix updates. As a result we
are closing this bug.

If you can reproduce this bug against a currently maintained version of Fedora
Linux
please feel free to reopen this bug against that version. Note that the version
field may be hidden. Click the "Show advanced fields" button if you do not see
the version field.

If you are unable to reopen this bug, please file a new report against an
active release.

Thank you for reporting this bug and we are sorry it could not be fixed.


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202113577%23c7
--
___
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: Obsoleting zlib in Fedora Rawhide

2023-12-05 Thread Yaakov Selkowitz 
On Tue, 2023-12-05 at 16:34 -0300, Tulio Magno Quites Machado Filho
wrote:
> Yaakov Selkowitz  writes:
> 
> > Also, since this is essentially an SONAME change wrt zlib, the
> > initial
> > build and mini-mass-rebuild of all dependents should occur in a
> > side-
> > tag.  You're announcement doesn't mention this occurring.
> 
> There are no SONAME changes.

Perhaps technically not, but...

> With zlib we have:
> 
> $ rpm -qf /usr/lib64/libz.so.1
> zlib-1.2.13-5.fc40.x86_64
> $ readelf -a /usr/lib64/libz.so.1.2.13 | grep -i soname
>  0x000e (SONAME) Library soname: [libz.so.1]
> 
> With zlib-ng-compat we have:
> 
> $ rpm -qf /usr/lib64/libz.so.1
> zlib-ng-compat-2.1.3-7.fc40.x86_64
> $ readelf -a /usr/lib64/libz.so.1  | grep soname
>  0x000e (SONAME) Library soname: [libz.so.1]
> 
> No mass rebuilds are required. zlib-ng in compat mode aims to be API
> and
> ABI compatible with zlib.

Except that it's not 100% compatible, since all those packages aren't
building/working with zlib-ng-compat.  At a minimum, you should be able
to show that everything zlib-dependent successfully rebuilds with this,
and since you've already identified some that don't, IMO they should be
fixed *first*.

-- 
Yaakov Selkowitz
Principal Software Engineer - Emerging RHEL
Red Hat, Inc.
--
___
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: Unified Kernel Support Phase Two (System-Wide)

2023-12-05 Thread Neal Gompa 
On Tue, Dec 5, 2023 at 3:47 PM Aoife Moloney  wrote:
>
> 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 ==
> Improve support for unified kernels in Fedora.
>
> == Owner ==
> * Name: [[User:kraxel| Gerd Hoffmann]]
> * Email: kra...@redhat.com
>
> * Name: [[User:vittyvk| Vitaly Kuznetsov]]
> * Email: vkuzn...@redhat.com
>
>
> == Detailed Description ==
> See [[ Changes/Unified_Kernel_Support_Phase_1 ]] for overview and Phase 1 
> goals.
>
>  Phase 2 goals 
>
> * Add support for booting UKIs directly.
> ** Boot path is shim.efi -> UKI, without any boot loader (grub,
> sd-boot) involved.
> ** The UEFI boot configuration will get an entry for each kernel installed.
> ** Newly installed kernels are configured to be booted once (via BootNext).
> ** Successful boot of the system will make the kernel update permanent
> (update BootOrder).
> * Enable UKIs for aarch64.
> ** Should be just flipping the switch, dependencies such as kernel
> zboot support are merged.
> * Add a UEFI-only cloud image variant which uses UKIs.
> ** Also suitable for being used in confidential VMs.
> ** Cover both x86_64 and aarch64.
>

What is the point of using shim in this path? We're not having UKIs
signed by Microsoft, and unless the Linux kernel knows how to call
shim for certificates, I don't see how this is supposed to be useful
for the Microsoft->Fedora->OS boot chain.



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

[Bug 2074940] Remove usage of gethostbyname() and inet_addr() from perl-FCGI package

2023-12-05 Thread bugzilla 
https://bugzilla.redhat.com/show_bug.cgi?id=2074940

Aoife Moloney  changed:

   What|Removed |Added

 Resolution|--- |EOL
 Status|ASSIGNED|CLOSED
Last Closed||2023-12-05 21:06:09



--- Comment #4 from Aoife Moloney  ---
Fedora Linux 37 entered end-of-life (EOL) status on None.

Fedora Linux 37 is no longer maintained, which means that it
will not receive any further security or bug fix updates. As a result we
are closing this bug.

If you can reproduce this bug against a currently maintained version of Fedora
Linux
please feel free to reopen this bug against that version. Note that the version
field may be hidden. Click the "Show advanced fields" button if you do not see
the version field.

If you are unable to reopen this bug, please file a new report against an
active release.

Thank you for reporting this bug and we are sorry it could not be fixed.


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202074940%23c4
--
___
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: Unified Kernel Support Phase Two (System-Wide)

2023-12-05 Thread Chris Adams 
Once upon a time, Aoife Moloney  said:
> * UKIs need this to find the root filesystem without root=... on the
> kernel command line.

How does this work in system with more than one Linux install?  Or any
more-complicated disk setup (e.g. SW RAID)?  Does this also lock users
out from ALL kernel command-line options?
-- 
Chris Adams 
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

F40 Change Proposal: Unified Kernel Support Phase Two (System-Wide)

2023-12-05 Thread Aoife Moloney 
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 ==
Improve support for unified kernels in Fedora.

== Owner ==
* Name: [[User:kraxel| Gerd Hoffmann]]
* Email: kra...@redhat.com

* Name: [[User:vittyvk| Vitaly Kuznetsov]]
* Email: vkuzn...@redhat.com


== Detailed Description ==
See [[ Changes/Unified_Kernel_Support_Phase_1 ]] for overview and Phase 1 goals.

 Phase 2 goals 

* Add support for booting UKIs directly.
** Boot path is shim.efi -> UKI, without any boot loader (grub,
sd-boot) involved.
** The UEFI boot configuration will get an entry for each kernel installed.
** Newly installed kernels are configured to be booted once (via BootNext).
** Successful boot of the system will make the kernel update permanent
(update BootOrder).
* Enable UKIs for aarch64.
** Should be just flipping the switch, dependencies such as kernel
zboot support are merged.
* Add a UEFI-only cloud image variant which uses UKIs.
** Also suitable for being used in confidential VMs.
** Cover both x86_64 and aarch64.

 Related bugs 

* shim: remove dependency on grub2-efi-x64
([https://bugzilla.redhat.com/show_bug.cgi?id=2240989 buzilla
2240989])
* shim: handling of multiple lines in BOOT.CSV is inconsistent
([https://issues.redhat.com/browse/RHEL-10704 jira RHEL-10704],
[https://github.com/rhboot/shim/issues/554 github 554])
* anaconda: add support for
[https://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/
discoverable partitions]
([https://bugzilla.redhat.com/show_bug.cgi?id=2160074 bugzilla
2160074], [https://bugzilla.redhat.com/show_bug.cgi?id=2178043
bugzilla 2178043])
* dracut: do not create yet another initramfs for UKIs
([https://github.com/dracutdevs/dracut/pull/2521 github PR 2521])
* kernel: enable UKIs on aarch64
([https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2818 MR
2818])

== Feedback ==


== Benefit to Fedora ==
* Better secure boot support: the UKI initrd is covered by the signature.
* Better support for tpm measurements and confidential computing.
** measurements are more useful if we know what hashes to expect for the initrd.
** measurements are more useful without grub.efi in the boot path
(which measures each grub.cfg line processed).
* More robust boot process
** generating the initrd on the installed system is fragile

== Scope ==
* Proposal owners:
** updates for virt-firmware and uki-direct packages.
** enable UKIs on aarch64
([https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2818 MR
2818]).
** prepare kickstart ([https://pagure.io/fedora-kickstarts.git Fedora
kickstarts]) changes for generating UKI enabled images.

* Other developers:
** installer/anaconda: implement discoverable partition support.
** bootloader/shim: fix bugs.
** Fedora Cloud SIG: Add UKI enabled images as an option to
[https://fedoraproject.org/cloud/download Download Fedora Cloud]
** See also: 
[https://fedoraproject.org/wiki/Changes/Unified_Kernel_Support_Phase_2#Related_bugs
Related Bugs] section.

* Release engineering: [https://pagure.io/releng/issues #Releng issue number]

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

None, it's opt-in.  Also the uefi cloud image is an additional image
and will not replace the current bios/uefi hybrid image.


== How To Test ==


 Switch an existing install to use UKIs. 

Needs up-to-date Fedora 39 or Rawhide install in a virtual machine.
Bare metal hardware with standard storage (ahci / nvme) should work too.

Needs an big enough ESP to store UKI images there (minimum 200M,
recommended 500M).

1. dnf install virt-firmware uki-direct
* The uki-direct package contains the kernel-install plugin and
systemd unit needed to automatically manage kernel updates.
* You should have version 23.10 or newer.

2. sh 
/usr/share/doc/python3-virt-firmware/experimental/fixup-partitions-for-uki.sh
* Workaround for [https://bugzilla.redhat.com/show_bug.cgi?id=2160074
bug 2160074] (anaconda not setting up
[https://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/
discoverable partitions]).
* UKIs need this to find the root filesystem without root=... on the
kernel command line.

3. dnf install kernel-uki-virt

4. kernel-bootcfg --show
* optional step, shows UEFI boot configuration, the new UKI should be
added as BootNext

 $ kernel-bootcfg --show
 # C - BootCurrent, N - BootNext, O - BootOrder
 # 
 #   N-  0008  -  6.5.7-300.fc39.x86_64<= entry for
the the new kernel
 # C   O  -  0007  -  6.5.6-300.fc39.x86_64<= currently
running kernel
 # O  -  0006  -  Fedora   <= grub2 entry
 # O  -

Fedora Linux 37 is EOL

2023-12-05 Thread Tomas Hrcka 
Hello all,

Fedora Linux 37 has gone end of life for updates and support on 2023-12-05.
No more updates of any kind, including security updates or security
announcements, will be available for Fedora Linux 37 after the said
date. All the updates of Fedora Linux 37 being pushed to stable will be
stopped as well.

Fedora Linux 38 will continue to receive updates until approximately
one month after the release of Fedora Linux 40. The maintenance
schedule of Fedora Linux releases is documented on the Fedora Project
wiki [1]. The Fedora Project wiki also contains instructions[2] on how
to upgrade from a previous release of Fedora Linux to a version
receiving updates.

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


Regards,
Tomas Hrcka
Fedora Release Engineering

[1] -
https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#Maintenance_Schedule
[2] - https://fedoraproject.org/wiki/Upgrading?rd=DistributionUpgrades
[3] - https://pagure.io/releng

-- 
Tomas Hrcka
fas: humaton
libera.CHAT: jednorozec
--
___
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

F40 Change Proposal: Unified Kernel Support Phase Two (System-Wide)

2023-12-05 Thread Aoife Moloney 
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 ==
Improve support for unified kernels in Fedora.

== Owner ==
* Name: [[User:kraxel| Gerd Hoffmann]]
* Email: kra...@redhat.com

* Name: [[User:vittyvk| Vitaly Kuznetsov]]
* Email: vkuzn...@redhat.com


== Detailed Description ==
See [[ Changes/Unified_Kernel_Support_Phase_1 ]] for overview and Phase 1 goals.

 Phase 2 goals 

* Add support for booting UKIs directly.
** Boot path is shim.efi -> UKI, without any boot loader (grub,
sd-boot) involved.
** The UEFI boot configuration will get an entry for each kernel installed.
** Newly installed kernels are configured to be booted once (via BootNext).
** Successful boot of the system will make the kernel update permanent
(update BootOrder).
* Enable UKIs for aarch64.
** Should be just flipping the switch, dependencies such as kernel
zboot support are merged.
* Add a UEFI-only cloud image variant which uses UKIs.
** Also suitable for being used in confidential VMs.
** Cover both x86_64 and aarch64.

 Related bugs 

* shim: remove dependency on grub2-efi-x64
([https://bugzilla.redhat.com/show_bug.cgi?id=2240989 buzilla
2240989])
* shim: handling of multiple lines in BOOT.CSV is inconsistent
([https://issues.redhat.com/browse/RHEL-10704 jira RHEL-10704],
[https://github.com/rhboot/shim/issues/554 github 554])
* anaconda: add support for
[https://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/
discoverable partitions]
([https://bugzilla.redhat.com/show_bug.cgi?id=2160074 bugzilla
2160074], [https://bugzilla.redhat.com/show_bug.cgi?id=2178043
bugzilla 2178043])
* dracut: do not create yet another initramfs for UKIs
([https://github.com/dracutdevs/dracut/pull/2521 github PR 2521])
* kernel: enable UKIs on aarch64
([https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2818 MR
2818])

== Feedback ==


== Benefit to Fedora ==
* Better secure boot support: the UKI initrd is covered by the signature.
* Better support for tpm measurements and confidential computing.
** measurements are more useful if we know what hashes to expect for the initrd.
** measurements are more useful without grub.efi in the boot path
(which measures each grub.cfg line processed).
* More robust boot process
** generating the initrd on the installed system is fragile

== Scope ==
* Proposal owners:
** updates for virt-firmware and uki-direct packages.
** enable UKIs on aarch64
([https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2818 MR
2818]).
** prepare kickstart ([https://pagure.io/fedora-kickstarts.git Fedora
kickstarts]) changes for generating UKI enabled images.

* Other developers:
** installer/anaconda: implement discoverable partition support.
** bootloader/shim: fix bugs.
** Fedora Cloud SIG: Add UKI enabled images as an option to
[https://fedoraproject.org/cloud/download Download Fedora Cloud]
** See also: 
[https://fedoraproject.org/wiki/Changes/Unified_Kernel_Support_Phase_2#Related_bugs
Related Bugs] section.

* Release engineering: [https://pagure.io/releng/issues #Releng issue number]

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

None, it's opt-in.  Also the uefi cloud image is an additional image
and will not replace the current bios/uefi hybrid image.


== How To Test ==


 Switch an existing install to use UKIs. 

Needs up-to-date Fedora 39 or Rawhide install in a virtual machine.
Bare metal hardware with standard storage (ahci / nvme) should work too.

Needs an big enough ESP to store UKI images there (minimum 200M,
recommended 500M).

1. dnf install virt-firmware uki-direct
* The uki-direct package contains the kernel-install plugin and
systemd unit needed to automatically manage kernel updates.
* You should have version 23.10 or newer.

2. sh 
/usr/share/doc/python3-virt-firmware/experimental/fixup-partitions-for-uki.sh
* Workaround for [https://bugzilla.redhat.com/show_bug.cgi?id=2160074
bug 2160074] (anaconda not setting up
[https://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/
discoverable partitions]).
* UKIs need this to find the root filesystem without root=... on the
kernel command line.

3. dnf install kernel-uki-virt

4. kernel-bootcfg --show
* optional step, shows UEFI boot configuration, the new UKI should be
added as BootNext

 $ kernel-bootcfg --show
 # C - BootCurrent, N - BootNext, O - BootOrder
 # 
 #   N-  0008  -  6.5.7-300.fc39.x86_64<= entry for
the the new kernel
 # C   O  -  0007  -  6.5.6-300.fc39.x86_64<= currently
running kernel
 # O  -  0006  -  Fedora   <= grub2 entry
 # O  -

Fedora Linux 37 is EOL

2023-12-05 Thread Tomas Hrcka 
Hello all,

Fedora Linux 37 has gone end of life for updates and support on 2023-12-05.
No more updates of any kind, including security updates or security
announcements, will be available for Fedora Linux 37 after the said
date. All the updates of Fedora Linux 37 being pushed to stable will be
stopped as well.

Fedora Linux 38 will continue to receive updates until approximately
one month after the release of Fedora Linux 40. The maintenance
schedule of Fedora Linux releases is documented on the Fedora Project
wiki [1]. The Fedora Project wiki also contains instructions[2] on how
to upgrade from a previous release of Fedora Linux to a version
receiving updates.

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


Regards,
Tomas Hrcka
Fedora Release Engineering

[1] -
https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#Maintenance_Schedule
[2] - https://fedoraproject.org/wiki/Upgrading?rd=DistributionUpgrades
[3] - https://pagure.io/releng

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

Re: Obsoleting zlib in Fedora Rawhide

2023-12-05 Thread Tulio Magno Quites Machado Filho 
Yaakov Selkowitz  writes:

> Also, since this is essentially an SONAME change wrt zlib, the initial
> build and mini-mass-rebuild of all dependents should occur in a side-
> tag.  You're announcement doesn't mention this occurring.

There are no SONAME changes.

With zlib we have:

$ rpm -qf /usr/lib64/libz.so.1
zlib-1.2.13-5.fc40.x86_64
$ readelf -a /usr/lib64/libz.so.1.2.13 | grep -i soname
 0x000e (SONAME) Library soname: [libz.so.1]

With zlib-ng-compat we have:

$ rpm -qf /usr/lib64/libz.so.1
zlib-ng-compat-2.1.3-7.fc40.x86_64
$ readelf -a /usr/lib64/libz.so.1  | grep soname
 0x000e (SONAME) Library soname: [libz.so.1]

No mass rebuilds are required. zlib-ng in compat mode aims to be API and
ABI compatible with zlib.

-- 
Tulio Magno
--
___
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: Obsoleting zlib in Fedora Rawhide

2023-12-05 Thread Miro Hrončok 

On 05. 12. 23 19:21, Tulio Magno Quites Machado Filho wrote:

Miro Hrončok  writes:


Do you happen to have a build.log available for this?


I re-run the tests for all architectures here:
https://copr.fedorainfracloud.org/coprs/tuliom/zlib-ng-compat-mpb/build/6726758/

Keep in mind that zlib-ng defines the following:
#define ZLIB_VERSION "1.3.0.zlib-ng"

Source upstream: https://github.com/zlib-ng/zlib-ng/blob/develop/zlib.h.in#L61


Oh, thanks!

Here is my upstream PR to fix this:

https://github.com/python/cpython/pull/112771


It's only python3.12 that fails and not the others?


I tested previous versions too, but I didn't analyse their results.
I can re-run them if you believe this is important.
Likewise for python3.13, which was not available when I started this test.


No need. They will all fail as well.

--
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: Obsoleting zlib in Fedora Rawhide

2023-12-05 Thread Stephen Gallagher 
On Tue, Dec 5, 2023 at 1:28 PM Yaakov Selkowitz  wrote:
>
> On Mon, 2023-12-04 at 16:10 -0300, Tulio Magno Quites Machado Filho
> wrote:
> > Following the recent approval from Fesco, I'm planning to distribute
> > zlib-ng-compat packages for Rawhide later this week.
> > I hope this will give us enough time to work on the issues before
> > Fedora 40 is released. 爛
> >
> > So, keep in mind this will *obsolete zlib in Rawhide*.
> >
> > This update is also known to trigger test failures in the following
> > packages:
> >
> >  - binutils
> >  - cpp-httplib
> >  - git
> >  - jose
> >  - libpng
> >  - openexr1
> >  - openms
> >  - python-3.12
> >  - qpdf
> >
> > In general, the failing tests expect that libz will always have the
> > same
> > behavior, e.g.
> >  - same output length
> >  - identical output
> >  - same version string format
> >
> > This will require changes in order to guarantee the tests do succeed.
> >
> > If you have any questions or need help with these issues, let me
> > know.
>
> I would expect these build/test issues to be fixed *BEFORE* the
> obsoletion takes place, through COPR test builds and PRs etc.  Please
> tell me that FESCo didn't give permissions to break such key packages?
>
> Also, since this is essentially an SONAME change wrt zlib, the initial
> build and mini-mass-rebuild of all dependents should occur in a side-
> tag.  You're announcement doesn't mention this occurring.
>

*Puts on FESCo Hat*
Yaakov is exactly right here; this all MUST be worked out in a side
tag before it lands in Rawhide.
--
___
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: Obsoleting zlib in Fedora Rawhide

2023-12-05 Thread Yaakov Selkowitz 
On Mon, 2023-12-04 at 16:10 -0300, Tulio Magno Quites Machado Filho
wrote:
> Following the recent approval from Fesco, I'm planning to distribute
> zlib-ng-compat packages for Rawhide later this week. 
> I hope this will give us enough time to work on the issues before
> Fedora 40 is released. 爛
> 
> So, keep in mind this will *obsolete zlib in Rawhide*.
> 
> This update is also known to trigger test failures in the following
> packages:
> 
>  - binutils
>  - cpp-httplib
>  - git
>  - jose
>  - libpng
>  - openexr1
>  - openms
>  - python-3.12
>  - qpdf
> 
> In general, the failing tests expect that libz will always have the
> same
> behavior, e.g.
>  - same output length
>  - identical output
>  - same version string format
> 
> This will require changes in order to guarantee the tests do succeed.
> 
> If you have any questions or need help with these issues, let me
> know.

I would expect these build/test issues to be fixed *BEFORE* the
obsoletion takes place, through COPR test builds and PRs etc.  Please
tell me that FESCo didn't give permissions to break such key packages?

Also, since this is essentially an SONAME change wrt zlib, the initial
build and mini-mass-rebuild of all dependents should occur in a side-
tag.  You're announcement doesn't mention this occurring.

-- 
Yaakov Selkowitz
Principal Software Engineer - Emerging RHEL
Red Hat, Inc.
--
___
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: Obsoleting zlib in Fedora Rawhide

2023-12-05 Thread Tulio Magno Quites Machado Filho 
Miro Hrončok  writes:

> Do you happen to have a build.log available for this?

I re-run the tests for all architectures here:
https://copr.fedorainfracloud.org/coprs/tuliom/zlib-ng-compat-mpb/build/6726758/

Keep in mind that zlib-ng defines the following:
#define ZLIB_VERSION "1.3.0.zlib-ng"

Source upstream: https://github.com/zlib-ng/zlib-ng/blob/develop/zlib.h.in#L61

> It's only python3.12 that fails and not the others?

I tested previous versions too, but I didn't analyse their results.
I can re-run them if you believe this is important.
Likewise for python3.13, which was not available when I started this test.

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

Packit online workshop

2023-12-05 Thread Maja Massarini 
We, the packit team, are happy to invite you to our upcoming workshop about 
pulling upstream releases to Fedora using Packit.

When: Wed, Jan 10, 9:30 AM - Wed, Jan 10, 12:30 PM (GMT+1)

Where: Online!

Who should attend: Anyone who maintains a package in Fedora or EPEL and would 
like to automate syncing the upstream releases for it. The automation is most 
suitable for simple packages with straightforward update processes (e.g. 
without patches, or need to build in side-tags). It works without access to the 
upstream repository.

No package? It’s not an issue. The workshop can help you understand the Fedora 
release process and the services involved. During the workshop, you can help 
someone else automate their package or ask someone around if you can help with 
the maintenance (that’s usually very welcome!). You can also bring an orphaned 
package back to life!

Can’t make it this time? You can also follow our documentation and ask for help 
in case of any issue: #packit:fedora.im (Matrix) / #team-packit (Slack).

If you want to join us please fill this form: 
https://forms.gle/WnEN3KXnhRS2cf1E7, we will send you further details. 

Looking forward to seeing 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

[Bug 2253024] New: perl-Sub-Override-0.10 is available

2023-12-05 Thread bugzilla 
https://bugzilla.redhat.com/show_bug.cgi?id=2253024

Bug ID: 2253024
   Summary: perl-Sub-Override-0.10 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Sub-Override
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr, iarn...@gmail.com,
jples...@redhat.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Releases retrieved: 0.10
Upstream release that is considered latest: 0.10
Current version/release in rawhide: 0.09-31.fc39
URL: http://search.cpan.org/dist/Sub-Override/

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


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


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


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


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


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202253024%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

[EPEL-devel] [Fedocal] Reminder meeting : EPEL Steering Committee

2023-12-05 Thread tdawson 
Dear all,

You are kindly invited to the meeting:
   EPEL Steering Committee on 2023-12-06 from 16:00:00 to 17:00:00 US/Eastern
   At fedora-meet...@chat.fedoraproject.org

The meeting will be about:
https://chat.fedoraproject.org/#/room/#meeting:fedoraproject.org

This is the weekly EPEL Steering Committee Meeting.

A general agenda is the following:

#topic aloha

#topic EPEL Issues https://pagure.io/epel/issues
* https://pagure.io/epel/issues?tags=meeting=Open

#topic Old Business (if needed)

#topic General Issues / Open Floor




Source: https://calendar.fedoraproject.org//meeting/9854/

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

[Bug 2252469] perl-Locale-Codes-3.77 is available

2023-12-05 Thread bugzilla 
https://bugzilla.redhat.com/show_bug.cgi?id=2252469

Michal Josef Spacek  changed:

   What|Removed |Added

   Fixed In Version||perl-Locale-Codes-3.77-1.fc
   ||40
 Resolution|--- |RAWHIDE
 Status|ASSIGNED|CLOSED
Last Closed||2023-12-05 15:33:03




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2252469
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[rpms/perl-Locale-Codes] PR #29: 3.77 bump

2023-12-05 Thread Michal Josef Špaček 

mspacek merged a pull-request against the project: `perl-Locale-Codes` that you 
are following.

Merged pull-request:

``
3.77 bump
``

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

[rpms/perl-Locale-Codes] PR #29: 3.77 bump

2023-12-05 Thread Michal Josef Špaček 

mspacek opened a new pull-request against the project: `perl-Locale-Codes` that 
you are following:
``
3.77 bump
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Locale-Codes/pull-request/29
--
___
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 2252469] perl-Locale-Codes-3.77 is available

2023-12-05 Thread bugzilla 
https://bugzilla.redhat.com/show_bug.cgi?id=2252469

Michal Josef Spacek  changed:

   What|Removed |Added

   Doc Type|--- |If docs needed, set a value
 Status|NEW |ASSIGNED



--- Comment #1 from Michal Josef Spacek  ---
Changes:

3.77  expected 2023-12-01  sbeck
  -  NEW CODE(s)
  -  Changed RELEASE_TESTING variable
 Now use a release-specific testing variable rather than
 RELEASE_TESTING. See GitHub #17 for details.

Only for rawhide.


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202252469%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 2252999] New: F38FailsToInstall: perl-PAR-Packer

2023-12-05 Thread bugzilla 
https://bugzilla.redhat.com/show_bug.cgi?id=2252999

Bug ID: 2252999
   Summary: F38FailsToInstall: perl-PAR-Packer
   Product: Fedora
   Version: 38
Status: NEW
 Component: perl-PAR-Packer
  Assignee: jples...@redhat.com
  Reporter: fti-b...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: anon.am...@gmail.com, jples...@redhat.com,
mmasl...@redhat.com,
perl-devel@lists.fedoraproject.org
Blocks: 2117177 (F38FailsToInstall)
  Target Milestone: ---
Classification: Fedora



Hello,

Please note that this comment was generated automatically by
https://pagure.io/releng/blob/main/f/scripts/ftbfs-fti/follow-policy.py
If you feel that this output has mistakes, please open an issue at
https://pagure.io/releng/

Your package (perl-PAR-Packer) Fails To Install in Fedora 38:

can't install perl-PAR-Packer:
  - nothing provides perl(:VERSION) = 5.36.1 needed by
perl-PAR-Packer-1.057-3.fc38.x86_64

If you know about this problem and are planning on fixing it, please
acknowledge so by setting the bug status to ASSIGNED. If you don't have time to
maintain this package, consider orphaning it, so maintainers of dependent
packages realize the problem.


If you don't react accordingly to the policy for FTBFS/FTI bugs
(https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/),
your package may be orphaned in 8+ weeks.


P.S. The data was generated solely from koji buildroot, so it might be newer
than the latest compose or the content on mirrors. To reproduce, use the
koji/local repo only, e.g. in mock:

$ mock -r fedora-38-x86_64 --config-opts mirrored=False install
perl-PAR-Packer


P.P.S. If this bug has been reported in the middle of upgrading multiple
dependent packages, please consider using side tags:
https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#updating-inter-dependent-packages

Thanks!



Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=2117177
[Bug 2117177] Fedora 38 Fails To install Tracker
-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2252999

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202252999%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 2252996] New: F39FailsToInstall: perl-PAR-Packer

2023-12-05 Thread bugzilla 
https://bugzilla.redhat.com/show_bug.cgi?id=2252996

Bug ID: 2252996
   Summary: F39FailsToInstall: perl-PAR-Packer
   Product: Fedora
   Version: 39
Status: NEW
 Component: perl-PAR-Packer
  Assignee: jples...@redhat.com
  Reporter: fti-b...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: anon.am...@gmail.com, jples...@redhat.com,
mmasl...@redhat.com,
perl-devel@lists.fedoraproject.org
Blocks: 2168845 (F39FailsToInstall)
  Target Milestone: ---
Classification: Fedora



Hello,

Please note that this comment was generated automatically by
https://pagure.io/releng/blob/main/f/scripts/ftbfs-fti/follow-policy.py
If you feel that this output has mistakes, please open an issue at
https://pagure.io/releng/

Your package (perl-PAR-Packer) Fails To Install in Fedora 39:

can't install perl-PAR-Packer:
  - nothing provides perl(:VERSION) = 5.38.0 needed by
perl-PAR-Packer-1.059-1.fc39.x86_64

If you know about this problem and are planning on fixing it, please
acknowledge so by setting the bug status to ASSIGNED. If you don't have time to
maintain this package, consider orphaning it, so maintainers of dependent
packages realize the problem.


If you don't react accordingly to the policy for FTBFS/FTI bugs
(https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/),
your package may be orphaned in 8+ weeks.


P.S. The data was generated solely from koji buildroot, so it might be newer
than the latest compose or the content on mirrors. To reproduce, use the
koji/local repo only, e.g. in mock:

$ mock -r fedora-39-x86_64 --config-opts mirrored=False install
perl-PAR-Packer


P.P.S. If this bug has been reported in the middle of upgrading multiple
dependent packages, please consider using side tags:
https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#updating-inter-dependent-packages

Thanks!



Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=2168845
[Bug 2168845] Fedora 39 Fails To install Tracker
-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2252996

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202252996%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: Adding/creating wasi-libc++ into the wasi-libc package

2023-12-05 Thread Jan Staněk 
Hello!

Tom Stellard  writes:
> Would it be possible to re-use the existing libcxx package and
> just build it twice, once for the host and once for wasm?  Kind
> of like what some packages do for mingw?

Maybe; I assume nor me nor Jan have any previous experience with
building libcxx, so we are not really qualified to answer.

The upstream wasi-sdk project (which my wasi-libc is one part of)
generally relies on llvm toolchain for everything. The SDK itself is
basically a llvm/clang/clang++ built to emit WASM with associated
standard libraries thrown in.

Now it might be possible to just build the GNU libcxx for wasm32-wasi
target (presumably using wasi-libc as the libc implementation)
and that would be usable; on the other hand, it might not, and the llvm
libcxx would be needed.

Tom, would you be able to provide a test build of libcxx for
wasm32-wasi, so the other Jan can see if that would work for him?
Then we can decide what approach to take next.
--
Jan Staněk
Software Engineer, Red Hat
jsta...@redhat.com   irc: jstanek


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: Update on the Modern C initiative

2023-12-05 Thread Daniel P . Berrangé 
On Sat, Dec 02, 2023 at 05:42:11PM +0100, Florian Weimer wrote:
> * Vít Ondruch:
> 
> > Dne 01. 12. 23 v 11:40 Milan Crha napsal(a):
> >> On Thu, 2023-11-30 at 18:09 +0100, Florian Weimer wrote:
> >>> Again, some of these are false positives.
> >>Hi,
> >> I think the errors from the configure time of the script are not always
> >> problems, are they?
> >
> >
> > This probably falls into the configuration bucket:
> >
> > https://gitlab.com/fweimer-rh/fedora-modernc-logs/-/blob/main/logs/r/rubygem-ruby-libvirt.log?ref_type=heads
> >
> > But I don't even know where GCC digs up the issues.
> 
> It looks like the GCC output lands in this file:
> 
> ruby-libvirt-0.7.1/usr/lib64/gems/ruby/ruby-libvirt-0.7.1/mkmf.log
> 
> I have not seen that one before, so the log dumper in the buildroot
> instrumentation does not cover it, sorry.
> 
> The failures look like this:
> 
> “
> LD_LIBRARY_PATH=.:/usr/lib64 "gcc -I/usr/include -I/usr/include/ruby/backward 
> -I/usr/include -I. -O2 -flto=auto -ffat-lto-objects -fexceptions -g 
> -grecord-gcc-switches -pipe -Wall -Werror=format-security 
> -Werror=implicit-function-declaration -Werror=implicit-int 
> -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  -fPIC  -m64  -c 
> conftest.c"
> conftest.c:8:16: error: initialization of ‘int’ from ‘char *’ makes integer 
> from pointer without a cast
> 8 | static int t = VIR_NODE_MEMORY_SHARED_MERGE_ACROSS_NODES;
>   |^
> In file included from /usr/include/libvirt/libvirt.h:35,
>  from conftest.c:5:
> conftest.c:8:16: error: initializer element is not computable at load time
> 8 | static int t = VIR_NODE_MEMORY_SHARED_MERGE_ACROSS_NODES;
>   |^
> conftest.c:8:12: warning: ‘t’ defined but not used [-Wunused-variable]
> 8 | static int t = VIR_NODE_MEMORY_SHARED_MERGE_ACROSS_NODES;
>   |^
> checked program was:
> /* begin */
> 1: #include "ruby.h"
> 2: 
> 3: #include "ruby.h"
> 4: 
> 5: #include 
> 6: 
> 7: /*top*/
> 8: static int t = VIR_NODE_MEMORY_SHARED_MERGE_ACROSS_NODES;
> /* end */
> ”
> 
> Looking at the Ruby MakeMakefile documention:
> 
> 
> 
> I think you need to supply a type for these constants and call
> have_const like this:
> 
>   have_const(["VIR_NODE_MEMORY_SHARED_MERGE_ACROSS_NODES",
>   "const char *"], ["libvirt/virterror.h"])
> 
> Does this help?  I'm not a Ruby programmer, so I'm not even sure if I
> got the list syntax right …

Thanks, it turns out these checks are really terribly obsolete. Checking
for existence of features that have been around for 10 years, so I'm
proposing to kill them all upstream and we'll get this into rawhide
after that.

  https://gitlab.com/libvirt/libvirt-ruby/-/merge_requests/28

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

Re: Update on the Modern C initiative

2023-12-05 Thread Florian Weimer 
* Jakub Jelinek:

> On Tue, Dec 05, 2023 at 04:38:55AM +0100, Kevin Kofler via devel wrote:
>> Florian Weimer wrote:
>> > The final patches for GCC 14 are currently under upstream review and
>> > should land very soon.  Earlier, I had received feedback that the larger
>> > community desires just one transition, so we end up with the following
>> > warnings which turn into errors by default:
>> > 
>> >   -Wimplicit-function-declaration
>> >   -Wimplicit-int
>> >   -Wint-conversion
>> >   -Wreturn-mismatch (new, previously part of -Wreturn-types)
>> >   -Wdeclaration-missing-parameter-type (new, previously unnamed)
>> >   -Wincompatible-pointer-types
>> > 
>> > Only the first two were covered in the initial Fedora conversion work.
>> 
>> As much as I understand the point of -Werror=implicit-function-declaration 
>> (since implicit function declarations can cause several subtle bugs), and 
>> implicit int is obscure enough for its removal to not be a big problem (even 
>> though its potential for causing bugs is much lower), as much I have to 
>> wonder about the others. Especially the incompatible pointer types sound 
>> more like nitpicking than actual bugs (though I guess strict aliasing can 
>> cause issues with those, but then I would expect to see -Wstrict-aliasing 
>> warnings).
>
> Look at the gimp case, where a function prototype was expecting double *
> argument but caller was calling it with address of float.
> void foo (double *);
> void
> bar ()
> {
>   float f = 5.0f;
>   foo ();
> }

> While this resulted in a warning even without -Wall, clearly nobody noticed
> until this was made an error:

And this results in an out-of-bounds write and potential memory
corruption.

That's actually not uncommon for such bugs.  Here's a similar issue for
python-tables:

  


Although the critical type size mismatch happens on 32-bit architectures
and Windows only.  Problems like these are the reason why I don't think
the Clang approach of restricting to incompatible-function-pointer-types
only makes much sense.

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: Obsoleting zlib in Fedora Rawhide

2023-12-05 Thread Miro Hrončok 

On 04. 12. 23 20:10, Tulio Magno Quites Machado Filho wrote:

Following the recent approval from Fesco, I'm planning to distribute
zlib-ng-compat packages for Rawhide later this week.
I hope this will give us enough time to work on the issues before
Fedora 40 is released. 爛

So, keep in mind this will *obsolete zlib in Rawhide*.

This update is also known to trigger test failures in the following
packages:

  - python-3.12


Hello.

Do you happen to have a build.log available for this?

It's only python3.12 that fails and not the others?



In general, the failing tests expect that libz will always have the same
behavior, e.g.
  - same output length
  - identical output
  - same version string format

This will require changes in order to guarantee the tests do succeed.

If you have any questions or need help with these issues, let me know.



--
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: Proven to be sickened

2023-12-05 Thread Michael J Gruber 
Richard W.M. Jones venit, vidit, dixit 2023-12-05 12:03:36:
> On Tue, Dec 05, 2023 at 10:35:35AM +, Daniel P. Berrangé wrote:
> > On Tue, Dec 05, 2023 at 11:18:57AM +0100, Vít Ondruch wrote:
> > 
> > [snip]
> > 
> > > Granted, these are dissimilar to initial Michaels's issue. But how can I 
> > > be
> > > sure that if I touch some of the packages, I won't be told that they were 
> > > in
> > > such state for purpose?
> > 
> > IMHO all changes should be opened as merge requests in pagure. This gives
> > the regular package maintainers a window of opportunity to review the
> > change before it is merged. If there's no response from the package
> > maintainer after a couple of weeks then a proven packager can go ahead
> > and approve the merge request.
> > 
> > Essentially proven packagers can follow the same workflow as anyone else
> > does for contributing to a package that they are not a (co)maintainer of.
> > They just need the extra priv of being able to approve their own MR at
> > their discretion. Pushing directly to git, bypassing merge requests,
> > should not be required in order to achieve what provenpackagers exist
> > to do.

Yes. My main point was communication, i.e. the "how", not the "what" of
those changes. The "what" may influence the "how", of course. An urgent
security fix does not leave time for upfront communication. But there
should always be time for communication afterwards.

> This workflow doesn't really work for mass rebuilds / mass maintenance
> of OCaml packages (I guess it's similar for other language packages).
> We want to be able to rebuild or fix all packages that contain OCaml
> code, and we have a bunch of scripts to do that including the push and
> build in a side tag.

That makes it even more important to communicate: you don't want a
packager to build into rawhide while your side tag is cooking.

Note that "communicate" can be as simple as a commit message "bump for
xy mass rebuild" or "fix FTBFS for xy rebuild", maybe together with a
link to the announcement. If there was an announcement ...
That is something you can do automatically. You only have to take the time
*once* to template a proper dist-git commit message.

> > At the same time I think it is good to remember that Fedora package
> > maintainers should think of themselves as guardians, not owners, and
> > thus should expect to receive contributions from others, including
> > provenpackagers, doing cleanups to follow Fedora guidelines better.
> 
> Yes indeed.

Yes, it goes both ways, and requires communication. That's all.

And, just to clarify: I probably wouldn't have reacted the way I did if
I hadn't experienced something like that over and over again. And that
included quelling test suites completely and other niceties (from
various pp's).

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

Re: Proven to be sickened

2023-12-05 Thread Richard W.M. Jones 
On Tue, Dec 05, 2023 at 10:35:35AM +, Daniel P. Berrangé wrote:
> On Tue, Dec 05, 2023 at 11:18:57AM +0100, Vít Ondruch wrote:
> 
> [snip]
> 
> > Granted, these are dissimilar to initial Michaels's issue. But how can I be
> > sure that if I touch some of the packages, I won't be told that they were in
> > such state for purpose?
> 
> IMHO all changes should be opened as merge requests in pagure. This gives
> the regular package maintainers a window of opportunity to review the
> change before it is merged. If there's no response from the package
> maintainer after a couple of weeks then a proven packager can go ahead
> and approve the merge request.
> 
> Essentially proven packagers can follow the same workflow as anyone else
> does for contributing to a package that they are not a (co)maintainer of.
> They just need the extra priv of being able to approve their own MR at
> their discretion. Pushing directly to git, bypassing merge requests,
> should not be required in order to achieve what provenpackagers exist
> to do.

This workflow doesn't really work for mass rebuilds / mass maintenance
of OCaml packages (I guess it's similar for other language packages).
We want to be able to rebuild or fix all packages that contain OCaml
code, and we have a bunch of scripts to do that including the push and
build in a side tag.

> At the same time I think it is good to remember that Fedora package
> maintainers should think of themselves as guardians, not owners, and
> thus should expect to receive contributions from others, including
> provenpackagers, doing cleanups to follow Fedora guidelines better.

Yes indeed.

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: Proven to be sickened

2023-12-05 Thread Daniel P . Berrangé 
On Tue, Dec 05, 2023 at 11:18:57AM +0100, Vít Ondruch wrote:

[snip]

> Granted, these are dissimilar to initial Michaels's issue. But how can I be
> sure that if I touch some of the packages, I won't be told that they were in
> such state for purpose?

IMHO all changes should be opened as merge requests in pagure. This gives
the regular package maintainers a window of opportunity to review the
change before it is merged. If there's no response from the package
maintainer after a couple of weeks then a proven packager can go ahead
and approve the merge request.

Essentially proven packagers can follow the same workflow as anyone else
does for contributing to a package that they are not a (co)maintainer of.
They just need the extra priv of being able to approve their own MR at
their discretion. Pushing directly to git, bypassing merge requests,
should not be required in order to achieve what provenpackagers exist
to do.

At the same time I think it is good to remember that Fedora package
maintainers should think of themselves as guardians, not owners, and
thus should expect to receive contributions from others, including
provenpackagers, doing cleanups to follow Fedora guidelines better.

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

Re: Proven to be sickened

2023-12-05 Thread Vít Ondruch 


Dne 05. 12. 23 v 5:56 Jason Tibbitts napsal(a):

Kevin Kofler via devel  writes:

My pet peeve is provenpackagers or comaintainers who add unwanted
automagic (autorelease, autosetup, autochangelog) to my packages.

That really shouldn't be happening for anything which wasn't officially
made mandatory or forbidden or whatnot.  Sure, I went through and
removed Group: tags long ago, and the same was done for ldconfig
scriptlets and such, but that was only after the whole thing had gone
through the change process.  I can't imagine it would be appropriate for
a provenpackager (who isn't also explicitly listed as a maintainer for a
specific package) to just make a fundamental change to package
maintenance like that with no discussion.  I would think that if it did
happen, it would definitely warrant an apology.


I just want to say that during my proven packager years, I certainly did 
substantial changes to other's packages, but I was pretty sure that the 
package was not maintained by anybody except proven packagers. I still 
find surprising, that we can have packages like that.


E.g. looking at 
https://src.fedoraproject.org/rpms/rubygem-json/commits/rawhide


How comes the package was not orphaned by some automated process yet, to 
find a rightful maintainer?



Can we also make a rule that if package reaches e.g. release 10 with 
only mass rebuild commits, it will be orphaned? I have a few examples at 
hand:


https://src.fedoraproject.org/rpms/rubygem-ansi/commits/rawhide

https://src.fedoraproject.org/rpms/rubygem-daemons/tree/rawhide

https://src.fedoraproject.org/rpms/rubygem-elasticsearch-transport/commits/rawhide

I am not going to continue, but from these 3, the rubygem-daemons looks 
reasonable (but without enabled test, so nobody can tell if the package 
works) to today standards, because it was touched by proven packager 
years ago.


How I know about these cases? Because from time to time I look at the 
packages which are not migrated to SPDX yet. Will these be migrated? I 
don't think so. Should proven packagers do that?



There are also cases such as 
https://koschei.fedoraproject.org/package/rubygem-async_sinatra which is 
FTBFS for a while already. Should I fix the package as a proven packager 
knowing it is broken (also knowing the reasons for the breakage and the 
fix should not be hard), or should I leave it, because it does not seems 
to be maintained, while I don't think the maintainer is completely inactive.



Granted, these are dissimilar to initial Michaels's issue. But how can I 
be sure that if I touch some of the packages, I won't be told that they 
were in such state for purpose?



Sorry for bit of OT.



Vít





But, fixing bugs and FTBFS issues?  That's absolutely part of what we
would expect provenpackagers to be doing.

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


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