date:20211230

[Bug 2036310] New: perl-Math-BigInt-1.999829 is available

2021-12-30 Thread bugzilla

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

Bug ID: 2036310
   Summary: perl-Math-BigInt-1.999829 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Math-BigInt
  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, ppi...@redhat.com
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 1.999829
Current version/release in rawhide: 1.9998.28-1.fc36
URL: http://search.cpan.org/dist/Math-BigInt/

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


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


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


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


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

Re: Request for Intel WiFi Backports - AX2xx

2021-12-30 Thread Peter Robinson

On Thu, Dec 30, 2021 at 6:21 PM Marcin Juszkiewicz
 wrote:
>
> W dniu 28.12.2021 o 00:30, Kevin Anderson pisze:
>
> > There was a iwlwifi issue that would cause firmware resets and cause
> > performance to significantly degrade to around ~500Kb/s till the
> > interface was brought down and then up again. Upstream identified the
> > issue and there are 2 patches that fix the issue by increasing the
> > scan timeout[1] and in cases where the firmware resets allows it to
> > recover quicker[2]. The patch to allow for quicker firmware recovery
> > is present in Linus' tree and present in the 5.16 rc releases while
> > the patch to prevent the firmware from crashing in the instance is in
> > net-next for 5.17.
>
> Did anyone thought of merging those patches into 5.15-stable upstream?
>
> This way it lands in all distributions on next kernel sync.

The kernel team will generally request that, outside of Fedora that
probably makes sense given 5.15 is LTS and I'm surprised it hasn't
actually happened given the widespread uses of iwl
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2028913] Please branch and build perl-GDGraph in epel9

2021-12-30 Thread bugzilla

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

Fedora Update System  changed:

   What|Removed |Added

 Resolution|--- |ERRATA
   Fixed In Version||perl-GDGraph-1.54-11.el9
 Status|ON_QA   |CLOSED
Last Closed||2021-12-31 01:47:42



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


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

[Bug 2034850] Please branch and build perl-Sub-Override in epel9

2021-12-30 Thread bugzilla

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version||perl-Sub-Override-0.09-26.e
   ||l9
 Resolution|--- |ERRATA
 Status|ON_QA   |CLOSED
Last Closed||2021-12-31 01:47:38



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


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

[Bug 2031731] Please branch and build perl-ExtUtils-PkgConfig in epel9

2021-12-30 Thread bugzilla

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

Fedora Update System  changed:

   What|Removed |Added

 Resolution|--- |ERRATA
 Status|ON_QA   |CLOSED
   Fixed In Version||perl-ExtUtils-PkgConfig-1.1
   ||6-16.el9
Last Closed||2021-12-31 01:47:32



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


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

[Bug 2028913] Please branch and build perl-GDGraph in epel9

2021-12-30 Thread bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=2028913
Bug 2028913 depends on bug 2031731, which changed state.

Bug 2031731 Summary: Please branch and build perl-ExtUtils-PkgConfig in epel9
https://bugzilla.redhat.com/show_bug.cgi?id=2031731

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA




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

[Bug 2031800] perl-GD-SecurityImage for EPEL 9

2021-12-30 Thread bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=2031800
Bug 2031800 depends on bug 2034048, which changed state.

Bug 2034048 Summary: perl-GD for EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2034048

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA




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

[Bug 2034851] Please branch and build perl-Throwable in epel9

2021-12-30 Thread bugzilla

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version||perl-Throwable-1.000-2.el9
 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA
Last Closed||2021-12-31 01:47:35



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


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

[Bug 2032426] perl-RDF-Query for EPEL 9

2021-12-30 Thread bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=2032426
Bug 2032426 depends on bug 2033606, which changed state.

Bug 2033606 Summary: Add perl-Set-Scalar to EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2033606

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA




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

[Bug 2033606] Add perl-Set-Scalar to EPEL 9

2021-12-30 Thread bugzilla

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||perl-Set-Scalar-1.29-21.el9
 Resolution|--- |ERRATA
Last Closed||2021-12-31 01:47:55



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


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

[Bug 2028913] Please branch and build perl-GDGraph in epel9

2021-12-30 Thread bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=2028913
Bug 2028913 depends on bug 2034048, which changed state.

Bug 2034048 Summary: perl-GD for EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2034048

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA




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

[Bug 2034048] perl-GD for EPEL 9

2021-12-30 Thread bugzilla

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

Fedora Update System  changed:

   What|Removed |Added

 Resolution|--- |ERRATA
 Status|ON_QA   |CLOSED
   Fixed In Version||perl-GD-2.73-1.el9
Last Closed||2021-12-31 01:47:44



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


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

[Bug 2031796] perl-Email-Sender for EPEL 9

2021-12-30 Thread bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=2031796
Bug 2031796 depends on bug 2034851, which changed state.

Bug 2034851 Summary: Please branch and build perl-Throwable in epel9
https://bugzilla.redhat.com/show_bug.cgi?id=2034851

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA




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

[Bug 2031796] perl-Email-Sender for EPEL 9

2021-12-30 Thread bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=2031796
Bug 2031796 depends on bug 2034850, which changed state.

Bug 2034850 Summary: Please branch and build perl-Sub-Override in epel9
https://bugzilla.redhat.com/show_bug.cgi?id=2034850

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA




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

[Bug 2034048] perl-GD for EPEL 9

2021-12-30 Thread bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=2034048
Bug 2034048 depends on bug 2031731, which changed state.

Bug 2031731 Summary: Please branch and build perl-ExtUtils-PkgConfig in epel9
https://bugzilla.redhat.com/show_bug.cgi?id=2031731

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA




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

[Bug 2030731] perl-SQL-Statement for EPEL 9

2021-12-30 Thread bugzilla

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||perl-SQL-Statement-1.414-6.
   ||el9
 Resolution|--- |ERRATA
Last Closed||2021-12-31 01:47:24



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


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

[Bug 2032513] Please branch and build perl-Sys-Virt in epel9

2021-12-30 Thread bugzilla

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||perl-Sys-Virt-7.10.0-1.el9
 Resolution|--- |ERRATA
Last Closed||2021-12-31 01:47:26



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


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

[Bug 2030731] perl-SQL-Statement for EPEL 9

2021-12-30 Thread bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=2030731
Bug 2030731 depends on bug 2030680, which changed state.

Bug 2030680 Summary: perl-DBD-CSV for EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2030680

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA




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

[Bug 2030680] perl-DBD-CSV for EPEL 9

2021-12-30 Thread bugzilla

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

Fedora Update System  changed:

   What|Removed |Added

 Resolution|--- |ERRATA
   Fixed In Version||perl-DBD-CSV-0.58-3.el9
 Status|ON_QA   |CLOSED
Last Closed||2021-12-31 01:47:21



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


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

Re: How do we announce new packages?

2021-12-30 Thread Fabio Valentini

On Sun, Dec 26, 2021 at 9:09 PM Matthew Miller  wrote:
>
> On Sat, Dec 25, 2021 at 09:15:38PM +0100, Fabio Valentini wrote:
> > So ... maybe we could have a mailing list for this?
> >
> > Maybe "awesome-announce" or "the-new-shinyness" (I'm kidding! I'm bad
> > with names!) at lists.fedoraproject.org, where all Fedora contributors
> > could post the fancy new thing that they just made? Because we
> > definitely don't have a good place for announcements like that right
> > now (the community blog might be the right place for some of those,
> > but it is a higher barrier to actually write a blog post that gets
> > edited etc. instead of writing an e-mail to a mailing list).
>
> Hmmm.
>
> The Community Blog should have a pretty low barrier to entry. Are
> people feeling blocked by that? We should try to adjust if so.
>
> As it is, the bar is basically "is this appropriate for this site" and "is
> the categorization right", with the editorial pass mostly being for
> egregious problems. In other words, I don't think it's actually much more
> heavyweight than a moderated announce mailing list would be.
>
> But I also am not sure Community Blog is the right audience — that's
> intended to be contributor-facing, and this seems like something aimed to e
> more user-facing.

Those are exactly my thoughts. I don't think there's a way for Fedora
contributors to "market" the cool new thing they've been working on to
*users* (or tech publications)?

I mean, submitting a Change Proposal results in things getting
announced pretty publicly, but that does not fit for smaller changes,
or changes that are not specific to the next Fedora release.

I know that some tech news websites follow discussions on the devel
list (and probably the announcement lists), but those are mostly not
really of interest to *users*, and there's no mailing list for "here's
a cool new feature!" that they can subscribe to. That might skew
newsworthy items more towards the "negative news" side of things, like
"this package is orphaned / retired" / "Is this maintainer still
responsive" etc., having more *positive* news to report on would be
nice for Fedora.

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

Re: F36 Change: Relocate RPM database to /usr (System-Wide Change proposal)

2021-12-30 Thread Gordon Messmer


On 12/30/21 12:22, Matthew Miller wrote:

So for a read-only filesystem, if the db has wal enabled, the files have
to exist. (it's possible to disable WAL mode by running the sqlite 'PRAGMA
journal_mode=DELETE;' command when the partition is writable beforehand,
but I didn't see how to alter the mode while it is readonly)

FWIW, Sqlite has guidance here:



Given that the "shared-memory file contains no persistent content", it 
seems like "rpmdb.sqlite-shm" could be a symlink to 
/dev/shm/rpmdb.sqlite-shm", or to some other tmpfs location.


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

Re: F36 Change: Relocate RPM database to /usr (System-Wide Change proposal)

2021-12-30 Thread Matthew Miller

On Thu, Dec 30, 2021 at 05:53:14PM +0900, Dominique Martinet wrote:

> So for a read-only filesystem, if the db has wal enabled, the files have
> to exist. (it's possible to disable WAL mode by running the sqlite 'PRAGMA
> journal_mode=DELETE;' command when the partition is writable beforehand,
> but I didn't see how to alter the mode while it is readonly)

FWIW, Sqlite has guidance here:

https://www.sqlite.org/wal.html#readonly

   Older versions of SQLite could not read a WAL-mode database that was
   read-only. In other words, write access was required in order to read a
   WAL-mode database. This constraint was relaxed beginning with SQLite
   version 3.22.0 (2018-01-22).

   On newer versions of SQLite, a WAL-mode database on read-only media, or a
   WAL-mode database that lacks write permission, can still be read as long
   as one or more of the following conditions are met:

   1. The -shm and -wal files already exists and are readable

   2. There is write permission on the directory containing the database so
  that the -shm and -wal files can be created.

   3. The database connection is opened using the immutable query parameter. 

   Even though it is possible to open a read-only WAL-mode database, it is
   good practice to converted to PRAGMA journal_mode=DELETE prior to burning
   an SQLite database image onto read-only media.

-- 
Matthew Miller

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

Re: F36 Change: Relocate RPM database to /usr (System-Wide Change proposal)

2021-12-30 Thread Neal Gompa

On Thu, Dec 30, 2021 at 2:14 PM Stephen John Smoogen  wrote:
>
>
>
> On Thu, 30 Dec 2021 at 13:58, Chris Murphy  wrote:
>>
>> On Thu, Dec 30, 2021 at 1:31 AM Zbigniew Jędrzejewski-Szmek
>>  wrote:
>> >
>> > On Thu, Dec 30, 2021 at 02:27:04AM -0500, Matthew Miller wrote:
>> > > On Wed, Dec 29, 2021 at 03:17:42PM +, Tom Hughes via devel wrote:
>> > > > At this point somebody will no doubt argue that /usr changes on a
>> > > > package update and that the RPM database is a static definition of
>> > > > the currently installed OS files, but evidence says otherwise:
>> > > >
>> > > > % ls -l /var/lib/rpm
>> > > >
>> > > > total 378M
>> > > >
>> > > > -rw-r--r--. 1 root root 378M Dec 28 16:08 rpmdb.sqlite
>> > > > -rw-r--r--. 1 root root  32K Dec 29 09:27 rpmdb.sqlite-shm
>> > > > -rw-r--r--. 1 root root0 Dec 28 16:08 rpmdb.sqlite-wal
>> > > >
>> > > >
>> > > > While "Dec 28 16:08" is indeed the last time I updated that machine
>> > > > it seems one of the files has changed more recently - no idea what
>> > > > triggered that but clearly the files are not static between updates.
>> > >
>> > > That is a sqlite write-ahead log shared memory file used to coordinate
>> > > access between concurrent clients. Someone who knows more about the 
>> > > depths
>> > > of DNF and RPM than me will need to comment, but it looks like `dnf list`
>> > > touches it -- even though `rpm -qa` doesn't.
>> >
>> > $ sudo strace -efile dnf list
>> > ...
>> > openat(AT_FDCWD, "/var/lib/rpm/rpmdb.sqlite-wal", 
>> > O_RDWR|O_CREAT|O_NOFOLLOW|O_CLOEXEC, 0644) = 4
>> > openat(AT_FDCWD, "/var/lib/rpm/rpmdb.sqlite-shm", 
>> > O_RDWR|O_CREAT|O_NOFOLLOW|O_CLOEXEC, 0644) = 5
>> > ...
>> >
>> > What happens if /var/lib is read-only? Changing (fixing?) this would
>> > be a pre-requisite to this proposal, we don't want 'dnf list' to break.
>>
>> Why should it be a prerequisite? In all Fedora editions and spins with
>> dnf, /usr and /var are read-write. In the case of rpm-ostree based
>> editions and spins, they don't include dnf. I agree dnf should
>> tolerate read-only rpmdb files, but I'm not following the logic
>> leading to it being a prerequisite (must tolerate rather than should
>> tolerate).
>
>
> I think that at least it needs to be ok'd that they can and will work on it 
> to fix. The dnf team may have other things on their queue that they need to 
> focus on this release so having to redesign their plumbing to deal with moved 
> files may not be possible. that leaves F36 shipped with a broken dnf and no 
> way anyone can update or run anything.
>

I've already validated this with DNF on openSUSE. This change was
executed in openSUSE for the rpmdb in 2017, and the DNF state
information in early 2021. DNF handled both transitions fine, since
libsolv gets the rpmdb path from rpm configuration.


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

Re: F36 Change: Relocate RPM database to /usr (System-Wide Change proposal)

2021-12-30 Thread Stephen John Smoogen

On Thu, 30 Dec 2021 at 13:58, Chris Murphy  wrote:

> On Thu, Dec 30, 2021 at 1:31 AM Zbigniew Jędrzejewski-Szmek
>  wrote:
> >
> > On Thu, Dec 30, 2021 at 02:27:04AM -0500, Matthew Miller wrote:
> > > On Wed, Dec 29, 2021 at 03:17:42PM +, Tom Hughes via devel wrote:
> > > > At this point somebody will no doubt argue that /usr changes on a
> > > > package update and that the RPM database is a static definition of
> > > > the currently installed OS files, but evidence says otherwise:
> > > >
> > > > % ls -l /var/lib/rpm
> > > >
> > > > total 378M
> > > >
> > > > -rw-r--r--. 1 root root 378M Dec 28 16:08 rpmdb.sqlite
> > > > -rw-r--r--. 1 root root  32K Dec 29 09:27 rpmdb.sqlite-shm
> > > > -rw-r--r--. 1 root root0 Dec 28 16:08 rpmdb.sqlite-wal
> > > >
> > > >
> > > > While "Dec 28 16:08" is indeed the last time I updated that machine
> > > > it seems one of the files has changed more recently - no idea what
> > > > triggered that but clearly the files are not static between updates.
> > >
> > > That is a sqlite write-ahead log shared memory file used to coordinate
> > > access between concurrent clients. Someone who knows more about the
> depths
> > > of DNF and RPM than me will need to comment, but it looks like `dnf
> list`
> > > touches it -- even though `rpm -qa` doesn't.
> >
> > $ sudo strace -efile dnf list
> > ...
> > openat(AT_FDCWD, "/var/lib/rpm/rpmdb.sqlite-wal",
> O_RDWR|O_CREAT|O_NOFOLLOW|O_CLOEXEC, 0644) = 4
> > openat(AT_FDCWD, "/var/lib/rpm/rpmdb.sqlite-shm",
> O_RDWR|O_CREAT|O_NOFOLLOW|O_CLOEXEC, 0644) = 5
> > ...
> >
> > What happens if /var/lib is read-only? Changing (fixing?) this would
> > be a pre-requisite to this proposal, we don't want 'dnf list' to break.
>
> Why should it be a prerequisite? In all Fedora editions and spins with
> dnf, /usr and /var are read-write. In the case of rpm-ostree based
> editions and spins, they don't include dnf. I agree dnf should
> tolerate read-only rpmdb files, but I'm not following the logic
> leading to it being a prerequisite (must tolerate rather than should
> tolerate).
>

I think that at least it needs to be ok'd that they can and will work on it
to fix. The dnf team may have other things on their queue that they need to
focus on this release so having to redesign their plumbing to deal with
moved files may not be possible. that leaves F36 shipped with a broken dnf
and no way anyone can update or run anything.


-- 
Stephen J Smoogen.
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Relocate RPM database to /usr (System-Wide Change proposal)

2021-12-30 Thread Chris Murphy

On Thu, Dec 30, 2021 at 1:31 AM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Thu, Dec 30, 2021 at 02:27:04AM -0500, Matthew Miller wrote:
> > On Wed, Dec 29, 2021 at 03:17:42PM +, Tom Hughes via devel wrote:
> > > At this point somebody will no doubt argue that /usr changes on a
> > > package update and that the RPM database is a static definition of
> > > the currently installed OS files, but evidence says otherwise:
> > >
> > > % ls -l /var/lib/rpm
> > >
> > > total 378M
> > >
> > > -rw-r--r--. 1 root root 378M Dec 28 16:08 rpmdb.sqlite
> > > -rw-r--r--. 1 root root  32K Dec 29 09:27 rpmdb.sqlite-shm
> > > -rw-r--r--. 1 root root0 Dec 28 16:08 rpmdb.sqlite-wal
> > >
> > >
> > > While "Dec 28 16:08" is indeed the last time I updated that machine
> > > it seems one of the files has changed more recently - no idea what
> > > triggered that but clearly the files are not static between updates.
> >
> > That is a sqlite write-ahead log shared memory file used to coordinate
> > access between concurrent clients. Someone who knows more about the depths
> > of DNF and RPM than me will need to comment, but it looks like `dnf list`
> > touches it -- even though `rpm -qa` doesn't.
>
> $ sudo strace -efile dnf list
> ...
> openat(AT_FDCWD, "/var/lib/rpm/rpmdb.sqlite-wal", 
> O_RDWR|O_CREAT|O_NOFOLLOW|O_CLOEXEC, 0644) = 4
> openat(AT_FDCWD, "/var/lib/rpm/rpmdb.sqlite-shm", 
> O_RDWR|O_CREAT|O_NOFOLLOW|O_CLOEXEC, 0644) = 5
> ...
>
> What happens if /var/lib is read-only? Changing (fixing?) this would
> be a pre-requisite to this proposal, we don't want 'dnf list' to break.

Why should it be a prerequisite? In all Fedora editions and spins with
dnf, /usr and /var are read-write. In the case of rpm-ostree based
editions and spins, they don't include dnf. I agree dnf should
tolerate read-only rpmdb files, but I'm not following the logic
leading to it being a prerequisite (must tolerate rather than should
tolerate).

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

Re: Request for Intel WiFi Backports - AX2xx

2021-12-30 Thread Marcin Juszkiewicz


W dniu 28.12.2021 o 00:30, Kevin Anderson pisze:


There was a iwlwifi issue that would cause firmware resets and cause
performance to significantly degrade to around ~500Kb/s till the
interface was brought down and then up again. Upstream identified the
issue and there are 2 patches that fix the issue by increasing the
scan timeout[1] and in cases where the firmware resets allows it to
recover quicker[2]. The patch to allow for quicker firmware recovery
is present in Linus' tree and present in the 5.16 rc releases while
the patch to prevent the firmware from crashing in the instance is in
net-next for 5.17.


Did anyone thought of merging those patches into 5.15-stable upstream?

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

Re: F36 Change: Relocate RPM database to /usr (System-Wide Change proposal)

2021-12-30 Thread Matthew Miller

On Thu, Dec 30, 2021 at 01:14:40PM -0500, Matthew Miller wrote:
> I'd be supportive of an effort to restart the FHS process with buy-in from
> openSUSE (and ideally Debian, Arch, FreeBSD...). And probably systemd too,
> from a plain pragmatic point of view.
> 
> I think we'd want to either ask Linux Foundation to split it back from the
> LSB into its own thing — or else explicitly fork into a new standard.

Wait, I hit send before finishing my thought, which is: we also need a
mechanism which reflects reality rather than an abstract design. Like, sure,
if we were going to create the whole thing from scratch now with no history,
it probably wouldn't look like it does. And distros (even Fedora) have
always just made exceptions. It'd be better to have a working, living
standard that makes room for that than one which everyone ignores.

Which is to say: I _don't_ think the process should be to get the FHS
restarted and updated and in agreement before moving forward, _especially_
when the proposal is already aligned with what openSUSE is doing, and what
we're already doing ourselves with IoT/CoreOS/Kinoite/Silverblue.

-- 
Matthew Miller

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

Re: F36 Change: Relocate RPM database to /usr (System-Wide Change proposal)

2021-12-30 Thread Matthew Miller

On Thu, Dec 30, 2021 at 10:12:20AM -0500, Neal Gompa wrote:
> > say, not as I do' route. I would say we either need to drop FHS
> > compliance or use an amended copy and work with the SuSE people on
> > making that a shared standard.
> 
> That's pretty much what has been going on. I've been working in
> openSUSE for a few years now to rationalize the FHS configuration in
> openSUSE to more closely match Fedora. As a result, today the only

I'd be supportive of an effort to restart the FHS process with buy-in from
openSUSE (and ideally Debian, Arch, FreeBSD...). And probably systemd too,
from a plain pragmatic point of view.

I think we'd want to either ask Linux Foundation to split it back from the
LSB into its own thing — or else explicitly fork into a new standard.


-- 
Matthew Miller

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

Re: F36 Change: Golang 1.18 (System-Wide Change proposal)

2021-12-30 Thread Fabio Valentini

On Tue, Dec 21, 2021 at 10:18 AM Alejandro Saez Morollon  
wrote:
>
> I was planning on doing the first, push go 1.18 beta/rc to rawhide (beta1 is 
> already there in fact).

Great, that's good to know.
It broke my only Go package, but at least go 1.18 is already in rawhide :)

> Go 1.18 beta 1 is already in the rawhide branch, so I guess we won't need a 
> second mass rebuild for golang.
> Regarding the Fedora 34 /35 impacting the decision. What happens if, for 
> whatever reason, 1.18 breaks a lot of builds and we decide to push back the 
> update.
> As  1.17 was never used in a mass rebuild, aren't the stable versions of Go 
> more suitable for the fall-back mass rebuild?

Go 1.17 has probably been in rawhide long enough that any big problems
should have been noticed already, so I don't think falling back to Go
1.17 for F36 should be a problem, in case 1.18 is very disruptive.

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

[Bug 2034850] Please branch and build perl-Sub-Override in epel9

2021-12-30 Thread bugzilla

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

Emmanuel Seyman  changed:

   What|Removed |Added

 Blocks||2036120





Referenced Bugs:

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

Re: F36 Change: Default To Noto Fonts (System-Wide Change proposal)

2021-12-30 Thread Michael Catanzaro

On Thu, Dec 30 2021 at 11:06:18 AM -0500, Neal Becker 
 wrote:

I'm testing in emacs.


I'm going to suggest testing in web browsers too, because the change is 
going to be especially noticeable there. A *lot* of websites use 
default fonts. I find https://lwn.net is a good test page.


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

[Bug 2034172] EPEL9 branch of perl-File-Find-Rule-Perl

2021-12-30 Thread bugzilla

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

Paul Howarth  changed:

   What|Removed |Added

 Blocks||2033349





Referenced Bugs:

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

[Bug 2036225] Please branch and build perl-Test-Portability-Files for EPEL-9

2021-12-30 Thread bugzilla

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

Paul Howarth  changed:

   What|Removed |Added

 Blocks||2033349





Referenced Bugs:

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

[Bug 2034030] Add perl-Test-MinimumVersion to EPEL 9

2021-12-30 Thread bugzilla

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

Paul Howarth  changed:

   What|Removed |Added

 Blocks||2033349





Referenced Bugs:

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

[Bug 2032452] perl-Test-Perl-Critic for EPEL 9

2021-12-30 Thread bugzilla

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

Paul Howarth  changed:

   What|Removed |Added

 Blocks||2033349





Referenced Bugs:

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

[Bug 2033196] Please branch and build perl-Task-Weaken for EPEL-9

2021-12-30 Thread bugzilla

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

Paul Howarth  changed:

   What|Removed |Added

 Blocks||2033349





Referenced Bugs:

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

[Bug 2033349] perl-Test-Modern for EPEL 9

2021-12-30 Thread bugzilla

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

Paul Howarth  changed:

   What|Removed |Added

 Depends On||2034172, 2034030, 2032452,
   ||2033196, 2036225
 Status|NEW |ASSIGNED





Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=2032452
[Bug 2032452] perl-Test-Perl-Critic for EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2033196
[Bug 2033196] Please branch and build perl-Task-Weaken for EPEL-9
https://bugzilla.redhat.com/show_bug.cgi?id=2034030
[Bug 2034030] Add perl-Test-MinimumVersion to EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2034172
[Bug 2034172] EPEL9 branch of perl-File-Find-Rule-Perl
https://bugzilla.redhat.com/show_bug.cgi?id=2036225
[Bug 2036225] Please branch and build perl-Test-Portability-Files for EPEL-9
-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2033349
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Default To Noto Fonts (System-Wide Change proposal)

2021-12-30 Thread Neal Becker

After seeing this proposal I tried playing with Noto Sans Mono.  I
find that while it comes with many weights, none look right to me.
Language is English.

I'm testing in emacs.  My usual default is Source code sans semibold
and I find that very pleasing.  I also tried Dejavu Sans Mono
semibold, which looks very similar.  But if I try Noto Sans Mono, no
weight looks right.  Medium is too light, and the next weight,
semibold, is too heavy.

On Wed, Dec 29, 2021 at 9:59 PM Robert Marcano via devel
 wrote:
>
> On 12/29/21 2:20 PM, Neal Gompa wrote:
> > On Wed, Dec 29, 2021 at 12:27 PM Artem Tim  wrote:
> >>
> >> Cantarell current default UI font in GNOME (Workstation) will be replaced 
> >> by Noto font as well or remain?
> >
> > The current plan is to keep Cantarell for now, though GNOME upstream
> > may decide to switch to Noto as KDE Plasma did years ago.
> >
>
> Does Noto have the default font-variant-numeric as tabular-nums? (non
> proportional decimal digits) because it will be a welcomed change.
>
> The current default of Cantarell makes any number showing application a
> pain to style, specially on toolkits that use the system font but are
> unable to change font variants (Java Swing with GTK Look and Feel).
>
> Even GNOME applications aren't properly styled for number entry use
> cases. See for example Calculator where 111,111,111 looks like a smaller
> number than 99,999,999 when the are one on top of the other, because the
> font is proportional by default.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure



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

[Bug 2036225] New: Please branch and build perl-Test-Portability-Files for EPEL-9

2021-12-30 Thread bugzilla

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

Bug ID: 2036225
   Summary: Please branch and build perl-Test-Portability-Files
for EPEL-9
   Product: Fedora EPEL
   Version: epel9
Status: NEW
 Component: perl-Test-Portability-Files
  Assignee: jples...@redhat.com
  Reporter: p...@city-fan.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com,
perl-devel@lists.fedoraproject.org, st...@silug.org
  Target Milestone: ---
Classification: Fedora



Could you please branch and build perl-Test-Portability-Files for EPEL-9 ?

If you prefer, you could add me (FAS: pghmcfc) as a committer and I'll do it
myself.


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

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

2021-12-30 Thread Fedora compose checker

No missing expected images.

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

Failed openQA tests: 21/228 (x86_64), 20/159 (aarch64)

New failures (same test not failed in Fedora-Rawhide-20211229.n.1):

ID: 1092363 Test: x86_64 Server-dvd-iso 
install_blivet_btrfs_preserve_home_uefi@uefi
URL: https://openqa.fedoraproject.org/tests/1092363
ID: 1092464 Test: x86_64 Silverblue-dvd_ostree-iso anaconda_help
URL: https://openqa.fedoraproject.org/tests/1092464
ID: 1092505 Test: aarch64 Server-dvd-iso install_default_upload@uefi
URL: https://openqa.fedoraproject.org/tests/1092505
ID: 1092515 Test: aarch64 Server-dvd-iso 
install_standard_partition_ext4@uefi
URL: https://openqa.fedoraproject.org/tests/1092515
ID: 1092528 Test: aarch64 Server-dvd-iso 
install_repository_hd_variation@uefi
URL: https://openqa.fedoraproject.org/tests/1092528
ID: 1092529 Test: aarch64 Server-dvd-iso install_btrfs_preserve_home@uefi
URL: https://openqa.fedoraproject.org/tests/1092529
ID: 1092607 Test: aarch64 Workstation-upgrade evince@uefi
URL: https://openqa.fedoraproject.org/tests/1092607
ID: 1092680 Test: x86_64 universal install_package_set_minimal
URL: https://openqa.fedoraproject.org/tests/1092680
ID: 1092710 Test: aarch64 universal install_asian_language@uefi
URL: https://openqa.fedoraproject.org/tests/1092710
ID: 1092712 Test: aarch64 universal install_cyrillic_language@uefi
URL: https://openqa.fedoraproject.org/tests/1092712

Old failures (same test failed in Fedora-Rawhide-20211229.n.1):

ID: 1092388 Test: x86_64 Server-dvd-iso 
server_role_deploy_domain_controller **GATING**
URL: https://openqa.fedoraproject.org/tests/1092388
ID: 1092393 Test: x86_64 Server-dvd-iso server_freeipa_replication_master
URL: https://openqa.fedoraproject.org/tests/1092393
ID: 1092394 Test: x86_64 Server-dvd-iso server_freeipa_replication_replica
URL: https://openqa.fedoraproject.org/tests/1092394
ID: 1092409 Test: x86_64 Server-dvd-iso realmd_join_cockpit
URL: https://openqa.fedoraproject.org/tests/1092409
ID: 1092410 Test: x86_64 Server-dvd-iso realmd_join_sssd **GATING**
URL: https://openqa.fedoraproject.org/tests/1092410
ID: 1092411 Test: x86_64 Server-dvd-iso server_freeipa_replication_client
URL: https://openqa.fedoraproject.org/tests/1092411
ID: 1092412 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart 
**GATING**
URL: https://openqa.fedoraproject.org/tests/1092412
ID: 1092420 Test: x86_64 Workstation-live-iso install_default@uefi 
**GATING**
URL: https://openqa.fedoraproject.org/tests/1092420
ID: 1092421 Test: x86_64 Workstation-live-iso install_default_upload 
**GATING**
URL: https://openqa.fedoraproject.org/tests/1092421
ID: 1092444 Test: x86_64 KDE-live-iso install_default_upload **GATING**
URL: https://openqa.fedoraproject.org/tests/1092444
ID: 1092445 Test: x86_64 KDE-live-iso install_no_user **GATING**
URL: https://openqa.fedoraproject.org/tests/1092445
ID: 1092450 Test: x86_64 KDE-live-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/1092450
ID: 1092477 Test: x86_64 Silverblue-dvd_ostree-iso release_identification
URL: https://openqa.fedoraproject.org/tests/1092477
ID: 1092561 Test: aarch64 Workstation-raw_xz-raw.xz desktop_printing@uefi
URL: https://openqa.fedoraproject.org/tests/1092561
ID: 1092562 Test: aarch64 Workstation-raw_xz-raw.xz gedit@uefi
URL: https://openqa.fedoraproject.org/tests/1092562
ID: 1092567 Test: aarch64 Workstation-raw_xz-raw.xz eog@uefi
URL: https://openqa.fedoraproject.org/tests/1092567
ID: 1092578 Test: aarch64 Cloud_Base-qcow2-qcow2 base_services_start@uefi
URL: https://openqa.fedoraproject.org/tests/1092578
ID: 1092580 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/1092580
ID: 1092589 Test: x86_64 Workstation-upgrade desktop_fprint
URL: https://openqa.fedoraproject.org/tests/1092589
ID: 1092603 Test: aarch64 Workstation-upgrade desktop_browser@uefi
URL: https://openqa.fedoraproject.org/tests/1092603
ID: 1092606 Test: aarch64 Workstation-upgrade desktop_printing@uefi
URL: https://openqa.fedoraproject.org/tests/1092606
ID: 1092618 Test: aarch64 Workstation-upgrade gedit@uefi
URL: https://openqa.fedoraproject.org/tests/1092618
ID: 1092619 Test: aarch64 Workstation-upgrade eog@uefi
URL: https://openqa.fedoraproject.org/tests/1092619
ID: 1092635 Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/1092635
ID: 1092691 Test: x86_64 universal upgrade_2_realmd_client
URL: https://openqa.fedoraproject.org/tests/1092691
ID: 1092692 Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/1092692
ID: 1092695 Test: x86_64 universal upgrade_realmd_client
URL:

Re: F36 Change: Relocate RPM database to /usr (System-Wide Change proposal)

2021-12-30 Thread Neal Gompa

On Thu, Dec 30, 2021 at 10:09 AM Stephen John Smoogen  wrote:
>
>
>
> On Wed, 29 Dec 2021 at 21:20, Matthew Miller  wrote:
>>
>> On Wed, Dec 29, 2021 at 10:51:44AM -0500, Stephen John Smoogen wrote:
>> > F36 but needs to be worked through the proper channels of 'upstream'. Get
>> > the FHS updated and fixed, work out that the change actually is going to be
>>
>>
>> Pretty sure that's a non-starter. FHS 3.0 was released in 2015, and the
>> whole thing has been effectively dead since.
>>
>
> I agree that the FHS and LSB are practically dead, but it is heavily used in 
> our work. FHS compliance is one of the first things package reviews get 
> dinged on and it doesn't help if we start down the 'Do as I say, not as I do' 
> route. I would say we either need to drop FHS compliance or use an amended 
> copy and work with the SuSE people on making that a shared standard.
>

That's pretty much what has been going on. I've been working in
openSUSE for a few years now to rationalize the FHS configuration in
openSUSE to more closely match Fedora. As a result, today the only
differences between Red Hat and SUSE distributions are in
/usr/lib/sysimage/rpm and usage of /srv in packages. I do not think
we'll adopt their usage of /srv anytime soon, but RPM-OSTree variants
already are working to move rpmdb from /usr/share/rpm to
/usr/lib/sysimage/rpm based on upstream feedback. This Change
basically makes it so we use the same rpmdb path regardless of Fedora
variant.




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

Re: F36 Change: Relocate RPM database to /usr (System-Wide Change proposal)

2021-12-30 Thread Stephen John Smoogen

On Wed, 29 Dec 2021 at 21:20, Matthew Miller 
wrote:

> On Wed, Dec 29, 2021 at 10:51:44AM -0500, Stephen John Smoogen wrote:
> > F36 but needs to be worked through the proper channels of 'upstream'. Get
> > the FHS updated and fixed, work out that the change actually is going to
> be
>
>
> Pretty sure that's a non-starter. FHS 3.0 was released in 2015, and the
> whole thing has been effectively dead since.
>
>
I agree that the FHS and LSB are practically dead, but it is heavily used
in our work. FHS compliance is one of the first things package reviews get
dinged on and it doesn't help if we start down the 'Do as I say, not as I
do' route. I would say we either need to drop FHS compliance or use an
amended copy and work with the SuSE people on making that a shared
standard.



-- 
Stephen J Smoogen.
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Copr - look back at 2021

2021-12-30 Thread Miroslav Suchý


Let me sum up what the Copr team did during 2021:

Mock:

 *

   We did eight releases of Mock

 *

   We moved Mock’s wiki to GitHub Pages to allow indexing by search engines
   https://rpm-software-management.github.io/mock/ 
and created a
   Fedora-based Jekyll container for local documentation testing
   (https://github.com/praiskup/jekyll-github-pages-fedora-container
   ).

 *

   We initiated the discussion about default epel-8-* config


Copr:

 *

   We did six releases of Copr and upgraded Copr servers to Fedora 35.

 *

   We wrote three “4 cool new projects to try in Copr” articles for Fedora 
Magazine

 *

   We rebuilt all gems from Rubygems.org for Fedora Rawhide
   http://frostyx.cz/posts/rebuilding-the-entire-rubygems-in-copr
   

 *

   We started to use AWS Spot instances for builders 
https://pavel.raiskup.cz/blog/aws-instances.html
   

 *

   We started to decommission APIv1 and APIv2 
https://fedora-copr.github.io/posts/EOL-APIv1-APIv2-pt2
   

 *

   You have an option to run a fedora-review after each build
   http://frostyx.cz/posts/running-fedora-review-after-copr-build
   

 *

   We created a new Ansible module `copr` which is available in community 
general collection
   https://fedora-copr.github.io/posts/new-ansible-module-copr
   

 *

   You can order your builds using batches now 
https://pavel.raiskup.cz/blog/build-ordering-by-batches-in-copr.html
   

 *

   People started using discussion under projects. There are more than one 
hundred active discussions
   https://discussion.fedoraproject.org/c/projects-in-copr/54 


 *

   We redesigned Copr’s home page

 *

   We worked on clean-up scripts resulting in 5+ TB cleaned from our backends.

 *

   We did six releases of `resalloc` with improvements for better throughput 
and reactions during peeks.
   https://github.com/praiskup/resalloc/ 

 *

   Copr’s servers got IPv6 
https://pavel.raiskup.cz/blog/switch-fedora-box-to-ipv6-in-aws.html
   

 *

   We did three releases of `prunerepo` https://pagure.io/prunerepo 


 *

   We added lots of builders and some architectures 
https://pavel.raiskup.cz/blog/copr-farm-of-builders.html
   and later we 
re-add ppc64le architecture, and started
   using spot AWS instances

 *

   We implemented Error Budget 
and our goal 
is:

 o

   97 % of builds of copr-ping package is finished within 6 minutes (this 
monitor length of queue and speed of
   builders)

 o

   99,3 % uptime of CDN

 o

   99,3 % uptime of copr-backend (dnf repositories) (cca 5h/month)

 o

   97.5 % uptime of copr-frontend (WebUI) (cca 18h/month)

 *

   There is work in progress on Kerberos authentication in copr-cli.

 *

   Statistics:

 o

   Copr run 2,900,000 builds.

 o

   People created 15 731 new projects.



Fedora:

 *

   We created a Fedora Sponsor site to easy find of a sponsor 
https://docs.pagure.org/fedora-sponsors/
   

 *

   We created a video explaining a dist-git https://youtu.be/VsnJymZRQOM 


 *

   We proposed Retired Packages change 
https://fedoraproject.org/wiki/Changes/RetiredPackages
   and it got accepted.

 *

   We created license-validate tool https://pagure.io/copr/license-validate/ 



Others:

 *

   We did four releases of Tito

 *

   We wrote an article about activating no-cost RHEL
   
https://developers.redhat.com/blog/2021/02/10/how-to-activate-your-no-cost-red-hat-enterprise-linux-subscription
   


 *

   We wrote three articles about storing GPG keys in DNS persuaded several 
distributions to put the records in DNS
   https://github.com/xsuchy/distribution-gpg-keys/#storing-keys-in-dns
   

 *

   New `modulemd-tools` release with "bld2repo" tool.


Outlook for 2022

 *

   We are in the middle of talking with IBM, which should result in the 
availability of native s390x builders

Re: F36 Change: Relocate RPM database to /usr (System-Wide Change proposal)

2021-12-30 Thread Francisco J . Tsao Santín via devel

It doesn't happen me since a long time, but rpmdb can be corrupted, and
it must be repaired without altering /usr. For me, rpmdb is variable
data so it must be placed at /var/lib according to FHS.

And because my sysadmin OCDs it would be disturbing for me relocating it at
/usr :-D

-- 
Francisco J. Tsao Santín
http://gattaca.es
1024D/71CF4D62  42 F1 53 35 EF 98 98 8A FC 6C 56 B3 4C A7 7D FB___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: DIGLIM (System-Wide Change proposal)

2021-12-30 Thread Zbigniew Jędrzejewski-Szmek

On Thu, Dec 30, 2021 at 01:04:29PM +, Roberto Sassu via devel wrote:
> > From: Zbigniew Jędrzejewski-Szmek [mailto:zbys...@in.waw.pl]
> > Sent: Thursday, December 30, 2021 1:02 PM
> > The gist of the proposal is described thus:
> > > The new feature behaves as follows. A modified kernel with the DIGLIM
> > > patches will expose to user space an interface to add/remove file
> > > digests from the kernel hash table. A user space parser, executed by
> > > the kernel during early boot, parses RPM headers found in /etc/diglim
> > > in the initial ram disk (included with a custom dracut script) and
> > > uploads them to the kernel. When a file is accessed, IMA calculates
> > > the file digest and queries it with DIGLIM. If the digest is found,
> > > measurement is skipped and appraisal is successful. If the digest is
> > > not found, a measurement of the file is performed and appraisal fails.
> > > When packages are installed or removed, the kernel hash table is kept
> > > synchronized with a new rpm plugin.
> > 
> > This description is … short.
> 
> I saw you asked more questions below. I will answer there.
> 
> > > A user space parser, executed by the kernel during early boot
> > 
> > Is it really executed by the kernel? This description makes it sound
> > like a special old-hotplug-helper-style program that is spawned directly
> > by the kernel.
> 
> Yes, it must be executed before init, otherwise the kernel
> would refuse to execute it. And probably, it must be executed
> earlier than now, as I'm seeing that the kmod binary is being
> executed (with the same mechanism, user-mode helper) before
> the digest lists are uploaded to the kernel.

Normally ima policy would be loaded by systemd if /etc/ima/ima-policy
is found… How does the loading of the digests relate to the loading
of the ima policy?

> The reason for the kernel denying any operation enforced
> by the IMA policy would be that there are no file signatures
> for appraisal. The digests loaded by the helper are used
> instead. For the same reason, the digest of the helper itself
> must be in the native format understood by the kernel
> (the process of generation and signing is done in kernel.spec),
> and the kernel must scan /etc/diglim to load the native
> digest list before the helper is executed.
> 
> > > parses RPM headers found in /etc/diglim in the initial ram disk
> > 
> > In general we try not to stuff more things in /etc, especially when
> > there is no reason to. Why doesn't the helper just read files from
> > /var/lib/rpm (or whatever %_dbpath du jour)?
> 
> The RPM DB cannot be loaded as it is. The kernel accepts a
> file format similar to kernel modules, with appended signatures
> (I added support for PGP appended signatures in IMA). Each RPM
> header, together with its signature, must be written individually
> in a file.
> 
> Also files in other formats can be added to the same directory
> (for example the user-generated digest lists).
> 
> If there is a better place than /etc, it would be fine for me to
> move the directory to a new location. 

Normally such files would go somewhere in /usr. In this case it makes
sense put them next to the rpmdb files. If users are allowed to add more
files, then those files provided by the admin should be in /etc.

> > This opens a bigger design question: the implementation seems to be
> > closely tied to a very specific boot sequence implementation:
> > grub2 + dracut. Unfortunately this is made even more opaque by the
> > text description which uses generic terms like "boot loader configuration"
> > when talking about a script which is intimately tied to some obsolete
> > imperative grub2 installation mechanism.
> 
> Ok, sorry for the confusion. We just need to add few parameters
> to the kernel command line, and include the digest lists in the
> initial ram disk. For now, I'm excluding the implementation of a
> custom script to select only the digest lists required for accessing
> files in the initial ram disk.

Hmm, so how does this work wrt. to transition to the host system?
The system has many more files from more packages, and those packages
are in different versions.

> > It would be much better if instead the helper to upload the hashes
> > to the kernel would be a generic tool that can be called whenever and
> > from whatever environment. _Then_ you can add a dracut module to call
> > it in the initrd, but that part should be a trivial wrapper, with all
> > the "business logic" contained in the generic helper.
> 
> Too late.
> 
> Also it cannot be a generic tool. First it is statically linked, to
> avoid depending on shared libraries for which a native digest
> list must be generated. At least with a static binary, only one
> file should be considered.
> 
> Second, I had to develop an ad-hoc LSM to protect the helper
> against the other root processes. The problem is that an attacker
> might be able to tamper with the memory of the helper containing
> the digests extracted from RPMs,

[Bug 2036215] New: perl-TheSchwartz-1.17 is available

2021-12-30 Thread bugzilla

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

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



Latest upstream release: 1.17
Current version/release in rawhide: 1.16-1.fc35
URL: http://search.cpan.org/dist/TheSchwartz/

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


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


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


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


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

Fedora rawhide compose report: 20211230.n.0 changes

2021-12-30 Thread Fedora Rawhide Report

OLD: Fedora-Rawhide-20211229.n.1
NEW: Fedora-Rawhide-20211230.n.0

= SUMMARY =
Added images:0
Dropped images:  1
Added packages:  1
Dropped packages:0
Upgraded packages:   20
Downgraded packages: 0

Size of added packages:  4.43 MiB
Size of dropped packages:0 B
Size of upgraded packages:   2.66 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =

= DROPPED IMAGES =
Image: Python_Classroom raw-xz aarch64
Path: 
Labs/aarch64/images/Fedora-Python-Classroom-Rawhide-20211229.n.1.aarch64.raw.xz

= ADDED PACKAGES =
Package: cachelib-16-2.20211220gitc4904ef.20211220gitc4904ef.fc36
Summary: Pluggable caching engine for scale high performance cache services
RPMs:cachelib cachelib-devel
Size:4.43 MiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  R-testthat-3.1.1-1.fc36
Old package:  R-testthat-3.1.0-1.fc36
Summary:  Unit Testing for R
RPMs: R-testthat
Size: 7.67 MiB
Size change:  55.85 KiB
Changelog:
  * Wed Dec 29 2021 Tom Callaway  - 3.1.1-1
  - update to 3.1.1


Package:  assimp-5.0.1-5.fc36
Old package:  assimp-5.0.1-4.fc36
Summary:  Library to import various 3D model formats into applications
RPMs: assimp assimp-devel assimp-doc python3-assimp
Size: 17.79 MiB
Size change:  18.32 KiB
Changelog:
  * Thu Dec 30 2021 Rich Mattes  - 5.0.1-5
  - Correct Unlicense shortname (rhbz#2036000)


Package:  bigloo-4.4c-1.2.fc36
Old package:  bigloo-4.4b-4.fc36
Summary:  A compiler for the Scheme programming language
RPMs: bigloo bigloo-doc bigloo-libs
Size: 87.30 MiB
Size change:  -714.47 KiB
Changelog:
  * Wed Dec 29 2021 Jerry James  - 4.4c-1.2
  - Version 4.4c-2
  - Drop obsolete -div-by-zero patch
  - Disable LTO again due to symbol collision errors
  - Reenable tests on s390x


Package:  ceph-2:16.2.7-2.fc36
Old package:  ceph-2:16.2.7-1.fc36
Summary:  User space components of the Ceph file system
RPMs: ceph ceph-base ceph-common ceph-fuse ceph-grafana-dashboards 
ceph-immutable-object-cache ceph-mds ceph-mgr ceph-mgr-cephadm 
ceph-mgr-dashboard ceph-mgr-diskprediction-local ceph-mgr-k8sevents 
ceph-mgr-modules-core ceph-mgr-rook ceph-mon ceph-osd ceph-prometheus-alerts 
ceph-radosgw ceph-resource-agents ceph-selinux ceph-test cephadm cephfs-java 
cephfs-mirror cephfs-shell cephfs-top libcephfs-devel libcephfs2 
libcephfs_jni-devel libcephfs_jni1 libcephsqlite libcephsqlite-devel 
librados-devel librados2 libradospp-devel libradosstriper-devel 
libradosstriper1 librbd-devel librbd1 librgw-devel librgw2 
python3-ceph-argparse python3-ceph-common python3-cephfs python3-rados 
python3-rbd python3-rgw rados-objclass-devel rbd-fuse rbd-mirror rbd-nbd
Size: 436.43 MiB
Size change:  -20.05 KiB
Changelog:
  * Wed Dec 29 2021 Kaleb S. KEITHLEY  - 2:16.2.7-2
  - 16.2.7, LGPLv2.1 -> LGPLv2+, rhbz#2036035


Package:  dummy-test-package-gloster-0-6498.fc36
Old package:  dummy-test-package-gloster-0-6495.fc36
Summary:  Dummy Test Package called Gloster
RPMs: dummy-test-package-gloster
Size: 395.93 KiB
Size change:  184 B
Changelog:
  * Wed Dec 29 2021 packagerbot  - 0-6496
  - rebuilt

  * Wed Dec 29 2021 packagerbot  - 0-6497
  - rebuilt

  * Thu Dec 30 2021 packagerbot  - 0-6498
  - rebuilt


Package:  efl-1.26.0-1.fc36
Old package:  efl-1.25.1-10.fc36
Summary:  Collection of Enlightenment libraries
RPMs: efl efl-devel
Size: 185.14 MiB
Size change:  43.32 MiB
Changelog:
  * Wed Dec 29 2021 Tom Callaway  - 1.26.0-1
  - update to 1.26.0


Package:  enlightenment-0.25.0-1.fc36
Old package:  enlightenment-0.24.2-3.fc35
Summary:  Enlightenment window manager
RPMs: enlightenment enlightenment-data enlightenment-devel
Size: 408.86 MiB
Size change:  356.57 MiB
Changelog:
  * Wed Dec 29 2021 Tom Callaway  - 0.25.0-1
  - update to 0.25.0


Package:  ghc9.2-9.2.1-4.fc36
Old package:  ghc9.2-9.2.1-3.fc36
Summary:  Glasgow Haskell Compiler
RPMs: ghc9.2 ghc9.2-Cabal ghc9.2-Cabal-devel ghc9.2-Cabal-doc 
ghc9.2-Cabal-prof ghc9.2-array ghc9.2-array-devel ghc9.2-array-doc 
ghc9.2-array-prof ghc9.2-base ghc9.2-base-devel ghc9.2-base-doc 
ghc9.2-base-prof ghc9.2-binary ghc9.2-binary-devel ghc9.2-binary-doc 
ghc9.2-binary-prof ghc9.2-bytestring ghc9.2-bytestring-devel 
ghc9.2-bytestring-doc ghc9.2-bytestring-prof ghc9.2-compiler 
ghc9.2-compiler-default ghc9.2-containers ghc9.2-containers-devel 
ghc9.2-containers-doc ghc9.2-containers-prof ghc9.2-deepseq 
ghc9.2-deepseq-devel ghc9.2-deepseq-doc ghc9.2-deepseq-prof ghc9.2-devel 
ghc9.2-directory ghc9.2-directory-devel ghc9.2-directory-doc 
ghc9.2-directory-prof ghc9.2-doc ghc9.2-doc-index ghc9.2-exceptions 
ghc9.2-exceptions-devel ghc9.2-exceptions-doc ghc9.2-exceptions-prof 
ghc9.2-filepath ghc9.2-filepath-devel ghc9.2-filepath-doc ghc

RE: F36 Change: DIGLIM (System-Wide Change proposal)

2021-12-30 Thread Roberto Sassu via devel

> From: Zbigniew Jędrzejewski-Szmek [mailto:zbys...@in.waw.pl]
> Sent: Thursday, December 30, 2021 1:02 PM
> The gist of the proposal is described thus:
> > The new feature behaves as follows. A modified kernel with the DIGLIM
> > patches will expose to user space an interface to add/remove file
> > digests from the kernel hash table. A user space parser, executed by
> > the kernel during early boot, parses RPM headers found in /etc/diglim
> > in the initial ram disk (included with a custom dracut script) and
> > uploads them to the kernel. When a file is accessed, IMA calculates
> > the file digest and queries it with DIGLIM. If the digest is found,
> > measurement is skipped and appraisal is successful. If the digest is
> > not found, a measurement of the file is performed and appraisal fails.
> > When packages are installed or removed, the kernel hash table is kept
> > synchronized with a new rpm plugin.
> 
> This description is … short.

I saw you asked more questions below. I will answer there.

> > A user space parser, executed by the kernel during early boot
> 
> Is it really executed by the kernel? This description makes it sound
> like a special old-hotplug-helper-style program that is spawned directly
> by the kernel.

Yes, it must be executed before init, otherwise the kernel
would refuse to execute it. And probably, it must be executed
earlier than now, as I'm seeing that the kmod binary is being
executed (with the same mechanism, user-mode helper) before
the digest lists are uploaded to the kernel.

The reason for the kernel denying any operation enforced
by the IMA policy would be that there are no file signatures
for appraisal. The digests loaded by the helper are used
instead. For the same reason, the digest of the helper itself
must be in the native format understood by the kernel
(the process of generation and signing is done in kernel.spec),
and the kernel must scan /etc/diglim to load the native
digest list before the helper is executed.

> > parses RPM headers found in /etc/diglim in the initial ram disk
> 
> In general we try not to stuff more things in /etc, especially when
> there is no reason to. Why doesn't the helper just read files from
> /var/lib/rpm (or whatever %_dbpath du jour)?

The RPM DB cannot be loaded as it is. The kernel accepts a
file format similar to kernel modules, with appended signatures
(I added support for PGP appended signatures in IMA). Each RPM
header, together with its signature, must be written individually
in a file.

Also files in other formats can be added to the same directory
(for example the user-generated digest lists).

If there is a better place than /etc, it would be fine for me to
move the directory to a new location. 

> This opens a bigger design question: the implementation seems to be
> closely tied to a very specific boot sequence implementation:
> grub2 + dracut. Unfortunately this is made even more opaque by the
> text description which uses generic terms like "boot loader configuration"
> when talking about a script which is intimately tied to some obsolete
> imperative grub2 installation mechanism.

Ok, sorry for the confusion. We just need to add few parameters
to the kernel command line, and include the digest lists in the
initial ram disk. For now, I'm excluding the implementation of a
custom script to select only the digest lists required for accessing
files in the initial ram disk.

> It would be much better if instead the helper to upload the hashes
> to the kernel would be a generic tool that can be called whenever and
> from whatever environment. _Then_ you can add a dracut module to call
> it in the initrd, but that part should be a trivial wrapper, with all
> the "business logic" contained in the generic helper.

Too late.

Also it cannot be a generic tool. First it is statically linked, to
avoid depending on shared libraries for which a native digest
list must be generated. At least with a static binary, only one
file should be considered.

Second, I had to develop an ad-hoc LSM to protect the helper
against the other root processes. The problem is that an attacker
might be able to tamper with the memory of the helper containing
the digests extracted from RPMs, before the digests are uploaded
to the kernel. Anything that the helper accesses must be inspected
by IMA to provide the guarantee that the helper was not tampered.

> This will make testing easier, and not preclude systems without an
> initrd.
> 
> > When a file is accessed, IMA calculates the file digest and queries it with
> DIGLIM
> 
> All files? What does "accessed" mean exactly in this context?

IMA selects the files to analyze depending on a policy. That policy
allows the usage of different criteria: inode UID/GID, process UID/EUID,
LSM label, etc. IMA does this selection at the time a file is executed,
mmapped, opened, or read from the kernel.

DIGLIM is invoked only whenever IMA selected a file, and IMA
decides what to do with the file depending on the

RE: F36 Change: DIGLIM (System-Wide Change proposal)

2021-12-30 Thread Roberto Sassu via devel

> From: Vitaly Zaitsev via devel [mailto:devel@lists.fedoraproject.org]
> Sent: Thursday, December 30, 2021 12:18 PM
> On 29/12/2021 15:20, Roberto Sassu via devel wrote:
> > The TPM has a fundamental advantage, compared to other
> > mechanisms. It is tamperproof, it often receives high-grade
> > certifications, and it is one of the few components that you
> > could rely on to protect your sensitive data in the event your
> > host becomes compromised.
> 
> https://arstechnica.com/gadgets/2021/08/how-to-go-from-stolen-pc-to-
> network-intrusion-in-30-minutes/

If I understood the article correctly, the communication was
spoofed due to not using the encrypted session feature of
the TPM. The TPM also supports protection against tampering
of the communication with the HMAC session.

Roberto

HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
Managing Director: Li Peng, Zhong Ronghua
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2036201] perl-Math-BigInt-GMP-1.6010 is available

2021-12-30 Thread bugzilla

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

Paul Howarth  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-Math-BigInt-GMP-1.6010
   ||-1.fc36
 Resolution|--- |RAWHIDE
Last Closed||2021-12-30 12:08:52




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

Re: F36 Change: DIGLIM (System-Wide Change proposal)

2021-12-30 Thread Zbigniew Jędrzejewski-Szmek

The gist of the proposal is described thus:
> The new feature behaves as follows. A modified kernel with the DIGLIM
> patches will expose to user space an interface to add/remove file
> digests from the kernel hash table. A user space parser, executed by
> the kernel during early boot, parses RPM headers found in /etc/diglim
> in the initial ram disk (included with a custom dracut script) and
> uploads them to the kernel. When a file is accessed, IMA calculates
> the file digest and queries it with DIGLIM. If the digest is found,
> measurement is skipped and appraisal is successful. If the digest is
> not found, a measurement of the file is performed and appraisal fails.
> When packages are installed or removed, the kernel hash table is kept
> synchronized with a new rpm plugin.

This description is … short.

> A user space parser, executed by the kernel during early boot

Is it really executed by the kernel? This description makes it sound
like a special old-hotplug-helper-style program that is spawned directly
by the kernel.

> parses RPM headers found in /etc/diglim in the initial ram disk

In general we try not to stuff more things in /etc, especially when
there is no reason to. Why doesn't the helper just read files from
/var/lib/rpm (or whatever %_dbpath du jour)?

This opens a bigger design question: the implementation seems to be
closely tied to a very specific boot sequence implementation:
grub2 + dracut. Unfortunately this is made even more opaque by the
text description which uses generic terms like "boot loader configuration"
when talking about a script which is intimately tied to some obsolete
imperative grub2 installation mechanism.

It would be much better if instead the helper to upload the hashes
to the kernel would be a generic tool that can be called whenever and
from whatever environment. _Then_ you can add a dracut module to call
it in the initrd, but that part should be a trivial wrapper, with all
the "business logic" contained in the generic helper.

This will make testing easier, and not preclude systems without an
initrd.

> When a file is accessed, IMA calculates the file digest and queries it with 
> DIGLIM

All files? What does "accessed" mean exactly in this context?

> When packages are installed or removed, the kernel hash table is kept
> synchronized with a new rpm plugin.

Does this mean that old hashes are removed from the kernel after a
package has been upgraded?

Are there any race conditions: e.g. when a new version of a package is
installed, at what point in time are the new hashes uploaded? Something
may be executed concurrently with the package upgrade, which would mean
that the new hashes would need to be uploaded before any files land on
disk.

And vice versa, if a file is opened, and later executed with fexecve(2),
and concurrently the package is upgraded between those two steps,
will the execution fail?

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

[Fedocal] Reminder meeting : ELN SIG

2021-12-30 Thread sgallagh

Dear all,

You are kindly invited to the meeting:
   ELN SIG on 2021-12-31 from 12:00:00 to 13:00:00 US/Eastern
   At fedora-meet...@irc.libera.chat

The meeting will be about:



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

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

RE: F36 Change: DIGLIM (System-Wide Change proposal)

2021-12-30 Thread Roberto Sassu via devel

> From: Vitaly Zaitsev via devel [mailto:devel@lists.fedoraproject.org]
> Sent: Thursday, December 30, 2021 12:16 PM
> On 29/12/2021 21:53, Michel Alexandre Salim wrote:
> > If/when something like this gets shipped, I hope Fedora limits itself to
> > shipping a policy that is the equivalent of SELinux's 'targeted' policy:
> > protect the RPMs that Fedora ships from being tampered with, let users
> > do whatever on top.
> 
> What about if the user wants to replace Fedora's version with another
> from mock/COPR?

I have a good example for that. I'm using myself a COPR repository
to build the kernel package with the DIGLIM patches. That kernel
also includes my own GPG key generated for me by COPR.

This has not been decided yet, but likely the Fedora kernel will
contain the official Fedora keys, and the user will decide to add
new keys (including those from COPR).

A simple way to find which keys you need will be from the
RPM DB:

rpm -qa | grep gpg-pubkey-

Roberto

HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
Managing Director: Li Peng, Zhong Ronghua
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2036201] perl-Math-BigInt-GMP-1.6010 is available

