Re: btrfs loses 32-bit application compatibility after a while

[Chris Murphy]

On Thu, Jul 20, 2023, at 11:55 AM, Florian Weimer wrote:
> * Demi Marie Obenour:
>
>> From this thread, it appears that non-LFS 32-bit software is fundamentally
>> unsupportable in the long run, just like software with 32-bit time_t is
>> unsupportable.  That leaves two options:
>>
>> 1. Break the ABI, preferably in such a way that causes non-LFS
>>code to fail at load time rather than crashing.
>>
>> 2. Drop 32-bit support from the distribution altogether.
>>
>> It looks like trying to keep 32-bit non-LFS software working will be an
>> endless time sink and is not sustainable in the long term.
>
> My impression is different.  It's btrfs that is a poor choice for people
> who want to run 32-bit software, have a lot of file creations/deletions,
> and do not want to reformat and reinstall periodically.  The situation
> with XFS, for example, is different because you can supply the inode32
> mount option and get 32-bit applications going again, maybe after making
> in-place copies of a few files.

It should be straightforward to have mock create a subvolume for each chroot 
instead of a directory. Subvolumes have their own inode pool. 

Mock already knows how to delete btrfs subvolumes, which is quite a lot more 
efficient than calling unlinkat() per file and directory. For the many files 
created and deleted workflow, I think it's worth taking advantage of this.

In the meantime, whatever parent directory is used for the chroots could be 
swapped out with a subvolume for a short term work around. It doesn't sound 
like the problem happens very quickly.



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

releng pushed to rpms/perl-namespace-sweep (rawhide). "Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild (..more)"

[notifications]

Notification time stamped 2023-07-21 03:50:05 UTC

From c133bb83e72e63f4a8749de3beb272da49564988 Mon Sep 17 00:00:00 2001
From: Fedora Release Engineering 
Date: Jul 21 2023 03:49:59 +
Subject: Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild


Signed-off-by: Fedora Release Engineering 

---

diff --git a/perl-namespace-sweep.spec b/perl-namespace-sweep.spec
index 45b13f8..6cd1ac7 100644
--- a/perl-namespace-sweep.spec
+++ b/perl-namespace-sweep.spec
@@ -1,6 +1,6 @@
 Name:   perl-namespace-sweep
 Version:0.006
-Release:20%{?dist}
+Release:21%{?dist}
 Summary:Sweep up imported subs in your classes
 License:GPL-1.0-or-later OR Artistic-1.0-Perl
 URL:https://metacpan.org/release/namespace-sweep
