date:20231023

Re: Optional %changelog (was: F38 proposal: Rpmautospec by Default (System-Wide Change proposal))

2023-10-23 Thread Neal Gompa

On Mon, Oct 23, 2023 at 11:05 PM Maxwell G  wrote:
>
> I'll bite :). I changed the subject accordingly.
>
> On Tue Oct 24, 2023 at 00:31 +0200, Pavel Raiskup wrote:
>
> > Packaging become an automatized task, and maintainers don't pay
> > attention to %changelog beauty so they simply generate it from git-log
> > (but I'd claim that git-log != %changelog).
>
> I tend to agree. A package's git log and %changelog have different
> purposes and cater to different audiences. The former focusses on
> developers. Each commit should each contain a single logical change to
> the code in distgit (specfile/patches/sources) with body text to justify
> the change as appropriate. The %changelog is a user-visible summary that
> should only mention user-visible changes and not have extra information
> related to the development itself. For simpler packages, combining these
> two logs via rpmautospec (with the ability to [skip changelog] commits)
> can work well, but in other cases, including every single commit message
> can create a %changelog full of garbage or otherwise confuse packagers.
>
> > %changelog become one of the most painful maintainers' headache :)
> >
> > What do you think about a static changelog like:
> >
> > %changelog
> > * See https://src.fedoraproject.org/rpms//commits/rawhide
> >
> > Aren't we ready to admit (something like) this is enough?
>
> The %changelog is supposed to follow a specific format, as per the
> guidelines, and the datestamps are used to set $SOURCE_DATE_EPOCH.
> Replacing the entire changelog with this type of text would break that,
> and I think having a (potentially flawed) %changelog generated from the
> git log is better than none at all.
>

I'm also generally opposed to dropping the changelog since it is the
main method of providing attribution to all contributors past and
present to a package when it is redistributed, especially over the
mirror networks, ISOs, etc.

Remember that our version control system *does not matter* because
it's not how sources are *actually* delivered. That's the SRPMs that
are built and shipped alongside the binary packages.




--
真実はいつも一つ！/ 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 2245662] perl-Inline-Python fails to build with Python 3.13: error: implicit declaration of function `Py_SetProgramName`

2023-10-23 Thread bugzilla

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

Mattias Ellert  changed:

   What|Removed |Added

 Resolution|--- |RAWHIDE
 Status|NEW |CLOSED
   Fixed In Version||perl-Inline-Python-0.57-7.f
   ||c40
Last Closed||2023-10-24 04:37:17




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2245662
___
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: Optional %changelog (was: F38 proposal: Rpmautospec by Default (System-Wide Change proposal))

2023-10-23 Thread Maxwell G

I'll bite :). I changed the subject accordingly.

On Tue Oct 24, 2023 at 00:31 +0200, Pavel Raiskup wrote:

> Packaging become an automatized task, and maintainers don't pay
> attention to %changelog beauty so they simply generate it from git-log
> (but I'd claim that git-log != %changelog).

I tend to agree. A package's git log and %changelog have different
purposes and cater to different audiences. The former focusses on
developers. Each commit should each contain a single logical change to
the code in distgit (specfile/patches/sources) with body text to justify
the change as appropriate. The %changelog is a user-visible summary that
should only mention user-visible changes and not have extra information
related to the development itself. For simpler packages, combining these
two logs via rpmautospec (with the ability to [skip changelog] commits)
can work well, but in other cases, including every single commit message
can create a %changelog full of garbage or otherwise confuse packagers.

> %changelog become one of the most painful maintainers' headache :)
>
> What do you think about a static changelog like:
>
> %changelog
> * See https://src.fedoraproject.org/rpms//commits/rawhide
>
> Aren't we ready to admit (something like) this is enough?

The %changelog is supposed to follow a specific format, as per the
guidelines, and the datestamps are used to set $SOURCE_DATE_EPOCH.
Replacing the entire changelog with this type of text would break that,
and I think having a (potentially flawed) %changelog generated from the
git log is better than none at all.

-- 
Best,

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

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

2023-10-23 Thread updates

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

dhcpdump-1.9-1.el7
python-ncclient-0.4.2-16.el7
python3-ncclient-0.6.15-1.el7

Details about builds:



 dhcpdump-1.9-1.el7 (FEDORA-EPEL-2023-e13fad4fed)
 Parse DHCP packets

Update Information:

Change upstream to a maintained fork

ChangeLog:

* Tue Oct 10 2023 Boian Bonev  - 1.9-1
- Change upstream to a maintained fork
* Wed Jul 19 2023 Fedora Release Engineering  - 1.8-6
- Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild
* Thu Feb 23 2023 Boian Bonev  - 1.8-5
- Import multiple fixes from Debian
* Thu Jan 19 2023 Fedora Release Engineering  - 1.8-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_38_Mass_Rebuild
* Sun Dec 11 2022 Florian Weimer  - 1.8-3
- Port to C99 (#2152420)
* Thu Jul 21 2022 Fedora Release Engineering  - 1.8-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild
* Wed Jul 13 2022 Jonathan Wright  - 1.8-1
- Initial version of the package




 python-ncclient-0.4.2-16.el7 (FEDORA-EPEL-2023-664082394d)
 Python library for the NETCONF protocol

Update Information:

General packaging improvements. Update License to SPDX. Drop HTML documentation.

ChangeLog:





 python3-ncclient-0.6.15-1.el7 (FEDORA-EPEL-2023-67eceff730)
 Python library for the NETCONF protocol

Update Information:

Update License to SPDX; update to 0.6.15:
https://github.com/ncclient/ncclient/releases/tag/v0.6.15

ChangeLog:

* Mon Oct 23 2023 Benjamin A. Beasley  - 0.6.15-1
- Update to 0.6.15
* Mon Oct 23 2023 Benjamin A. Beasley  - 0.6.13-5
- Update License to SPDX
* Mon Oct 23 2023 Benjamin A. Beasley  - 0.6.13-4
- Drop pytest-cov/pytest-runner dependencies
* Mon Oct 23 2023 Benjamin A. Beasley  - 0.6.13-3
- Set up the test environment better
* Mon Oct 23 2023 Benjamin A. Beasley  - 0.6.13-2
- Use a trailing slash when listing directories in files lists


___
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 2245584] perl-Test2-Suite-0.000158 is available

2023-10-23 Thread bugzilla

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

Michal Josef Spacek  changed:

   What|Removed |Added

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



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

0.000158  2023-10-22 22:05:42-07:00 America/Los_Angeles

- Mark Workflow-Acceptance.t as AUTHOR_TESTING

0.000157  2023-10-22 21:26:49-07:00 America/Los_Angeles

- Fix #280: Document --no_srand option in Test2::V0
- Fix #276: Document bool() import in Test2::V0
- Fix #279: Merged fix for VMS test issues
- Fix #277: Merged POD tweaks

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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202245584%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 2245583] perl-Term-Table-0.018 is available

2023-10-23 Thread bugzilla

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

Michal Josef Spacek  changed:

   What|Removed |Added

 Resolution|--- |RAWHIDE
   Fixed In Version||perl-Term-Table-0.018-1.fc4
   ||0
 Status|ASSIGNED|CLOSED
Last Closed||2023-10-24 01:25:20




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2245583
___
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-Term-Table] PR #6: 0.018 bump

2023-10-23 Thread Michal Josef Špaček


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

Merged pull-request:

``
0.018 bump
``

https://src.fedoraproject.org/rpms/perl-Term-Table/pull-request/6
___
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-Term-Table] PR #6: 0.018 bump

2023-10-23 Thread Michal Josef Špaček


mspacek opened a new pull-request against the project: `perl-Term-Table` that 
you are following:
``
0.018 bump
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Term-Table/pull-request/6
___
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: How to deal with COPR and RPMAutoSpec

2023-10-23 Thread Pavel Raiskup

On úterý 17. října 2023 22:47:23 CEST Richard Shaw wrote:
> I'm trying to test build packages before actually creating a side tag and
> doing real builds.
> 
> I'm using rpkg to do the test builds but openshading language uses
> RPMAutoSpec. I've tried creating empty commits to bump the release but it
> does not appear to be working.
> 
> What's the work around?

One of the ways might be:
$ copr-distgit-client clone --dist-git fedora 
$ cd 
$ git commit -m "bump" --allow-empty
$ copr-distgit-client sources
$ copr-distgit-client srpm
...
Wrote: /tmp/--.src.rpm

Pavel


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

Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

2023-10-23 Thread Pavel Raiskup

On úterý 24. října 2023 0:31:49 CEST Pavel Raiskup wrote:
> On pátek 30. prosince 2022 20:01:55 CEST Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/Rpmautospec_by_Default
> > 
> > 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 ==
> > Rpmautospec (`%autorelease` and `%autochangelog`) is recommended as
> > the default approach.
> > Packaging Guidelines and other documentation are adjusted to describe
> > this approach first.
> > Various tools that provide spec file templates are adjusted.
> 
> While on it, could we please make %changelog optional?

Whooops!  My INBOX got reordered, and it is obvious it is too late for
me :-) sorry for bumping this old thread (I have just been dealing with
autospec on multiple levels recently so I thought this thread was also
relevant).

> Packaging become an automatized task, and maintainers don't pay
> attention to %changelog beauty so they simply generate it from git-log
> (but I'd claim that git-log != %changelog).  Seems that
> %changelog become one of the most painful maintainers' headache :)
> 
> What do you think about a static changelog like:
> 
> %changelog
> * See https://src.fedoraproject.org/rpms//commits/rawhide
> 
> Aren't we ready to admit (something like) this is enough?
> 
> Pavel
> 



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

Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

2023-10-23 Thread Pavel Raiskup

On pátek 30. prosince 2022 20:01:55 CEST Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/Rpmautospec_by_Default
> 
> 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 ==
> Rpmautospec (`%autorelease` and `%autochangelog`) is recommended as
> the default approach.
> Packaging Guidelines and other documentation are adjusted to describe
> this approach first.
> Various tools that provide spec file templates are adjusted.

While on it, could we please make %changelog optional?

Packaging become an automatized task, and maintainers don't pay
attention to %changelog beauty so they simply generate it from git-log
(but I'd claim that git-log != %changelog).  Seems that
%changelog become one of the most painful maintainers' headache :)

What do you think about a static changelog like:

%changelog
* See https://src.fedoraproject.org/rpms//commits/rawhide

Aren't we ready to admit (something like) this is enough?

Pavel


___
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 2245689] perl-WWW-Curl core dumps perl if use of setopt CURLOPT_RESOLV

2023-10-23 Thread bugzilla

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



--- Comment #1 from static  ---
It looks like besides the license change, the #ifdef was the only change for
4.17 version.  They tried to add the #ifdef for old libcurl versions that
didn't support for the setopt CURLOPT_RESOLV.  I don't know that is an issue
with EL8 or EL7.  Looking at the changelog for curl/libcurl, it looks like that
has been in curl even in EL7.


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

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

[rpms/perl-Web-Scraper] PR #1: Fix flatpak build

2023-10-23 Thread Yaakov Selkowitz


yselkowitz commented on the pull-request: `Fix flatpak build` that you are 
following:
``
ping @corsepiu 
``

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

[Bug 2245689] New: perl-WWW-Curl core dumps perl if use of setopt CURLOPT_RESOLV

2023-10-23 Thread bugzilla

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

Bug ID: 2245689
   Summary: perl-WWW-Curl core dumps perl if use of setopt
CURLOPT_RESOLV
   Product: Fedora EPEL
   Version: epel9
  Hardware: All
OS: Linux
Status: NEW
 Component: perl-WWW-Curl
  Severity: medium
  Assignee: emman...@seyman.fr
  Reporter: agibs...@gmail.com
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr, mspa...@redhat.com,
perl-devel@lists.fedoraproject.org,
xav...@bachelot.org
  Target Milestone: ---
Classification: Fedora



Description of problem:
If you try to use the setopt(CURLOPT_RESOLV, ...) option, perl core dumps. 
This was tracked down awhile but seems to not be fixed upstream.  A previous
commit in the upstream source for version 4.17 added #ifdef in Curl.xs for
building CURLOPT_RESOLV support but the ifdef for CURLOPT_RESOLV is always
false because CURLOPT_RESOLV is an enum and not a define.

Version-Release number of selected component (if applicable):


How reproducible:
Every time

Steps to Reproduce:
1. Install perl-WWW-Curl
1. Create program that uses WWW::Curl::Easy and does a setopt OPTCURL_RESOLV. 
Perl immediately crashes when it hits that line.
   An example simple source program and an explenation of the problem is
below...
   https://github.com/szbalint/WWW--Curl/issues/9

Additional info:
To fix it, removing the #ifdef for CURLOPT_RESOLV in the Curl.xs allows it to
be compiled into perl-WWW-Curl.


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202245689%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 2243201] perl-CGI-Application-Plugin-Session-1.05-27.fc40 FTBFS with CGI-4.59: Failed test 'Expiry should not change' at t/06_expiry.t line 69

2023-10-23 Thread bugzilla

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

Fedora Update System  changed:

   What|Removed |Added

 Resolution|--- |ERRATA
   Fixed In Version||perl-CGI-Application-Plugin
   ||-Session-1.05-28.fc40
 Status|MODIFIED|CLOSED
Last Closed||2023-10-23 14:58:11



--- Comment #2 from Fedora Update System  ---
FEDORA-2023-b289e51e94 has been pushed to the Fedora 40 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=2243201

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

Orphaned perl-Fennec

2023-10-23 Thread Paul Howarth

I've just orphaned perl-Fennec, which has been deprecated upstream
since 2018 (in favor of perl-Test2-Suite).

According to fedrq, nothing in Fedora depends on it:
$ fedrq whatrequires-src -X -F source perl-Fennec
(nothing)

This was actually triggered by a test suite failure for the package in
koji that started a couple of weeks ago but I cannot reproduce locally
in mock. Given its state both upstream and in Fedora, I don't think
it's worth expending debugging cycles on this.

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

[Bug 2243201] perl-CGI-Application-Plugin-Session-1.05-27.fc40 FTBFS with CGI-4.59: Failed test 'Expiry should not change' at t/06_expiry.t line 69

2023-10-23 Thread bugzilla

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

Fedora Update System  changed:

   What|Removed |Added

 Status|NEW |MODIFIED



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


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202243201%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 2245583] perl-Term-Table-0.018 is available

2023-10-23 Thread bugzilla

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

Michal Josef Spacek  changed:

   What|Removed |Added

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



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

0.018 2023-10-22 21:55:51-07:00 America/Los_Angeles

- Merged doc fix PR

Doc changes, 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=2245583

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

Fedora 39 compose report: 20231023.n.0 changes

2023-10-23 Thread Fedora Branched Report

OLD: Fedora-39-20231020.n.0
NEW: Fedora-39-20231023.n.0

= SUMMARY =
Added images:2
Dropped images:  0
Added packages:  0
Dropped packages:0
Upgraded packages:   4
Downgraded packages: 0

Size of added packages:  0 B
Size of dropped packages:0 B
Size of upgraded packages:   11.17 MiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   100.16 KiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: LXQt live aarch64
Path: Spins/aarch64/iso/Fedora-LXQt-Live-aarch64-39-20231023.n.0.iso
Image: Workstation live aarch64
Path: 
Workstation/aarch64/iso/Fedora-Workstation-Live-aarch64-39-20231023.n.0.iso

= DROPPED IMAGES =

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  dnf-4.18.0-2.fc39
Old package:  dnf-4.17.0-6.fc39
Summary:  Package manager
RPMs: dnf dnf-automatic dnf-data python3-dnf yum
Size: 1.19 MiB
Size change:  37.16 KiB
Changelog:
  * Wed Oct 18 2023 Jan Kolarik  - 4.18.0-1
  - Update to 4.18.0
  - base: Add obsoleters of only latest versions (RhBug:2183279,2176263)
  - comps: Fix marking a group package as installed (RhBug:2066638)
  - distro-sync: Print better info message when no match (RhBug:2011850)
  - Include dist-info for python3-dnf (RhBug:2239323)
  - Revert "Block signals during RPM transaction processing" (RhBug:2133398)
  - Do not print details of verifying (RhBug:1908253)
  - Add Recommends /usr/bin/sqlite3 for bash-completion for Fedora
  - conf: Split $releasever to $releasever_major and $releasever_minor 
(RhBug:1789346)
  - Allow DNF to be removed by DNF 5 (RhBug:2221907)
  - Update translations

  * Thu Oct 19 2023 Jan Kolarik  - 4.18.0-2
  - Revert "Does not print Verify: package" (RhBug:1908253)


Package:  kexec-tools-2.0.27-2.fc39
Old package:  kexec-tools-2.0.27-1.fc39
Summary:  The kexec/kdump userspace component
RPMs: kexec-tools
Size: 1.83 MiB
Size change:  -11.17 KiB
Changelog:
  * Wed Oct 18 2023 Coiby Xu  - 2.0.27-2
  - Only try to reset crashkernel when kdump.service is enabled


Package:  libdnf-0.72.0-1.fc39
Old package:  libdnf-0.71.0-2.fc39
Summary:  Library providing simplified C and Python API to libsolv
RPMs: libdnf libdnf-devel python3-hawkey python3-libdnf
Size: 7.27 MiB
Size change:  68.30 KiB
Changelog:
  * Wed Oct 18 2023 Jan Kolarik  - 0.72.0-1
  - Update to 0.72.0
  - Avoid reinstalling installonly packages marked for ERASE (RhBug:2163474)
  - transaction: Save the reason for installing (RhBug:1733274)
  - hawkey.subject: get_best_selectors only obsoleters of latest 
(RhBug:2183279,2176263)
  - conf: Add limited shell-style variable expansion (RhBug:1789346)
  - conf: Add support for $releasever_major, $releasever_minor (RhBug:1789346)
  - repo: Don't download the repository if the local cache is up to date
  - Allow DNF to be removed by DNF 5 (RhBug:2221907)
  - Include dist-info for python3-libdnf
  - bindings: Load all modules with RTLD_GLOBAL
  - Update translations


Package:  librepo-1.17.0-1.fc39
Old package:  librepo-1.16.0-2.fc39
Summary:  Repodata downloading library
RPMs: librepo librepo-devel python3-librepo
Size: 902.03 KiB
Size change:  5.87 KiB
Changelog:
  * Wed Oct 18 2023 Jan Kolarik  - 1.17.0-1
  - Update to 1.17.0
  - lr_gpg_check_signature: Forward PGP error messages from RPM
  - PGP: fix: Support importing binary public keys in librpm backend
  - PGP: Enable creating a UID directory for GnuGP agent socket in 
/run/gnupg/user
  - PGP: Set a default creation SELinux labels on GnuPG directories



= DOWNGRADED PACKAGES =
___
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: F40 MariaDB MySQL repackaging (Self-Contained)

2023-10-23 Thread Neal Gompa

On Mon, Oct 23, 2023 at 5:23 AM Michal Schorm  wrote:
>
> Hi,
>
> On Fri, Oct 20, 2023 at 1:12 AM Kevin Kofler via devel
>  wrote:
> >
> > > * Rename package 'community-mysql' to 'mysql' and Stop providing
> > > 'mysql' symbols by package 'mariadb'
> >
> > Why not just drop community-mysql (and keep mariadb as the provider of
> > mysql*) instead? I really do not see why we need to ship 2 competing forks
> > of the same database in Fedora. Applications typically do not even notice
> > the difference.
> >
> > > When MariaDB was introduced to Fedora, it seemed like it eventually
> > > replaces MySQL
> >
> > Is that not what has happened? Who still uses the Oracle crippleware?
> >
> > As I understand it, most distros are shipping only MariaDB.
>
> MySQL is definitely still on the scene. Few examples from the big distros 
> here:
>   Ubuntu: 
> https://packages.ubuntu.com/search?suite=default=all=any=mysql=names
>   Arch: https://aur.archlinux.org/packages/mysql
>
> Some distros dropped MySQL entirely, some favors MariaDB. None of that
> changes the fact that MySQL still is a popular DB.
> Take a look how many people use, or want to learn MySQL:
> https://survey.stackoverflow.co/2023/#most-popular-technologies-database
> https://survey.stackoverflow.co/2022/#most-popular-technologies-database
>
> What I want to do in Fedora is to merely recognize that MariaDB and
> MySQL are not fully interchangeable (drop-in) anymore. Their abilities
> and feature set grow diverse, so they both should have their own
> designated place, without pretending or confusion on which is which.
>
>

For what it's worth, I have increasingly encountered issues with the
interchangeability of the two.

In a previous job, there was a lot of drive toward MariaDB initially,
but then they switched to MySQL (particularly with Galera or XtraDB).

In the end, they have become increasingly divergent implementations
with a common ancestor. And that's fine.

> > > I want to change the packaging structure so the result will look as
> > > follows: * The unversioned name ('mariadb') will become a meta-package
> > > ** It will point to the one versioned variant which I choose to be the
> > > default one for the given Fedora release
> > > ** It will provide all of the unversioned names for the versioned
> > > variant that is default for the given Fedora release, to minimize the
> > > changes visible to the users
> > > * All other versions will have their own versioned package (e.g
> > > "mariadb10.5" "mariadb10.11") and will conflict with each other
> > >
> > > This will allow for:
> > > * users to keep using the unversioned names they are used to
> > > * maintainer to change the default version for a given Fedora release
> > > on a single, centralized place
> > > * users to enjoy all of the features of the modularity I offered them,
> > > in a simpler way
> > > * maintainer to add new versions quickly, without any need of changing
> > > the default version (other than adding new conflicts)
> >
> > There is a major issue with this approach: Users installing Fedora 40 will
> > get the mariadb metapackages dragging in mariadb10.11. Then they upgrade to
> > Fedora 41 or 42 or whatever that will ship mariadb10.whatever. So then
> > mariadb will want to drag in mariadb10.whatever, but mariadb10.11 will also
> > want to get upgraded, leading to a conflict that DNF will not be able to
> > resolve in a satisfactory way. (Most likely, it will upgrade mariadb10.11,
> > keep the old Fedora n-1 version of the mariadb metapackage, and never
> > install the new mariadb10.whatever.)
> >
> > The default version should just be unversioned, instead of having the
> > unversioned package be a metapackage.
>
> Thanks for pointing that out, I'll look into it.
>
>

We have a few examples of this for libraries and runtimes, I don't
think it'd be too difficult to do for database software too.

The advantage of this is that it maintains the principle of least
surprise, and people will be upgraded by default to the latest
versions in a way they expect.

I'd like to see this for PostgreSQL someday too...

> > >   Note:
> > >   I specifically don't want the packages to be parallel installable. I
> > > only want them to be parallel available.
> >
> > That makes it a lot less useful to use versioned package names.
> >
> > I suggest you ship one set of MariaDB packages in Fedora, and then use Copr
> > to distribute different versions (which would also be named mariadb, not
> > e.g. mariadb10.5 or mariadb10.11, and just have, say, Version: 10.5 and,
> > since that is a downgrade compared to the official packages, Epoch: n+1,
> > where n is the Epoch of the official packages). To switch to a non-default
> > version, one would just dnf copr enable @mariadb-sig/mariadb-10.5 && dnf
> > upgrade (or distro-sync, but since it would be an "upgrade" at RPM level,
> > distro-sync is not needed here), and to switch back to the default version,
> > dnf copr disable @mariadb-sig/mariadb-10.5 && dnf

[Bug 2245662] New: perl-Inline-Python fails to build with Python 3.13: error: implicit declaration of function `Py_SetProgramName`

2023-10-23 Thread bugzilla

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

Bug ID: 2245662
   Summary: perl-Inline-Python fails to build with Python 3.13:
error: implicit declaration of function
`Py_SetProgramName`
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Inline-Python
  Assignee: mattias.ell...@physics.uu.se
  Reporter: ksu...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: j.k.nil...@usit.uio.no, ksu...@redhat.com,
mattias.ell...@physics.uu.se, mhron...@redhat.com,
perl-devel@lists.fedoraproject.org
Blocks: 2231791 (F40FTBFS,RAWHIDEFTBFS), 2244836 (PYTHON3.13)
  Target Milestone: ---
Classification: Fedora



perl-Inline-Python fails to build with Python 3.13.0a1.

Python.xs: In function â€˜do_pyinitâ€™:
Python.xs:33:5: error: implicit declaration of function
â€˜Py_SetProgramNameâ€™; did you mean â€˜Py_GetProgramNameâ€™?
[-Werror=implicit-function-declaration]
   33 | Py_SetProgramName(L"python");
  | ^
  | Py_GetProgramName
Python.xs:40:5: error: implicit declaration of function â€˜PySys_SetArgvâ€™
[-Werror=implicit-function-declaration]
   40 | PySys_SetArgv(_python_argc, _python_argv);  /* Tk needs this */
  | ^
cc1: some warnings being treated as errors

Py_SetProgramName has been removed from Python 3.13.
According to https://docs.python.org/3.13/whatsnew/3.13.html:
Py_SetProgramName(): set PyConfig.program_name instead.

For the build logs, see:
https://copr-be.cloud.fedoraproject.org/results/@python/python3.13/fedora-rawhide-x86_64/06546755-perl-Inline-Python/

For all our attempts to build perl-Inline-Python with Python 3.13, see:
https://copr.fedorainfracloud.org/coprs/g/python/python3.13/package/perl-Inline-Python/

Testing and mass rebuild of packages is happening in copr.
You can follow these instructions to test locally in mock if your package
builds with Python 3.13:
https://copr.fedorainfracloud.org/coprs/g/python/python3.13/

Let us know here if you have any questions.

Python 3.13 is planned to be included in Fedora 41.
To make that update smoother, we're building Fedora packages with all
pre-releases of Python 3.13.
A build failure prevents us from testing all dependent packages (transitive
[Build]Requires),
so if this package is required a lot, it's important for us to get it fixed
soon.

We'd appreciate help from the people who know this package best,
but if you don't want to work on this now, let us know so we can try to work
around it on our side.



Referenced Bugs:

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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202245662%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 2245577] perl-Devel-Declare-Parser-0.021 is available

2023-10-23 Thread bugzilla

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version||perl-Devel-Declare-Parser-0
   ||.021-1.fc40
 Resolution|--- |ERRATA
 Status|MODIFIED|CLOSED
Last Closed||2023-10-23 13:37:11



--- Comment #2 from Fedora Update System  ---
FEDORA-2023-4fb59df83c has been pushed to the Fedora 40 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=2245577

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202245577%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 2245577] perl-Devel-Declare-Parser-0.021 is available

2023-10-23 Thread bugzilla

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



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


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

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

[rpms/perl-Devel-Declare-Parser] PR #1: 0.021 bump; Package tests

2023-10-23 Thread Jitka Plesnikova


jplesnik merged a pull-request against the project: `perl-Devel-Declare-Parser` 
that you are following.

Merged pull-request:

``
0.021 bump; Package tests
``

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

[rpms/perl-Devel-Declare-Parser] PR #1: 0.021 bump; Package tests

2023-10-23 Thread Jitka Plesnikova


jplesnik opened a new pull-request against the project: 
`perl-Devel-Declare-Parser` that you are following:
``
0.021 bump; Package tests
``

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

Re: [Fedora Change draft] Minizip transition to minizip-ng

2023-10-23 Thread Lukas Javorsky

Here is the list of transitively dependent packages that will be FTBFS due
to the chromium, libdigidocpp, and OpenColorIO FTBFS (retrieved using
find_unblocked_orphans
 releng
tool):
OpenImageIO
YafaRay
asv
blender
calligra
embree
krita
luxcorerender
oidn
open-eid
openpgl
openshadinglanguage
openvkl
qdigidoc
tinygo
usd

As the maintainer checked, some of these (that depend on OpenColorIO)
packages are ready for the minizip-ng-compat [1].
The chromium issue is being discussed with minizip-ng upstream [2].

[1]
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/IMJJDVACGCYCUW5VM2O6NZKULXMBO2CG/
[2] https://github.com/zlib-ng/minizip-ng/issues/447

On Thu, Oct 19, 2023 at 12:30 PM Lukas Javorsky  wrote:

> Hi,
>
> We've been working on a set of Fedora changes (zlib and minizip) and now
> I'd like to share the minizip Fedora change [1] with you, the community.
>
> This one is smaller than the zlib one, but it needs to be finished before
> the zlib (as we will remove the minizip-compat subpackage with the zlib
> package).
>
> All details are mentioned in the Change proposal, I just wanted to share
> it directly with you via this email.
>
> Please raise any questions/feedback, so we can fine-tune it before asking
> for a wrangler from FESCo.
>
> There are currently three packages that don't build with the new
> minizip-ng (all reported to their maintainers):
> Chromium: https://bugzilla.redhat.com/show_bug.cgi?id=2242271
> Libdigidocpp: https://bugzilla.redhat.com/show_bug.cgi?id=2240599
> OpenColorIO: https://bugzilla.redhat.com/show_bug.cgi?id=2239262
>
> All other packages have been rebuilt in the testing COPR repository [2].
>
> PS: Don't worry the zlib Fedora Change will be shared with you as well
>
> [1] https://fedoraproject.org/wiki/Changes/MinizipNGTransition
> [2] https://copr.fedorainfracloud.org/coprs/ljavorsk/minizip-ng/packages/
>
> --
> S pozdravom/ Best regards
>
> Lukáš Javorský
>
> Software Engineer, Core service - Databases
>
> Red Hat 
>
> Purkyňova 115 (TPB-C)
>
> 612 00 Brno - Královo Pole
>
> ljavo...@redhat.com
> 
>


-- 
S pozdravom/ Best regards

Lukáš Javorský

Software Engineer, Core service - Databases

Red Hat 

Purkyňova 115 (TPB-C)

612 00 Brno - Královo Pole

ljavo...@redhat.com

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

Re: F40 Change Proposal: F40 MariaDB MySQL repackaging (Self-Contained)

2023-10-23 Thread Michal Schorm

Hi,

On Fri, Oct 20, 2023 at 1:12 AM Kevin Kofler via devel
 wrote:
>
> > * Rename package 'community-mysql' to 'mysql' and Stop providing
> > 'mysql' symbols by package 'mariadb'
>
> Why not just drop community-mysql (and keep mariadb as the provider of
> mysql*) instead? I really do not see why we need to ship 2 competing forks
> of the same database in Fedora. Applications typically do not even notice
> the difference.
>
> > When MariaDB was introduced to Fedora, it seemed like it eventually
> > replaces MySQL
>
> Is that not what has happened? Who still uses the Oracle crippleware?
>
> As I understand it, most distros are shipping only MariaDB.

MySQL is definitely still on the scene. Few examples from the big distros here:
  Ubuntu: 
https://packages.ubuntu.com/search?suite=default=all=any=mysql=names
  Arch: https://aur.archlinux.org/packages/mysql

Some distros dropped MySQL entirely, some favors MariaDB. None of that
changes the fact that MySQL still is a popular DB.
Take a look how many people use, or want to learn MySQL:
https://survey.stackoverflow.co/2023/#most-popular-technologies-database
https://survey.stackoverflow.co/2022/#most-popular-technologies-database

What I want to do in Fedora is to merely recognize that MariaDB and
MySQL are not fully interchangeable (drop-in) anymore. Their abilities
and feature set grow diverse, so they both should have their own
designated place, without pretending or confusion on which is which.


> > I want to change the packaging structure so the result will look as
> > follows: * The unversioned name ('mariadb') will become a meta-package
> > ** It will point to the one versioned variant which I choose to be the
> > default one for the given Fedora release
> > ** It will provide all of the unversioned names for the versioned
> > variant that is default for the given Fedora release, to minimize the
> > changes visible to the users
> > * All other versions will have their own versioned package (e.g
> > "mariadb10.5" "mariadb10.11") and will conflict with each other
> >
> > This will allow for:
> > * users to keep using the unversioned names they are used to
> > * maintainer to change the default version for a given Fedora release
> > on a single, centralized place
> > * users to enjoy all of the features of the modularity I offered them,
> > in a simpler way
> > * maintainer to add new versions quickly, without any need of changing
> > the default version (other than adding new conflicts)
>
> There is a major issue with this approach: Users installing Fedora 40 will
> get the mariadb metapackages dragging in mariadb10.11. Then they upgrade to
> Fedora 41 or 42 or whatever that will ship mariadb10.whatever. So then
> mariadb will want to drag in mariadb10.whatever, but mariadb10.11 will also
> want to get upgraded, leading to a conflict that DNF will not be able to
> resolve in a satisfactory way. (Most likely, it will upgrade mariadb10.11,
> keep the old Fedora n-1 version of the mariadb metapackage, and never
> install the new mariadb10.whatever.)
>
> The default version should just be unversioned, instead of having the
> unversioned package be a metapackage.

Thanks for pointing that out, I'll look into it.


> >   Note:
> >   I specifically don't want the packages to be parallel installable. I
> > only want them to be parallel available.
>
> That makes it a lot less useful to use versioned package names.
>
> I suggest you ship one set of MariaDB packages in Fedora, and then use Copr
> to distribute different versions (which would also be named mariadb, not
> e.g. mariadb10.5 or mariadb10.11, and just have, say, Version: 10.5 and,
> since that is a downgrade compared to the official packages, Epoch: n+1,
> where n is the Epoch of the official packages). To switch to a non-default
> version, one would just dnf copr enable @mariadb-sig/mariadb-10.5 && dnf
> upgrade (or distro-sync, but since it would be an "upgrade" at RPM level,
> distro-sync is not needed here), and to switch back to the default version,
> dnf copr disable @mariadb-sig/mariadb-10.5 && dnf distro-sync (to
> "downgrade" to the official packages' lower EVR).

I would like to have the alternative versions "closer" to Fedora.
COPR is somehow "far", requiring users to be educated to know where to
look and what to search for.
I hope the parallel availability will significantly enhance the user
experience, over any kind of "distant" repos.




--

Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat

--
On Fri, Oct 20, 2023 at 1:12 AM Kevin Kofler via devel
 wrote:
>
> > * Rename package 'community-mysql' to 'mysql' and Stop providing
> > 'mysql' symbols by package 'mariadb'
>
> Why not just drop community-mysql (and keep mariadb as the provider of
> mysql*) instead? I really do not see why we need to ship 2 competing forks
> of the same database in Fedora. Applications typically do not even notice
> the difference.
>
> > When MariaDB was introduced to Fedora, it seemed like it

Re: Whole system analysis with frame pointers

2023-10-23 Thread Richard W.M. Jones

On Sat, Oct 21, 2023 at 02:05:39PM +0100, Richard W.M. Jones wrote:
>   http://oirase.annexia.org/tmp/2023-03-08-flamegraphs.mp4 [57M, 15m41s]
...
> Captures work across userspace and kernel code, as shown in the third
> example which is a KVM (ie. hardware assisted) virtual machine doing
> some highly parallel work inside:
> 
>   http://oirase.annexia.org/tmp/2023-kvm-build.svg
> 
> You can clearly see the 8 virtual (guest) CPUs on the left side, using
> KVM.  More interesting is that this guest uses a qcow2 file for disk
> and there's a heck of an overhead writing to that file.  There's
> nothing to fix here -- qcow2 files shouldn't be used in this
> situation; for best performance it would be better to use a local
> block device to back the guest.

We had some discussion on chat about this trace so I want to clarify
two things.

The problem is not qcow2, but using a regular file as backing for the
guest disk.  I reran the test using a block device and things are,
well, different:

  http://oirase.annexia.org/tmp/2023-kvm-build-on-device.svg

(The block device backed test ran quicker.)

Which brings me to the second point of clarification.  perf cycles
collection only samples processes which are running.  In both the
flamegraphs here, the host machine is mostly idle.

This sampling is sometimes exactly what you want.  But unless you're
aware of it, it can mislead.  In particular it has the effect of
exaggerating things which are actually not taking much time.
'wpa_supplicant', for example, is not consuming a huge 3.2% of the
entire system, but 3.2% of the non-idle time of the system, which is a
very different thing.

I covered this point in my talk (see link above), but wanted to
emphasize it.  It is also something that is hopefully fixed when we
get perf --off-cpu support, see adjacent subthread.

(Thanks Hanna & Dan for raising these questions)

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Dist-git decoupling investigation

2023-10-23 Thread Michal Konecny


Hi everyone,

We would like to inform you that Advanced Reconnaissance Crew (ARC) [0] 
from the CPE team is currently conducting research into decoupling 
dist-git from its pagure-related dependencies.


This investigation has come about as part of discussions that arose from 
https://pagure.io/cpe/initiatives-proposal/issue/26 [1].


The investigation has the following objectives:
1. Enumerate and write down a description of all the integrations we 
rely on in our current git forge (Pagure)
2. Create a list of integrations to continue after moving to different 
git forge
3. Write a recommendation plan on how we can loosely couple these 
integrations generically with another git forge (make it git forge 
agnostic as possible)
4. Add the list and descriptions of integrations to the right place in 
our documentation


This will then inform future design requirements and the next set of 
objectives that looks like this:

* Map API calls that need to remain
* Removing the Pagure from dist-git
* Base git as backend
** What functionality needs to move to dist-git when git is used as base 
backend


You can find a list of existing work items here: 
https://pagure.io/fedora-infra/arc/issues [2]
You can also follow along with the findings on our HackMD: 
https://hackmd.io/@fnF231raRruGKZbPBWKsHQ/SJceJYaxa [3]


On behalf of ARC,
Michal

P.S.: You can also discuss this on discourse: 
https://discussion.fedoraproject.org/t/dist-git-decoupling-investigation/93644 
[4]


[0] https://fedora-arc.readthedocs.io/en/latest/workflow.html
[1] https://pagure.io/cpe/initiatives-proposal/issue/26
[2] https://pagure.io/fedora-infra/arc/issues
[3] https://hackmd.io/@fnF231raRruGKZbPBWKsHQ/SJceJYaxa
[4] 
https://discussion.fedoraproject.org/t/dist-git-decoupling-investigation/93644

___
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: Whole system analysis with frame pointers

2023-10-23 Thread Richard W.M. Jones

On Mon, Oct 23, 2023 at 12:15:06PM +0200, Michal Schmidt wrote:
> On Sat, Oct 21, 2023 at 3:06 PM Richard W.M. Jones  wrote:
> > I was asked about the topic in the subject, and I think it's not very
> > well known.  The news is that since Fedora 38, whole system
> > performance analysis is now easy to do.  This can be used to identify
> > hot spots in single applications, or what the (whole computer) is
> > really doing during lengthy operations.
> >
> > You can visualise these in various ways - my favourite is Brendan
> > Gregg's Flame Graphs tools, but perf has many alternate ways to
> > capture and display the data:
> >
> >   https://www.brendangregg.com/linuxperf.html
> >   https://www.brendangregg.com/flamegraphs.html
> >   https://perf.wiki.kernel.org/index.php/Tutorial
> >
> > I did a 15 min talk on this topic, actually to an internal Red Hat
> > audience, but I guess it's fine to open it up to everyone:
> >
> >   http://oirase.annexia.org/tmp/2023-03-08-flamegraphs.mp4 [57M, 15m41s]
> 
> Hello Richard,
> Thank you for posting this.
> In the talk you mentioned that the "--off-cpu" option was not yet available.
> Has there been any progress to enable it since the talk was recorded?
> I have just tried it in Rawhide. perf is still built without it:
>  Warning: option `off-cpu' is being ignored because no BUILD_BPF_SKEL=1
> 
> What is blocking the enablement of this feature? Are there some trade-offs?
>
> Is there a thread or a Bugzilla ticket where it is discussed?

There have been a few technical issues.  Here is, I think, the latest
patch series:

  https://lkml.org/lkml/2023/9/14/970

You can see from the link in that email that it missed Linux 6.4
because it caused a build error.  Linus went on to describe the whole
effort as "garbage", but there was further discussion starting around
here:

  https://lore.kernel.org/lkml/zfosuab5xejd0...@kernel.org/

Rich.

> Michal
> 
> > To show the kind of thing which is possible I have captured three
> > whole system flame graphs.  First comes from doing "make -j32" in the
> > qemu build tree:
> >
> >   http://oirase.annexia.org/tmp/2023-gcc-with-lto.svg
> >
> > 8% of the time is spent running the assembler.  I seem to recall that
> > Clang uses a different approach of integrating the assembler into the
> > compiler and I guess it probably avoids most of that overhead.
> >
> > The second is an rpmbuild of the Fedora Rawhide kernel package:
> >
> >   http://oirase.annexia.org/tmp/2023-kernel-build.svg
> >
> > I think it's interesting that 6% of the time is spent compressing the
> > RPMs, and another 6% running pahole (debuginfo generation?)  But the
> > most surprising thing is it appears 42% of the time is spent just
> > parsing C code [if I'm reading that right, I actually can't believe
> > parsing takes so much time].  If true there must be opportunities to
> > optimize things here.
> >
> > Captures work across userspace and kernel code, as shown in the third
> > example which is a KVM (ie. hardware assisted) virtual machine doing
> > some highly parallel work inside:
> >
> >   http://oirase.annexia.org/tmp/2023-kvm-build.svg
> >
> > You can clearly see the 8 virtual (guest) CPUs on the left side, using
> > KVM.  More interesting is that this guest uses a qcow2 file for disk
> > and there's a heck of an overhead writing to that file.  There's
> > nothing to fix here -- qcow2 files shouldn't be used in this
> > situation; for best performance it would be better to use a local
> > block device to back the guest.
> >
> >
> > The overhead of frame pointers in my measurements is about 1%, so this
> > enhanced visibility into the system seems well worthwhile.  I use this
> > all the time.  This year I've used it to suggest optimizations in
> > qemu, nbdkit and the kernel.
> >
> > Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Whole system analysis with frame pointers

2023-10-23 Thread Michal Schmidt

On Sat, Oct 21, 2023 at 3:06 PM Richard W.M. Jones  wrote:
> I was asked about the topic in the subject, and I think it's not very
> well known.  The news is that since Fedora 38, whole system
> performance analysis is now easy to do.  This can be used to identify
> hot spots in single applications, or what the (whole computer) is
> really doing during lengthy operations.
>
> You can visualise these in various ways - my favourite is Brendan
> Gregg's Flame Graphs tools, but perf has many alternate ways to
> capture and display the data:
>
>   https://www.brendangregg.com/linuxperf.html
>   https://www.brendangregg.com/flamegraphs.html
>   https://perf.wiki.kernel.org/index.php/Tutorial
>
> I did a 15 min talk on this topic, actually to an internal Red Hat
> audience, but I guess it's fine to open it up to everyone:
>
>   http://oirase.annexia.org/tmp/2023-03-08-flamegraphs.mp4 [57M, 15m41s]

Hello Richard,
Thank you for posting this.
In the talk you mentioned that the "--off-cpu" option was not yet available.
Has there been any progress to enable it since the talk was recorded?
I have just tried it in Rawhide. perf is still built without it:
 Warning: option `off-cpu' is being ignored because no BUILD_BPF_SKEL=1

What is blocking the enablement of this feature? Are there some trade-offs?
Is there a thread or a Bugzilla ticket where it is discussed?

Michal

> To show the kind of thing which is possible I have captured three
> whole system flame graphs.  First comes from doing "make -j32" in the
> qemu build tree:
>
>   http://oirase.annexia.org/tmp/2023-gcc-with-lto.svg
>
> 8% of the time is spent running the assembler.  I seem to recall that
> Clang uses a different approach of integrating the assembler into the
> compiler and I guess it probably avoids most of that overhead.
>
> The second is an rpmbuild of the Fedora Rawhide kernel package:
>
>   http://oirase.annexia.org/tmp/2023-kernel-build.svg
>
> I think it's interesting that 6% of the time is spent compressing the
> RPMs, and another 6% running pahole (debuginfo generation?)  But the
> most surprising thing is it appears 42% of the time is spent just
> parsing C code [if I'm reading that right, I actually can't believe
> parsing takes so much time].  If true there must be opportunities to
> optimize things here.
>
> Captures work across userspace and kernel code, as shown in the third
> example which is a KVM (ie. hardware assisted) virtual machine doing
> some highly parallel work inside:
>
>   http://oirase.annexia.org/tmp/2023-kvm-build.svg
>
> You can clearly see the 8 virtual (guest) CPUs on the left side, using
> KVM.  More interesting is that this guest uses a qcow2 file for disk
> and there's a heck of an overhead writing to that file.  There's
> nothing to fix here -- qcow2 files shouldn't be used in this
> situation; for best performance it would be better to use a local
> block device to back the guest.
>
>
> The overhead of frame pointers in my measurements is about 1%, so this
> enhanced visibility into the system seems well worthwhile.  I use this
> all the time.  This year I've used it to suggest optimizations in
> qemu, nbdkit and the kernel.
>
> Rich.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[rpms/perl] PR #6: Fix flatpak build

2023-10-23 Thread Jitka Plesnikova


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

Merged pull-request:

``
Fix flatpak build
``

https://src.fedoraproject.org/rpms/perl/pull-request/6
___
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 2245551] perl-DateTime-1.63 is available

2023-10-23 Thread bugzilla

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|CLOSED
   Fixed In Version||perl-DateTime-1.63-1.fc40
 Resolution|--- |ERRATA
Last Closed||2023-10-23 09:04:12



--- Comment #4 from Fedora Update System  ---
FEDORA-2023-0b1a7e0518 has been pushed to the Fedora 40 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=2245551

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

[Bug 2245551] perl-DateTime-1.63 is available

2023-10-23 Thread bugzilla

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

Fedora Update System  changed:

   What|Removed |Added

 Status|NEW |MODIFIED



--- Comment #3 from Fedora Update System  ---
FEDORA-2023-0b1a7e0518 has been submitted as an update to Fedora 40.
https://bodhi.fedoraproject.org/updates/FEDORA-2023-0b1a7e0518


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

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

Next Open NeuroFedora Meeting: 1300 UTC on Monday, 23 October (today)

2023-10-23 Thread Ankur Sinha

Hello everyone,

Please join us at the next Open NeuroFedora team meeting on Monday 23
October at 1300UTC in the NeuroFedora channel on Matrix.  The meeting
is a public meeting, and open for everyone to attend. You can join us
over:

Matrix: https://matrix.to/#/%23neuro:fedoraproject.org

You can use this link to see the local time for the meeting:
https://www.timeanddate.com/worldclock/fixedtime.html?msg=Open+NeuroFedora+Meeting=20231023T13=%3A=1

or you can use this command in a terminal:
$ date --date='TZ="UTC" 1300 Monday'

The meeting will be chaired by @ankursinha. The agenda for the
meeting is:

- New introductions and roll call.
- Tasks from last meeting: https://meetbot.fedoraproject.org/latest/neurofedora
- Open Pagure tickets: 
https://pagure.io/neuro-sig/NeuroFedora/issues?status=Open=S%3A+Next+meeting
- Package health check: 
https://packager-dashboard.fedoraproject.org/dashboard?groups=neuro-sig
- Open package reviews check: 
https://bugzilla.redhat.com/show_bug.cgi?id=fedora-neuro
- CompNeuro lab compose status check for F39: 
https://koji.fedoraproject.org/koji/packageinfo?packageID=30691
- Neuroscience query of the week
- Next meeting day, and chair.
- Open floor.

We hope to see you there!

The meeting announcement is also posted on the NeuroFedora blog here:
https://neuroblog.fedoraproject.org/2023/10/23/next-open-neurofedora-meeting-23-October-1300-utc.html

You can learn more about NeuroFedora here:
https://neuro.fedoraproject.org


-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | 
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London


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

Retiring libabigail from EPEL 9

2023-10-23 Thread Dodji Seketeli

Hello,

I have retired libabigail from EPEL 9 because the package is now shipped
in RHEL 9.2 onward.

You can see that the files have been removed from the SCM at
https://src.fedoraproject.org/rpms/libabigail/tree/epel9.

The Rawhide, f39, f38, f37, EPEL7 and EPEL8 package are still
maintained.

Cheers,

-- 
Dodji
___
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 2245584] New: perl-Test2-Suite-0.000158 is available

2023-10-23 Thread bugzilla

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

Bug ID: 2245584
   Summary: perl-Test2-Suite-0.000158 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Test2-Suite
  Keywords: FutureFeature, Triaged
  Assignee: mspa...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: mspa...@redhat.com, perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Releases retrieved: 0.000158
Upstream release that is considered latest: 0.000158
Current version/release in rawhide: 0.000156-1.fc40
URL: http://search.cpan.org/dist/Test2-Suite/

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


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


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202245584%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 2245583] New: perl-Term-Table-0.018 is available

2023-10-23 Thread bugzilla

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

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



Releases retrieved: 0.018
Upstream release that is considered latest: 0.018
Current version/release in rawhide: 0.017-1.fc40
URL: http://search.cpan.org/dist/Term-Table/

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


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


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

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

38 matches

Mail list logo