2021-12-30 Thread bugzilla

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

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

[Bug 2036201] New: perl-Math-BigInt-GMP-1.6010 is available

2021-12-30 Thread bugzilla

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

Bug ID: 2036201
   Summary: perl-Math-BigInt-GMP-1.6010 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Math-BigInt-GMP
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com, p...@city-fan.org,
perl-devel@lists.fedoraproject.org, st...@silug.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 1.6010
Current version/release in rawhide: 1.6009-1.fc36
URL: http://search.cpan.org/dist/Math-BigInt-GMP/

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


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


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


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


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

Re: F36 Change: Hunspell Dictionary dir change (System-Wide Change proposal)

2021-12-30 Thread Dan Čermák

Elliott Sales de Andrade  writes:

> On Wed, 29 Dec 2021 at 10:02, Ben Cotton  wrote:
>>
>> https://fedoraproject.org/wiki/Changes/Hunspell_dictionary_dir_change
>>
>> == Summary ==
>> Update Hunspell Dictionary system directory from /usr/share/myspell/
>> to /usr/share/hunspell/
>>
>> == Owner ==
>> * Name: [[User:vishalvvr| Vishal Vijayraghavan]]
>> * Email: 
>>
>>
>> == Detailed Description ==
>> In most of Linux distributions the standard Hunspell dictionary path
>> is `/usr/share/hunspell/` but in Fedora still has
>> `/usr/share/myspell/`. This effort is to follow default standard to
>> install all Hunspell dictionary into `/usr/share/hunspell/` instead of
>> `/usr/share/myspell/`.
>>
>>
>> == Benefit to Fedora ==
>> This will future proof Fedora to use the correct current location for
>> hunspell spelling dictionaries.
>>
>> == Scope ==
>> * Proposal owners:
>> In total there are `135` packages which is to be updated. libreoffice
>> & Firefox are the two main applications and rest are mostly language
>> dictionary packages.
>>
>> * Other developers:
>>
>> * Policies and guidelines: N/A (not needed for this Change)
>> * Trademark approval: N/A (not needed for this Change)
>> * Alignment with Objectives:
>>
>>
>> == Upgrade/compatibility impact ==
>>
>>
>> == How To Test ==
>> 1. Check if default installed dictionary path is
>> `/usr/share/hunspell/` instead of `/usr/share/myspell/`
>>
>> `$ hunspell -D` or `$ ls /usr/share/hunspell/`
>>
>> 2. Install any language dictionary and check if it getting installed
>> into '/usr/share/hunspell/'
>>
>> `$ dnf install hunspell-hi`
>>
>> `$ hunspell -D`
>>
>
> If, as mentioned above, this will possibly affect applications such as
> Firefox and LibreOffice, then those should also be tested as well.

Emacs and other text editors could be affected by this as well.


Cheers,

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

Re: F36 Change: DIGLIM (System-Wide Change proposal)

2021-12-30 Thread Vitaly Zaitsev via devel


On 30/12/2021 09:21, Chris Murphy wrote:

CPU is proprietary, the firmware is proprietary. Guess we can't trust
our computers?


RISC-V.

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

Re: F36 Change: DIGLIM (System-Wide Change proposal)

2021-12-30 Thread Vitaly Zaitsev via devel


On 29/12/2021 15:20, Roberto Sassu via devel wrote:

The TPM has a fundamental advantage, compared to other
mechanisms. It is tamperproof, it often receives high-grade
certifications, and it is one of the few components that you
could rely on to protect your sensitive data in the event your
host becomes compromised.


https://arstechnica.com/gadgets/2021/08/how-to-go-from-stolen-pc-to-network-intrusion-in-30-minutes/

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

Re: F36 Change: DIGLIM (System-Wide Change proposal)

2021-12-30 Thread Vitaly Zaitsev via devel


On 29/12/2021 21:53, Michel Alexandre Salim wrote:

If/when something like this gets shipped, I hope Fedora limits itself to
shipping a policy that is the equivalent of SELinux's 'targeted' policy:
protect the RPMs that Fedora ships from being tampered with, let users
do whatever on top.


What about if the user wants to replace Fedora's version with another 
from mock/COPR?


This is a very common scenario. Most of Fedora packages can't be updated 
to the latest major version in stable releases due to Fedora Updates 
policy, and users install them from COPR.


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

Re: F36 Change: Hunspell Dictionary dir change (System-Wide Change proposal)

2021-12-30 Thread Vitaly Zaitsev via devel


On 30/12/2021 10:21, Zbigniew Jędrzejewski-Szmek wrote:

Would it be possible to symlink /usr/share/myspell → hunspell
so that applications which try to use the old path still work?


+1 for creating a symbolic link. Some proprietary applications may still 
use the old path.


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

Re: F36 Change: Relocate RPM database to /usr (System-Wide Change proposal)

2021-12-30 Thread Vitaly Zaitsev via devel


On 29/12/2021 18:47, Gordon Messmer wrote:
If /usr really is read-only, then it probably doesn't matter where the 
rpmdb is, since packages can't be installed (generally).


dnf opens these database files for writing, even for the simple `dnf list`.

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

Fedora-Cloud-34-20211230.0 compose check report

2021-12-30 Thread Fedora compose checker

No missing expected images.

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

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

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

Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Hunspell Dictionary dir change (System-Wide Change proposal)

2021-12-30 Thread Zbigniew Jędrzejewski-Szmek

On Wed, Dec 29, 2021 at 10:01:49AM -0500, Ben Cotton wrote:
> == How To Test ==
> 1. Check if default installed dictionary path is
> `/usr/share/hunspell/` instead of `/usr/share/myspell/`

Would it be possible to symlink /usr/share/myspell → hunspell
so that applications which try to use the old path still work?

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

Re: F36 Change: Relocate RPM database to /usr (System-Wide Change proposal)

2021-12-30 Thread Dominique Martinet

Zbigniew Jędrzejewski-Szmek wrote on Thu, Dec 30, 2021 at 08:29:54AM +:
> $ sudo strace -efile dnf list
> ...
> openat(AT_FDCWD, "/var/lib/rpm/rpmdb.sqlite-wal", 
> O_RDWR|O_CREAT|O_NOFOLLOW|O_CLOEXEC, 0644) = 4
> openat(AT_FDCWD, "/var/lib/rpm/rpmdb.sqlite-shm", 
> O_RDWR|O_CREAT|O_NOFOLLOW|O_CLOEXEC, 0644) = 5
> ...
> 
> What happens if /var/lib is read-only? Changing (fixing?) this would
> be a pre-requisite to this proposal, we don't want 'dnf list' to break.

That's easy enough to test.
Apparently, of the files already exist the open calls work without
problem.
If the files don't (e.g. cleared by running 'sqlite3 rpmdb.sqlite
vacuum'), then sqlite apparently tries to create them and fails
horribly -- but so does rpm -qa:

# rpm -qa
error: sqlite failure: CREATE TABLE IF NOT EXISTS 'Packages' (hnum INTEGER 
PRIMARY KEY AUTOINCREMENT,blob BLOB NOT NULL): unable to open database file
error: cannot open Packages index using sqlite - No such file or directory (2)
error: cannot open Packages database in /var/lib/rpm

or for that matter plain sqlite3:
# sqlite3 rpmdb.sqlite 'select * from Packages;'
Error: unable to open database file

So for a read-only filesystem, if the db has wal enabled, the files have
to exist.
(it's possible to disable WAL mode by running the sqlite 'PRAGMA
journal_mode=DELETE;'  command when the partition is writable
beforehand, but I didn't see how to alter the mode while it is readonly)


Anyway, I don't think vacuum ever runs automatically so the files should
always be present and it probably should just work™.


FWIW I've been running with my rpmdb in /usr (through a bind mount) for
a few years precisely to keep the rpmdb in sync with the rest of /usr
for snapshots -- it's pretty much necessary to run rpm -q on old
snapshots and figure which version of what was where easily.
Unless btrfs somehow becomes able to tie multiple subvolume snapshots
together I think it's a good change.

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

Fedora-Cloud-35-20211230.0 compose check report

2021-12-30 Thread Fedora compose checker

No missing expected images.

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

Old soft failures (same test soft failed in Fedora-Cloud-35-20211229.0):

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

Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Relocate RPM database to /usr (System-Wide Change proposal)

2021-12-30 Thread Zbigniew Jędrzejewski-Szmek

On Thu, Dec 30, 2021 at 02:27:04AM -0500, Matthew Miller wrote:
> On Wed, Dec 29, 2021 at 03:17:42PM +, Tom Hughes via devel wrote:
> > At this point somebody will no doubt argue that /usr changes on a
> > package update and that the RPM database is a static definition of
> > the currently installed OS files, but evidence says otherwise:
> > 
> > % ls -l /var/lib/rpm
> > 
> > total 378M
> > 
> > -rw-r--r--. 1 root root 378M Dec 28 16:08 rpmdb.sqlite
> > -rw-r--r--. 1 root root  32K Dec 29 09:27 rpmdb.sqlite-shm
> > -rw-r--r--. 1 root root0 Dec 28 16:08 rpmdb.sqlite-wal
> > 
> > 
> > While "Dec 28 16:08" is indeed the last time I updated that machine
> > it seems one of the files has changed more recently - no idea what
> > triggered that but clearly the files are not static between updates.
> 
> That is a sqlite write-ahead log shared memory file used to coordinate
> access between concurrent clients. Someone who knows more about the depths
> of DNF and RPM than me will need to comment, but it looks like `dnf list`
> touches it -- even though `rpm -qa` doesn't.

$ sudo strace -efile dnf list
...
openat(AT_FDCWD, "/var/lib/rpm/rpmdb.sqlite-wal", 
O_RDWR|O_CREAT|O_NOFOLLOW|O_CLOEXEC, 0644) = 4
openat(AT_FDCWD, "/var/lib/rpm/rpmdb.sqlite-shm", 
O_RDWR|O_CREAT|O_NOFOLLOW|O_CLOEXEC, 0644) = 5
...

What happens if /var/lib is read-only? Changing (fixing?) this would
be a pre-requisite to this proposal, we don't want 'dnf list' to break.

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

Re: F36 Change: DIGLIM (System-Wide Change proposal)

2021-12-30 Thread Chris Murphy

On Wed, Dec 29, 2021 at 7:39 AM Vitaly Zaitsev via devel
 wrote:
>
> On 29/12/2021 12:38, Neal Gompa wrote:
> > Were they really? TPM devices*are*  commonly used today to support
> > attestation and multi-factor encryption and authentication mechanisms.
> > In many ways, the trusted computing initiative was a success. And even
> > virtualization is used for implementing trusted computing in some
> > platforms.
>
> All hardware TPM implementations are proprietary. We can't trust them.

CPU is proprietary, the firmware is proprietary. Guess we can't trust
our computers?



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

67 matches

Mail list logo