@@ -62,6 +62,9 @@ will still be able to use the imported functions without any 
problems.
 %{_mandir}/man3/*
 
 %changelog
+* Fri Jul 21 2023 Fedora Release Engineering  - 
0.006-21
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild
+
 * Fri Jan 20 2023 Fedora Release Engineering  - 
0.006-20
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_38_Mass_Rebuild
 



https://src.fedoraproject.org/rpms/perl-namespace-sweep/c/c133bb83e72e63f4a8749de3beb272da49564988?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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

releng pushed to rpms/perl-WWW-Form-UrlEncoded (rawhide). "Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild (..more)"

[notifications]

Notification time stamped 2023-07-21 03:21:10 UTC

From 892c0a10c7b1998df912fe34c55beeb771748142 Mon Sep 17 00:00:00 2001
From: Fedora Release Engineering 
Date: Jul 21 2023 03:21:04 +
Subject: Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild


Signed-off-by: Fedora Release Engineering 

---

diff --git a/perl-WWW-Form-UrlEncoded.spec b/perl-WWW-Form-UrlEncoded.spec
index a5df54b..a0f0b91 100644
--- a/perl-WWW-Form-UrlEncoded.spec
+++ b/perl-WWW-Form-UrlEncoded.spec
@@ -1,6 +1,6 @@
 Name:   perl-WWW-Form-UrlEncoded
 Version:0.26
-Release:13%{?dist}
+Release:14%{?dist}
 Summary:Parser and builder for application/x-www-form-urlencoded
 License:GPL-1.0-or-later OR Artistic-1.0-Perl
 URL:https://metacpan.org/release/WWW-Form-UrlEncoded
@@ -55,6 +55,9 @@ BREAK_BACKWARD_COMPAT=1 ./Build test
 %{_mandir}/man3/*
 
 %changelog
+* Fri Jul 21 2023 Fedora Release Engineering  - 
0.26-14
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild
+
 * Fri Jan 20 2023 Fedora Release Engineering  - 
0.26-13
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_38_Mass_Rebuild
 



https://src.fedoraproject.org/rpms/perl-WWW-Form-UrlEncoded/c/892c0a10c7b1998df912fe34c55beeb771748142?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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

releng pushed to rpms/perl-Validation-Class (rawhide). "Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild (..more)"

[notifications]

Notification time stamped 2023-07-21 03:19:25 UTC

From 550f90339e7e2b56f4fc0162e94e59a30cd153e5 Mon Sep 17 00:00:00 2001
From: Fedora Release Engineering 
Date: Jul 21 2023 03:19:19 +
Subject: Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild


Signed-off-by: Fedora Release Engineering 

---

diff --git a/perl-Validation-Class.spec b/perl-Validation-Class.spec
index 6c70fc3..b59ac74 100644
--- a/perl-Validation-Class.spec
+++ b/perl-Validation-Class.spec
@@ -1,6 +1,6 @@
 Name:   perl-Validation-Class
 Version:7.900059
-Release:1%{?dist}
+Release:2%{?dist}
 Summary:Powerful Data Validation Framework
 License:GPL-1.0-or-later OR Artistic-1.0-Perl
 URL:https://metacpan.org/release/Validation-Class
@@ -67,6 +67,9 @@ complete set of pre-defined validations and filters referred 
to as
 %{_mandir}/man3/*
 
 %changelog
+* Fri Jul 21 2023 Fedora Release Engineering  - 
7.900059-2
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild
+
 * Mon Apr 03 2023 Ralf Corsépius  - 7.900059-1
 - Upstream update to 7.900059.
 



https://src.fedoraproject.org/rpms/perl-Validation-Class/c/550f90339e7e2b56f4fc0162e94e59a30cd153e5?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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Orphaned libdmapsharing

[W. Michael Petullo]

I orphaned the libdmapsharing package. All of the F38 and Rawhide packages
that depended on libdmapsharing have moved on to libdmapsharing4. I
recommend allowing libdmapsharing to retire in favor of libdmapsharing4.

-- 
Mike

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

releng pushed to rpms/perl-Types-Path-Tiny (rawhide). "Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild (..more)"

[notifications]

Notification time stamped 2023-07-21 03:10:07 UTC

From 9146b128e917d008fa439aedd2f327d55b2c77ef Mon Sep 17 00:00:00 2001
From: Fedora Release Engineering 
Date: Jul 21 2023 03:10:02 +
Subject: Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild


Signed-off-by: Fedora Release Engineering 

---

diff --git a/perl-Types-Path-Tiny.spec b/perl-Types-Path-Tiny.spec
index 64699b0..01d 100644
--- a/perl-Types-Path-Tiny.spec
+++ b/perl-Types-Path-Tiny.spec
@@ -1,6 +1,6 @@
 Name:   perl-Types-Path-Tiny
 Version:0.006
-Release:17%{?dist}
+Release:18%{?dist}
 Summary:Path::Tiny types and coercions for Moose and Moo
 License:Apache-2.0
 URL:https://metacpan.org/release/Types-Path-Tiny
@@ -53,6 +53,9 @@ This module provides Path::Tiny types for Moose, Moo, etc.
 %{_mandir}/man3/*
 
 %changelog
+* Fri Jul 21 2023 Fedora Release Engineering  - 
0.006-18
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild
+
 * Fri Jan 20 2023 Fedora Release Engineering  - 
0.006-17
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_38_Mass_Rebuild
 



https://src.fedoraproject.org/rpms/perl-Types-Path-Tiny/c/9146b128e917d008fa439aedd2f327d55b2c77ef?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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

releng pushed to rpms/perl-Test2-Plugin-NoWarnings (rawhide). "Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild (..more)"

[notifications]

Notification time stamped 2023-07-21 02:42:30 UTC

From f0ecb9e4011ae90ee79acb04c64b6302d2258095 Mon Sep 17 00:00:00 2001
From: Fedora Release Engineering 
Date: Jul 21 2023 02:42:23 +
Subject: Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild


Signed-off-by: Fedora Release Engineering 

---

diff --git a/perl-Test2-Plugin-NoWarnings.spec 
b/perl-Test2-Plugin-NoWarnings.spec
index 5a89281..e25416f 100644
--- a/perl-Test2-Plugin-NoWarnings.spec
+++ b/perl-Test2-Plugin-NoWarnings.spec
@@ -1,6 +1,6 @@
 Name:  perl-Test2-Plugin-NoWarnings
 Version:   0.09
-Release:   9%{?dist}
+Release:   10%{?dist}
 Summary:   Fail if tests warn
 License:   Artistic-2.0
 URL:   https://metacpan.org/release/Test2-Plugin-NoWarnings
@@ -63,6 +63,9 @@ make test
 %{_mandir}/man3/Test2::Plugin::NoWarnings.3*
 
 %changelog
+* Fri Jul 21 2023 Fedora Release Engineering  - 
0.09-10
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild
+
 * Fri Jan 20 2023 Fedora Release Engineering  - 
0.09-9
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_38_Mass_Rebuild
 



https://src.fedoraproject.org/rpms/perl-Test2-Plugin-NoWarnings/c/f0ecb9e4011ae90ee79acb04c64b6302d2258095?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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

releng pushed to rpms/perl-Sub-Infix (rawhide). "Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild (..more)"

[notifications]

Notification time stamped 2023-07-21 01:49:46 UTC

From 7f5c92257d73a0b2685e351cc4dabe0e28a5fb47 Mon Sep 17 00:00:00 2001
From: Fedora Release Engineering 
Date: Jul 21 2023 01:49:41 +
Subject: Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild


Signed-off-by: Fedora Release Engineering 

---

diff --git a/perl-Sub-Infix.spec b/perl-Sub-Infix.spec
index 295a379..f62487f 100644
--- a/perl-Sub-Infix.spec
+++ b/perl-Sub-Infix.spec
@@ -1,6 +1,6 @@
 Name:   perl-Sub-Infix
 Version:0.004
-Release:20%{?dist}
+Release:21%{?dist}
 Summary:Create a fake infix operator
 License:GPL-1.0-or-later OR Artistic-1.0-Perl
 URL:https://metacpan.org/release/Sub-Infix
@@ -51,6 +51,9 @@ source filters, or Devel::Declare, or any of that magic.
 %{_mandir}/man3/*
 
 %changelog
+* Fri Jul 21 2023 Fedora Release Engineering  - 
0.004-21
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild
+
 * Fri Jan 20 2023 Fedora Release Engineering  - 
0.004-20
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_38_Mass_Rebuild
 



https://src.fedoraproject.org/rpms/perl-Sub-Infix/c/7f5c92257d73a0b2685e351cc4dabe0e28a5fb47?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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

releng pushed to rpms/perl-Sub-Exporter-Lexical (rawhide). "Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild (..more)"

[notifications]

Notification time stamped 2023-07-21 01:49:05 UTC

From 976ae3670f78f83ff2d07451b0de87753c615083 Mon Sep 17 00:00:00 2001
From: Fedora Release Engineering 
Date: Jul 21 2023 01:49:00 +
Subject: Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild


Signed-off-by: Fedora Release Engineering 

---

diff --git a/perl-Sub-Exporter-Lexical.spec b/perl-Sub-Exporter-Lexical.spec
index 533d14e..3ce0345 100644
--- a/perl-Sub-Exporter-Lexical.spec
+++ b/perl-Sub-Exporter-Lexical.spec
@@ -1,6 +1,6 @@
 Name:   perl-Sub-Exporter-Lexical
 Version:1.000
-Release:1%{?dist}
+Release:2%{?dist}
 Summary:Export lexically-available subs with Sub::Exporter
 License:GPL-1.0-or-later OR Artistic-1.0-Perl
 URL:https://metacpan.org/release/Sub-Exporter-Lexical
@@ -54,6 +54,9 @@ rm $RPM_BUILD_ROOT%{perl_vendorlib}/Sub/Exporter/snippet.pl
 %{_mandir}/man3/*
 
 %changelog
+* Fri Jul 21 2023 Fedora Release Engineering  - 
1.000-2
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild
+
 * Tue Apr 04 2023 Ralf Corsépius  - 1.000-1
 - Update to 1.000.
 



https://src.fedoraproject.org/rpms/perl-Sub-Exporter-Lexical/c/976ae3670f78f83ff2d07451b0de87753c615083?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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

releng pushed to rpms/perl-Specio (rawhide). "Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild (..more)"

[notifications]

Notification time stamped 2023-07-21 01:40:08 UTC

From 9468f4c8fc543f3606a6eba672e2ff7a46164b73 Mon Sep 17 00:00:00 2001
From: Fedora Release Engineering 
Date: Jul 21 2023 01:40:03 +
Subject: Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild


Signed-off-by: Fedora Release Engineering 

---

diff --git a/perl-Specio.spec b/perl-Specio.spec
index 824720a..a8e31f7 100644
--- a/perl-Specio.spec
+++ b/perl-Specio.spec
@@ -7,7 +7,7 @@
 
 Name:  perl-Specio
 Version:   0.48
-Release:   3%{?dist}
+Release:   4%{?dist}
 Summary:   Type constraints and coercions for Perl
 # lib/Specio/PartialDump.pm:   GPL-1.0-or-later OR Artistic-1.0-Perl
 #  

@@ -161,6 +161,9 @@ make test
 %{_mandir}/man3/Test::Specio.3*
 
 %changelog
+* Fri Jul 21 2023 Fedora Release Engineering  - 
0.48-4
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild
+
 * Fri Jan 20 2023 Fedora Release Engineering  - 
0.48-3
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_38_Mass_Rebuild
 



https://src.fedoraproject.org/rpms/perl-Specio/c/9468f4c8fc543f3606a6eba672e2ff7a46164b73?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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

releng pushed to rpms/perl-SOAP-WSDL (rawhide). "Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild (..more)"

[notifications]

Notification time stamped 2023-07-21 01:26:34 UTC

From e3b0491220e1b5c40e7913f7b3774f420bae21b7 Mon Sep 17 00:00:00 2001
From: Fedora Release Engineering 
Date: Jul 21 2023 01:26:29 +
Subject: Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild


Signed-off-by: Fedora Release Engineering 

---

diff --git a/perl-SOAP-WSDL.spec b/perl-SOAP-WSDL.spec
index 1012c63..2d36d24 100644
--- a/perl-SOAP-WSDL.spec
+++ b/perl-SOAP-WSDL.spec
@@ -1,7 +1,7 @@
 Summary:   Perl module for SOAP with WSDL support
 Name:  perl-SOAP-WSDL
 Version:   3.004
-Release:   13%{?dist}
+Release:   14%{?dist}
 License:   GPL+ or Artistic
 URL:   https://metacpan.org/release/SOAP-WSDL
 Source:
https://cpan.metacpan.org/modules/by-module/SOAP/SOAP-WSDL-%{version}.tar.gz
@@ -133,6 +133,9 @@ chmod 0755 %{buildroot}%{_bindir}/wsdl2perl.pl
 
 
 %changelog
+* Fri Jul 21 2023 Fedora Release Engineering  - 
3.004-14
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild
+
 * Fri Jan 20 2023 Fedora Release Engineering  - 
3.004-13
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_38_Mass_Rebuild
 



https://src.fedoraproject.org/rpms/perl-SOAP-WSDL/c/e3b0491220e1b5c40e7913f7b3774f420bae21b7?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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

releng pushed to rpms/perl-Return-Type (rawhide). "Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild (..more)"

[notifications]

Notification time stamped 2023-07-21 01:23:03 UTC

From 3e1006980e5998c95cb5c7c6d6c5592fddb1d458 Mon Sep 17 00:00:00 2001
From: Fedora Release Engineering 
Date: Jul 21 2023 01:22:58 +
Subject: Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild


Signed-off-by: Fedora Release Engineering 

---

diff --git a/perl-Return-Type.spec b/perl-Return-Type.spec
index 7d66ab6..e8fe43c 100644
--- a/perl-Return-Type.spec
+++ b/perl-Return-Type.spec
@@ -1,6 +1,6 @@
 Name:   perl-Return-Type
 Version:0.007
-Release:9%{?dist}
+Release:10%{?dist}
 Summary:Specify a return type for a function
 License:GPL-1.0-or-later OR Artistic-1.0-Perl
 URL:https://metacpan.org/release/Return-Type
@@ -54,6 +54,9 @@ library are supported.
 %{_mandir}/man3/*
 
 %changelog
+* Fri Jul 21 2023 Fedora Release Engineering  - 
0.007-10
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild
+
 * Fri Jan 20 2023 Fedora Release Engineering  - 
0.007-9
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_38_Mass_Rebuild
 



https://src.fedoraproject.org/rpms/perl-Return-Type/c/3e1006980e5998c95cb5c7c6d6c5592fddb1d458?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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

releng pushed to rpms/perl-Ref-Util-XS (rawhide). "Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild (..more)"

[notifications]

Notification time stamped 2023-07-21 01:20:15 UTC

From 69a89d6478745fc7aa96a06108728d407596947e Mon Sep 17 00:00:00 2001
From: Fedora Release Engineering 
Date: Jul 21 2023 01:20:10 +
Subject: Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild


Signed-off-by: Fedora Release Engineering 

---

diff --git a/perl-Ref-Util-XS.spec b/perl-Ref-Util-XS.spec
index 431eb3c..fd1b9ae 100644
--- a/perl-Ref-Util-XS.spec
+++ b/perl-Ref-Util-XS.spec
@@ -7,7 +7,7 @@
 
 Name:  perl-Ref-Util-XS
 Version:   0.117
-Release:   19%{?dist}
+Release:   20%{?dist}
 Summary:   Utility functions for checking references
 License:   MIT
 URL:   https://metacpan.org/release/Ref-Util-XS
@@ -70,6 +70,9 @@ make test
 %{_mandir}/man3/Ref::Util::XS.3*
 
 %changelog
+* Fri Jul 21 2023 Fedora Release Engineering  - 
0.117-20
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild
+
 * Tue Jul 11 2023 Jitka Plesnikova  - 0.117-19
 - Perl 5.38 rebuild
 



https://src.fedoraproject.org/rpms/perl-Ref-Util-XS/c/69a89d6478745fc7aa96a06108728d407596947e?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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

releng pushed to rpms/perl-Ref-Util (rawhide). "Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild (..more)"

[notifications]

Notification time stamped 2023-07-21 01:20:05 UTC

From 79a1acee75a36f06b795a3a1c88556b1a1adaa88 Mon Sep 17 00:00:00 2001
From: Fedora Release Engineering 
Date: Jul 21 2023 01:19:59 +
Subject: Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild


Signed-off-by: Fedora Release Engineering 

---

diff --git a/perl-Ref-Util.spec b/perl-Ref-Util.spec
index 77832cf..421152e 100644
--- a/perl-Ref-Util.spec
+++ b/perl-Ref-Util.spec
@@ -7,7 +7,7 @@
 
 Name:  perl-Ref-Util
 Version:   0.204
-Release:   17%{?dist}
+Release:   18%{?dist}
 Summary:   Utility functions for checking references
 License:   MIT
 URL:   https://metacpan.org/release/Ref-Util
@@ -80,6 +80,9 @@ make test
 %{_mandir}/man3/Ref::Util::PP.3*
 
 %changelog
+* Fri Jul 21 2023 Fedora Release Engineering  - 
0.204-18
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild
+
 * Wed May 10 2023 Paul Howarth  - 0.204-17
 - SPDX migration
 - Use %%license unconditionally



https://src.fedoraproject.org/rpms/perl-Ref-Util/c/79a1acee75a36f06b795a3a1c88556b1a1adaa88?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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

releng pushed to rpms/perl-Params-ValidationCompiler (rawhide). "Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild (..more)"

[notifications]

Notification time stamped 2023-07-21 00:52:43 UTC

From 40d2934be1b78764088e4774e5f6f2e8318db1f3 Mon Sep 17 00:00:00 2001
From: Fedora Release Engineering 
Date: Jul 21 2023 00:52:38 +
Subject: Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild


Signed-off-by: Fedora Release Engineering 

---

diff --git a/perl-Params-ValidationCompiler.spec 
b/perl-Params-ValidationCompiler.spec
index ba4326e..051e29f 100644
--- a/perl-Params-ValidationCompiler.spec
+++ b/perl-Params-ValidationCompiler.spec
@@ -7,7 +7,7 @@
 
 Name:  perl-Params-ValidationCompiler
 Version:   0.31
-Release:   2%{?dist}
+Release:   3%{?dist}
 Summary:   Build an optimized subroutine parameter validator once, use it 
forever
 License:   Artistic-2.0
 URL:   https://metacpan.org/release/Params-ValidationCompiler
@@ -86,6 +86,9 @@ make test
 %{_mandir}/man3/Params::ValidationCompiler::Exceptions.3*
 
 %changelog
+* Fri Jul 21 2023 Fedora Release Engineering  - 
0.31-3
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild
+
 * Fri Jan 20 2023 Fedora Release Engineering  - 
0.31-2
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_38_Mass_Rebuild
 



https://src.fedoraproject.org/rpms/perl-Params-ValidationCompiler/c/40d2934be1b78764088e4774e5f6f2e8318db1f3?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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

releng pushed to rpms/perl-Net-LDAP-Server-Test (rawhide). "Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild (..more)"

[notifications]

Notification time stamped 2023-07-21 00:22:37 UTC

From ef7b39f64c6f6fa3165f9ed932799b74e11a4610 Mon Sep 17 00:00:00 2001
From: Fedora Release Engineering 
Date: Jul 21 2023 00:22:31 +
Subject: Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild


Signed-off-by: Fedora Release Engineering 

---

diff --git a/perl-Net-LDAP-Server-Test.spec b/perl-Net-LDAP-Server-Test.spec
index a35a56d..5933fd6 100644
--- a/perl-Net-LDAP-Server-Test.spec
+++ b/perl-Net-LDAP-Server-Test.spec
@@ -1,6 +1,6 @@
 Name:   perl-Net-LDAP-Server-Test
 Version:0.22
-Release:21%{?dist}
+Release:22%{?dist}
 Summary:Test Net::LDAP code
 License:GPL-1.0-or-later OR Artistic-1.0-Perl
 URL:https://metacpan.org/release/Net-LDAP-Server-Test
@@ -67,6 +67,9 @@ Test your Net::LDAP code without having a real LDAP server 
available.
 %{_mandir}/man3/*
 
 %changelog
+* Fri Jul 21 2023 Fedora Release Engineering  - 
0.22-22
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild
+
 * Fri Jan 20 2023 Fedora Release Engineering  - 
0.22-21
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_38_Mass_Rebuild
 



https://src.fedoraproject.org/rpms/perl-Net-LDAP-Server-Test/c/ef7b39f64c6f6fa3165f9ed932799b74e11a4610?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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

releng pushed to rpms/perl-Net-LDAP-Server (rawhide). "Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild (..more)"

[notifications]

Notification time stamped 2023-07-21 00:22:27 UTC

From 3ab22dc19a2f64c508d389d6c3ebfcc85e407591 Mon Sep 17 00:00:00 2001
From: Fedora Release Engineering 
Date: Jul 21 2023 00:22:21 +
Subject: Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild


Signed-off-by: Fedora Release Engineering 

---

diff --git a/perl-Net-LDAP-Server.spec b/perl-Net-LDAP-Server.spec
index 50d00be..76a28f1 100644
--- a/perl-Net-LDAP-Server.spec
+++ b/perl-Net-LDAP-Server.spec
@@ -1,6 +1,6 @@
 Name:   perl-Net-LDAP-Server
 Version:0.43
-Release:22%{?dist}
+Release:23%{?dist}
 Summary:Net::LDAP::Server Perl module
 License:GPL-1.0-or-later OR Artistic-1.0-Perl
 URL:https://metacpan.org/release/Net-LDAP-Server
@@ -57,6 +57,9 @@ connection with the client.
 %{_mandir}/man3/*
 
 %changelog
+* Fri Jul 21 2023 Fedora Release Engineering  - 
0.43-23
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild
+
 * Fri Jan 20 2023 Fedora Release Engineering  - 
0.43-22
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_38_Mass_Rebuild
 



https://src.fedoraproject.org/rpms/perl-Net-LDAP-Server/c/3ab22dc19a2f64c508d389d6c3ebfcc85e407591?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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

releng pushed to rpms/perl-Net-LDAP-SID (rawhide). "Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild (..more)"

[notifications]

Notification time stamped 2023-07-21 00:22:17 UTC

From 8bc0e2c49591e4690450fffa6950a2d97a4ffca2 Mon Sep 17 00:00:00 2001
From: Fedora Release Engineering 
Date: Jul 21 2023 00:22:11 +
Subject: Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild


Signed-off-by: Fedora Release Engineering 

---

diff --git a/perl-Net-LDAP-SID.spec b/perl-Net-LDAP-SID.spec
index 2ccc6bd..b2c1bc8 100644
--- a/perl-Net-LDAP-SID.spec
+++ b/perl-Net-LDAP-SID.spec
@@ -1,6 +1,6 @@
 Name:   perl-Net-LDAP-SID
 Version:0.001
-Release:21%{?dist}
+Release:22%{?dist}
 Summary:Net::LDAP::SID Perl module
 License:Artistic-2.0
 URL:https://metacpan.org/release/Net-LDAP-SID
@@ -42,6 +42,9 @@ Active Directory Security Identifier manipulation
 %{_mandir}/man3/*
 
 %changelog
+* Fri Jul 21 2023 Fedora Release Engineering  - 
0.001-22
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild
+
 * Fri Jan 20 2023 Fedora Release Engineering  - 
0.001-21
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_38_Mass_Rebuild
 



https://src.fedoraproject.org/rpms/perl-Net-LDAP-SID/c/8bc0e2c49591e4690450fffa6950a2d97a4ffca2?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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2224456] New: perl-Catalyst-Runtime-5.90131 is available

[bugzilla]

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

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



Releases retrieved: 5.90131
Upstream release that is considered latest: 5.90131
Current version/release in rawhide: 5.90130-2.fc38
URL: https://metacpan.org/release/Catalyst-Runtime/

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


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


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


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


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


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202224456%23c0
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Java-devel list?

[Peter Boy]

Is there something wrong with the Java-Devel list? 

I can send a message to the list and get no reject or error, but is never shows 
up, at least it looks like that.

Or did I miss something? 





--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
p...@fedoraproject.org

Timezone: CET (UTC+1) / CEST /UTC+2)

Fedora Server Edition Working Group member
Fedora Docs team contributor and board member
Java developer and enthusiast


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

releng pushed to rpms/perl-Module-Extract-Use (rawhide). "Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild (..more)"

[notifications]

Notification time stamped 2023-07-20 23:37:52 UTC

From 4ea96a9010fc63b2875260173d049b523e96347e Mon Sep 17 00:00:00 2001
From: Fedora Release Engineering 
Date: Jul 20 2023 23:37:45 +
Subject: Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild


Signed-off-by: Fedora Release Engineering 

---

diff --git a/perl-Module-Extract-Use.spec b/perl-Module-Extract-Use.spec
index 139265c..77ae9e3 100644
--- a/perl-Module-Extract-Use.spec
+++ b/perl-Module-Extract-Use.spec
@@ -1,7 +1,7 @@
 Summary:   Pull out the modules a module explicitly uses
 Name:  perl-Module-Extract-Use
 Version:   1.051
-Release:   5%{?dist}
+Release:   6%{?dist}
 License:   Artistic-2.0
 URL:   https://metacpan.org/release/Module-Extract-Use
 Source0:   
https://cpan.metacpan.org/modules/by-module/Module/Module-Extract-Use-%{version}.tar.gz
@@ -59,6 +59,9 @@ make test
 %{_mandir}/man3/Module::Extract::Use.3*
 
 %changelog
+* Thu Jul 20 2023 Fedora Release Engineering  - 
1.051-6
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild
+
 * Fri Jan 20 2023 Fedora Release Engineering  - 
1.051-5
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_38_Mass_Rebuild
 



https://src.fedoraproject.org/rpms/perl-Module-Extract-Use/c/4ea96a9010fc63b2875260173d049b523e96347e?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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

releng pushed to rpms/perl-Mock-Config (rawhide). "Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild (..more)"

[notifications]

Notification time stamped 2023-07-20 23:34:37 UTC

From 7f25de28de4f01ff8399adc704fb8b83087b5931 Mon Sep 17 00:00:00 2001
From: Fedora Release Engineering 
Date: Jul 20 2023 23:34:32 +
Subject: Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild


Signed-off-by: Fedora Release Engineering 

---

diff --git a/perl-Mock-Config.spec b/perl-Mock-Config.spec
index 2fefe3c..44f24ff 100644
--- a/perl-Mock-Config.spec
+++ b/perl-Mock-Config.spec
@@ -1,6 +1,6 @@
 Name:   perl-Mock-Config
 Version:0.03
-Release:19%{?dist}
+Release:20%{?dist}
 Summary:Temporarily set Config or XSConfig values
 License:Artistic-2.0
 URL:https://metacpan.org/release/Mock-Config
@@ -43,6 +43,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Thu Jul 20 2023 Fedora Release Engineering  - 
0.03-20
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild
+
 * Fri Jan 20 2023 Fedora Release Engineering  - 
0.03-19
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_38_Mass_Rebuild
 



https://src.fedoraproject.org/rpms/perl-Mock-Config/c/7f25de28de4f01ff8399adc704fb8b83087b5931?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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

releng pushed to rpms/perl-Mail-Transport (rawhide). "Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild (..more)"

[notifications]

Notification time stamped 2023-07-20 23:23:38 UTC

From 2dc3ecdfaee6bf46825ed01a5167e92f90fb61ed Mon Sep 17 00:00:00 2001
From: Fedora Release Engineering 
Date: Jul 20 2023 23:23:32 +
Subject: Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild


Signed-off-by: Fedora Release Engineering 

---

diff --git a/perl-Mail-Transport.spec b/perl-Mail-Transport.spec
index 6c97ad8..ef431b4 100644
--- a/perl-Mail-Transport.spec
+++ b/perl-Mail-Transport.spec
@@ -1,6 +1,6 @@
 Name:  perl-Mail-Transport
 Version:   3.005
-Release:   8%{?dist}
+Release:   9%{?dist}
 Summary:   Email message exchange
 License:   GPL-1.0-or-later OR Artistic-1.0-Perl
 URL:   https://metacpan.org/release/Mail-Transport
@@ -67,6 +67,9 @@ make test
 %{_mandir}/man3/Mail::Transport::Sendmail.3*
 
 %changelog
+* Thu Jul 20 2023 Fedora Release Engineering  - 
3.005-9
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild
+
 * Fri Jan 20 2023 Fedora Release Engineering  - 
3.005-8
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_38_Mass_Rebuild
 



https://src.fedoraproject.org/rpms/perl-Mail-Transport/c/2dc3ecdfaee6bf46825ed01a5167e92f90fb61ed?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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

releng pushed to rpms/perl-Mail-Message (rawhide). "Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild (..more)"

[notifications]

Notification time stamped 2023-07-20 23:22:17 UTC

From 8386eb4bbc365c58be2d471a05fe62dc0909e697 Mon Sep 17 00:00:00 2001
From: Fedora Release Engineering 
Date: Jul 20 2023 23:22:12 +
Subject: Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild


Signed-off-by: Fedora Release Engineering 

---

diff --git a/perl-Mail-Message.spec b/perl-Mail-Message.spec
index 02c843e..069bd0c 100644
--- a/perl-Mail-Message.spec
+++ b/perl-Mail-Message.spec
@@ -1,6 +1,6 @@
 Name:  perl-Mail-Message
 Version:   3.013
-Release:   1%{?dist}
+Release:   2%{?dist}
 Summary:   MIME message handling
 License:   GPL-1.0-or-later OR Artistic-1.0-Perl
 URL:   https://metacpan.org/release/Mail-Message
@@ -124,6 +124,9 @@ make test
 %{_mandir}/man3/Mail::*.3*
 
 %changelog
+* Thu Jul 20 2023 Fedora Release Engineering  - 
3.013-2
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild
+
 * Sun Jun 25 2023 Paul Howarth  - 3.013-1
 - Update to 3.013 (rhbz#2217164)
 



https://src.fedoraproject.org/rpms/perl-Mail-Message/c/8386eb4bbc365c58be2d471a05fe62dc0909e697?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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

releng pushed to rpms/perl-Mail-Box-POP3 (rawhide). "Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild (..more)"

[notifications]

Notification time stamped 2023-07-20 23:20:56 UTC

From ce3b7718cf5f7501b740fef9e0c98e05137c2e37 Mon Sep 17 00:00:00 2001
From: Fedora Release Engineering 
Date: Jul 20 2023 23:20:51 +
Subject: Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild


Signed-off-by: Fedora Release Engineering 

---

diff --git a/perl-Mail-Box-POP3.spec b/perl-Mail-Box-POP3.spec
index 9df0407..6111514 100644
--- a/perl-Mail-Box-POP3.spec
+++ b/perl-Mail-Box-POP3.spec
@@ -1,6 +1,6 @@
 Name:   perl-Mail-Box-POP3
 Version:3.005
-Release:13%{?dist}
+Release:14%{?dist}
 Summary:Handle POP3 folders as client
 License:GPL-1.0-or-later OR Artistic-1.0-Perl
 URL:https://metacpan.org/release/Mail-Box-POP3
@@ -75,6 +75,9 @@ MARKOV_DEVEL=1 make test
 %{_mandir}/man3/*
 
 %changelog
+* Thu Jul 20 2023 Fedora Release Engineering  - 
3.005-14
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild
+
 * Fri Jan 20 2023 Fedora Release Engineering  - 
3.005-13
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_38_Mass_Rebuild
 



https://src.fedoraproject.org/rpms/perl-Mail-Box-POP3/c/ce3b7718cf5f7501b740fef9e0c98e05137c2e37?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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

releng pushed to rpms/perl-MCE-Shared (rawhide). "Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild (..more)"

[notifications]

Notification time stamped 2023-07-20 23:17:39 UTC

From bab68cf798fa3f1d08e4d9e9224e17104b246257 Mon Sep 17 00:00:00 2001
From: Fedora Release Engineering 
Date: Jul 20 2023 23:17:34 +
Subject: Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild


Signed-off-by: Fedora Release Engineering 

---

diff --git a/perl-MCE-Shared.spec b/perl-MCE-Shared.spec
index bd0b895..c869b80 100644
--- a/perl-MCE-Shared.spec
+++ b/perl-MCE-Shared.spec
@@ -1,6 +1,6 @@
 Name:  perl-MCE-Shared
 Version:   1.885
-Release:   1%{?dist}
+Release:   2%{?dist}
 Summary:   MCE extension for sharing data, supporting threads and processes
 License:   GPL-1.0-or-later OR Artistic-1.0-Perl
 URL:   https://metacpan.org/release/MCE-Shared
@@ -92,6 +92,9 @@ make test
 %{_mandir}/man3/MCE::Shared::Server.3*
 
 %changelog
+* Thu Jul 20 2023 Fedora Release Engineering  - 
1.885-2
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild
+
 * Fri Jun  9 2023 Paul Howarth  - 1.885-1
 - Update to 1.885
   - Fix typo in Queue dequeue_timed documentation



https://src.fedoraproject.org/rpms/perl-MCE-Shared/c/bab68cf798fa3f1d08e4d9e9224e17104b246257?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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

releng pushed to rpms/perl-List-MoreUtils-XS (rawhide). "Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild (..more)"

[notifications]

Notification time stamped 2023-07-20 23:08:33 UTC

From f6bf3b0443896b20c99929721ae4bcc08cc65347 Mon Sep 17 00:00:00 2001
From: Fedora Release Engineering 
Date: Jul 20 2023 23:08:27 +
Subject: Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild


Signed-off-by: Fedora Release Engineering 

---

diff --git a/perl-List-MoreUtils-XS.spec b/perl-List-MoreUtils-XS.spec
index 747c097..c3e7b31 100644
--- a/perl-List-MoreUtils-XS.spec
+++ b/perl-List-MoreUtils-XS.spec
@@ -7,7 +7,7 @@
 
 Name:  perl-List-MoreUtils-XS
 Version:   0.430
-Release:   10%{?dist}
+Release:   11%{?dist}
 Summary:   Provide compiled List::MoreUtils functions
 # Code from List-MoreUtils < 0.417 is GPL-1.0-or-later OR Artistic-1.0-Perl
 # Anything after that is Apache-2.0
@@ -89,6 +89,9 @@ make test
 %{_mandir}/man3/List::MoreUtils::XS.3*
 
 %changelog
+* Thu Jul 20 2023 Fedora Release Engineering  - 
0.430-11
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild
+
 * Tue Jul 11 2023 Jitka Plesnikova  - 0.430-10
 - Perl 5.38 rebuild
 



https://src.fedoraproject.org/rpms/perl-List-MoreUtils-XS/c/f6bf3b0443896b20c99929721ae4bcc08cc65347?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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2224451] New: perl-Module-CoreList-5.20230720 is available

[bugzilla]

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

Bug ID: 2224451
   Summary: perl-Module-CoreList-5.20230720 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Module-CoreList
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com, mspa...@redhat.com,
perl-devel@lists.fedoraproject.org, spo...@gmail.com,
st...@silug.org
  Target Milestone: ---
Classification: Fedora



Releases retrieved: 5.20230720
Upstream release that is considered latest: 5.20230720
Current version/release in rawhide: 5.20230520-499.fc39
URL: https://metacpan.org/dist/Module-CoreList/

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


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


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


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


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


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202224451%23c0
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Should Fedora switch to full kernel preemption (CONFIG_PREEMPT=y)?

[stan via devel]

On Thu, 20 Jul 2023 09:17:51 -0500
Justin Forbes  wrote:

> for them. I have been running preempt=full for quite some time on my
> desktops systems here.

I've been running custom compiled kernels with preempt_full=Y on my
desktop for several years (since at least kernel 5.1). Currently
running 6.5 with it enabled.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

releng pushed to rpms/perl-IO-FDPass (rawhide). "Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild (..more)"

[notifications]

Notification time stamped 2023-07-20 22:39:37 UTC

From 7d3912af22d1a3398843dd20fc48d73145fdf44b Mon Sep 17 00:00:00 2001
From: Fedora Release Engineering 
Date: Jul 20 2023 22:39:31 +
Subject: Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild


Signed-off-by: Fedora Release Engineering 

---

diff --git a/perl-IO-FDPass.spec b/perl-IO-FDPass.spec
index 0d1f23d..91a369a 100644
--- a/perl-IO-FDPass.spec
+++ b/perl-IO-FDPass.spec
@@ -1,6 +1,6 @@
 Name:  perl-IO-FDPass
 Version:   1.3
-Release:   9%{?dist}
+Release:   10%{?dist}
 Summary:   Pass a file descriptor over a socket
 License:   GPL-1.0-or-later OR Artistic-1.0-Perl
 URL:   https://metacpan.org/release/IO-FDPass
@@ -57,6 +57,9 @@ make test
 %{_mandir}/man3/IO::FDPass.3*
 
 %changelog
+* Thu Jul 20 2023 Fedora Release Engineering  - 
1.3-10
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild
+
 * Tue Jul 11 2023 Jitka Plesnikova  - 1.3-9
 - Perl 5.38 rebuild
 



https://src.fedoraproject.org/rpms/perl-IO-FDPass/c/7d3912af22d1a3398843dd20fc48d73145fdf44b?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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

releng pushed to rpms/perl-HTTP-MultiPartParser (rawhide). "Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild (..more)"

[notifications]

Notification time stamped 2023-07-20 22:29:33 UTC

From 3c29b715501213dba50a81c4fd57a1780c474834 Mon Sep 17 00:00:00 2001
From: Fedora Release Engineering 
Date: Jul 20 2023 22:29:28 +
Subject: Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild


Signed-off-by: Fedora Release Engineering 

---

diff --git a/perl-HTTP-MultiPartParser.spec b/perl-HTTP-MultiPartParser.spec
index 76a52ca..2f4a14a 100644
--- a/perl-HTTP-MultiPartParser.spec
+++ b/perl-HTTP-MultiPartParser.spec
@@ -1,6 +1,6 @@
 Name:   perl-HTTP-MultiPartParser
 Version:0.02
-Release:20%{?dist}
+Release:21%{?dist}
 Summary:HTTP MultiPart Parser
 License:GPL-1.0-or-later OR Artistic-1.0-Perl
 URL:https://metacpan.org/release/HTTP-MultiPartParser
@@ -58,6 +58,9 @@ streams conforming to MultiPart types as defined in RFC 2616.
 %{_mandir}/man3/*
 
 %changelog
+* Thu Jul 20 2023 Fedora Release Engineering  - 
0.02-21
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild
+
 * Fri Jan 20 2023 Fedora Release Engineering  - 
0.02-20
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_38_Mass_Rebuild
 



https://src.fedoraproject.org/rpms/perl-HTTP-MultiPartParser/c/3c29b715501213dba50a81c4fd57a1780c474834?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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

releng pushed to rpms/perl-HTTP-Entity-Parser (rawhide). "Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild (..more)"

[notifications]

Notification time stamped 2023-07-20 22:28:21 UTC

From 04dabc1b5b74b5ac56a236fde7e25de142bafb33 Mon Sep 17 00:00:00 2001
From: Fedora Release Engineering 
Date: Jul 20 2023 22:28:15 +
Subject: Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild


Signed-off-by: Fedora Release Engineering 

---

diff --git a/perl-HTTP-Entity-Parser.spec b/perl-HTTP-Entity-Parser.spec
index ff9c9c6..242cbec 100644
--- a/perl-HTTP-Entity-Parser.spec
+++ b/perl-HTTP-Entity-Parser.spec
@@ -1,6 +1,6 @@
 Name:   perl-HTTP-Entity-Parser
 Version:0.25
-Release:9%{?dist}
+Release:10%{?dist}
 Summary:PSGI compliant HTTP Entity Parser
 License:GPL-1.0-or-later OR Artistic-1.0-Perl
 URL:https://metacpan.org/release/HTTP-Entity-Parser
@@ -68,6 +68,9 @@ data and application/json.
 %{_mandir}/man3/*
 
 %changelog
+* Thu Jul 20 2023 Fedora Release Engineering  - 
0.25-10
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild
+
 * Fri Jan 20 2023 Fedora Release Engineering  - 
0.25-9
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_38_Mass_Rebuild
 



https://src.fedoraproject.org/rpms/perl-HTTP-Entity-Parser/c/04dabc1b5b74b5ac56a236fde7e25de142bafb33?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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: python3 build failure

[Yaakov Selkowitz]

On Thu, 2023-07-20 at 15:38 -0400, Steve Dickson wrote:
> On 7/20/23 2:09 PM, Yaakov Selkowitz wrote:
> > On Thu, 2023-07-20 at 13:59 -0400, Steve Dickson wrote:
> > > This bz[1] was opened on one of my packages not building on f39.
> > > I did a quick rawhide scratch build and sure enough
> > > the build fails with [2]
> > 
> > The important part is earlier in the log:
> > 
> > ModuleNotFoundError: No module named 'distutils'
> > 
> > distutils was removed in 3.12 for https://peps.python.org/pep-0632/
> > 
> > Solution: Add BuildRequires: python3-setuptools to get it building
> > for
> > now, and work with upstream to migrate to a modern Python packaging
> > setup.
> Yes... this was the needed required package.
> 
> > 
> > > But when I do the build locally on both f38 and rawhide (f39)
> > > there is no problem and I do have a "BuildRequires: python3-
> > > devel"
> > > in the spec file so I'm a bit lost as to what can be the
> > > problem...
> > 
> > F38 is on Python 3.11, where distutils still exists.  Your mock
> > cache
> > must be stale if local rawhide builds are still succeeding without
> > this.
> > 
> Well the F38 scratch build still builds w/out add adding
> new dependency... should I go ahead and add it or not worry
> about it?

There is no harm in adding the BuildRequires to any stable branches,
but rawhide (f39) is the only branch where it is strictly required in
order to build.

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

releng pushed to rpms/perl-Encode-IMAPUTF7 (rawhide). "Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild (..more)"

[notifications]

Notification time stamped 2023-07-20 21:29:39 UTC

From 9658e30de65e1edd139905ed0590b9fb073d99a6 Mon Sep 17 00:00:00 2001
From: Fedora Release Engineering 
Date: Jul 20 2023 21:29:33 +
Subject: Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild


Signed-off-by: Fedora Release Engineering 

---

diff --git a/perl-Encode-IMAPUTF7.spec b/perl-Encode-IMAPUTF7.spec
index 3ec8c0b..dcbf879 100644
--- a/perl-Encode-IMAPUTF7.spec
+++ b/perl-Encode-IMAPUTF7.spec
@@ -2,7 +2,7 @@
 
 Name:   perl-Encode-IMAPUTF7
 Version:1.05
-Release:21%{?dist}
+Release:22%{?dist}
 Summary:Process the special UTF-7 variant required by IMAP
 License:GPL+ or Artistic
 URL:https://metacpan.org/release/Encode-IMAPUTF7
@@ -41,6 +41,9 @@ make test
 %_mandir/man3/*
 
 %changelog
+* Thu Jul 20 2023 Fedora Release Engineering  - 
1.05-22
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild
+
 * Fri Jan 20 2023 Fedora Release Engineering  - 
1.05-21
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_38_Mass_Rebuild
 



https://src.fedoraproject.org/rpms/perl-Encode-IMAPUTF7/c/9658e30de65e1edd139905ed0590b9fb073d99a6?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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2224450] New: perl-CPAN-Perl-Releases-5.20230720 is available

[bugzilla]

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

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



Releases retrieved: 5.20230720
Upstream release that is considered latest: 5.20230720
Current version/release in rawhide: 5.20230703-1.fc39
URL: https://metacpan.org/dist/CPAN-Perl-Releases/

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


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


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


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


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


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202224450%23c0
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Potential changes to systemd RPM macros

[Kevin Fenzi]

On Thu, Jul 20, 2023 at 07:40:08AM -0700, Andrea Bolognani wrote:
> Hi,
> 
> this requires a bit of background, so please bear with me :)

Thanks for all the background... :)

...snip reasonable stuff...

I agree that an upstream systemd solution is what we should strive for.

> The problem is that Fedora 39 and RHEL 9.3 are fast approaching and,
> if we don't do anything about this issue before then, a subset of
> libvirt users will see their deployments broken after upgrade. In the
> interest of avoiding that, I would prefer to get the libvirt-specific
> version of the macros merged as soon as possible, and focus on
> upstreaming the work all the way to systemd as a follow-up.

Do you have a patch/PR we could look at to show what exactly these
macros look like? 

> Does this plan sound reasonable to the Fedora community? Are there
> any serious concerns regarding the approach taken for the macros that
> would cause them to be considered a complete no-go? Any scenarios
> that I might have missed while implementing them?

Not sure, but possibly. :)

If for some reason this didn't turn out to be something we wanted to
ship, what does the 'manual fix' look like? Complex? 

kevin


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

releng pushed to rpms/perl-DateTime-Calendar-Julian (rawhide). "Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild (..more)"

[notifications]

Notification time stamped 2023-07-20 21:00:04 UTC

From 3b9043e270bb8f23d5ca7251edb734f20e2de3af Mon Sep 17 00:00:00 2001
From: Fedora Release Engineering 
Date: Jul 20 2023 20:59:58 +
Subject: Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild


Signed-off-by: Fedora Release Engineering 

---

diff --git a/perl-DateTime-Calendar-Julian.spec 
b/perl-DateTime-Calendar-Julian.spec
index 2c93c7c..8fbc1d6 100644
--- a/perl-DateTime-Calendar-Julian.spec
+++ b/perl-DateTime-Calendar-Julian.spec
@@ -1,6 +1,6 @@
 Name:  perl-DateTime-Calendar-Julian
 Version:   0.107
-Release:   4%{?dist}
+Release:   5%{?dist}
 License:   GPL+ or Artistic
 Summary:   Julian Calendar support for DateTime.pm
 Url:   https://metacpan.org/release/DateTime-Calendar-Julian
@@ -38,6 +38,9 @@ make test
 %{_mandir}/man3/DateTime::Calendar::Julian.3pm*
 
 %changelog
+* Thu Jul 20 2023 Fedora Release Engineering  - 
0.107-5
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild
+
 * Fri Jan 20 2023 Fedora Release Engineering  - 
0.107-4
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_38_Mass_Rebuild
 



https://src.fedoraproject.org/rpms/perl-DateTime-Calendar-Julian/c/3b9043e270bb8f23d5ca7251edb734f20e2de3af?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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Making sense of golang packaging guidelines

[Carlos Rodriguez Fernandez]

Hi Fabio, Robert-André,

Thank you for the explanation. It makes sense.
Golang has this uniqueness about libs that removes some of the shared
objects pros but I see there are other things at play.

Thank you,
Carlos.

On Thu, Jul 20, 2023 at 1:44 PM  wrote:

> On 7/20/23 8:20 PM, Carlos Rodriguez Fernandez <
> carlosrodrifernan...@gmail.com> wrote:
> > Hi all,
> >
> > I am interested in packaging some golang programs for Fedora (and EPEL),
> and I read through
> > the guidelines:
> > https://docs.fedoraproject.org/en-US/packaging-guidelines/Golang/
> > 
> >
> > My question is more about the reasoning for the recommended handling of
> dependencies.
> >
> > Other language platforms have shared runtime objects, and devel packages
> provide the
> > interface to link to them when necessary; however golang compiles it all
> statically. It is
> > very easy to bring all the dependencies locally for compilation directly
> from git repos and
> > then nothing is necessary at runtime.
> >
> > Creating rpm packages for each golang dependency seems counterproductive
> as it adds an
> > additional burden to maintain without the benefits of shared runtime
> objects.
> >
> > I have the feeling I am missing something. What is the benefit of having
> each golang build
> > dependency as rpms?
> > Is it a requirement for golang programs rpm contributions or it is
> optional? (e.g.
> > prometheus in EPEL9 does not follow the deps handling guidelines but not
> sure if it is a
> > tech debt or an option).
> >
> >
> > Thank you,
> > Carlos
> >
>
> We need to build into Koji, there is no "local build". As such we have two
> options :
>  - bundle the dependencies in the package
>  - package all the libraries separately
>
> The Fedora guidelines is to package library separately, per
> https://docs.fedoraproject.org/en-US/fesco/Bundled_Software_policy/ :
>
>
>
> All packages whose upstreams allow them to be built against system
> libraries must be built against system libraries.
>
> All packages whose upstreams have no mechanism to build against system
> libraries must be contacted publicly about a path to supporting system
> libraries. If upstream refuses, this must be recorded in the spec file
> using a persistent mechanism to be clarified in the packaging guidelines.
>
> All packages whose upstreams have no mechanism to build against system
> libraries may opt to carry bundled libraries, but if they do, they must
> include Provides: bundled() = in their RPM spec file.
>
>
> This policy only applies to Fedora. In EPEL we bundle because we don't
> have our macros and the Go ecosystem is not bootstrapped.
>
> Best regards,
>
> Robert-André
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: proposed change to FESCo voting rules

[Ben Cotton]

On Thu, Jul 20, 2023 at 3:46 PM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> Stephen Gallagher proposed a change to FESCo voting rules [1].

This will be helpful to people who aren't regularly involved in FESCo
votes. If that's you: the proposal presented here is largely
clarification. There's not much in the way of substance change.

I did notice that the "fast track" voting mechanism fell out. I think
that's worth preserving.

Also, the proposal says "eligible voters" a lot. Let's replace it with
"FESCo members" to make it more clear that it's not a wide-open vote.
If you really want, you can say "eligible FESCo members", but there's
not been any case that I'm aware of where a FESCo member was
ineligible to vote on something, so adding that word inserts
unnecessary complexity.

> Change ticket is assumed to be a a formal proposal upon creation.

Duplicate "a"

> An official vote in a ticket must be one of +1, -1 as defined herein:

I suggest striking "as defined herein" for simplicity. Also you may
want to include 0 in the sentence since it's in the list that follows.

> At the end of one week, if a ticket has at least 3 votes of +1 and no
> votes of -1, it is approved and may proceed with implementation. If
> there is at least one -1 vote, the ticket must be added to the
> upcoming meeting agenda and subject to the Meeting Votes rules.

I'd make that "…and is subject…"

> A proposal must achieve a majority (at least 51%) of +1 votes from
> eligible voters. Votes must be one of +1, 0 or -1 as defined herein:

s/as defined herein/g :-)

> +1 I am in favor of the proposal as currently written.
>
> 0 I am electing to remove myself from the list of eligible
> voters. This reduces the denominator of the fraction required to
> achieve the 51% majority. In effect, I am agreeing to vote with
> the remaining majority, whatever they decide.
>
> -1 I am opposed to the proposal as currently written.

This largely duplicates the definitions for in-ticket votes. It might
be better to just refer to that and add the special meaning of 0.
Something like:

A proposal must achieve a majority (at least 51%) of +1 votes from
eligible voters. Votes must be one of +1, 0 or -1 as described in
Ticket votes. In a meeting vote, a vote of 0 reduces the denominator
of the fraction required to achieve the 51% majority. In effect, it
says "I am agreeing to vote with the remaining majority, whatever they
decide."


-- 
Ben Cotton (he/him)
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/User:Bcotton
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

releng pushed to rpms/perl-Crypt-IDEA (rawhide). "Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild (..more)"

[notifications]

Notification time stamped 2023-07-20 20:29:28 UTC

From ccd1d0bc51d9d2e52651f5268333715c25a26908 Mon Sep 17 00:00:00 2001
From: Fedora Release Engineering 
Date: Jul 20 2023 20:29:23 +
Subject: Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild


Signed-off-by: Fedora Release Engineering 

---

diff --git a/perl-Crypt-IDEA.spec b/perl-Crypt-IDEA.spec
index fed3918..f8f9ba5 100644
--- a/perl-Crypt-IDEA.spec
+++ b/perl-Crypt-IDEA.spec
@@ -1,7 +1,7 @@
 Summary:   Perl interface to IDEA block cipher
 Name:  perl-Crypt-IDEA
 Version:   1.10
-Release:   27%{?dist}
+Release:   28%{?dist}
 License:   BSD with advertising
 URL:   https://metacpan.org/release/Crypt-IDEA
 Source0:   
https://cpan.metacpan.org/modules/by-module/Crypt/Crypt-IDEA-%{version}.tar.gz
@@ -64,6 +64,9 @@ make test
 %{_mandir}/man3/Crypt::IDEA.3*
 
 %changelog
+* Thu Jul 20 2023 Fedora Release Engineering  - 
1.10-28
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild
+
 * Tue Jul 11 2023 Jitka Plesnikova  - 1.10-27
 - Perl 5.38 rebuild
 



https://src.fedoraproject.org/rpms/perl-Crypt-IDEA/c/ccd1d0bc51d9d2e52651f5268333715c25a26908?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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

releng pushed to rpms/perl-Cookie-Baker (rawhide). "Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild (..more)"

[notifications]

Notification time stamped 2023-07-20 20:25:49 UTC

From 5b163921e973941e6e972232d18f813dc81c8af7 Mon Sep 17 00:00:00 2001
From: Fedora Release Engineering 
Date: Jul 20 2023 20:25:44 +
Subject: Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild


Signed-off-by: Fedora Release Engineering 

---

diff --git a/perl-Cookie-Baker.spec b/perl-Cookie-Baker.spec
index affb341..bab4f87 100644
--- a/perl-Cookie-Baker.spec
+++ b/perl-Cookie-Baker.spec
@@ -1,6 +1,6 @@
 Name:   perl-Cookie-Baker
 Version:0.11
-Release:13%{?dist}
+Release:14%{?dist}
 Summary:Cookie string generator / parser
 License:GPL-1.0-or-later OR Artistic-1.0-Perl
 URL:https://metacpan.org/release/Cookie-Baker
@@ -49,6 +49,9 @@ Cookie::Baker provides simple cookie string generator and 
parser.
 %{_mandir}/man3/*
 
 %changelog
+* Thu Jul 20 2023 Fedora Release Engineering  - 
0.11-14
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild
+
 * Fri Jan 20 2023 Fedora Release Engineering  - 
0.11-13
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_38_Mass_Rebuild
 



https://src.fedoraproject.org/rpms/perl-Cookie-Baker/c/5b163921e973941e6e972232d18f813dc81c8af7?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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

releng pushed to rpms/perl-Code-TidyAll-Plugin-Test-Vars (rawhide). "Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild (..more)"

[notifications]

Notification time stamped 2023-07-20 20:13:53 UTC

From c24c31bed5a044432a70bc737164d74afb888ec3 Mon Sep 17 00:00:00 2001
From: Fedora Release Engineering 
Date: Jul 20 2023 20:13:48 +
Subject: Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild


Signed-off-by: Fedora Release Engineering 

---

diff --git a/perl-Code-TidyAll-Plugin-Test-Vars.spec 
b/perl-Code-TidyAll-Plugin-Test-Vars.spec
index 55b2b4e..948c2a9 100644
--- a/perl-Code-TidyAll-Plugin-Test-Vars.spec
+++ b/perl-Code-TidyAll-Plugin-Test-Vars.spec
@@ -1,6 +1,6 @@
 Name:   perl-Code-TidyAll-Plugin-Test-Vars
 Version:0.04
-Release:21%{?dist}
+Release:22%{?dist}
 Summary:Provides Test::Vars plugin for Code::TidyAll
 License:GPL-1.0-or-later OR Artistic-1.0-Perl
 URL:https://metacpan.org/release/Code-TidyAll-Plugin-Test-Vars
@@ -56,6 +56,9 @@ This module uses Test::Vars to detect unused variables in 
Perl modules.
 %{_mandir}/man3/*
 
 %changelog
+* Thu Jul 20 2023 Fedora Release Engineering  - 
0.04-22
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild
+
 * Fri Jan 20 2023 Fedora Release Engineering  - 
0.04-21
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_38_Mass_Rebuild
 



https://src.fedoraproject.org/rpms/perl-Code-TidyAll-Plugin-Test-Vars/c/c24c31bed5a044432a70bc737164d74afb888ec3?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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

releng pushed to rpms/perl-Class-Std-Fast (rawhide). "Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild (..more)"

[notifications]

Notification time stamped 2023-07-20 20:11:32 UTC

From da80016ba97bdcb43025058ed39e31ee356ab624 Mon Sep 17 00:00:00 2001
From: Fedora Release Engineering 
Date: Jul 20 2023 20:11:26 +
Subject: Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild


Signed-off-by: Fedora Release Engineering 

---

diff --git a/perl-Class-Std-Fast.spec b/perl-Class-Std-Fast.spec
index 8403dbf..0897bf1 100644
--- a/perl-Class-Std-Fast.spec
+++ b/perl-Class-Std-Fast.spec
@@ -1,6 +1,6 @@
 Name:   perl-Class-Std-Fast
 Version:0.0.8
-Release:22%{?dist}
+Release:23%{?dist}
 Summary:Faster but less secure replacement for Class::Std
 License:GPL+ or Artistic
 URL:https://metacpan.org/release/Class-Std-Fast
@@ -67,6 +67,9 @@ make test
 
 
 %changelog
+* Thu Jul 20 2023 Fedora Release Engineering  - 
0.0.8-23
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild
+
 * Fri Jan 20 2023 Fedora Release Engineering  - 
0.0.8-22
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_38_Mass_Rebuild
 



https://src.fedoraproject.org/rpms/perl-Class-Std-Fast/c/da80016ba97bdcb43025058ed39e31ee356ab624?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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Fedora rawhide compose report: 20230720.n.1 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20230719.n.0
NEW: Fedora-Rawhide-20230720.n.1

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

Size of added packages:  15.69 MiB
Size of dropped packages:0 B
Size of upgraded packages:   3.71 GiB
Size of downgraded packages: 3.06 MiB

Size change of upgraded packages:   11.80 MiB
Size change of downgraded packages: 312 B

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

= DROPPED IMAGES =
Image: LXQt live aarch64
Path: Spins/aarch64/iso/Fedora-LXQt-Live-aarch64-Rawhide-20230719.n.0.iso
Image: i3 live aarch64
Path: Spins/aarch64/iso/Fedora-i3-Live-aarch64-Rawhide-20230719.n.0.iso

= ADDED PACKAGES =
Package: publican-4.3.2-26.fc39
Summary: Common files and scripts for publishing with DocBook XML
RPMs:publican publican-common-db5-web publican-common-web publican-doc 
publican-releasenotes
Size:5.24 MiB

Package: python-cython0.29-0.29.35-3.fc39
Summary: Cython 0.29.x for compatibility purposes
RPMs:python3-cython0.29
Size:10.41 MiB

Package: rust-msru-0.2.0-1
Summary: Rust-safe library for interacting with Model Specific Registers in 
user-space
RPMs:rust-msru+default-devel rust-msru-devel
Size:20.70 KiB

Package: rust-sha1-asm-0.5.1-1.fc39
Summary: Assembly implementation of SHA-1 compression function
RPMs:rust-sha1-asm+default-devel rust-sha1-asm-devel
Size:20.94 KiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  Cython-3.0.0-1.fc39
Old package:  Cython-0.29.35-2.fc39
Summary:  Language for writing Python extension modules
RPMs: python3-cython
Added RPMs:   python3-cython
Dropped RPMs: emacs-cython-mode python3-Cython
Size: 15.26 MiB
Size change:  2.22 MiB
Changelog:
  * Thu Jul 13 2023 Tom Hrn??iar  - 3.0.0~rc2-1
  - Update to 3.0.0rc2
  - The emacs-cython-mode package is no longer part of this project

  * Mon Jul 17 2023 Miro Hron??ok  - 3.0.0-1
  - Update to 3.0.0
  - Rename python3-Cython to python3-cython


Package:  TeXmacs-2.1.2-4.fc39
Old package:  TeXmacs-2.1.2-3.fc38
Summary:  Structured WYSIWYG scientific text editor
RPMs: TeXmacs TeXmacs-devel texmacs-fedora-fonts
Size: 220.05 MiB
Size change:  87.71 KiB
Changelog:
  * Wed Jul 19 2023 Fedora Release Engineering  - 
2.1.2-4
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild


Package:  Zim-0.75.2-3.fc39
Old package:  Zim-0.75.1-2.fc38
Summary:  Desktop wiki & notekeeper
RPMs: Zim
Size: 2.27 MiB
Size change:  -23.05 KiB
Changelog:
  * Thu Jun 15 2023 Python Maint  - 0.75.1-3
  - Rebuilt for Python 3.12

  * Wed Jul 19 2023 Fedora Release Engineering  - 
0.75.1-4
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild

  * Wed Jul 19 2023 Yaakov Selkowitz  - 0.75.1-5
  - Fix build with Python 3.12

  * Wed Jul 19 2023 Otto Liljalaakso  - 0.75.2-1
  - Update to 0.75.2 (rhbz#2221307)

  * Thu Jul 20 2023 Otto Liljalaakso  - 0.75.2-2
  - License review, migrate to SPDX license identifiers

  * Thu Jul 20 2023 Otto Liljalaakso  - 0.75.2-3
  - Exclude i686 architecture


Package:  apptainer-1.2.0-1.fc39
Old package:  apptainer-1.2.0~rc.2-1.fc39
Summary:  Application and environment virtualization formerly known as 
Singularity
RPMs: apptainer apptainer-suid
Size: 121.33 MiB
Size change:  320.00 KiB
Changelog:
  * Wed Jul 19 2023 Fedora Release Engineering  - 
1.2.0~rc.2-2
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild

  * Tue Jul 25 2023 Dave Dykstra  - 1.2.0
  - Update to upstream 1.2.0


Package:  aubio-0.4.9-18.fc39
Old package:  aubio-0.4.9-15.fc38
Summary:  An audio labeling tool
RPMs: aubio aubio-devel aubio-lib aubio-python3
Size: 2.65 MiB
Size change:  -29.44 KiB
Changelog:
  * Tue Jun 13 2023 Python Maint  - 0.4.9-16
  - Rebuilt for Python 3.12

  * Wed Jul 19 2023 Fedora Release Engineering  - 
0.4.9-17
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild

  * Thu Jul 20 2023 Guido Aulisi  - 0.4.9-18
  - Fix FTBFS with Python 3.12 #2219938


Package:  azure-cli-2.50.0-7.fc39
Old package:  azure-cli-2.50.0-3.fc39
Summary:  Microsoft Azure Command-Line Tools
RPMs: azure-cli python3-azure-cli-core python3-azure-cli-telemetry 
python3-azure-cli-testsdk
Size: 10.83 MiB
Size change:  3.08 KiB
Changelog:
  * Fri Jul 14 2023 Python Maint  - 2.50.0-4
  - Rebuilt for Python 

proposed change to FESCo voting rules

[Zbigniew Jędrzejewski-Szmek]

Hi,

Stephen Gallagher proposed a change to FESCo voting rules [1].

The latest draft:

--&<-
Ticket Votes (Preferred)

Once a formal proposal is made in a ticket, voting will proceed. A
Change ticket is assumed to be a a formal proposal upon creation.

An official vote in a ticket must be one of +1, -1 as defined herein:

+1 — I am in favor of the proposal as currently written.

0 — I am electing to remove myself from the list of eligible
voters. This has no effect unless the ticket votes are used for a
meeting vote.

-1 — I am opposed to the proposal as currently written. This topic
 must be discussed live in a meeting.

At the end of one week, if a ticket has at least 3 votes of +1 and no
votes of -1, it is approved and may proceed with implementation. If
there is at least one -1 vote, the ticket must be added to the
upcoming meeting agenda and subject to the Meeting Votes rules.

If there are insufficient +1 votes at the end of one week, one
additional week will be granted. At the end of this period, if there
is at least one +1 vote and no votes of -1, the proposal is
approved. If there is at least one -1 vote, the ticket must be added
to the upcoming meeting agenda and subject to the Meeting Votes
rules. If there are no votes at all, the proposal is considered
rejected and the status quo will be maintained. The submitter may at
this time make a new proposal which will restart this process.

Meeting votes

At the meeting, a reasonable amount of time must be given for
discussion. Once a proposal is made in the chat, the vote will be
tallied as follows:

A proposal must achieve a majority (at least 51%) of +1 votes from
eligible voters. Votes must be one of +1, 0 or -1 as defined herein:

+1 I am in favor of the proposal as currently written.

0 I am electing to remove myself from the list of eligible
voters. This reduces the denominator of the fraction required to
achieve the 51% majority. In effect, I am agreeing to vote with
the remaining majority, whatever they decide.

-1 I am opposed to the proposal as currently written.

Any eligible voter that cannot attend the meeting is assumed to retain
any vote that they have made in the ticket prior to the meeting. Note
that this does not apply to new proposals made in the meeting, with
the exception of simple clarification edits.

If a vote in the meeting achieves a 51% majority in favor of a
proposal (accounting for any explicit 0 votes), that proposal is
accepted.

If a vote in the meeting achieves a 51% majority against a proposal
(accounting for any explicit 0 votes), that proposal is rejected.

If a proposal in a meeting fails to achieve a majority either for or
against, the FESCo members present must either:

Present a new proposal, restarting the meeting voting process.

Return the proposal to the ticket, restarting the ticket voting
process above. All votes made in the meeting will be transferred
to the ticket (Note: negative votes recorded in this way do
trigger discussion at the next meeting as normal). Once FESCo
agrees to return the proposal to the ticket, all discussion in the
current meeting on the topic is ended until that ticket vote has
concluded with either a decision or is transferred to another
meeting.

-->&-

Please comment here or in the ticket.

[1] https://pagure.io/fesco/issue/3038

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

Summary/Minutes from today's FESCo Meeting (2023-07-20)

[Zbigniew Jędrzejewski-Szmek]

Minutes: 
https://meetbot.fedoraproject.org/fedora-meeting-2/2023-07-20/fesco.2023-07-20-17.00.html
Minutes (text): 
https://meetbot.fedoraproject.org/fedora-meeting-2/2023-07-20/fesco.2023-07-20-17.00.txt
Log: 
https://meetbot.fedoraproject.org/fedora-meeting-2/2023-07-20/fesco.2023-07-20-17.00.log.html

Meeting summary
---
* init process  (zbyszek[m], 17:01:00)
  * ACTION: APPROVED (+7, 0, 0)  (zbyszek, 17:16:16)

* #3031 Change: AllowRemovalOfTzdata  (zbyszek, 17:19:01)
  * AGREED: APPROVED (+7, 0, -1)  (zbyszek, 17:20:21)

* #3038 New (clarified) voting rules for FESCo  (zbyszek, 17:20:42)
  * A second draft was posted today. We'll continue the discussion in
the ticket.  (zbyszek, 17:23:01)
  * ACTION: zbyszek to send a heads-up to fedora-devel mailing list.
(zbyszek, 17:28:28)

* #3039 RFC: Roadmap for DNF5 in Fedora 39 / invoking the Contingency
  Mechanism  (zbyszek, 17:31:44)
  * https://fedoraproject.org/wiki/Changes/ReplaceDnfWithDnf5  (zbyszek,
17:34:36)
  * https://pagure.io/fesco/issue/3039#comment-864924  (zbyszek,
17:36:41)
  * https://pagure.io/fedora-ci/general/issue/416  (zbyszek, 17:50:22)
  * ACTION: decathorpe will update the list in the ticket  (zbyszek,
18:15:24)
  * AGREED: We'll work on an updated list of acceptance criteria in
#3039. We'll revisit the issue of contingency mechanism invocation
at the next meeting. (+7, 0, 0)  (zbyszek, 18:15:53)

* Next week's chair  (zbyszek, 18:17:56)
  * ACTION: tstellar will chair the next meeting.  (zbyszek, 18:19:03)

* Open Floor  (zbyszek, 18:20:07)

Meeting ended at 18:30:50 UTC.

Action Items

* APPROVED (+7, 0, 0)
* zbyszek to send a heads-up to fedora-devel mailing list.
* decathorpe will update the list in the ticket
* tstellar will chair the next meeting.

People Present (lines said)
---
* zbyszek (87)
* dcantrell (51)
* sgallagh (41)
* nirik (38)
* decathorpe (36)
* Eighth_Doctor (31)
* zodbot (23)
* jmracek (22)
* zbyszek[m] (19)
* mhayden (14)
* codonell (11)
* tstellar (9)
* bcotton (9)
* Pharaoh_Atem (8)
* gotmax23 (6)
* mattdm (1)
* mhroncok (0)
* Conan_Kudo (0)
* Son_Goku (0)
* King_InuYasha (0)
* Sir_Gallantmon (0)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: python3 build failure

[Steve Dickson]

On 7/20/23 2:09 PM, Yaakov Selkowitz wrote:

On Thu, 2023-07-20 at 13:59 -0400, Steve Dickson wrote:

This bz[1] was opened on one of my packages not building on f39.
I did a quick rawhide scratch build and sure enough
the build fails with [2]


The important part is earlier in the log:

ModuleNotFoundError: No module named 'distutils'

distutils was removed in 3.12 for https://peps.python.org/pep-0632/

Solution: Add BuildRequires: python3-setuptools to get it building for
now, and work with upstream to migrate to a modern Python packaging
setup.

Yes... this was the needed required package.




But when I do the build locally on both f38 and rawhide (f39)
there is no problem and I do have a "BuildRequires: python3-devel"
in the spec file so I'm a bit lost as to what can be the
problem...


F38 is on Python 3.11, where distutils still exists.  Your mock cache
must be stale if local rawhide builds are still succeeding without
this.


Well the F38 scratch build still builds w/out add adding
new dependency... should I go ahead and add it or not worry
about it?

Thank you... very much!!!

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

Re: Making sense of golang packaging guidelines

[zebob . m]

On 7/20/23 8:20 PM, Carlos Rodriguez Fernandez  
wrote:

Hi all,

I am interested in packaging some golang programs for Fedora (and EPEL), and I read through 
the guidelines:
https://docs.fedoraproject.org/en-US/packaging-guidelines/Golang/ 



My question is more about the reasoning for the recommended handling of 
dependencies.

Other language platforms have shared runtime objects, and devel packages provide the 
interface to link to them when necessary; however golang compiles it all statically. It is 
very easy to bring all the dependencies locally for compilation directly from git repos and 
then nothing is necessary at runtime.


Creating rpm packages for each golang dependency seems counterproductive as it adds an 
additional burden to maintain without the benefits of shared runtime objects.


I have the feeling I am missing something. What is the benefit of having each golang build 
dependency as rpms?
Is it a requirement for golang programs rpm contributions or it is optional? (e.g. 
prometheus in EPEL9 does not follow the deps handling guidelines but not sure if it is a 
tech debt or an option).



Thank you,
Carlos



We need to build into Koji, there is no "local build". As such we have two 
options :
- bundle the dependencies in the package
- package all the libraries separately

The Fedora guidelines is to package library separately, per 
https://docs.fedoraproject.org/en-US/fesco/Bundled_Software_policy/ :



All packages whose upstreams allow them to be built against system libraries 
must be built against system libraries.

All packages whose upstreams have no mechanism to build against system 
libraries must be contacted publicly about a path to supporting system 
libraries. If upstream refuses, this must be recorded in the spec file using a 
persistent mechanism to be clarified in the packaging guidelines.

All packages whose upstreams have no mechanism to build against system 
libraries may opt to carry bundled libraries, but if they do, they must include 
Provides: bundled() = in their RPM spec file.


This policy only applies to Fedora. In EPEL we bundle because we don't have our 
macros and the Go ecosystem is not bootstrapped.

Best regards,

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

Re: Making sense of golang packaging guidelines

[Fabio Valentini]

On Thu, Jul 20, 2023 at 8:22 PM Carlos Rodriguez Fernandez
 wrote:
>
> Hi all,
>
> I am interested in packaging some golang programs for Fedora (and EPEL), and 
> I read through the guidelines:
> https://docs.fedoraproject.org/en-US/packaging-guidelines/Golang/
>
> My question is more about the reasoning for the recommended handling of 
> dependencies.
>
> Other language platforms have shared runtime objects, and devel packages 
> provide the interface to link to them when necessary; however golang compiles 
> it all statically. It is very easy to bring all the dependencies locally for 
> compilation directly from git repos and then nothing is necessary at runtime.
>
> Creating rpm packages for each golang dependency seems counterproductive as 
> it adds an additional burden to maintain without the benefits of shared 
> runtime objects.
>
> I have the feeling I am missing something. What is the benefit of having each 
> golang build dependency as rpms?
> Is it a requirement for golang programs rpm contributions or it is optional? 
> (e.g. prometheus in EPEL9 does not follow the deps handling guidelines but 
> not sure if it is a tech debt or an option).

There are different trade-offs to both approaches (packaging
dependencies separately vs. bundling them where they are needed, i.e.
"vendoring").
The "vendoring" approach is technically allowed in Fedora, but
definitely not the preferred option.

For example, when things are packaged, you need to verify that
dependencies fulfil certain technical and legal requirements.
When you package dependencies individually, that burden is shared
between all packagers who need these libraries.
When using the "vendored" approach, that burden basically falls on
every single maintainer, leading to duplicated effort.

Additionally, it is usually good to run test suites of projects
(applications *and* libraries) when packaging them for Fedora.
This is not possible when using "vendored" dependencies, but easy when
packaging things separately.

Having libraries packaged independently also makes certain other tasks
easier, for example, applying a patch for a security update (in *one*
place!) and then rebuilding affected packages.
Applying security fixes to packages that vendor their dependencies is
much more cumbersome, and also needs to happen separately in every
affected application.

I'm sure I forgot some points (both in favor or against both
approaches), but that's the "elevator pitch" I can give you quickly.
:)

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

Making sense of golang packaging guidelines

[Carlos Rodriguez Fernandez]

Hi all,

I am interested in packaging some golang programs for Fedora (and EPEL),
and I read through the guidelines:
https://docs.fedoraproject.org/en-US/packaging-guidelines/Golang/

My question is more about the reasoning for the recommended handling of
dependencies.

Other language platforms have shared runtime objects, and devel packages
provide the interface to link to them when necessary; however golang
compiles it all statically. It is very easy to bring all the dependencies
locally for compilation directly from git repos and then nothing is
necessary at runtime.

Creating rpm packages for each golang dependency seems counterproductive as
it adds an additional burden to maintain without the benefits of shared
runtime objects.

I have the feeling I am missing something. What is the benefit of having
each golang build dependency as rpms?
Is it a requirement for golang programs rpm contributions or it is
optional? (e.g. prometheus in EPEL9 does not follow the deps handling
guidelines but not sure if it is a tech debt or an option).


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

Re: python3 build failure

[Yaakov Selkowitz]

On Thu, 2023-07-20 at 13:59 -0400, Steve Dickson wrote:
> This bz[1] was opened on one of my packages not building on f39.
> I did a quick rawhide scratch build and sure enough
> the build fails with [2]

The important part is earlier in the log:

ModuleNotFoundError: No module named 'distutils'

distutils was removed in 3.12 for https://peps.python.org/pep-0632/

Solution: Add BuildRequires: python3-setuptools to get it building for
now, and work with upstream to migrate to a modern Python packaging
setup.

> But when I do the build locally on both f38 and rawhide (f39)
> there is no problem and I do have a "BuildRequires: python3-devel"
> in the spec file so I'm a bit lost as to what can be the
> problem...

F38 is on Python 3.11, where distutils still exists.  Your mock cache
must be stale if local rawhide builds are still succeeding without
this.

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

python3 build failure

[Steve Dickson]

Hello,

This bz[1] was opened on one of my packages not building on f39.
I did a quick rawhide scratch build and sure enough
the build fails with [2]

Traceback (most recent call last):
  File 
"/usr/lib/python3.11/site-packages/mockbuild/trace_decorator.py", line 
93, in trace

result = func(*args, **kw)
 ^
  File "/usr/lib/python3.11/site-packages/mockbuild/util.py", line 597, 
in do_with_status
raise exception.Error("Command failed: \n # %s\n%s" % (command, 
output), child.returncode)

mockbuild.exception.Error: Command failed:

But when I do the build locally on both f38 and rawhide (f39)
there is no problem and I do have a "BuildRequires: python3-devel"
in the spec file so I'm a bit lost as to what can be the
problem...

Any thoughts? tia!!

steved.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=2219922
[2] https://kojipkgs.fedoraproject.org//work/tasks/2595/103632595/build.log
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Several questionable packages installed on fresh system

[Paul Howarth]

On Thu, 13 Jul 2023 14:10:37 +0200
Vít Ondruch  wrote:

> Dne 10. 07. 23 v 10:38 Vít Ondruch napsal(a):
> > Hi,
> >
> >
> > libtomcrypt
> >  
> 
> So this is the dependency chain:
> 
> libtomcrypt <= python3-crypto <= python3-beaker <= python3-mako

I raised https://bugzilla.redhat.com/show_bug.cgi?id=2224405 to get the
Recommends: for python3-crypto dropped from python-beaker.

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

[Bug 2224383] New: perl-PAR-Packer-1.059 is available

[bugzilla]

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

Bug ID: 2224383
   Summary: perl-PAR-Packer-1.059 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-PAR-Packer
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: anon.am...@gmail.com, jples...@redhat.com,
mmasl...@redhat.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Releases retrieved: 1.059
Upstream release that is considered latest: 1.059
Current version/release in rawhide: 1.058-2.fc39
URL: http://search.cpan.org/dist/PAR-Packer/

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


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


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


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


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


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202224383%23c0
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: btrfs loses 32-bit application compatibility after a while

[Florian Weimer]

* Demi Marie Obenour:

> From this thread, it appears that non-LFS 32-bit software is fundamentally
> unsupportable in the long run, just like software with 32-bit time_t is
> unsupportable.  That leaves two options:
>
> 1. Break the ABI, preferably in such a way that causes non-LFS
>code to fail at load time rather than crashing.
>
> 2. Drop 32-bit support from the distribution altogether.
>
> It looks like trying to keep 32-bit non-LFS software working will be an
> endless time sink and is not sustainable in the long term.

My impression is different.  It's btrfs that is a poor choice for people
who want to run 32-bit software, have a lot of file creations/deletions,
and do not want to reformat and reinstall periodically.  The situation
with XFS, for example, is different because you can supply the inode32
mount option and get 32-bit applications going again, maybe after making
in-place copies of a few files.

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

Re: btrfs loses 32-bit application compatibility after a while

[Demi Marie Obenour]

On 7/20/23 11:06, Florian Weimer wrote:
> * Demi Marie Obenour:
> 
>> On 7/17/23 09:51, Florian Weimer wrote:
>>> * Daniel P. Berrangé:
>>>
> But that still raises the question - why does it look like this
> started to happen pretty suddenly around June 30?
> The list of updates that were applied to builders in that timeframe
> doesn't raise any alarm bells (except maybe the 6.3 kernel):
> (see https://pagure.io/releng/issue/11531#comment-864471)
> I read the release notes for the 6.3 kernel but didn't see any
> mentions of BTRFS changes that could explain this. :(

 Or what 32-bit code is being run in the context of koji that is
 NOT compiled with LFS ?  Is this something silly like configure
 script tests not enabling LFS, but the resulting applications
 correctly using LFS ?
>>>
>>> A dependency used during RPM file creation, libcap, is not fully built
>>> in LFS mode.  Once we fix that, we know that we'll run into issues with
>>> chkconfig and update-alternatives.  It's a never-ending source of bugs.
>>> It's not a good use of maintainer time.
>>>
>>> We can't change the overall distribution flags with CFLAGS injection
>>> because doing so has ABI implications.
>>
>> Can they be changed at the next mass rebuild?
> 
> Not if we want to maintain compatibility with non-Fedora software.  It
> probably doesn't matter for most packages, but doing a per-package
> analysis is a lot of work.

From this thread, it appears that non-LFS 32-bit software is fundamentally
unsupportable in the long run, just like software with 32-bit time_t is
unsupportable.  That leaves two options:

1. Break the ABI, preferably in such a way that causes non-LFS
   code to fail at load time rather than crashing.

2. Drop 32-bit support from the distribution altogether.

It looks like trying to keep 32-bit non-LFS software working will be an
endless time sink and is not sustainable in the long term.
-- 
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: btrfs loses 32-bit application compatibility after a while

[Fabio Valentini]

Thu, Jul 20, 2023 at 5:07 PM Florian Weimer  wrote:
>
> * Demi Marie Obenour:
>
> > On 7/17/23 09:51, Florian Weimer wrote:
> >> * Daniel P. Berrangé:
> >>
>  But that still raises the question - why does it look like this
>  started to happen pretty suddenly around June 30?
>  The list of updates that were applied to builders in that timeframe
>  doesn't raise any alarm bells (except maybe the 6.3 kernel):
>  (see https://pagure.io/releng/issue/11531#comment-864471)
>  I read the release notes for the 6.3 kernel but didn't see any
>  mentions of BTRFS changes that could explain this. :(
> >>>
> >>> Or what 32-bit code is being run in the context of koji that is
> >>> NOT compiled with LFS ?  Is this something silly like configure
> >>> script tests not enabling LFS, but the resulting applications
> >>> correctly using LFS ?
> >>
> >> A dependency used during RPM file creation, libcap, is not fully built
> >> in LFS mode.  Once we fix that, we know that we'll run into issues with
> >> chkconfig and update-alternatives.  It's a never-ending source of bugs.
> >> It's not a good use of maintainer time.
> >>
> >> We can't change the overall distribution flags with CFLAGS injection
> >> because doing so has ABI implications.
> >
> > Can they be changed at the next mass rebuild?
>
> Not if we want to maintain compatibility with non-Fedora software.  It
> probably doesn't matter for most packages, but doing a per-package
> analysis is a lot of work.

While it's not a long-term solution, would it be possible to just
"delay things for long enough until we can drop i686 entirely" by
modifying specific packages?

For example, in this case, libcap was not 64-bit inode aware, and
shadow-utils failed to install in the default buildroot (I hope I
summarize this right), but modifying libcap to build with support for
64-bit inodes would have solved this, if I understand correctly?

-> Pro: Small changes to specific packages
-> Con: Things might still fail later in the build process

However, since the libcap/shadow-utils thing was the only failure that
I saw that affected the default buildroot, at least this would (for
now) completely solve the issue (or make much less likely to happen)
for several workflows:

- buildSRPMfromSCM tasks would no longer randomly fail if assigned to
i686 builders
- koschei builds would no longer randomly fail (even though they don't
even build on i686)
- noarch builds could only fail if assigned to i686 (unlucky case)
- scratch builds that only include non-i686 architectures would no longer fail
- EPEL builds would no longer fail (don't get built for i686)

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

Re: Cython 3 plans

[Miro Hrončok]

On 20. 07. 23 12:16, Miro Hrončok wrote:

python-rapidfuzz thrnciar troycurtisjr


See https://src.fedoraproject.org/rpms/python-rapidfuzz/pull-request/2

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: btrfs loses 32-bit application compatibility after a while

[Florian Weimer]

* Demi Marie Obenour:

> On 7/17/23 09:51, Florian Weimer wrote:
>> * Daniel P. Berrangé:
>> 
 But that still raises the question - why does it look like this
 started to happen pretty suddenly around June 30?
 The list of updates that were applied to builders in that timeframe
 doesn't raise any alarm bells (except maybe the 6.3 kernel):
 (see https://pagure.io/releng/issue/11531#comment-864471)
 I read the release notes for the 6.3 kernel but didn't see any
 mentions of BTRFS changes that could explain this. :(
>>>
>>> Or what 32-bit code is being run in the context of koji that is
>>> NOT compiled with LFS ?  Is this something silly like configure
>>> script tests not enabling LFS, but the resulting applications
>>> correctly using LFS ?
>> 
>> A dependency used during RPM file creation, libcap, is not fully built
>> in LFS mode.  Once we fix that, we know that we'll run into issues with
>> chkconfig and update-alternatives.  It's a never-ending source of bugs.
>> It's not a good use of maintainer time.
>> 
>> We can't change the overall distribution flags with CFLAGS injection
>> because doing so has ABI implications.
>
> Can they be changed at the next mass rebuild?

Not if we want to maintain compatibility with non-Fedora software.  It
probably doesn't matter for most packages, but doing a per-package
analysis is a lot of work.

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

[Bug 2218167] Please consider removing/porting aspell dependency. Aspell has been deprecated

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version||perl-Code-TidyAll-0.83-3.fc
   ||39
 Status|MODIFIED|CLOSED
 Resolution|--- |ERRATA
Last Closed||2023-07-20 15:00:55



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


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202218167%23c2
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2218167] Please consider removing/porting aspell dependency. Aspell has been deprecated

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|NEW |MODIFIED



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


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202218167%23c1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Potential changes to systemd RPM macros

[Andrea Bolognani]

Hi,

this requires a bit of background, so please bear with me :)


Earlier this year, the libvirt project changed its RPM package to be
more granular[1] as a step towards a future where the legacy
monolithic daemon (libvirtd) is completely gone. This change has
happened upstream, but the Fedora package uses the same spec file so
it was quickly reflected in Rawhide.

As part of this change virtproxyd, a service which has historically
been part of the libvirt-daemon package, has been moved to the
newly-introduced libvirt-daemon-proxy package.

More recently we have realized that, despite our care in trying to
ensure smooth upgrades, splitting the package this way has
unfortunately caused unintended consequences[2][3]. Specifically,
since the libvirt-daemon-proxy package is a completely new one as far
as RPM is concerned, all its systemd units will get presets applied
during %post. In at least two completely valid deployment scenarios,
this results in some amount of brokenness due to local configuration
changes made by the admin getting discarded.


In order to avoid this problem, I have implemented a new set of RPM
macros[4][5] that base the decision of whether presets should be
applied for a systemd unit not on whether the package that contains
them is being newly installed, but rather on whether the unit itself
existed on the system before package installation. This should
address not only the scenario of services being split off to separate
packages, but also the one where an existing package starts shipping
additional services.

Now, since this is clearly not a libvirt-specific issue, I believe
this approach should be adopted across Fedora by way of these macros
(or comparable ones) being added to systemd. Packages would have to
migrate from the old macros over time, and at some point it should be
possible to get rid of them entirely.

Note that openSUSE already has its own distro-specific RPM macros for
dealing with systemd units, and in fact the approach that I have
implemented is partially inspired by theirs. Ideally, we'd be able to
collaborate with them to create a single set of macros that lives in
systemd and satisfies the needs of both Fedora and openSUSE.


The problem is that Fedora 39 and RHEL 9.3 are fast approaching and,
if we don't do anything about this issue before then, a subset of
libvirt users will see their deployments broken after upgrade. In the
interest of avoiding that, I would prefer to get the libvirt-specific
version of the macros merged as soon as possible, and focus on
upstreaming the work all the way to systemd as a follow-up.


Does this plan sound reasonable to the Fedora community? Are there
any serious concerns regarding the approach taken for the macros that
would cause them to be considered a complete no-go? Any scenarios
that I might have missed while implementing them?


Thanks for your patience in reading this far :) and looking forward
to your feedback!


[1] https://listman.redhat.com/archives/libvir-list/2023-January/237059.html
[2] https://bugzilla.redhat.com/show_bug.cgi?id=2210058
[3] https://listman.redhat.com/archives/libvir-list/2023-June/240226.html
[4] https://listman.redhat.com/archives/libvir-list/2023-July/240723.html
[5] https://listman.redhat.com/archives/libvir-list/2023-July/240729.html
-- 
Andrea Bolognani / Red Hat / Virtualization
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Should Fedora switch to full kernel preemption (CONFIG_PREEMPT=y)?

[Justin Forbes]

On Thu, Jul 20, 2023 at 8:53 AM Daniel P. Berrangé  wrote:
>
> On Sat, May 20, 2023 at 06:14:17PM -0500, Justin Forbes wrote:
> > On Sat, May 20, 2023 at 3:44 PM Demi Marie Obenour
> >  wrote:
> > >
> > > I noticed that by default, Qubes OS has voluntary kernel preemption
> > > as opposed to full preemption.  I found that enabling full preemption
> > > (preempt=full on kernel command line) makes the system significantly
> > > more responsive under heavy I/O load.  In particular, if I build a
> > > kernel in a Qubes OS VM, it significantly degrades responsiveness
> > > without preempt=full.  With preempt=full, the system remains
> > > responsive.  The storage stack used is LVM thin provisioning on LUKS,
> > > and I have observed significant CPU usage in dom0 kernel threads with
> > > names that indicate they are related to dm-thin and dm-crypt.
> > >
> > For workstation, preempt=full does likely make sense, and I have been
> > running it for a while.  For server, maybe not so much. That is the
> > joy of dynamic preempt. You can boot with preempt=full and run that
> > way if you like.  There is an open issue for the workstation WG to
> > look at making preempt=full the default there at some point.
>
> What's the downside from full pre-empt that makes it inappropriate
> as the defualt for Fedora server spins too ? Is it that it is
> trading off overall peak performance in favour of reduced latency,
> and we think servers would prefer the peak performance in general ?

That is the downside.  It might be interesting to ask the performance
group for RHEL to run a battery against preempt=full and see what the
results are.  The ELN kernel does enable PREEMPT_DYNAMIC and there
should already be a baseline to compare against there.  I just do not
know if they have space cycles to run those tests.  No matter what
default we choose, there are no plans to turn off PREEMPT_DYNAMIC
meaning any user is free to choose the preempt mode that works best
for them. I have been running preempt=full for quite some time on my
desktops systems here.

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

Re: libarrow (Apache Arrow) soname bump in Rawhide

[Fabio Valentini]

On Thu, Jul 20, 2023 at 4:07 PM Kaleb Keithley  wrote:
>
>
>
> On Mon, May 1, 2023 at 8:01 AM Kaleb Keithley  wrote:
>>
>>
>>
>> Now Apache Arrow 12.0.0 has been released.
>>
>> Rebase landing soon in Rawhide.
>
>
> Apache Arrow (libarrow) 13.0.0 has been released.
>
> At least within Fedora, only Ceph (ceph-common, ceph-radosgw, ceph-test, 
> librgw2) depends on libarrow.
>
> I know of a couple of external consumers that are using it.
>
> Rebase landing shortly in Rawhide.

You might want to wait until the mass rebuild is over, otherwise it
will likely interfere with your builds.

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

Re: libarrow (Apache Arrow) soname bump in Rawhide

[Kaleb Keithley]

On Mon, May 1, 2023 at 8:01 AM Kaleb Keithley  wrote:

>
>
> Now Apache Arrow 12.0.0 has been released.
>
> Rebase landing soon in Rawhide.
>

Apache Arrow (libarrow) 13.0.0 has been released.

At least within Fedora, only Ceph (ceph-common, ceph-radosgw, ceph-test,
librgw2) depends on libarrow.

I know of a couple of external consumers that are using it.

Rebase landing shortly in Rawhide.

-- 

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

Re: Should Fedora switch to full kernel preemption (CONFIG_PREEMPT=y)?

[Chris Murphy]

On Thu, Jul 20, 2023, at 9:53 AM, Daniel P. Berrangé wrote:

> What's the downside from full pre-empt that makes it inappropriate
> as the defualt for Fedora server spins too ? Is it that it is
> trading off overall peak performance in favour of reduced latency,
> and we think servers would prefer the peak performance in general ?

Maybe. But I'm not aware of any recent data one way or the other, certainly 
nothing Fedora specific.

I don't expect full preemption will impact servers in any meaningful way. I 
just can't prove that.



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

Re: Should Fedora switch to full kernel preemption (CONFIG_PREEMPT=y)?

[Chris Murphy]

On Thu, Jul 20, 2023, at 9:51 AM, Michael Catanzaro wrote:
> On Wed, Jul 19 2023 at 06:50:24 PM -0400, Chris Murphy 
>  wrote:
>> If restricted to desktops, then we can only do it with kernel 
>> parameters. That probably means doing it in Anaconda kickstart, with 
>> a per edition/spin option for doing so.
>
> I'm not fond of this solution. In practice, this would likely mean the 
> new preemption mode would apply only to new installs and not also to 
> upgraded systems, right?

Probably.

A grubby command could add the proper kernel parameter to the bootloader 
configuration, but grubby isn't being used anywhere in Fedora (not anaconda for 
initial installs, not when installing kernel upgrades) so it isn't being 
exercised.

The more users customize, the less likely grubby is going to detect their use 
case and fail gracefully. grubby would need to have a strict "only add new 
parameter" option. Right now it also replaces the kernel command line with the 
contents of /etc/kernel/cmdline to all bootloader snippets in 
/boot/loader/entries - including snippets for other OS's, which would be bad.


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

Re: Should Fedora switch to full kernel preemption (CONFIG_PREEMPT=y)?

[Daniel P . Berrangé]

On Sat, May 20, 2023 at 06:14:17PM -0500, Justin Forbes wrote:
> On Sat, May 20, 2023 at 3:44 PM Demi Marie Obenour
>  wrote:
> >
> > I noticed that by default, Qubes OS has voluntary kernel preemption
> > as opposed to full preemption.  I found that enabling full preemption
> > (preempt=full on kernel command line) makes the system significantly
> > more responsive under heavy I/O load.  In particular, if I build a
> > kernel in a Qubes OS VM, it significantly degrades responsiveness
> > without preempt=full.  With preempt=full, the system remains
> > responsive.  The storage stack used is LVM thin provisioning on LUKS,
> > and I have observed significant CPU usage in dom0 kernel threads with
> > names that indicate they are related to dm-thin and dm-crypt.
> >
> For workstation, preempt=full does likely make sense, and I have been
> running it for a while.  For server, maybe not so much. That is the
> joy of dynamic preempt. You can boot with preempt=full and run that
> way if you like.  There is an open issue for the workstation WG to
> look at making preempt=full the default there at some point.

What's the downside from full pre-empt that makes it inappropriate
as the defualt for Fedora server spins too ? Is it that it is
trading off overall peak performance in favour of reduced latency,
and we think servers would prefer the peak performance in general ?

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

Re: Should Fedora switch to full kernel preemption (CONFIG_PREEMPT=y)?

[Michael Catanzaro]

On Wed, Jul 19 2023 at 06:50:24 PM -0400, Chris Murphy 
 wrote:
If restricted to desktops, then we can only do it with kernel 
parameters. That probably means doing it in Anaconda kickstart, with 
a per edition/spin option for doing so.


I'm not fond of this solution. In practice, this would likely mean the 
new preemption mode would apply only to new installs and not also to 
upgraded systems, right?


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

Re: btrfs loses 32-bit application compatibility after a while

[Demi Marie Obenour]

On 7/17/23 09:51, Florian Weimer wrote:
> * Daniel P. Berrangé:
> 
>>> But that still raises the question - why does it look like this
>>> started to happen pretty suddenly around June 30?
>>> The list of updates that were applied to builders in that timeframe
>>> doesn't raise any alarm bells (except maybe the 6.3 kernel):
>>> (see https://pagure.io/releng/issue/11531#comment-864471)
>>> I read the release notes for the 6.3 kernel but didn't see any
>>> mentions of BTRFS changes that could explain this. :(
>>
>> Or what 32-bit code is being run in the context of koji that is
>> NOT compiled with LFS ?  Is this something silly like configure
>> script tests not enabling LFS, but the resulting applications
>> correctly using LFS ?
> 
> A dependency used during RPM file creation, libcap, is not fully built
> in LFS mode.  Once we fix that, we know that we'll run into issues with
> chkconfig and update-alternatives.  It's a never-ending source of bugs.
> It's not a good use of maintainer time.
> 
> We can't change the overall distribution flags with CFLAGS injection
> because doing so has ABI implications.

Can they be changed at the next mass rebuild?
-- 
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Orphaned Zim

[Sandro]

On 20-07-2023 14:38, Otto Liljalaakso wrote:
I think I may have used Zim in the past and I may have some use for it 
again. I'd be happy to co-maintain. 


Great! I have added you with commit privileges. In case you (or anybody 
else) know Python buildsystems, you could check the upstream issue about 
distutils deprecation [1]. Upstream has just indicated they are 
interested in migrating to something else, but would appreciate some 
suggestions and help.


[1]: https://github.com/zim-desktop-wiki/zim-desktop-wiki/issues/2420


I will take a look. I fixed a few of those already as part of the 
Python3.12 fallout.


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

Re: Say goodbye to polymake

[Richard W.M. Jones]

On Thu, Jul 20, 2023 at 02:20:59AM +0200, Kevin Kofler via devel wrote:
> Richard W.M. Jones wrote:
> > 
> /home/rjones/d/fedora/polymake/rawhide/polymake-4.10/lib/core/src/perl/RefHash.xxs:737:11:
> > error: ‘Perl_ck_fun’ was not declared in this scope; did you mean
> > ‘Perl_cx_dup’?
> >   737 |return Perl_ck_fun(aTHX_ o);
> >   |   ^~~
> >   |   Perl_cx_dup
> > ninja: build stopped: subcommand failed.
> 
> As I understand it, this function is included in the public (at least, it is 
> declared EXT, so it should not be hidden) PL_check array (several times, the 
> first time at index 2), so I believe something like:
> #define Perl_ck_fun (PL_check[2])
> should work.

That seems possible, although it's a bit of a hack to misuse the array
like this:

https://github.com/Perl/perl5/blob/ccfa6b533228ad41e4dbc5576cd43081b8fd2a13/opcode.h#L1431

I suppose if polymake is going to fiddle with Perl internals anyway,
then why not.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
nbdkit - Flexible, fast NBD server with plugins
https://gitlab.com/nbdkit/nbdkit
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Orphaned Zim

[Otto Liljalaakso]

Sandro kirjoitti 20.7.2023 klo 12.42:

On 19-07-2023 23:11, Otto Liljalaakso wrote:

Robin Lee kirjoitti 14.7.2023 klo 17.53:
I've orphaned the Zim package. It fails to build with Python 3.12 in 
Rawhide.


Users can move to the flatpak on Flathub, which is also packaged by me.

Thank you for maintaining the Zim package until now. I took it. The 
build failure was easy to fix by BuildRequiring setuptools. I also 
updated to the latest version, and am in the process of looking at 
open bugs and switching to SPDX license identifiers.


I think I may have used Zim in the past and I may have some use for it 
again. I'd be happy to co-maintain. 


Great! I have added you with commit privileges. In case you (or anybody 
else) know Python buildsystems, you could check the upstream issue about 
distutils deprecation [1]. Upstream has just indicated they are 
interested in migrating to something else, but would appreciate some 
suggestions and help.


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

Re: F39 proposal: Perl 5.38 (System-Wide Change proposal)

[Xiaojie Chen]

Hi，I am interesting in the upgrading of perl. Where can I find the detailed 
process of upgrading and building Perl, including the entire build steps, the 
list of built RPM packages, and the building order of Perl module packages?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Orphaned Onboard

[Qiyu Yan]

Hi all,

I've orphaned the Onboard package. I stopped using it personally and don't have 
enough time to handle some bug report.

If anyone want to take it please do so.

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

Schedule for Thursday's FESCo Meeting (2023-07-20)

[Zbigniew Jędrzejewski-Szmek]

Following is the list of topics that will be discussed in the
FESCo meeting Thursday at 17:00UTC in #fedora-meeting-2 on
irc.libera.chat.

To convert UTC to your local time, take a look at
  http://fedoraproject.org/wiki/UTCHowto

or run:
  date -d '2023-07-20 17:00 UTC'

Links to all issues to be discussed can be found at: 
https://pagure.io/fesco/report/meeting_agenda

= Discussed and Voted in the Ticket =

#3034 Change: LLVM 17
https://pagure.io/fesco/issue/3034
APPROVED (+6, 0, 0)

#3033 Change: ImproveDefaultFontHandling
https://pagure.io/fesco/issue/3033
APPROVED (+4, 0, 0)

#3028 Change: sericea-xorgless
https://pagure.io/fesco/issue/3028
APPROVED (+6, 0, 0)

#3027 Change: Retire Modularity
https://pagure.io/fesco/issue/3027
APPROVED (+7,0,-0)

#3026 Change: Python Extension Flags Reduction
https://pagure.io/fesco/issue/3026
APPROVED (+8, 0, 0)

#3025 Change: No custom Qt theming for Fedora Workstation
https://pagure.io/fesco/issue/3025
APPROVED (+5, 1, 0)

#3024 Change: LibuserDeprecation
https://pagure.io/fesco/issue/3024
APPROVED (+6, 0, 0)

#3023 Change: Golang1.21
https://pagure.io/fesco/issue/3023
Approved(+5, 0, 0)

#3022 Change: Clean Systemd-boot installs
https://pagure.io/fesco/issue/3022
APPROVED (+4, 0, 0)

#3021 Change: Passkey authentication for centrally managed users
https://pagure.io/fesco/issue/3021
APPROVED (+6, 0, 0)

= Followups =


= New business =

#3031 Change: AllowRemovalOfTzdata
https://pagure.io/fesco/issue/3031

#3038 New (clarified) voting rules for FESCo
https://pagure.io/fesco/issue/3038

#3039 RFC: Roadmap for DNF5 in Fedora 39 / invoking the Contingency Mechanism
https://pagure.io/fesco/issue/3039


= Open Floor = 

For more complete details, please visit each individual
issue.  The report of the agenda items can be found at
https://pagure.io/fesco/report/meeting_agenda

If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue at
https://pagure.io/fesco, e-mail me directly, or bring it
up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting. 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: DNF5-5.0.1 has a stable API

[Kevin Kofler via devel]

Miroslav Suchý wrote:
> "Only dead projects has stable API"

Sorry, but this is just nonsense. APIs can be appended to, even rewrites can 
be made API-compatible if developers actually care about that. Even if the 
internal code is completely different, the public API can be retained, at 
least if it was properly designed to begin with. (Things such as 
unencapsulated fields can be dealbreakers.)

And besides:
> Subject: DNF5-5.0.1 has a stable API
> "Only dead projects has stable API"
Hence, DNF5-5.0.1 is dead. ;-) So either that statement is true, or one of 
the two quoted ones is false.

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

Re: Cython 3 plans

[Miro Hrončok]

On 17. 07. 23 21:09, Miro Hrončok wrote:

Hello Pythonistas,

apparently, Cython 3.0.0 final was released today.

I plan to make it build somehow in 
https://src.fedoraproject.org/rpms/Cython/pull-request/41 and once it does, 
I'll update the package in Rawhide, introducing a python(3)-cython0.29 
conflicting compact package for those who cannot upgrade yet (like python-lxml).


Note that Cython 0.29 was only built without tests during the Python 3.12 
bootstrap and I am unsure we will ever be able to enable them again (at least 
not all of them).


We'll get rid of emacs-cython-mode during the transition -- it can be packaged 
separately by someone else if desired.


This is ready to be shipped in:

https://src.fedoraproject.org/rpms/Cython/pull-request/41
https://src.fedoraproject.org/rpms/python-cython0.29/pull-request/1

Some packages succeeded in 
https://copr.fedorainfracloud.org/coprs/g/python/cython0.29/ but failed in 
https://copr.fedorainfracloud.org/coprs/g/python/cython3/


Unless the failure was transient, they will need to pin the build dependency on 
python3dist(cython) < 3~~.


Maintainers by package:
MUSICankursinha
PyYAML   jeckersb
cantera  fuller sic
h5py orion stevetraylen terjeros
libarrow kkeithle
libfreenect  jkastner kathenas kwizart rmattes
libgpuarray  orphan
mlpack   fed500 rcurtin
mpi4py   limb tomspur
numpycstratak limb orion rdieter tomspur ttomecek
petscsagitter
pygame   jskarvad limb sergiomb
pyliblo  fab
python-blosc2zbyszek
python-calcephpy mattia
python-cftimeorion
python-comprefformusic
python-cyipopt   music
python-cysignals pcpa
python-cytoolz   orion
python-djvulibre aekoroglu
python-editdistance-s limb
python-ezdxf music
python-fastavro  ankursinha
python-gbinder   aleasto
python-giacpysagitter
python-gssapisimo
python-healpylupinix
python-hidapijonny
python-imagecodecs   orion
python-indexed_gzip  ankursinha
python-jnius raphgro
python-kmod  grover mlombard
python-llfusedfateyev maci
python-lxml  cstratak fale lbalhar mizdebsk
python-oracledb  stevetraylen
python-orderedsetvtrefny
python-pari-jupyter  jjames
python-peeweecarlwgeorge cstratak vkrizan
python-pplpy jjames
python-pyclipper athoscr
python-pyedflib  iztokf
python-pysam davidsch
python-pyspike   ankursinha
python-rapidfuzz thrnciar troycurtisjr
python-rtmidifab
python-smartcols kalev
python-statsmodels   sergiopr
python-tablesjonathanspw zbyszek
python-uamqp mhayden
rdma-coredledford honli jwilson kheib michich
rust-cbindgendecathorpe
scipycstratak mmuzila nforro orion psimovec tomspur ttomecek
setools  alexl caolanm dwalsh mbarnes pcmoore plautrba rhughes 
rstrode vmojzis

urh  jskarvad
vapoursynth  slaanesh

Packages by maintainer:
aekoroglu  python-djvulibre
aleastopython-gbinder
alexl  setools
ankursinha MUSIC python-fastavro python-indexed_gzip python-pyspike
athoscrpython-pyclipper
caolanmsetools
carlwgeorge python-peewee
cstratak   numpy python-lxml python-peewee scipy
davidsch   python-pysam
decathorpe rust-cbindgen
dfateyev   python-llfuse
dledford   rdma-core
dwalsh setools
fabpyliblo python-rtmidi
fale   python-lxml
fed500 mlpack
fuller cantera
grover python-kmod
honli  rdma-core
iztokf python-pyedflib
jeckersb   PyYAML
jjames python-pari-jupyter python-pplpy
jkastner   libfreenect
jonathanspw python-tables
jonny  python-hidapi
jskarvad   pygame urh
jwilsonrdma-core
kalev  python-smartcols
kathenas   libfreenect
kheib  rdma-core
kkeithle   libarrow
kwizartlibfreenect
lbalharpython-lxml
limb   mpi4py numpy pygame python-editdistance-s
lupinixpython-healpy
maci   python-llfuse
mattia python-calcephpy
mbarnessetools
mhaydenpython-uamqp
michichrdma-core
mizdebsk   python-lxml
mlombard   python-kmod
mmuzilascipy
music  python-compreffor python-cyipopt python-ezdxf
nforro scipy
orion  h5py numpy python-cftime python-cytoolz python-imagecodecs scipy
orphan libgpuarray
pcmooresetools
pcpa   python-cysignals
plautrba   setools
psimovec   scipy
raphgropython-jnius
rcurtinmlpack
rdieternumpy
rhughessetools
rmatteslibfreenect
rstrodesetools
sagitter   petsc python-giacpy
sergiomb   pygame
sergiopr   python-statsmodels
siccantera
simo   python-gssapi
slaanesh   vapoursynth
stevetraylen h5py python-oracledb
terjeros   h5py
thrnciar   python-rapidfuzz
tomspurmpi4py numpy scipy
troycurtisjr python-rapidfuzz
ttomecek   numpy scipy
vkrizanpython-peewee
vmojzissetools
vtrefnypython-orderedset
zbyszek

Re: DNF5-5.0.1 has a stable API

[Peter Robinson]

On Thu, Jul 20, 2023 at 10:46 AM Miroslav Suchý  wrote:
>
> Dne 20. 07. 23 v 10:08 Peter Robinson napsal(a):
> > The dnf5 API has similar primitives (Base, Goal, Package, etc.), but it's
> >> not at all compatible.
>
> It may be worth to add the link to the API:
>
> https://dnf5.readthedocs.io/en/latest/api/index.html
>
> > So everything has to be rewritten across the entire ecosystem to work
> > with it? Wow, who thinks that's a good idea? It took the ecosystem
> > long enough to migrate from the yum "API" to dnf and now they have to
> > do that all over again?
>
> "Only dead projects has stable API"

You can evolve APIs with versioning to ensure backwards compatibility
while also evolving the usecases.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: DNF5-5.0.1 has a stable API

[Miroslav Suchý]

Dne 20. 07. 23 v 10:08 Peter Robinson napsal(a):

The dnf5 API has similar primitives (Base, Goal, Package, etc.), but it's

not at all compatible.


It may be worth to add the link to the API:

https://dnf5.readthedocs.io/en/latest/api/index.html


So everything has to be rewritten across the entire ecosystem to work
with it? Wow, who thinks that's a good idea? It took the ecosystem
long enough to migrate from the yum "API" to dnf and now they have to
do that all over again?


"Only dead projects has stable API"

        Me.

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

Re: Orphaned Zim

[Sandro]

On 19-07-2023 23:11, Otto Liljalaakso wrote:

Robin Lee kirjoitti 14.7.2023 klo 17.53:
I've orphaned the Zim package. It fails to build with Python 3.12 in 
Rawhide.


Users can move to the flatpak on Flathub, which is also packaged by me.

Thank you for maintaining the Zim package until now. I took it. The 
build failure was easy to fix by BuildRequiring setuptools. I also 
updated to the latest version, and am in the process of looking at open 
bugs and switching to SPDX license identifiers.


I think I may have used Zim in the past and I may have some use for it 
again. I'd be happy to co-maintain.


Cheers,


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

[EPEL-devel] Retiring Zim from EPEL

[Otto Liljalaakso]

Recently, I adopted the orphaned Zim package for Fedora. The previous 
maintainer had added the package to EPEL, while I am not involved with 
EPEL at all. Consequently, I will not maintain the EPEL branches anymore.


From going through the EPEC documentation, it looks like the Retirement 
Process: No Time or Desire [1] is the procedure I should follow. So, 
unless somebody steps up to maintain the EPEL branches for Zim, I will 
retire the package from EPEL.


To my knowledge, there are no issues with Zim and EPEL. I am simply not 
involved with EPEL. The fact that there is no epel9 branch, only epel8 
and epel7, seems strange, but then, I do not know much about EPEL 
package maintenance.


In case I am following the wrong process, please let me know and point 
me to the correct one.


[1]: 
https://docs.fedoraproject.org/en-US/epel/epel-policy-retirement/#process_no_time_or_desire

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

[Bug 2224116] perl-Business-ISBN-Data-20230719.001 is available

[bugzilla]

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

Paul Howarth  changed:

   What|Removed |Added

   Doc Type|--- |If docs needed, set a value
   Assignee|jples...@redhat.com |p...@city-fan.org
 Status|NEW |ASSIGNED




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

[Bug 2224116] perl-Business-ISBN-Data-20230719.001 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version||perl-Business-ISBN-Data-202
   ||30719.001-1.fc39
 Resolution|--- |ERRATA
 Status|MODIFIED|CLOSED
Last Closed||2023-07-20 08:42:55



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


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202224116%23c2
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2224116] perl-Business-ISBN-Data-20230719.001 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



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


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202224116%23c1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: DNF5-5.0.1 has a stable API

[Peter Robinson]

On Wed, Jul 19, 2023 at 11:35 PM Maxwell G  wrote:
>
>
> 2023-07-19T13:39:57Z Peter Robinson :
>
> > On Wed, Jul 19, 2023 at 2:20 PM Nicola Sella  wrote:
> >>
> >> Hi all,
> >> Yesterday, DNF5 5.1.0 was released upstream[1] and in rawhide[2]. This
> >> update makes DNF5's API stable. This means that changes to the API
> >> won't happen in stable Fedora releases.
> >
> > How compatible is this API with the old dnf4 API?
> The dnf5 API has similar primitives (Base, Goal, Package, etc.), but it's
> not at all compatible.

So everything has to be rewritten across the entire ecosystem to work
with it? Wow, who thinks that's a good idea? It took the ecosystem
long enough to migrate from the yum "API" to dnf and now they have to
do that all over again?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue