[EPEL-devel] Re: SPDX identifiers in old branches?

[Gary Buhrmaster]

On Wed, May 25, 2022 at 12:47 AM Maxwell G  wrote:

> I don't follow. What "rpm spec file support" are you referring to?

I interpreted the proposal as adding a
new stanza SPDX: in addition to License:
which requires changing the definition.

The follow up suggested that the license
field be differently formatted.

I disagree with such explanatory
prefixes, as it requires yet more apps
to parse/support various prefixes.

If msuchy's proposal is not accepted
(allow packagers to use SPDX in all)
lets just go back to one of the original
proposals and have proven packagers
just do a bulk conversion after giving
existing packagers time to do their own
conversion.  One and done (and, yes,
wrong some of the time, but that too
can be fixed).
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: SPDX identifiers in old branches?

[Gary Buhrmaster]

On Wed, May 25, 2022 at 12:47 AM Maxwell G  wrote:

> I don't follow. What "rpm spec file support" are you referring to?

I interpreted the proposal as adding a
new stanza SPDX: in addition to License:
which requires changing the definition.

The follow up suggested that the license
field be differently formatted.

I disagree with such explanatory
prefixes, as it requires yet more apps
to parse/support various prefixes.

If msuchy's proposal is not accepted
(allow packagers to use SPDX in all)
lets just go back to one of the original
proposals and have proven packagers
just do a bulk conversion after giving
existing packagers time to do their own
conversion.  One and done (and, yes,
wrong some of the time, but that too
can be fixed).
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-4add1d3059   
needrestart-3.6-1.el7
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-d1317f7176   
rubygem-git-1.3.0-2.el7


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

rust-1.61.0-2.el7

Details about builds:



 rust-1.61.0-2.el7 (FEDORA-EPEL-2022-32d1e9430d)
 The Rust Programming Language

Update Information:

Update to Rust 1.61.0:  * Custom exit codes from `main` * More capabilities for
`const fn` * Static handles for locked stdio * Stabilized APIs  See the [blog
post](https://blog.rust-lang.org/2022/05/19/Rust-1.61.0.html) and [release
notes](https://github.com/rust-
lang/rust/blob/master/RELEASES.md#version-1610-2022-05-19) for more details.

ChangeLog:

* Mon May 23 2022 Josh Stone  - 1.61.0-2
- Add missing target_feature to the list of well known cfg names
* Thu May 19 2022 Josh Stone  - 1.61.0-1
- Update to 1.61.0.
- Add rust-toolset for ELN.


___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-Rawhide-20220524.n.1 compose check report

[Fedora compose checker]

Missing expected images:

Minimal raw-xz armhfp

Compose FAILS proposed Rawhide gating check!
3 of 43 required tests failed, 4 results missing
openQA tests matching unsatisfied gating requirements shown with **GATING** 
below

Failed openQA tests: 30/231 (x86_64), 22/161 (aarch64)

New failures (same test not failed in Fedora-Rawhide-20220524.n.0):

ID: 1277730 Test: x86_64 Workstation-live-iso install_default@uefi 
**GATING**
URL: https://openqa.fedoraproject.org/tests/1277730
ID: 1277763 Test: x86_64 KDE-live-iso desktop_login
URL: https://openqa.fedoraproject.org/tests/1277763
ID: 1277767 Test: x86_64 KDE-live-iso desktop_printing_builtin
URL: https://openqa.fedoraproject.org/tests/1277767
ID: 1277768 Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/1277768
ID: 122 Test: x86_64 KDE-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/122
ID: 128 Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/128
ID: 1277850 Test: aarch64 Server-dvd-iso server_cockpit_default@uefi
URL: https://openqa.fedoraproject.org/tests/1277850
ID: 1277855 Test: aarch64 Server-dvd-iso server_realmd_join_kickstart@uefi
URL: https://openqa.fedoraproject.org/tests/1277855
ID: 1277895 Test: x86_64 Workstation-upgrade upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/1277895
ID: 1277950 Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/1277950
ID: 1278081 Test: x86_64 Server-dvd-iso realmd_join_cockpit
URL: https://openqa.fedoraproject.org/tests/1278081
ID: 1278090 Test: aarch64 Workstation-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/1278090
ID: 1278124 Test: aarch64 universal install_kickstart_user_creation@uefi
URL: https://openqa.fedoraproject.org/tests/1278124

Old failures (same test failed in Fedora-Rawhide-20220524.n.0):

ID: 1277685 Test: x86_64 Server-dvd-iso install_vnc_server
URL: https://openqa.fedoraproject.org/tests/1277685
ID: 1277699 Test: x86_64 Server-dvd-iso install_blivet_btrfs_preserve_home
URL: https://openqa.fedoraproject.org/tests/1277699
ID: 1277718 Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/1277718
ID: 1277726 Test: x86_64 Everything-boot-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/1277726
ID: 1277731 Test: x86_64 Workstation-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/1277731
ID: 1277732 Test: x86_64 Workstation-live-iso install_default_upload 
**GATING**
URL: https://openqa.fedoraproject.org/tests/1277732
ID: 1277755 Test: x86_64 KDE-live-iso anaconda_help
URL: https://openqa.fedoraproject.org/tests/1277755
ID: 1277781 Test: x86_64 Silverblue-dvd_ostree-iso evince
URL: https://openqa.fedoraproject.org/tests/1277781
ID: 1277782 Test: x86_64 Silverblue-dvd_ostree-iso eog
URL: https://openqa.fedoraproject.org/tests/1277782
ID: 1277785 Test: x86_64 Silverblue-dvd_ostree-iso base_system_logging
URL: https://openqa.fedoraproject.org/tests/1277785
ID: 1277787 Test: x86_64 Silverblue-dvd_ostree-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/1277787
ID: 1277788 Test: x86_64 Silverblue-dvd_ostree-iso gnome_text_editor
URL: https://openqa.fedoraproject.org/tests/1277788
ID: 1277791 Test: x86_64 Silverblue-dvd_ostree-iso desktop_background
URL: https://openqa.fedoraproject.org/tests/1277791
ID: 1277820 Test: aarch64 Server-dvd-iso install_vncconnect_client@uefi
URL: https://openqa.fedoraproject.org/tests/1277820
ID: 1277821 Test: aarch64 Server-dvd-iso install_vncconnect_server@uefi
URL: https://openqa.fedoraproject.org/tests/1277821
ID: 1277822 Test: aarch64 Server-dvd-iso install_btrfs_preserve_home@uefi
URL: https://openqa.fedoraproject.org/tests/1277822
ID: 1277823 Test: aarch64 Server-dvd-iso 
install_btrfs_preserve_home_uefi@uefi
URL: https://openqa.fedoraproject.org/tests/1277823
ID: 1277917 Test: aarch64 Workstation-upgrade upgrade_desktop_64bit@uefi
URL: https://openqa.fedoraproject.org/tests/1277917
ID: 1277938 Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/1277938
ID: 1277956 Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/1277956
ID: 1277972 Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/1277972
ID: 1277988 Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/1277988
ID: 1277993 Test: x86_64 universal install_european_language
URL: https://openqa.fedoraproject.org/tests/1277993
ID: 1278008 Test: x86_64 universal upgrade_2_realmd_client
URL: https://openqa.fedoraproject.org/tests/1278008
ID: 1278011 Test

[Bug 2062024] [RFE: EPEL9] EPEL9 branch for perl-Proc-Daemon

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
FEDORA-EPEL-2022-ef9b294e1f has been pushed to the Fedora EPEL 9 testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-ef9b294e1f

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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2062024
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2086322] perlbrew-0.95 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Resolution|RAWHIDE |ERRATA
   Fixed In Version|perlbrew-0.95-1.fc37|perlbrew-0.95-1.fc37
   ||perlbrew-0.95-1.fc36



--- Comment #3 from Fedora Update System  ---
FEDORA-2022-a8548911e8 has been pushed to the Fedora 36 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=2086322
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2086331] perl-Modern-Perl-1.20220515 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Modern-Perl-1.20220515 |perl-Modern-Perl-1.20220515
   |-1.fc37 |-1.fc37
   |perl-Modern-Perl-1.20220515 |perl-Modern-Perl-1.20220515
   |-1.el9  |-1.el9
   ||perl-Modern-Perl-1.20220515
   ||-1.fc36



--- Comment #8 from Fedora Update System  ---
FEDORA-2022-2112f38983 has been pushed to the Fedora 36 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=2086331
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: python-passlib for python38 module

[Maxwell G via epel-devel]

On Tuesday, May 24, 2022 6:56:41 PM CDT Orion Poplawski wrote:
> Sure, except I know nothing about how docs.fp.o works ;)

The source code for the EPEL docs page is here[1]. Honestly, I'm not super 
familiar with it either :).

[1]: https://pagure.io/epel/tree/main

> It looks like it's hard-coded to python3dist, so I think it has to 
> change to %{py38_dist}.

I looked at the macros file on Fedora and saw that it was dynamic, but I was 
too lazy to look at an actual EL 8 system and notice it hadn't been backported 
;(. I opened https://bugzilla.redhat.com/show_bug.cgi?id=2090007. Let's see 
what the RHEL Python maintainers have to say... As far as I know, `%
{py38_dist}` doesn't exist at all.


-- 
Thanks,

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

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

[EPEL-devel] Re: SPDX identifiers in old branches?

[Maxwell G via epel-devel]

On Tuesday, May 24, 2022 7:08:13 PM CDT Gary Buhrmaster wrote:
> I don't think that is going to work unless the rpm spec
> file support would be backported to previous releases
> (without another macro that tries to do some magic).

I don't follow. What "rpm spec file support" are you referring to?

> And the goal for some of us is to have one spec file
> work across all currently supported releases.

I agree; divergent dist-git branches are a nuisance.

-- 
Thanks,

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

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

Re: SPDX identifiers in old branches?

[Maxwell G via devel]

On Tuesday, May 24, 2022 7:08:13 PM CDT Gary Buhrmaster wrote:
> I don't think that is going to work unless the rpm spec
> file support would be backported to previous releases
> (without another macro that tries to do some magic).

I don't follow. What "rpm spec file support" are you referring to?

> And the goal for some of us is to have one spec file
> work across all currently supported releases.

I agree; divergent dist-git branches are a nuisance.

-- 
Thanks,

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

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

Re: SPDX identifiers in old branches?

[Miro Hrončok]

On 24. 05. 22 22:11, Miroslav Suchý wrote:

As reaction to

   https://fedoraproject.org/wiki/Changes/SPDX_Licenses_Phase_1

there were two similar feedbacks:

* maintainer of package wants to use SPDX in both new and old branches 
(including f36, epel7...)


* Bodhi cannot recognize old short names in old branches and new SPDX formulas 
in new branches.


The thing with Bodhi is that once an update is created, then a message is 
emitted and rpminspect checks the license (among other things) and adds a good 
or bad stamp. It is only a warning for the maintainer and cannot stop the 
update itself.


We (the proposal owners) agreed that rpminspect will be altered (if the change 
will be approved) to accept both old short names and new SPDX identifiers. In 
all branches.


And the Packaging Guidelines will be altered that in old active branches you 
may use either the old shortname or the new SPDX identifiers. What will better 
work for you.


We see no reason why not to do that. It should not cause any harm. If **you** 
know of any reason we should not propose this, please tell us now.


The theoretical problems I could think of:


1) It will be a weird mixture. Some packages will say Apache-2.0, some will say 
ASL 2.0. Some will use and/or, some AND/OR. It won't be consistent.



2) There are tags that might mean slightly different things in each notation. 
E.g. MIT. Is this package licensed with the SPDX MIT? Or is it a old-style MIT 
that might mean different SPDX notation? Note that the old-style MIT seems to 
be a superset of SPDX MIT, so this isn't probably getting worse than it is, 
it's just a tad confusing.



3) Existing software in the wild other than rpminspect might make assumptions 
about the format and suddenly, we are pushing "bacward-incompatible" metadata. 
This can confuse such software.



4) Existing software in the wild other than rpminspect might report "the 
license tag has changed, please inspect" and users who care about those sort of 
things might get a big amount of such reports to manually verify, possibly for 
many years ahead (in EPEL).



I personally consider all 4 of them acceptable.

--
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2086331] perl-Modern-Perl-1.20220515 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Modern-Perl-1.20220515 |perl-Modern-Perl-1.20220515
   |-1.fc37 |-1.fc37
   ||perl-Modern-Perl-1.20220515
   ||-1.el9
 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA
Last Closed||2022-05-25 00:31:35



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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2086331
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: SPDX identifiers in old branches?

[Chris Adams]

Once upon a time, Gary Buhrmaster  said:
> On Tue, May 24, 2022 at 11:29 PM Chris Adams  wrote:
> > Would it make sense to make ALL the new tags be SPDX:, at least for
> > an interim period (of years most likely) where both old and new tags are
> > allowed?
> 
> I don't think that is going to work unless the rpm spec
> file support would be backported to previous releases
> (without another macro that tries to do some magic).
> And the goal for some of us is to have one spec file
> work across all currently supported releases.

I'm not talking about a new tag or format, just literally making the
License: tag be "SPDX:".
-- 
Chris Adams 
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: SPDX identifiers in old branches?

[Chris Adams]

Once upon a time, Gary Buhrmaster  said:
> On Tue, May 24, 2022 at 11:29 PM Chris Adams  wrote:
> > Would it make sense to make ALL the new tags be SPDX:, at least for
> > an interim period (of years most likely) where both old and new tags are
> > allowed?
> 
> I don't think that is going to work unless the rpm spec
> file support would be backported to previous releases
> (without another macro that tries to do some magic).
> And the goal for some of us is to have one spec file
> work across all currently supported releases.

I'm not talking about a new tag or format, just literally making the
License: tag be "SPDX:".
-- 
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: python-passlib for python38 module

[Miro Hrončok]

On 25. 05. 22 1:56, Orion Poplawski wrote:



== Issues ==
* How to handle %{py3_dist} macro?


I believe `%{py3_dist}` works properly if you add `%global python3_pkgversion
3X`.


It looks like it's hard-coded to python3dist, so I think it has to change to 
%{py38_dist}.


That could (should?) be fixed by either redefining the macro in each 
python3X-rpm-macros or by changing the macro in python-srpm-macros to use 
%python3_pkgversion value -- that would require some "guess-work" where to put 
the dot, but I suppose the logic won't be that convoluted:


 * 3 -> python3dist
 * 3X -> python3.Xdist
 * 3XY -> python3.XYdist
 * 3.X -> python3.Xdist
 * 3.Y -> python3.XYdist
 * anything else -> blow up?

That reminds me https://bugzilla.redhat.com/show_bug.cgi?id=1812665 which was 
fixed incorrectly in RHEL 7 but a followup was never opened.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: SPDX identifiers in old branches?

[Gary Buhrmaster]

On Tue, May 24, 2022 at 11:29 PM Chris Adams  wrote:

> Would it make sense to make ALL the new tags be SPDX:, at least for
> an interim period (of years most likely) where both old and new tags are
> allowed?

I don't think that is going to work unless the rpm spec
file support would be backported to previous releases
(without another macro that tries to do some magic).
And the goal for some of us is to have one spec file
work across all currently supported releases.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: SPDX identifiers in old branches?

[Gary Buhrmaster]

On Tue, May 24, 2022 at 11:29 PM Chris Adams  wrote:

> Would it make sense to make ALL the new tags be SPDX:, at least for
> an interim period (of years most likely) where both old and new tags are
> allowed?

I don't think that is going to work unless the rpm spec
file support would be backported to previous releases
(without another macro that tries to do some magic).
And the goal for some of us is to have one spec file
work across all currently supported releases.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: python-passlib for python38 module

[Orion Poplawski]

On 5/24/22 11:53, Maxwell G via epel-devel wrote:

On Monday, May 23, 2022 11:18:38 PM CDT Orion Poplawski wrote:

I've been coming to the thinking that naming the SRPMS
python3X-%{srcname}-epel is a better choice. This makes modifying
original Fedora specs simpler.


I think that makes sense, especially considering that these packages will not
be built for Fedora.


Right - that's the other help hopefully to reduce bugzilla issues filed 
against the wrong component.



See https://fedoraproject.org/wiki/EPEL/Python3X


Here is some feedback:

First, aren't we trying to move off the wiki? Wouldn't this be a better
candidate for the EPEL docs on docs.fp.o?


Sure, except I know nothing about how docs.fp.o works ;)


separate Python 3 minor versions in EPEL 8 are packaged as separate python3X
(currently python38) packages to allow for independent versions for each
Python version.


There is also python39.


egads.  added.


== Issues ==
* How to handle %{py3_dist} macro?


I believe `%{py3_dist}` works properly if you add `%global python3_pkgversion
3X`.


It looks like it's hard-coded to python3dist, so I think it has to 
change to %{py38_dist}.



When I built ansible-5 for Python 3.8, I just ran `:%s python3-/python%
{python3_pkgversion}-/` and added `%global python3_pkgversion 38`. `%
{python3_pkgversion}` is set to 3
by default. I would recommend doing that in your example instead of hardcoding
`python38`.


Yeah, I think maybe a sed script is in order.




== Example Spec ==



[...]

%global sum An example python module


I don't think there's any point to have a %sum macro when you can use `%
{summary}` in subpackage definitions. Admittedly, this is more of a packaging
nitpick than a comment related to the issue at hand :D.


%global __python3 /usr/bin/python3.8


I think it's better to add `Requires: python%{python3_pkgversion}-rpm-macros`.
To be fair, they both do effectively the same thing: set %__python3 to the
correct value. In any case, I submitted https://src.fedoraproject.org/rpms/
epel-rpm-macros/pull-request/44 so neither should be necessary.


%check
%{__python3} setup.py test


I was going to suggest using `%pytest`, but then I remembered that https://
pagure.io/releng/issue/10679 is still outstanding :(.


%files -n python38-%{srcname}

[...]

%{python3_sitelib}/*

Globs like this are against the Python Packaging Guidelines.


True.  Fixed.

Thanks.


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


smime.p7s
Description: S/MIME Cryptographic Signature
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: SPDX identifiers in old branches?

[Chris Adams]

Once upon a time, Maxwell G via devel  said:
> I already brought this up previously, but how will we handle license 
> identifiers such as MIT that are valid in both SPDX and Fedora but have 
> different meanings? We won't know whether it's specifically referring to the 
> MIT/Expat License (SPDX) or a group of MIT-like licenses (Fedora) and we 
> won't 
> be able to tell which specfiles have been converted to use SPDX identifiers 
> and 
> which haven't.

Would it make sense to make ALL the new tags be SPDX:, at least for
an interim period (of years most likely) where both old and new tags are
allowed?
-- 
Chris Adams 
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: SPDX identifiers in old branches?

[Chris Adams]

Once upon a time, Maxwell G via devel  said:
> I already brought this up previously, but how will we handle license 
> identifiers such as MIT that are valid in both SPDX and Fedora but have 
> different meanings? We won't know whether it's specifically referring to the 
> MIT/Expat License (SPDX) or a group of MIT-like licenses (Fedora) and we 
> won't 
> be able to tell which specfiles have been converted to use SPDX identifiers 
> and 
> which haven't.

Would it make sense to make ALL the new tags be SPDX:, at least for
an interim period (of years most likely) where both old and new tags are
allowed?
-- 
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2089997] New: perl-CPAN-FindDependencies-3.13 is available

[bugzilla]

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

Bug ID: 2089997
   Summary: perl-CPAN-FindDependencies-3.13 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-CPAN-FindDependencies
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: cicku...@gmail.com, jples...@redhat.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 3.13
Current version/release in rawhide: 3.12-1.fc37
URL: http://search.cpan.org/dist/CPAN-FindDependencies/

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


More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring


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


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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2089997
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: SPDX identifiers in old branches?

[Maxwell G via epel-devel]

On Tuesday, May 24, 2022 3:11:39 PM CDT Miroslav Suchý wrote:
> We see no reason why not to do that. It should not cause any harm. If 
**you** know of any reason we should not propose 
> this, please tell us now.

I already brought this up previously, but how will we handle license 
identifiers such as MIT that are valid in both SPDX and Fedora but have 
different meanings? We won't know whether it's specifically referring to the 
MIT/Expat License (SPDX) or a group of MIT-like licenses (Fedora) and we won't 
be able to tell which specfiles have been converted to use SPDX identifiers and 
which haven't.

From the Change Proposal:

> * Convert license string to SPDX formula:
> $ license-fedora2spdx 'MIT or GPLv1'
>
> Warning: more options how to interpret MIT. Possible options:
> ['Adobe-Glyph', 'MIT-CMU', 'MIT-CMU', 'HPND', 'HPND', 'no-spdx-yet
> (MIT license (also X11))', 'SGI-B-2.0', 'SGI-B-2.0', 'SMLNJ',
> 'MIT-enna', 'MIT-feh', 'mpich2']
>
> mpich2 or GPL-1.0-only

-- 
Thanks,

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

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

Re: SPDX identifiers in old branches?

[Maxwell G via devel]

On Tuesday, May 24, 2022 3:11:39 PM CDT Miroslav Suchý wrote:
> We see no reason why not to do that. It should not cause any harm. If 
**you** know of any reason we should not propose 
> this, please tell us now.

I already brought this up previously, but how will we handle license 
identifiers such as MIT that are valid in both SPDX and Fedora but have 
different meanings? We won't know whether it's specifically referring to the 
MIT/Expat License (SPDX) or a group of MIT-like licenses (Fedora) and we won't 
be able to tell which specfiles have been converted to use SPDX identifiers and 
which haven't.

From the Change Proposal:

> * Convert license string to SPDX formula:
> $ license-fedora2spdx 'MIT or GPLv1'
>
> Warning: more options how to interpret MIT. Possible options:
> ['Adobe-Glyph', 'MIT-CMU', 'MIT-CMU', 'HPND', 'HPND', 'no-spdx-yet
> (MIT license (also X11))', 'SGI-B-2.0', 'SGI-B-2.0', 'SMLNJ',
> 'MIT-enna', 'MIT-feh', 'mpich2']
>
> mpich2 or GPL-1.0-only

-- 
Thanks,

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

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

Fedora rawhide compose report: 20220524.n.1 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20220524.n.0
NEW: Fedora-Rawhide-20220524.n.1

= SUMMARY =
Added images:0
Dropped images:  0
Added packages:  0
Dropped packages:0
Upgraded packages:   43
Downgraded packages: 0

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

Size change of upgraded packages:   -109.13 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  anaconda-37.9-1.fc37
Old package:  anaconda-37.8-1.fc37
Summary:  Graphical system installer
RPMs: anaconda anaconda-core anaconda-dracut anaconda-gui 
anaconda-install-env-deps anaconda-install-img-deps anaconda-live anaconda-tui 
anaconda-widgets anaconda-widgets-devel
Size: 16.01 MiB
Size change:  608 B
Changelog:
  * Tue May 24 2022 Packit  - 37.9-1
  - Use the IsRootAccountLocked property (vponcova)
  - Web UI: Fix strings (vponcova)


Package:  apitrace-11.1-1.fc37
Old package:  apitrace-11.0-0.fc37
Summary:  Tools for tracing OpenGL
RPMs: apitrace apitrace-gui apitrace-libs
Size: 15.63 MiB
Size change:  -11.57 KiB
Changelog:
  * Tue May 24 2022 Sandro Mani  - 11.1-1
  - Update to 11.1


Package:  awscli-1.24.6-1.fc37
Old package:  awscli-1.24.5-1.fc37
Summary:  Universal Command Line Environment for AWS
RPMs: awscli
Size: 2.17 MiB
Size change:  -84 B
Changelog:
  * Mon May 23 2022 Gwyn Ciesla  - 1.24.6-1
  - 1.24.6


Package:  binutils-2.38-12.fc37
Old package:  binutils-2.38-11.fc37
Summary:  A GNU collection of binary utilities
RPMs: binutils binutils-devel binutils-gold
Size: 74.10 MiB
Size change:  9.26 KiB
Changelog:
  * Tue May 24 2022 Nick Clifton   - 2.38-12
  - x86 linker: Disallow invalid relocations against protected symbols.  
(#2089358)


Package:  cockpit-270-1.fc37
Old package:  cockpit-269-1.fc37
Summary:  Web Console for Linux servers
RPMs: cockpit cockpit-bridge cockpit-doc cockpit-kdump 
cockpit-networkmanager cockpit-packagekit cockpit-pcp cockpit-selinux 
cockpit-sosreport cockpit-storaged cockpit-system cockpit-tests cockpit-ws
Size: 13.98 MiB
Size change:  211.61 KiB
Changelog:
  * Tue May 24 2022 Packit  - 270-1
  - Services: User-created timer deletion
  - System Diagnostics: Working with diagnostic reports has been improved


Package:  cockpit-machines-269-1.fc37
Old package:  cockpit-machines-268-1.fc37
Summary:  Cockpit user interface for virtual machines
RPMs: cockpit-machines
Size: 790.85 KiB
Size change:  2.33 KiB
Changelog:
  * Tue May 24 2022 Marius Vollmer  - 269-1
  - Machines: Redesign content removal dialogs


Package:  container-selinux-2:2.186.0-1.fc37
Old package:  container-selinux-2:2.183.0-4.fc37
Summary:  SELinux policies for container runtimes
RPMs: container-selinux
Size: 51.50 KiB
Size change:  2.36 KiB
Changelog:
  * Tue May 24 2022 RH Container Bot  
2:2.186.0-1
  - auto bump to v2.186.0


Package:  doctl-1.76.0-1.fc37
Old package:  doctl-1.75.0-1.fc37
Summary:  The official command line interface for the DigitalOcean API
RPMs: doctl golang-github-digitalocean-doctl-devel
Size: 20.20 MiB
Size change:  39.58 KiB
Changelog:
  * Tue May 24 2022 Mikel Olasagasti Uranga  1.76.0-1
  - Update to 1.76.0 - Closes rhbz#2089560


Package:  dummy-test-package-gloster-0-8778.fc37
Old package:  dummy-test-package-gloster-0-8770.fc37
Summary:  Dummy Test Package called Gloster
RPMs: dummy-test-package-gloster
Size: 498.08 KiB
Size change:  479 B
Changelog:
  * Tue May 24 2022 packagerbot  - 0-8771
  - rebuilt

  * Tue May 24 2022 packagerbot  - 0-8772
  - rebuilt

  * Tue May 24 2022 packagerbot  - 0-8773
  - rebuilt

  * Tue May 24 2022 packagerbot  - 0-8774
  - rebuilt

  * Tue May 24 2022 packagerbot  - 0-8775
  - rebuilt

  * Tue May 24 2022 packagerbot  - 0-8776
  - rebuilt

  * Tue May 24 2022 packagerbot  - 0-8777
  - rebuilt

  * Tue May 24 2022 packagerbot  - 0-8778
  - rebuilt


Package:  flexiblas-3.2.0-3.fc37
Old package:  flexiblas-3.2.0-2.fc37
Summary:  A BLAS/LAPACK wrapper library with runtime exchangeable backends
RPMs: flexiblas flexiblas-atlas flexiblas-blis-openmp 
flexiblas-blis-openmp64 flexiblas-blis-serial flexiblas-blis-serial64 
flexiblas-blis-threads flexiblas-blis-threads64 flexiblas-devel 
flexiblas-hook-profile flexiblas-hook-profile64 flexiblas-netlib 
flexiblas-netlib64 flexiblas-openblas-openmp flexiblas-openblas-openmp64 
flexiblas-openblas-serial flexiblas-openblas-serial64 
flexiblas-openblas-threads flexiblas-openblas-threads64
Size: 28.24 MiB
Size change:  8.54 KiB
Changelog:
  * Tue May 24 2022 I??aki ??car  - 3.2.0-3
  - Add explicit requires to devel package to content rpmdeps test


Package

Re: F37 proposal: Enhance Persian Font Support (Self-Contained Change proposal)

[Hedayat Vatankhah]

On ۱۴۰۱/۳/۲ ۱۱:۵۵ بعدازظهر, Sebastian Crane wrote:

As something of a typography enthusiast, I'm very much in support of
this. For English, the consistent fonts on Fedora Workstation make a
noticeable and positive effect on the general aesthetic, so anything
that can widen that benefit would be advantageous.


Yeah, inconsistency makes the experience really annoying.



I did notice that the 'How to Test' section of the proposal was empty;
just as a suggestion, please could we have some screenshots of the
main Persian fonts used in Fedora currently? I'm mostly just curious,
but it might be useful for testing to see whether the changes are
successfully reflected in all desktop applications - especially for
people like me, who can't (yet!) read the Persian alphabet.


Sure, I'll add screenshots of the current state in F36 and the target 
state. Although, I'm not sure if I'd be able to do anything for 
Firefox/Thunderbird inconsistency problem [1]; but at least the current 
state will be improved significantly.






Best wishes,

Sebastian


Thanks,

Hedayat


[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1770662
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 proposal: Enhance Persian Font Support (Self-Contained Change proposal)

[Hedayat Vatankhah]

On ۱۴۰۱/۳/۲ ۹:۰۲ بعدازظهر, Michael Catanzaro wrote:
On Mon, May 23 2022 at 11:54:30 AM -0400, Ben Cotton 
 wrote:

Default Persian font will be changed automatically on upgrades.


Good, but how will you achieve this? We finally noticed that noto 
fonts don't get installed when upgrading F35 -> F36 and should avoid 
making the same mistake again. ...




Good point. I should confess that I'm unaware of what happened for Noto 
fonts. And I thought updating langpacks-core-font-fa package dependency 
should suffice for upgrades to automatically install the new font; 
assuming that the user already has it. But now you made me doubt that 
assumption.



Thanks,

Hedayat

___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: SPDX identifiers in old branches?

[Gary Buhrmaster]

On Tue, May 24, 2022 at 8:11 PM Miroslav Suchý  wrote:

> And the Packaging Guidelines will be altered that in old active branches you 
> may use either the old shortname or the new
> SPDX identifiers. What will better work for you.
>
> We see no reason why not to do that. It should not cause any harm. If **you** 
> know of any reason we should not propose
> this, please tell us now.

This seems perfectly acceptable (and reasonable) to me.

Thanks for getting this done.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: PSA: I am not getting all email from Fedora, reach me directly if you need me

[Kevin Fenzi]

On Tue, May 24, 2022 at 07:08:00PM +0200, Miro Hrončok wrote:
> Hello Fedorans,
> 
> this is a just a heads up: If I ignored your question in a Pagure issue, or
> your pull request, possibly haven't replied to your bugzilla report or a
> devel thread... it's because my email is broken and I don't get some (many)
> Fedora emails. Other colleagues from Red Hat report the same.
> 
> https://pagure.io/fedora-infrastructure/issue/10705
> 
> Feel free to email me directly (hope that actually works) or better reach me
> out at Matrix/IRC with a link to the message that requires my attention.
> 
> Sorry about that.

Yeah, I am sorry as well. ;( 

I _think_ everything is back to working except for one path now. 
(the case of a redhat.com address mailing a fedoraproject.org alias with
gmail or some host that filters email based on SPF record. In that case
the emails are rejected currently. I have a internal ticket on that
pending)

kevin


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

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

[Kevin Fenzi]

On Tue, May 24, 2022 at 04:57:54PM +0200, Jiri Vanek wrote:
> 
> We are testing also upstream. note that RH is maintainer of ojdk 11 and 8,
> so we have to.  But that is much easier, as the usptream is static within
> intree libraries. And we have to run also for 17 and 18/19 as we need this
> reference run, to be sure that downstream is guilty, not vanilla jdk. Thus
> we test the (source x build) just once.  And we can test the binary on some
> known system where we always pass.

Well, I meant test the _dynamic_ build that Fedora does now...

> But in downstream, new issues usually appear due to the dynamic linking and
> nature of system where only it can be installed. Also for dowstram, each
> sources are built N times, so N times tested in thsoe N systems - usually
> each with its psecific failures.
> 
> > 
> > Could we integrate the TCK testing in our CI to save you overhead of
> > managing submitting, etc? Or where is the most time spent in this
> > workflow?
> 
> As I described in another reply, it is both human and hw. Hw to run all those 
> swarm of builds on all platforms, and humans to verify the issue and to fix 
> it.
> TCK are very complex, and you need at least three machines in distributed 
> system to run them. At least two of those slaves are not trivial (krb master 
> and system where tck are running).
> Generally saying, I have autoamtion to prepare that all, but second part is 
> reproducibility. If the "non mine" setup run will fail for some reason, can I 
> rerun it? Can I debug it? I'm finding this very hard in 3rd party hw clusters.

Would it help to have some cloud resources to do this in? 
We could definitely get you access to some ec2 instances to setup a test
cluster for testing fedora builds. 

> > I know others have suggested fewer openjdk streams to reduce workload,
> > but I didn't see any reply on that from change owners.
> > 
> 
> I replied it already in that thread, but happy to repeat:
> It will help, but less then it seems so.
> Now we can drop 8. Soem legacy applciations will be unhappy, as EOL of jdk8 
> is in some 4 years, so fedora will suffer a bit. But it will be nice 12 TCK 
> runs down.
> but we can not droop 11, as it is system jdk in f35
> Similarly, we couldn't introduce fresh jdk17 directly to f36 as system JDK. 
> It needs it time to be tuned before being proposed as system jdk.
> And we can not drop java-latest-openjdk, becasue it is necessary to boot next 
> system JDK.
> Yes, in 8 months, we would be able to drop 11. And live for 1 year only on 
> latest and 17. Which is putting load for one year to 1/2. But the cost of not 
> having 11 (and 8) will be felt by fedora users more, then having static jdk 
> from repos.
> Unluckily, with new future system jdk, we will need to boostrap it by latest, 
> keep it as secondary jdk at least for one , better two, fedora cycles, so 
> again we will be in 3  jdks x 3 systems.
> Sure, we do not need to backport newest future system jdk to older fedoras, 
> but usually the users want us to do so. tbh, I do not have strong preference 
> on it. it is like 51 for backport, and 49 for not. Even with knwoledge of TCK 
> burden.
> 
> If currently we have 4 jdks on 3 fedoras with 3 primary architectures=> 36 TCK
> With this shortage, we would have
> 2 jdks on 2 fedoras with 3 primary architectures=> 12 tck in minimum. That 
> sound like a reasonable drop, but only for very short period of time, duriong 
> which we will nee to have capcity reserved for ppreparation of next
> system jdk: 3 jdks on 3 fedoras with 3 primary architectures=>  27 avarage, 
> With much more stress about possible integration issues and with - imo(!) - 
> considerable negative imapct to fedora.

ok, sorry I missed a previous reply on this. ;) 

So, what would you then think about just:

1. having some cloud resources to setup a tck test env that you could
manage better than some ci somewhere and use to test fedora builds.
and
2. switching fedora to the static system libraries so you didn't need to
keep the dynamic ones in sync.

but then trying to see if that reduces your workload to a sustainable
level and avoid the 'build once, certify' thing that is going to end up
being a lot of trouble. 

kevin


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

[EPEL-devel] Fwd: SPDX identifiers in old branches?

[Miroslav Suchý]

Forwarded here as it will affect old epel branches.


 Přeposlaná zpráva 
Předmět:SPDX identifiers in old branches?
Datum:  Tue, 24 May 2022 22:11:39 +0200
Od: Miroslav Suchý 
Společnost: Red Hat Czech, s.r.o.
Komu:   Development discussions related to Fedora 




As reaction to

https://fedoraproject.org/wiki/Changes/SPDX_Licenses_Phase_1

there were two similar feedbacks:

* maintainer of package wants to use SPDX in both new and old branches 
(including f36, epel7...)

* Bodhi cannot recognize old short names in old branches and new SPDX formulas 
in new branches.

The thing with Bodhi is that once an update is created, then a message is emitted and rpminspect checks the license 
(among other things) and adds a good or bad stamp. It is only a warning for the maintainer and cannot stop the update 
itself.


We (the proposal owners) agreed that rpminspect will be altered (if the change will be approved) to accept both old 
short names and new SPDX identifiers. In all branches.


And the Packaging Guidelines will be altered that in old active branches you may use either the old shortname or the new 
SPDX identifiers. What will better work for you.


We see no reason why not to do that. It should not cause any harm. If **you** know of any reason we should not propose 
this, please tell us now.


Miroslav
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

SPDX identifiers in old branches?

[Miroslav Suchý]

As reaction to

  https://fedoraproject.org/wiki/Changes/SPDX_Licenses_Phase_1

there were two similar feedbacks:

* maintainer of package wants to use SPDX in both new and old branches 
(including f36, epel7...)

* Bodhi cannot recognize old short names in old branches and new SPDX formulas 
in new branches.

The thing with Bodhi is that once an update is created, then a message is emitted and rpminspect checks the license 
(among other things) and adds a good or bad stamp. It is only a warning for the maintainer and cannot stop the update 
itself.


We (the proposal owners) agreed that rpminspect will be altered (if the change will be approved) to accept both old 
short names and new SPDX identifiers. In all branches.


And the Packaging Guidelines will be altered that in old active branches you may use either the old shortname or the new 
SPDX identifiers. What will better work for you.


We see no reason why not to do that. It should not cause any harm. If **you** know of any reason we should not propose 
this, please tell us now.


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

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

[Fabio Valentini]

On Tue, May 24, 2022 at 5:03 PM Jiri Vanek  wrote:
> I replied it already in that thread, but happy to repeat:
> It will help, but less then it seems so.
> Now we can drop 8. Soem legacy applciations will be unhappy, as EOL of jdk8 
> is in some 4 years, so fedora will suffer a bit. But it will be nice 12 TCK 
> runs down.
> but we can not droop 11, as it is system jdk in f35
> Similarly, we couldn't introduce fresh jdk17 directly to f36 as system JDK. 
> It needs it time to be tuned before being proposed as system jdk.
> And we can not drop java-latest-openjdk, becasue it is necessary to boot next 
> system JDK.
> Yes, in 8 months, we would be able to drop 11. And live for 1 year only on 
> latest and 17. Which is putting load for one year to 1/2. But the cost of not 
> having 11 (and 8) will be felt by fedora users more, then having static jdk 
> from repos.
> Unluckily, with new future system jdk, we will need to boostrap it by latest, 
> keep it as secondary jdk at least for one , better two, fedora cycles, so 
> again we will be in 3  jdks x 3 systems.
> Sure, we do not need to backport newest future system jdk to older fedoras, 
> but usually the users want us to do so. tbh, I do not have strong preference 
> on it. it is like 51 for backport, and 49 for not. Even with knwoledge of TCK 
> burden.

Is this based on user requests, or is this only what you *think* users
of OpenJDK on Fedora need?
Speaking for myself, I have never used anything other than the default
"system JDK" for running Java applications on Fedora.

What would you think about the following scenario:

- Fedora X defaults to new OpenJDK LTS N
- Fedora X keeps OpenJDK LTS N-1 so it's possible to revert the change
- Fedora X+1 drops OpenJDK N-1, since the newer OpenJDK N was already
the default for one release
- do not backport OpenJDK n to Fedora X-1 and X-2
- keep java-latest-openjdk, as you seen to need this for bootstrapping
new OpenJDK releases

You could even drop java-latest-openjdk from all branches but rawhide,
since it's only needed for bootstrapping there.
This should pretty dramatically reduce the size of your test matrix.
Applying the current numbers:

- Fedora Rawhide: java-17-openjdk (default), java-latest-openjdk
- Fedora 36: java-17-openjdk (default), java-11-openjdk (in case the
default needs to be switched back), java-latest-openjdk
- Fedora 35: java-11-openjdk, java-latest-openjdk

> With much more stress about possible integration issues and with - imo(!) - 
> considerable negative imapct to fedora.

Would this reduced set of supported OpenJDK versions, but keeping the
"latest" version, address this "considerable negative impact"?

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

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

[Vitaly Zaitsev via devel]

On 24/05/2022 21:00, Jiri Vanek wrote:
I repeat what was told several times.We really do no t like this change, 
especially in its full sound of one static build repacked to all ive 
fedoras, but we have nto found a better way.


1. Stop doing TCK certification. Most Fedora OpenJDK users don't need 
certified binaries. All they need is a working and well packaged OpenJDK.


2. Reduce the number of OpenJDK branches in the repositories. I think 
the latest LTS version will be enough.


--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2062024] [RFE: EPEL9] EPEL9 branch for perl-Proc-Daemon

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



--- Comment #2 from Fedora Update System  ---
FEDORA-EPEL-2022-ef9b294e1f has been submitted as an update to Fedora EPEL 9.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-ef9b294e1f


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2062024
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Interested in an updated "Exploring Our Bugs" talk at Nest?

[Ben Cotton]

At Nest With Fedora last year, I presented a talk called "Exploring
Our Bugs"[1]. In this talk, I took a look at some summary data about
Fedora Linux bugs since F19. I'm considering proposing this for Nest
2022. The new talk would mostly be an update with bugs up through F34,
but if there were particular topics to dig into, I'm open to
suggestions.

If there's something that last year's talk left unanswered that you
want me to dig into, please let me know off-list.

[1] https://www.youtube.com/watch?v=k9NWVYTXj_I

-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

[Jiri Vanek]

On 5/24/22 18:37, Vitaly Zaitsev via devel wrote:

On 24/05/2022 16:31, Jiri Vanek wrote:

The goal is to go as shim and cisco - to build in koji, certify, and repack.


shim and openh264 have a good reason for this - legal issues. OpenJDK doesn't. 
Sorry, but I can't treat the laziness of the maintainers as a good reason.


Even if you woulf call 10 years of 5 engineers to keep dynamic builds (and 
generlay jdk in Fedora) alivem, tt had become human-impossible  to continue in 
current way of things.
It will lead to lost of JDK or heavy rework of how JDK s handled now

I repeat what was told several times.We really do no t like this change, 
especially in its full sound of one static build repacked to all ive fedoras, 
but we have nto found a better way.

Really sorry,
  J.




--
Jiri Vanek Mgr.
Principal QA Software Engineer
Red Hat Inc.
+420 775 39 01 09
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

[Demi Marie Obenour]

On 5/24/22 10:57, Jiri Vanek wrote:
> 
> 
> On 5/23/22 20:40, Kevin Fenzi wrote:
>> So, just replying here since this is a nice monster of a thread. ;(
>>
>> First, just to clear up some previous coments, shim does build against
>> the oldest stable Fedora in koji and then is manually tagged into newer
>> ones. This is not at all a good process. It only gets a bodhi update for
>> the one release (and sometimes not even that), so it never gets good
>> testing. It requires manual intervention from releng each time there's
>> an update. I think the only reason this has kept going is that shim is
>> very small and simple and updates rarely. If we need to do this for tons
>> of openjdk updates, we really should revisit the process, although I am
>> not sure how to make it more open to testing and less a burden on
>> releng. ;(
> 
> Thanx for bringing up additional details!
>>
>> Next, My understanding of the current process for openjdks (openjdki?):
>>
>> for each openjdk:
>>
>> Build dyanmically linking against system libraries in all fedoras.
>> Submit to TCK and wait for them all to process.
>> Fix any TCK failures and repeat
>> Once there's no failures, push the builds to updates
>>
>> Is that right? And keeping the dynamic builds passing is taking more
>> cycles than you have to give for the number of jdks?
> 
> super correct.
> 
>>
>> What about the possibility of adding CI _upstream_ to test against the
>> dynamic version? Then TCK failures would be caught upstream and not
>> downstream where it's a lot of work for you to fix?
> 
> We are testing also upstream. note that RH is maintainer of ojdk 11 and 8, so 
> we have to.  But that is much easier, as the usptream is static within intree 
> libraries. And we have to run also for 17 and 18/19 as we need this reference 
> run, 
> to be sure that downstream is guilty, not vanilla jdk. Thus we test the 
> (source x build) just once.  And we can test the binary on some known system 
> where we always pass.
> But in downstream, new issues usually appear due to the dynamic linking and 
> nature of system where only it can be installed. Also for dowstram, each 
> sources are built N times, so N times tested in thsoe N systems - usually 
> each with its 
> psecific failures.

Kevin’s suggestion is for upstream to test dynamic builds, not just
static ones, in its CI.  That means that if the dynamic build breaks,
it would be upstream’s problem.

In other words: Instead of shipping a static JDK in Fedora, make the
dynamic JDK a first-class citizen upstream.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: python-passlib for python38 module

[Maxwell G via epel-devel]

On Monday, May 23, 2022 11:18:38 PM CDT Orion Poplawski wrote:
> I've been coming to the thinking that naming the SRPMS 
> python3X-%{srcname}-epel is a better choice. This makes modifying 
> original Fedora specs simpler. 

I think that makes sense, especially considering that these packages will not 
be built for Fedora.

> See https://fedoraproject.org/wiki/EPEL/Python3X

Here is some feedback:

First, aren't we trying to move off the wiki? Wouldn't this be a better 
candidate for the EPEL docs on docs.fp.o?

> separate Python 3 minor versions in EPEL 8 are packaged as separate python3X 
> (currently python38) packages to allow for independent versions for each
> Python version. 

There is also python39.

> == Issues ==
> * How to handle %{py3_dist} macro?

I believe `%{py3_dist}` works properly if you add `%global python3_pkgversion 
3X`.

When I built ansible-5 for Python 3.8, I just ran `:%s python3-/python%
{python3_pkgversion}-/` and added `%global python3_pkgversion 38`. `%
{python3_pkgversion}` is set to 3 
by default. I would recommend doing that in your example instead of hardcoding 
`python38`.

> == Example Spec ==
> 
> 
[...]
> %global sum An example python module

I don't think there's any point to have a %sum macro when you can use `%
{summary}` in subpackage definitions. Admittedly, this is more of a packaging 
nitpick than a comment related to the issue at hand :D.

> %global __python3 /usr/bin/python3.8

I think it's better to add `Requires: python%{python3_pkgversion}-rpm-macros`. 
To be fair, they both do effectively the same thing: set %__python3 to the 
correct value. In any case, I submitted https://src.fedoraproject.org/rpms/
epel-rpm-macros/pull-request/44 so neither should be necessary.

> %check
> %{__python3} setup.py test

I was going to suggest using `%pytest`, but then I remembered that https://
pagure.io/releng/issue/10679 is still outstanding :(.

> %files -n python38-%{srcname}
[...]
> %{python3_sitelib}/*
Globs like this are against the Python Packaging Guidelines.

-- 
Thanks,

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

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

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

[Chris Adams]

Once upon a time, Vitaly Zaitsev  said:
> Sorry, but I can't treat the laziness of the
> maintainers as a good reason.

Can you PLEASE stop with the personal attacks?
-- 
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

PSA: I am not getting all email from Fedora, reach me directly if you need me

[Miro Hrončok]

Hello Fedorans,

this is a just a heads up: If I ignored your question in a Pagure issue, or 
your pull request, possibly haven't replied to your bugzilla report or a devel 
thread... it's because my email is broken and I don't get some (many) Fedora 
emails. Other colleagues from Red Hat report the same.


https://pagure.io/fedora-infrastructure/issue/10705

Feel free to email me directly (hope that actually works) or better reach me 
out at Matrix/IRC with a link to the message that requires my attention.


Sorry about that.

--
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

pghmcfc pushed to perl-MCE-Shared (rawhide). "Update to 1.877 (..more)"

[notifications]

Notification time stamped 2022-05-24 12:13:06 UTC

From afac8becb69640cd16f0b39f794ce3c72ceafafa Mon Sep 17 00:00:00 2001
From: Paul Howarth 
Date: May 24 2022 12:11:27 +
Subject: Update to 1.877


- New upstream release 1.877
  - Replace http with https in documentation and meta files
  - Call PDL::set_autopthread_targ(1); disables PDL auto-threading
  - Allow sharing additional PDL objects via class methods: pdl_sbyte,
pdl_ulong, pdl_ulonglong, pdl_ldouble, pdl_grandom, and pdl_zero

---

diff --git a/perl-MCE-Shared.spec b/perl-MCE-Shared.spec
index a558bb1..600ff42 100644
--- a/perl-MCE-Shared.spec
+++ b/perl-MCE-Shared.spec
@@ -1,5 +1,5 @@
 Name:  perl-MCE-Shared
-Version:   1.876
+Version:   1.877
 Release:   1%{?dist}
 Summary:   MCE extension for sharing data, supporting threads and processes
 License:   GPL+ or Artistic
@@ -93,6 +93,13 @@ make test
 %{_mandir}/man3/MCE::Shared::Server.3*
 
 %changelog
+* Tue May 24 2022 Paul Howarth  - 1.877-1
+- Update to 1.877
+  - Replace http with https in documentation and meta files
+  - Call PDL::set_autopthread_targ(1); disables PDL auto-threading
+  - Allow sharing additional PDL objects via class methods: pdl_sbyte,
+pdl_ulong, pdl_ulonglong, pdl_ldouble, pdl_grandom, and pdl_zero
+
 * Sun Feb 20 2022 Paul Howarth  - 1.876-1
 - Update to 1.876
   - Improved suppressing the PDL CLONE warning; piddles should not be naively
diff --git a/sources b/sources
index 4df096e..8969792 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (MCE-Shared-1.876.tar.gz) = 
dfc167d034a17e08b5315bd0f71a7b4ef6caf98406515be8adb0012730a78d080485938dea0c705c179c0a6b1410da6f02b0768b347ecfdcd8116f2176e3324f
+SHA512 (MCE-Shared-1.877.tar.gz) = 
4e837eb6d305aafb6d65b5a55c5f22c760b28a57807957f2d0b91f54a2805aed8b473f7a90775d6e818f917b86ab916a4709c70054e4c5e51c5ada15127651ea



https://src.fedoraproject.org/rpms/perl-MCE-Shared/c/afac8becb69640cd16f0b39f794ce3c72ceafafa?branch=rawhide
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[Test-Announce] Re: Fedora 37 Rawhide 20220524.n.0 nightly compose nominated for testing

[Adam Williamson]

On Tue, 2022-05-24 at 09:53 +, rawh...@fedoraproject.org wrote:
> Announcing the creation of a new nightly release validation test event
> for Fedora 37 Rawhide 20220524.n.0. Please help run some tests for this
> nightly compose if you have time. For more information on nightly
> release validation testing, see:
> https://fedoraproject.org/wiki/QA:Release_validation_test_plan
> 
> Notable package version changes:
> anaconda - 20220520.n.0: anaconda-37.7-2.fc37.src, 20220524.n.0: 
> anaconda-37.8-1.fc37.src
> lorax - 20220520.n.0: lorax-37.1-1.fc37.src, 20220524.n.0: 
> lorax-37.2-1.fc37.src

There's a significant bug in anaconda in this compose - it'll crash if
you try to enable the root account during install. We're doing a
20220524.n.1 compose, and I'll manually nominate that as the current
validation compose once it's done.
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

[Vitaly Zaitsev via devel]

On 24/05/2022 16:31, Jiri Vanek wrote:

The goal is to go as shim and cisco - to build in koji, certify, and repack.


shim and openh264 have a good reason for this - legal issues. OpenJDK 
doesn't. Sorry, but I can't treat the laziness of the maintainers as a 
good reason.


--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

[Jiri Vanek]

On 5/21/22 13:38, Neal Gompa wrote:

On Sat, May 21, 2022 at 7:28 AM Jiri Vanek  wrote:




On 5/20/22 14:57, Vitaly Zaitsev via devel wrote:

On 20/05/2022 14:28, Jiri Vanek wrote:

wait, what? What do you mean? And waht give you this impression?


https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs:

  > Make the normal rpms to not built jdk, but to repack the portable rpms with 
all integration


thanx.




Or are you already in the follwoing year, when the attempt will be doen to 
build each JDK  in koji just  once, and ship it to al llive fedoras?


Repackaging of anything even it was built in Koji is strictly prohibited. All 
packages must be built from sources. No exceptions.


shim?


Shim is technically built on Fedora infrastructure as shim-unsigned.
Microsoft signs that binary and the shim package has those binaries as
sources in that package.

OpenJDK is not that strict, and frankly I don't think we'd want to do
more than just that package that way. It's a massive pain and it's
pretty evident that this arrangement causes us serious problems too,
since it locks the Fedora community out of fixing issues at that
level.



Hm. For "silent observer" (in case of shmi and codecs) the burden seemed not so 
high, But as Kevinlater described, it was a bit underestimated.






--
Jiri Vanek Mgr.
Principal QA Software Engineer
Red Hat Inc.
+420 775 39 01 09
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

[Jiri Vanek]

On 5/23/22 20:40, Kevin Fenzi wrote:

So, just replying here since this is a nice monster of a thread. ;(

First, just to clear up some previous coments, shim does build against
the oldest stable Fedora in koji and then is manually tagged into newer
ones. This is not at all a good process. It only gets a bodhi update for
the one release (and sometimes not even that), so it never gets good
testing. It requires manual intervention from releng each time there's
an update. I think the only reason this has kept going is that shim is
very small and simple and updates rarely. If we need to do this for tons
of openjdk updates, we really should revisit the process, although I am
not sure how to make it more open to testing and less a burden on
releng. ;(


Thanx for bringing up additional details!


Next, My understanding of the current process for openjdks (openjdki?):

for each openjdk:

Build dyanmically linking against system libraries in all fedoras.
Submit to TCK and wait for them all to process.
Fix any TCK failures and repeat
Once there's no failures, push the builds to updates

Is that right? And keeping the dynamic builds passing is taking more
cycles than you have to give for the number of jdks?


super correct.



What about the possibility of adding CI _upstream_ to test against the
dynamic version? Then TCK failures would be caught upstream and not
downstream where it's a lot of work for you to fix?


We are testing also upstream. note that RH is maintainer of ojdk 11 and 8, so we have to.  But that is much easier, as the usptream is static within intree libraries. And we have to run also for 17 and 18/19 as we need this reference run, 
to be sure that downstream is guilty, not vanilla jdk. Thus we test the (source x build) just once.  And we can test the binary on some known system where we always pass.
But in downstream, new issues usually appear due to the dynamic linking and nature of system where only it can be installed. Also for dowstram, each sources are built N times, so N times tested in thsoe N systems - usually each with its 
psecific failures.




Could we integrate the TCK testing in our CI to save you overhead of
managing submitting, etc? Or where is the most time spent in this
workflow?


As I described in another reply, it is both human and hw. Hw to run all those 
swarm of builds on all platforms, and humans to verify the issue and to fix it.
TCK are very complex, and you need at least three machines in distributed 
system to run them. At least two of those slaves are not trivial (krb master 
and system where tck are running).
Generally saying, I have autoamtion to prepare that all, but second part is 
reproducibility. If the "non mine" setup run will fail for some reason, can I 
rerun it? Can I debug it? I'm finding this very hard in 3rd party hw clusters.



I know others have suggested fewer openjdk streams to reduce workload,
but I didn't see any reply on that from change owners.



I replied it already in that thread, but happy to repeat:
It will help, but less then it seems so.
Now we can drop 8. Soem legacy applciations will be unhappy, as EOL of jdk8 is 
in some 4 years, so fedora will suffer a bit. But it will be nice 12 TCK runs 
down.
but we can not droop 11, as it is system jdk in f35
Similarly, we couldn't introduce fresh jdk17 directly to f36 as system JDK. It 
needs it time to be tuned before being proposed as system jdk.
And we can not drop java-latest-openjdk, becasue it is necessary to boot next 
system JDK.
Yes, in 8 months, we would be able to drop 11. And live for 1 year only on 
latest and 17. Which is putting load for one year to 1/2. But the cost of not 
having 11 (and 8) will be felt by fedora users more, then having static jdk 
from repos.
Unluckily, with new future system jdk, we will need to boostrap it by latest, 
keep it as secondary jdk at least for one , better two, fedora cycles, so again 
we will be in 3  jdks x 3 systems.
Sure, we do not need to backport newest future system jdk to older fedoras, but 
usually the users want us to do so. tbh, I do not have strong preference on it. 
it is like 51 for backport, and 49 for not. Even with knwoledge of TCK burden.

If currently we have 4 jdks on 3 fedoras with 3 primary architectures=> 36 TCK
With this shortage, we would have
2 jdks on 2 fedoras with 3 primary architectures=> 12 tck in minimum. That 
sound like a reasonable drop, but only for very short period of time, duriong 
which we will nee to have capcity reserved for ppreparation of next
system jdk: 3 jdks on 3 fedoras with 3 primary architectures=>  27 avarage, 
With much more stress about possible integration issues and with - imo(!) - 
considerable negative imapct to fedora.


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

[Fedocal] Reminder meeting : Fedora Source-git SIG

[csomh]

Dear all,

You are kindly invited to the meeting:
   Fedora Source-git SIG on 2022-05-25 from 14:30:00 to 15:30:00 GMT
   At meet.google.com/mic-otnv-kse

The meeting will be about:
Meeting of the Fedora source-git SIG

Agenda:
https://pagure.io/fedora-source-git/sig/issues?tags=meeting=Open

SIG Info:
https://fedoraproject.org/wiki/SIGs/Source-git


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

___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: FESCo election nominations are now open

[Ben Cotton]

This is your final reminder of the nomination period for FESCo
elections. You may nominate yourself (or someone else, with their
permission) at 
https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations
. Nominations must be made by 2359 UTC on Wednesday 25 May. We
currently have four candidates for four open seats.

-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

[Jiri Vanek]

On 5/21/22 13:51, Vitaly Zaitsev via devel wrote:

On 21/05/2022 13:22, Jiri Vanek wrote:

shim?


Built on Koji from sources as shim-unsigned, then uploaded to Microsoft for 
signing.

This is a special legal case, just like openh264 and Cisco.

Both of them built from sources on Fedora infra.



I repeat, aprox 21st time - I will never ever use blob. I will always build 
from sources in koji.
The goal is to go as shim and cisco - to build in koji, certify, and repack.

J.

--
Jiri Vanek Mgr.
Principal QA Software Engineer
Red Hat Inc.
+420 775 39 01 09
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [HEADS UP] Fedora 37 Boost 1.78 rebuilds starting in a side tag

[Jonathan Wakely]

On Thu, 5 May 2022 at 09:46, Miro Hrončok  wrote:
>
> On 04. 05. 22 1:34, Thomas Rodgers wrote:
> > We are starting the rebuilds for
> > https://fedoraproject.org/wiki/Changes/F37Boost178  
> >   in the f37-boost
> > side tag.
> >
> > If your package depends on Boost, or just if you see a "Rebuilt for
> > Boost 1.78" commit pushed to your package's dist-git repo, please
> > co-ordinate with me about any updates to the
> > package. If you need to push other changes to rawhide then you will
> > need to build in the side tag, or we'll have to rebuild it multiple
> > times.
>
> All of the remaining failures:
>
> freecad
>
> /builddir/build/BUILD/FreeCAD-0.19.4/src/Mod/Part/App/BRepOffsetAPI_MakeFillingPyImp.cpp:100:14:
> error: 'unique_ptr' is not a member of 'std'
>100 | std::unique_ptr ptr(new
> BRepOffsetAPI_MakeFilling(degree, nbPtsOnCur, nbIter,
>|  ^~

This is a latent package bug, exposed by GCC 12. It needs to #include
 explicitly to use std::unique_ptr.
https://gcc.gnu.org/gcc-12/porting_to.html#header-dep-changes


> grive2
>  /builddir/build/BUILD/grive2-0.5.1/libgrive/src/base/Syncer.hh:58:22:
> error: 'unique_ptr' in namespace 'std' does not name a template type
> 58 | virtual std::unique_ptr GetFolders() = 0;
>|  ^~

As above.


> guitarix
>  /usr/include/glib-2.0/glib/gatomic.h:163:44: error: invalid conversion
> from ‘volatile void*’ to ‘void*’ [-fpermissive]
>163 | __atomic_compare_exchange_n ((atomic), _oldval,
> (newval), FALSE, __ATOMIC_SEQ_CST, __ATOMIC_SEQ_CST) ? TRUE : FALSE; \
>|^~

Huh, I thought we fixed this in Glib. Unrelated to Boost anyway, I
think this has been broken since GCC 11.


> libzypp
>  /builddir/build/BUILD/libzypp-17.25.6/zypp/target/rpm/RpmHeader.cc: In
> function 'int unameToUid(const char*, uid_t*)':
>  /builddir/build/BUILD/libzypp-17.25.6/zypp/target/rpm/RpmHeader.cc:41:16:
> error: 'strcmp' was not declared in this scope
> 41 | } else if (strcmp(thisUname, "root") == 0) {
>|^~

Looks like a package bug.


> vsomeip3
> /builddir/build/BUILD/vsomeip-3.1.20.3/implementation/endpoints/src/endpoint_impl.cpp:8:10:
> fatal error: boost/asio/ip/udp_ext.hpp: No such file or directory
>  8 | #include 
>|  ^~~

This one might be due to the new Boost.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2089521] perl-Math-BigInt-1.999835 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 CC|jples...@redhat.com,|
   |mspa...@redhat.com, |
   |ppi...@redhat.com   |
   Doc Type|--- |If docs needed, set a value
   Fixed In Version||perl-Math-BigInt-1.9998.35-
   ||1.fc37
 Status|NEW |CLOSED
 Resolution|--- |RAWHIDE
Last Closed||2022-05-24 13:32:54




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2089521
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2089613] perl-Switch-2.17-24.fc37 FTBFS: Bad given statement (problem in the code block?) near t/given.t line 21

[bugzilla]

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



--- Comment #2 from Tom "spot" Callaway  ---
It feels very much like Switch is unmaintained upstream. I tried making what
seemed like the corresponding fix, but it did not resolve the issue. Any help
would be greatly appreciated here.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2089613
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-Rawhide-20220524.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Minimal raw-xz armhfp

Compose FAILS proposed Rawhide gating check!
20 of 43 required tests failed, 17 results missing
openQA tests matching unsatisfied gating requirements shown with **GATING** 
below

Failed openQA tests: 113/231 (x86_64), 65/161 (aarch64)

New failures (same test not failed in Fedora-Rawhide-20220523.n.0):

ID: 1277058 Test: x86_64 Server-boot-iso install_default **GATING**
URL: https://openqa.fedoraproject.org/tests/1277058
ID: 1277059 Test: x86_64 Server-boot-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/1277059
ID: 1277060 Test: x86_64 Server-dvd-iso 
install_blivet_standard_partition_ext4
URL: https://openqa.fedoraproject.org/tests/1277060
ID: 1277061 Test: x86_64 Server-dvd-iso 
install_blivet_standard_partition_ext4@uefi
URL: https://openqa.fedoraproject.org/tests/1277061
ID: 1277062 Test: x86_64 Server-dvd-iso install_default_upload **GATING**
URL: https://openqa.fedoraproject.org/tests/1277062
ID: 1277063 Test: x86_64 Server-dvd-iso anaconda_help
URL: https://openqa.fedoraproject.org/tests/1277063
ID: 1277067 Test: x86_64 Server-dvd-iso install_repository_hd_variation
URL: https://openqa.fedoraproject.org/tests/1277067
ID: 1277075 Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/1277075
ID: 1277076 Test: x86_64 Server-dvd-iso install_vncconnect_server
URL: https://openqa.fedoraproject.org/tests/1277076
ID: 1277077 Test: x86_64 Server-dvd-iso install_btrfs_preserve_home
URL: https://openqa.fedoraproject.org/tests/1277077
ID: 1277078 Test: x86_64 Server-dvd-iso 
install_btrfs_preserve_home_uefi@uefi
URL: https://openqa.fedoraproject.org/tests/1277078
ID: 1277079 Test: x86_64 Server-dvd-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/1277079
ID: 1277080 Test: x86_64 Server-dvd-iso install_lvm_ext4
URL: https://openqa.fedoraproject.org/tests/1277080
ID: 1277081 Test: x86_64 Server-dvd-iso install_lvm_ext4@uefi
URL: https://openqa.fedoraproject.org/tests/1277081
ID: 1277082 Test: x86_64 Server-dvd-iso install_standard_partition_ext4
URL: https://openqa.fedoraproject.org/tests/1277082
ID: 1277083 Test: x86_64 Server-dvd-iso install_standard_partition_ext4@uefi
URL: https://openqa.fedoraproject.org/tests/1277083
ID: 1277088 Test: x86_64 Server-dvd-iso install_blivet_btrfs_preserve_home
URL: https://openqa.fedoraproject.org/tests/1277088
ID: 1277089 Test: x86_64 Server-dvd-iso 
install_blivet_btrfs_preserve_home_uefi@uefi
URL: https://openqa.fedoraproject.org/tests/1277089
ID: 1277090 Test: x86_64 Server-dvd-iso install_blivet_lvm_ext4
URL: https://openqa.fedoraproject.org/tests/1277090
ID: 1277091 Test: x86_64 Server-dvd-iso install_blivet_lvm_ext4@uefi
URL: https://openqa.fedoraproject.org/tests/1277091
ID: 1277093 Test: x86_64 Server-dvd-iso support_server
URL: https://openqa.fedoraproject.org/tests/1277093
ID: 1277101 Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/1277101
ID: 1277102 Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/1277102
ID: 1277108 Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/1277108
ID: 1277110 Test: x86_64 Server-dvd-iso install_repository_nfsiso_variation
URL: https://openqa.fedoraproject.org/tests/1277110
ID: 1277114 Test: x86_64 Everything-boot-iso install_default **GATING**
URL: https://openqa.fedoraproject.org/tests/1277114
ID: 1277115 Test: x86_64 Everything-boot-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/1277115
ID: 1277116 Test: x86_64 Everything-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/1277116
ID: 1277117 Test: x86_64 Everything-boot-iso memory_check@uefi
URL: https://openqa.fedoraproject.org/tests/1277117
ID: 1277121 Test: x86_64 Workstation-live-iso install_default_upload 
**GATING**
URL: https://openqa.fedoraproject.org/tests/1277121
ID: 1277147 Test: x86_64 KDE-live-iso install_default_upload **GATING**
URL: https://openqa.fedoraproject.org/tests/1277147
ID: 1277174 Test: x86_64 Silverblue-dvd_ostree-iso base_system_logging
URL: https://openqa.fedoraproject.org/tests/1277174
ID: 1277179 Test: x86_64 Silverblue-dvd_ostree-iso base_selinux
URL: https://openqa.fedoraproject.org/tests/1277179
ID: 1277180 Test: x86_64 Silverblue-dvd_ostree-iso desktop_background
URL: https://openqa.fedoraproject.org/tests/1277180
ID: 1277200 Test: aarch64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/1277200
ID: 1277201 Test: aarch64 Server-dvd-iso support_server@uefi
URL: https://openqa.fedoraproject.org/tests/1277201
ID: 1277202 Test: aarch64 Server-dvd-iso anaconda_help@uefi
URL: https://openqa.fedoraproject.org/tests/1277202
ID: 

[Bug 2089708] perl-MCE-1.879 is available

[bugzilla]

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

Paul Howarth  changed:

   What|Removed |Added

   Doc Type|--- |If docs needed, set a value
   Fixed In Version||perl-MCE-1.879-1.fc37
 Status|NEW |CLOSED
 Resolution|--- |RAWHIDE
Last Closed||2022-05-24 12:05:15



--- Comment #1 from Paul Howarth  ---
Build done:
https://koji.fedoraproject.org/koji/taskinfo?taskID=87438702


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2089708
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[modules] 'fedpkg request-branch' - how ?

[Michal Schorm]

Hello,

I want to create a new module stream.
All the RPMs repos and the Module repo exist. I just need new branches
in all of them.

However I've run into a deadlock.
Non-release branches require SL to be defined. And SL before it is
defined checks that such a branch exists.

| fedpkg request-branch 10.8
| Could not execute request_branch: You must provide SLs for
non-release branches (10.8)
|
| fedpkg request-branch 10.8 --sl 10.8:2030-12-01
| Could not execute request_branch: The SL "10.8" is not in PDC

--

Beside that, the
| fedpkg request-branch -h
doesn't explain what will be the content of the newly created branch.

In my case it would suit me best to call the command from inside of
repo and the new branch to be created as a copy of the currently
checked out branch.
(So it would be similar as 'git checkout -b ... ')
Should I rather use the '--no-git-branch' argument to create the
branch as I need ?
   Can I actually do that, since SL needs the branch to exist first ??

I also don't understand what happens when in a case of module named
'X', consisting of RPMs named 'X' and 'Y', I go to the RPM 'Y' and
call the 'fedpkg-request branch' without '--no-auto-module'.
Will that create a new modular repo named 'Y' ?
Will that create a branch with a name I choosed in the modular repo 'X' ?

--

Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat

--
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora rawhide compose report: 20220524.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20220523.n.0
NEW: Fedora-Rawhide-20220524.n.0

= SUMMARY =
Added images:6
Dropped images:  0
Added packages:  4
Dropped packages:0
Upgraded packages:   111
Downgraded packages: 0

Size of added packages:  1.70 MiB
Size of dropped packages:0 B
Size of upgraded packages:   3.81 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =
Image: Scientific vagrant-libvirt x86_64
Path: 
Labs/x86_64/images/Fedora-Scientific-Vagrant-Rawhide-20220524.n.0.x86_64.vagrant-libvirt.box
Image: Scientific vagrant-virtualbox x86_64
Path: 
Labs/x86_64/images/Fedora-Scientific-Vagrant-Rawhide-20220524.n.0.x86_64.vagrant-virtualbox.box
Image: Robotics live x86_64
Path: Labs/x86_64/iso/Fedora-Robotics-Live-x86_64-Rawhide-20220524.n.0.iso
Image: Astronomy_KDE live x86_64
Path: Labs/x86_64/iso/Fedora-Astronomy_KDE-Live-x86_64-Rawhide-20220524.n.0.iso
Image: Scientific_KDE live x86_64
Path: Labs/x86_64/iso/Fedora-Scientific_KDE-Live-x86_64-Rawhide-20220524.n.0.iso
Image: Minimal raw-xz aarch64
Path: Spins/aarch64/images/Fedora-Minimal-Rawhide-20220524.n.0.aarch64.raw.xz

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: golang-github-max-sum-base32768-0-0.1.20220523git7937843.fc37
Summary: Go implementation of base32768, optimized for UTF-16
RPMs:golang-github-max-sum-base32768-devel
Size:14.67 KiB

Package: golang-github-rclone-ftp-0-0.1.20220523git901caa1.fc37
Summary: FTP client package for Go
RPMs:golang-github-rclone-ftp-devel
Size:28.36 KiB

Package: obserware-0.2.9-1.fc37
Summary: An advanced system monitor utility written in Python and Qt
RPMs:obserware
Size:1.42 MiB

Package: python-azure-servicebus-7.6.1-1.fc37
Summary: Microsoft Azure Service Bus Client Library for Python
RPMs:python3-azure-servicebus
Size:249.91 KiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  ags-3.6.0.25-1.fc37
Old package:  ags-3.5.0.32-3.fc36
Summary:  Engine for creating and running videogames of adventure (quest) 
genre
RPMs: ags
Size: 5.29 MiB
Size change:  660.81 KiB
Changelog:
  * Thu May 12 2022 Dominik Mierzejewski  - 3.6.0.25-1
  - update to 3.6.0.25
  - unbundle khrplatform.h header
  - unbundle glm, ogg, theora, tinyxml2 and vorbis
  - use openal-soft instead of bundled mojoAL


Package:  anaconda-37.8-1.fc37
Old package:  anaconda-37.7-2.fc37
Summary:  Graphical system installer
RPMs: anaconda anaconda-core anaconda-dracut anaconda-gui 
anaconda-install-env-deps anaconda-install-img-deps anaconda-live anaconda-tui 
anaconda-widgets anaconda-widgets-devel
Size: 16.01 MiB
Size change:  23.90 KiB
Changelog:
  * Mon May 23 2022 Packit  - 37.8-1
  - Web UI: Add the Language label on the Welcome page (vponcova)
  - Specify that we want the Adwaita icon theme (awilliam)
  - Web UI: Fix the style of paragraphs (vponcova)
  - Web UI: Fix header styles in the Review screen (vponcova)
  - Web UI: Inform users about the required space and the partitioning method 
(vponcova)
  - Round the required device size up (vponcova)
  - tests: Use MD instead of LVM to test available RAID levels (vtrefny)
  - webui: Show installation status text on progress screen (mkolman)
  - build(deps): bump @patternfly/patternfly in /ui/webui 
(49699333+dependabot[bot])
  - webui: Wait longer for installation to fail (mkolman)
  - webui: Add a Quit confirmation dialog (mkolman)
  - build(deps): bump @patternfly/react-core in /ui/webui 
(49699333+dependabot[bot])
  - Don't use Cockpit style overrides (vponcova)
  - Web UI: Reset the bootloader drive before we schedule partitions (vponcova)
  - webui: tests: Streamline working with dbus language setting (zveleba)
  - Make check for geolocation start a standalone helper (vslavik)
  - Split Timezone module tests for tasks to new file (vslavik)
  - Move the default source type on DBus (vponcova)
  - Temporarily keep setter methods for Initial Setup (vponcova)
  - Temporarily keep setter methods for the OSCAP add-on (vponcova)
  - Temporarily keep setter methods for the Kdump add-on (vponcova)
  - Use DBus read-write properties (vponcova)
  - Simplify the implementation for the DBus interface for Users module 
(vponcova)
  - Install rdma-core if infiniband network device is found (rvykydal)


Package:  ansible-collection-ansible-posix-1.4.0-1.fc37
Old package:  ansible-collection-ansible-posix-1.3.0-3.fc36
Summary:  Ansible Collection targeting POSIX and POSIX-ish platforms
RPMs: ansible-collection-ansible-posix
Size: 129.23 KiB
Size change:  7.79 KiB
Changelog:
  * Tue Feb 22 2022 Maxwell G  - 1.3.0-4
  - Switch to ansible-packaging.

  * Tue May 10 2022 Maxwell G  - 1.3.0-5
  - Rebuild for new ansible-packaging.

  * Tue May 24 2022 Maxwell G  - 1.4.0-1
  - Update to 1.4.0. Fixes rhbz#2089504.


Package:  ansible-collections

[Test-Announce] Fedora 37 Rawhide 20220524.n.0 nightly compose nominated for testing

[rawhide]

Announcing the creation of a new nightly release validation test event
for Fedora 37 Rawhide 20220524.n.0. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test_plan

Notable package version changes:
anaconda - 20220520.n.0: anaconda-37.7-2.fc37.src, 20220524.n.0: 
anaconda-37.8-1.fc37.src
lorax - 20220520.n.0: lorax-37.1-1.fc37.src, 20220524.n.0: lorax-37.2-1.fc37.src

Test coverage information for the current release can be seen at:
https://openqa.fedoraproject.org/testcase_stats/37

You can see all results, find testing instructions and image download
locations, and enter results on the Summary page:

https://fedoraproject.org/wiki/Test_Results:Fedora_37_Rawhide_20220524.n.0_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_37_Rawhide_20220524.n.0_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_37_Rawhide_20220524.n.0_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_37_Rawhide_20220524.n.0_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_37_Rawhide_20220524.n.0_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_37_Rawhide_20220524.n.0_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_37_Rawhide_20220524.n.0_Security_Lab

Thank you for testing!
-- 
Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2089708] New: perl-MCE-1.879 is available

[bugzilla]

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

Bug ID: 2089708
   Summary: perl-MCE-1.879 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-MCE
  Keywords: FutureFeature, Triaged
  Assignee: p...@city-fan.org
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: p...@city-fan.org, perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 1.879
Current version/release in rawhide: 1.878-1.fc37
URL: http://search.cpan.org/dist/MCE/

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


More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring


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


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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2089708
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-Cloud-34-20220524.0 compose check report

[Fedora compose checker]

No missing expected images.

Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64)
(Tests completed, but using a workaround for a known bug)

Old soft failures (same test soft failed in Fedora-Cloud-34-20220523.0):

ID: 1277043 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/1277043
ID: 1277051 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/1277051

Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Help with annocheck output

[Iñaki Ucar]

Hi,

I'm trying to understand why annocheck is complaining in [1] about
_FORTIFY_SOURCE and _GLIBCXX_ASSERTIONS when these flags are defined
(see [2]).

A specific example, the first function reported:

Hardened: /usr/lib/flexiblas/libflexiblas_fallback_lapack.so: FAIL:
fortify test because -D_FORTIFY_SOURCE=2 was not present on the
command line (function: sgbbrd_)

If we take a look at the build log, we see:

[ 34%] Building C object
src/CMakeFiles/flexiblas.dir/lapack_interface/wrapper/sgbbrd.c.o
cd /builddir/build/BUILD/flexiblas-3.2.0/build/src && /usr/bin/gcc
-DFLEXIBLAS_CBLAS -DFLEXIBLAS_LAPACK -D_FILE_OFFSET_BITS=64 -D_NONE_
-D_POSIX_C_SOURCE=200809L -Dflexiblas_EXPORTS
-I/builddir/build/BUILD/flexiblas-3.2.0/src
-I/builddir/build/BUILD/flexiblas-3.2.0/build/include
-I/builddir/build/BUILD/flexiblas-3.2.0/include
-I/builddir/build/BUILD/flexiblas-3.2.0/build
-I/builddir/build/BUILD/flexiblas-3.2.0/libcscutils/include
-I/builddir/build/BUILD/flexiblas-3.2.0/build/libcscutils/include
-I/builddir/build/BUILD/flexiblas-3.2.0/libcscutils/src
-I/builddir/build/BUILD/flexiblas-3.2.0/build/libcscutils/src
-I/builddir/build/BUILD/flexiblas-3.2.0/build/libcscutils/include/cscutils
-O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches
-pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
-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 -fPIC -std=c99
-fstack-protector-strong -fstack-clash-protection
-D_FILE_OFFSET_BITS=64 -DNDEBUG -O3 -fPIC -MD -MT
src/CMakeFiles/flexiblas.dir/lapack_interface/wrapper/sgbbrd.c.o -MF
CMakeFiles/flexiblas.dir/lapack_interface/wrapper/sgbbrd.c.o.d -o
CMakeFiles/flexiblas.dir/lapack_interface/wrapper/sgbbrd.c.o -c
/builddir/build/BUILD/flexiblas-3.2.0/src/lapack_interface/wrapper/sgbbrd.c

So the flags are there. Is this a false positive or am I missing something?

[1] 
https://osci-jenkins-1.ci.fedoraproject.org/job/fedora-ci/job/rpminspect-pipeline/job/master/101025/testReport/(root)/tests/_annocheck/
[2] 
https://kojipkgs.fedoraproject.org//packages/flexiblas/3.2.0/2.fc37/data/logs/x86_64/build.log

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

Re: Fedora 37: Add kernel parameters that help prevent local exploits

[Marcin Juszkiewicz]

W dniu 19.05.2022 o 05:15, Hellosway Here via devel pisze:

Add `slab_nomerge init_on_alloc=1 init_on_free=1 page_alloc.shuffle=1
pti=on randomize_kstack_offset=on vsyscall=none ` as default kernel
command line arguments. 


Some of them are a matter of kernel configuration options. Which is 
better option than adding yet another set of variables to kernel command 
line.

___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Announcing the Fedora BIOS boot SIG

[Hans de Goede]

Hi,

On 5/23/22 08:41, Adam Williamson wrote:
> On Fri, 2022-05-20 at 12:18 +0200, Hans de Goede wrote:
>> Hi All,
>>
>> Now that FESCo has decided (1) that Fedora will keep supporting BIOS
>> booting, the people working on Fedora's bootloader stack will need
>> help from the Fedora community to keep Fedora booting on systems which
>> require Legacy BIOS to boot.
>>
>> To help with this the Fedora BIOS boot SIG (special interest group) has
>> been formed. The main goal of this SIG are to help the Fedora bootloader
>> people by:
>>
>> 1) Doing regular testing of nightly Fedora N + 1 composes on hardware
>> which only supports BIOS booting
> 
> Note, we already do automated a-lot-more-than-nightly testing of ISOs
> on VMs that only support BIOS booting (qemu without UEFI). This won't
> help with the specific case of real-world systems whose firmware can't
> handle GPT-labeled disks, or similar things, but we will at least
> notice very quickly if BIOS boot just breaks entirely.

That is good to know, thanks.

If things do break, please Cc: biosboot-...@lists.fedoraproject.org
on any bugs filed.

Regards,

Hans
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2089521] perl-Math-BigInt-1.999835 is available

[bugzilla]

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

Upstream Release Monitoring  
changed:

   What|Removed |Added

Summary|perl-Math-BigInt-1.999834   |perl-Math-BigInt-1.999835
   |is available|is available



--- Comment #1 from Upstream Release Monitoring 
 ---
Latest upstream release: 1.999835
Current version/release in rawhide: 1.9998.33-1.fc37
URL: http://search.cpan.org/dist/Math-BigInt/

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


More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring


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


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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2089521
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

seahorse license change from GPLv2+ and LGPLv2+ to GPLv2+ and LGPLv2+ and CC-BY-SA

[David King]

While updating seahorse to the latest version, I noticed that the user 
documentation was incorrectly listed as being under the GFDL. After 
confirming with upstream, I updated to to the current CC-BY-SA license:


https://gitlab.gnome.org/GNOME/seahorse/-/merge_requests/199

--
https://amigadave.com/


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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2089613] perl-Switch-2.17-24.fc37 FTBFS: Bad given statement (problem in the code block?) near t/given.t line 21

[bugzilla]

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



--- Comment #1 from Petr Pisar  ---
Bisected to this Text-Balanced upstream's commit:

commit 7bbb21936fc20ac71c820847e586999c79b3c723 (HEAD, refs/bisect/bad)
Author: Ed J 
Date:   Thu Mar 3 06:33:35 2022 +

_match_codeblock regex inputs pre-compiled


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2089613
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2062024] [RFE: EPEL9] EPEL9 branch for perl-Proc-Daemon

[bugzilla]

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

Emmanuel Seyman  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED



--- Comment #1 from Emmanuel Seyman  ---
https://pagure.io/releng/fedora-scm-requests/issue/44567


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2062024
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2089613] New: perl-Switch-2.17-24.fc37 FTBFS: Bad given statement (problem in the code block?) near t/given.t line 21

[bugzilla]

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

Bug ID: 2089613
   Summary: perl-Switch-2.17-24.fc37 FTBFS: Bad given statement
(problem in the code block?) near t/given.t line 21
   Product: Fedora
   Version: rawhide
   URL: https://koschei.fedoraproject.org/package/perl-Switch
Status: NEW
 Component: perl-Switch
  Assignee: spo...@gmail.com
  Reporter: ppi...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, spo...@gmail.com
Blocks: 2045102 (F37FTBFS,RAWHIDEFTBFS)
  Target Milestone: ---
Classification: Fedora



perl-Switch-2.17-24.fc37 fails to build in Fedora 37 because tests fail like
this:

$ perl -I/home/test/fedora/perl-Text-Balanced/Text-Balanced-2.05/lib/ -I.
t/given.t 
Bad given statement (problem in the code block?) near t/given.t line 21

This is triggered by upgrading perl-Text-Balanced from 2.04-479.fc36 to
2.05-1.fc37.



Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=2045102
[Bug 2045102] Fedora 37 FTBFS Tracker
-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2089613
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure