Re: Fedora 34 Change: Deprecate python-mock (Self-Contained change proposal)

On Mon, Feb 08, 2021 at 07:54:00PM -0500, Robbie Harwood wrote: > Miro Hrončok writes: > > > On 08. 02. 21 20:38, Robbie Harwood wrote: > >> Robbie Harwood writes: > >> > >>> Ben Cotton writes: > >>> > A simple `sed` can be applied in `%prep` as a temporary (or even > permanent)

Re: Fedora 34 Mass Rebuild

On Mon, 2021-02-08 at 23:17 +0100, Jonathan Wakely wrote: > No, it's simply that glib2 was changed a few days ago, after the mass > rebuild. The syncevolution sources didn't change, but some of the > headers it depends on did change. Hi, you are right, it was just a good timing thing.

Fedora-Cloud-33-20210209.0 compose check report

No missing expected images. Soft failed openQA tests: 1/7 (x86_64), 1/7 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-33-20210208.0): ID: 772532 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL:

[389-devel] 389 DS nightly 2021-02-09 - 95% PASS

https://fedorapeople.org/groups/389ds/ci/nightly/2021/02/09/report-389-ds-base-2.0.2-20210209git4f22163e6.fc33.x86_64.html ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to

Re: New memory tester application potentially to replace memtest86+: PCMemTest

On Mon, Feb 8, 2021 at 7:13 PM Kevin Kofler via devel wrote: > > Chris Murphy wrote: > > If you want to take the risk of acquiring a rootkit that can > > permanently take control of your firmware, that is up to you. It > > should not be a distribution recommendation to subject users to such > >

Re: New memory tester application potentially to replace memtest86+: PCMemTest

On Mon, Feb 8, 2021 at 9:13 PM Kevin Kofler via devel wrote: > > Chris Murphy wrote: > > If you want to take the risk of acquiring a rootkit that can > > permanently take control of your firmware, that is up to you. It > > should not be a distribution recommendation to subject users to such > >

Re: New memory tester application potentially to replace memtest86+: PCMemTest

Chris Murphy wrote: > If you want to take the risk of acquiring a rootkit that can > permanently take control of your firmware, that is up to you. It > should not be a distribution recommendation to subject users to such > bad advice. And the "good advice" would be to accept that your computer

Re: New memory tester application potentially to replace memtest86+: PCMemTest

On Mon, Feb 8, 2021 at 5:19 PM Kevin Kofler via devel wrote: > > Chris Murphy wrote: > > Yeah I definitely do not want Fedora in a position where anyone has to > > give users advice like "you need to disable UEFI Secure Boot" in order > > to do X. Be it testing RAM or anything else. > > Why would

[Bug 1922743] perlbrew-0.91 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1922743 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In

[Bug 1922014] perlbrew-0.90 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1922014 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In

Re: Fedora 34 Change: Deprecate python-mock (Self-Contained change proposal)

Miro Hrončok writes: > On 08. 02. 21 20:38, Robbie Harwood wrote: >> Robbie Harwood writes: >> >>> Ben Cotton writes: >>> A simple `sed` can be applied in `%prep` as a temporary (or even permanent) downstream solution. In most cases, performing the following replacement

Re: New memory tester application potentially to replace memtest86+: PCMemTest

Chris Murphy wrote: > Yeah I definitely do not want Fedora in a position where anyone has to > give users advice like "you need to disable UEFI Secure Boot" in order > to do X. Be it testing RAM or anything else. Why would anyone want to NOT disable Restricted Boot? (Assuming the firmware is not

Re: Fedora 34 Mass Branching

Hi, I were unable to find time in the schedule, at which the new F35 GPG key would be activated to sign new builds. In order to prevent bug 1872248 [1], new key must not be used until all stable releases got new key with symlinks for all supported arches. New builds were done few days ago, f33

Re: New memory tester application potentially to replace memtest86+: PCMemTest

On Mon, Feb 8, 2021 at 4:47 PM Martin Whitaker wrote: > > On 07/02/2021 22:23, Chris Murphy wrote: > > On Sun, Feb 7, 2021 at 2:08 AM Neal Gompa wrote: > >> > >> Hey all, > >> > >> I discovered today that there's a new replacement for memtest86+ that > >> appears to even have UEFI support called

Re: Policy proposal (draft): Don't push knowingly broken or work-in-progress work to dist git

Jonathan Wakely wrote: > How do you get that directly from koji in a script? > > Is it as easy as a single git command to check if rawhide and > rawhide-build are the same ref? > > It looks to me like I need to parse the build ID from the output of > "koji latest-build " and then use "koji

Re: Fedora 34 Change: LTO Build Improvements (System-Wide Change proposal)

On 2/2/21 5:03 PM, Ian McInerney wrote: > On Mon, Jan 4, 2021 at 7:28 PM Jeff Law > wrote: > > > snip... > > > > What is this macro going to be called?  I would like to get an early > > start on updating my packages. > No idea.  I'm open to

[EPEL-devel] Re: Proposal: EPEL9 timeline

On Mon, Feb 8, 2021 at 11:50 AM Kevin Fenzi wrote: > > On Mon, Feb 08, 2021 at 08:19:24AM -0500, Stephen John Smoogen wrote: > > There is a little nuance here. In order to get the repository going, we had > > to 'mass-branch' about 40 or so packages. fedpkg and some other items > > require quite

Re: Fedora 34 Mass Rebuild

On 08/02/21 14:40 +0100, Milan Crha wrote: On Mon, 2021-02-01 at 15:03 -0500, Mohan Boddu wrote: Fedora 34 mass rebuild of rpms is done Hi, I just noticed that syncevolution built just fine on the January 30th, but it is failing to build right now, using the same sources as releng. I

linux-firmware heads up for brcmfmac wifi firmware

Hi All, Just a heads up for those that have a brcmfmac, the Cypress variants of these WiFi modules (there's 3 vendors that make them: Broadcom, Cypress/Infineon and now Synaptics) have got new firmwares, I'm giving a heads up because in some cases the firmwares are being updated from firmwares

Re: Fedora 34 Change: Deprecate python-mock (Self-Contained change proposal)

On 08. 02. 21 22:43, Miro Hrončok wrote: On 08. 02. 21 20:38, Robbie Harwood wrote: Robbie Harwood writes: Ben Cotton writes: A simple `sed` can be applied in `%prep` as a temporary (or even permanent) downstream solution. In most cases, performing the following replacement should be

Re: Fedora 34 Change: Deprecate python-mock (Self-Contained change proposal)

On 08. 02. 21 20:38, Robbie Harwood wrote: Robbie Harwood writes: Ben Cotton writes: A simple `sed` can be applied in `%prep` as a temporary (or even permanent) downstream solution. In most cases, performing the following replacement should be enough: s/^(\s*)import mock/\1from

[EPEL-devel] Re: Proposal: EPEL9 timeline

On 08. 02. 21 14:19, Stephen John Smoogen wrote: There is a little nuance here. In order to get the repository going, we had to 'mass-branch' about 40 or so packages. fedpkg and some other items require quite a few packages which all have to be done at once. Without those you can't build

Re: Orphaned packages looking for new maintainers

On Mon, Feb 8, 2021 at 8:04 PM José Abílio Matos wrote: > Something that I am curious is that the package that was rebuilt on the mass > rebuild does not show in the stable version of Fedora 34: > > https://src.fedoraproject.org/rpms/python-blinker > > Is this expected? You mean it does not show

Re: Orphaned packages looking for new maintainers

On Mon, Feb 08, 2021 at 07:07:40PM +0100, Miro Hrončok wrote: > On 08. 02. 21 19:03, Gwyn Ciesla via devel wrote: > > I believe Tomasz was asking about the many packages that indirectly require > > uw-imap. Exactly, sorry for not communicating clearly enough. > Oh. Right, php indeed.

Re: New memory tester application potentially to replace memtest86+: PCMemTest

On 2/8/21 2:44 PM, Chris Murphy wrote: On Mon, Feb 8, 2021 at 2:46 AM Vít Ondruch wrote: Being devils advocate, but should we have the memtest86 or similar by default? I have certainly not used this feature in my 10+ yeas with Fedora. You mean get rid of it (from media and installations)?

Re: New memory tester application potentially to replace memtest86+: PCMemTest

On Mon, Feb 8, 2021 at 2:46 AM Vít Ondruch wrote: > > Being devils advocate, but should we have the memtest86 or similar by > default? I have certainly not used this feature in my 10+ yeas with Fedora. > You mean get rid of it (from media and installations)? Because we install it unconditionally

Re: Fedora 34 Change: Deprecate python-mock (Self-Contained change proposal)

Robbie Harwood writes: > Ben Cotton writes: > >> A simple `sed` can be applied in `%prep` as a temporary (or even >> permanent) downstream solution. >> >> In most cases, performing the following replacement should be enough: >> >> s/^(\s*)import mock/\1from unittest import mock/ >>

[EPEL-devel] Re: Proposal: EPEL9 timeline

On Mon, Feb 08, 2021 at 08:19:24AM -0500, Stephen John Smoogen wrote: > There is a little nuance here. In order to get the repository going, we had > to 'mass-branch' about 40 or so packages. fedpkg and some other items > require quite a few packages which all have to be done at once. Without >

Fedora-IoT-34-20210208.0 compose check report

Missing expected images: Iot dvd x86_64 Iot dvd aarch64 Failed openQA tests: 3/16 (x86_64), 5/15 (aarch64) Old failures (same test failed in Fedora-IoT-34-20210206.0): ID: 772291 Test: x86_64 IoT-dvd_ostree-iso base_services_start URL: https://openqa.fedoraproject.org/tests/772291 ID:

Re: Orphaned packages looking for new maintainers

On Monday, February 8, 2021 5:15:13 PM WET Adam Williamson wrote: > For the record it's also required by fedora-messaging, which is why > just about everything else in the world needed it The last release is from 2015, but there are different commits over the years with the last being 10 days

Re: Orphaned packages looking for new maintainers

Can uw-imap be replaced with something else, or should someone pick it up? --  Gwyn Ciesla she/her/hers   in your fear, seek only peace  in your fear, seek only love -d. bowie Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On

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

Missing expected images: Xfce raw-xz armhfp Minimal raw-xz armhfp Compose FAILS proposed Rawhide gating check! 8 of 43 required tests failed, 4 results missing openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 22/183 (x86_64), 18/124

[Bug 1926383] New: perl-BibTeX-Parser-1.03 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1926383 Bug ID: 1926383 Summary: perl-BibTeX-Parser-1.03 is available Product: Fedora Version: rawhide Status: NEW Component: perl-BibTeX-Parser Keywords: FutureFeature, Triaged

Re: Policy proposal (draft): Don't push knowingly broken or work-in-progress work to dist git

On 08/02/21 10:14 -0800, Kevin Fenzi wrote: Is there really a need for a rawhide-build branch? What if we just pushed a tag for the commit that built after the build finishes in koji? In an earlier reply I did say a tag would also work. To me, a branch ref seems more natural than a tag that

Re: Policy proposal (draft): Don't push knowingly broken or work-in-progress work to dist git

On 08/02/21 16:28 +0100, Kevin Kofler via devel wrote: Jonathan Wakely wrote: You've completely misunderstood the suggestion. No, sorry, I understood it completely. I think that you are the one who completely misunderstood my objection, and also missed the point of the original post. Let me

Re: Policy proposal (draft): Don't push knowingly broken or work-in-progress work to dist git

Is there really a need for a rawhide-build branch? What if we just pushed a tag for the commit that built after the build finishes in koji? We already have this information in pagure... for example, look at https://src.fedoraproject.org/rpms/ansible/c/e89035e0fbd49cd2569dc923325e373bee43fbad

Re: Orphaned packages looking for new maintainers

On 08. 02. 21 19:03, Gwyn Ciesla via devel wrote: I believe Tomasz was asking about the many packages that indirectly require uw-imap. Oh. Right, php indeed. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list --

Re: Orphaned packages looking for new maintainers

I believe Tomasz was asking about the many packages that indirectly require uw-imap. --  Gwyn Ciesla she/her/hers   in your fear, seek only peace  in your fear, seek only love -d. bowie Sent with ProtonMail Secure Email. ‐‐‐ Original Message

Re: Orphaned packages looking for new maintainers

On 08. 02. 21 17:08, Tomasz Torcz wrote: What's the magic deep dependency for uw-imap? Is it PHP? uw-imap is orphaned directly. No magic. It was orphaned due to https://bugzilla.redhat.com/show_bug.cgi?id=1907175 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

Re: [Qa-tools-sig] Orphaned packages looking for new maintainers

On Mon, Feb 8, 2021 at 4:57 PM Miro Hrončok wrote: > python-flask-openid orphan, pjp, sundaram 0 weeks > ago > Taken. We still need that for blockerbugs, sigh. It's dead upstream, replaced by oidc. I'll try to poke others depending on this (eg. copr) once we finish

Re: Request for exception to non-responsive maintainer policy for Sugar packages

On Sun, Feb 7, 2021 at 6:28 PM Alex Perez wrote: > > Hi folks, > > > > I've opened https://pagure.io/fesco/issue/2574 to facilitate assumption > ownership of the Sugar packages in Fedora, most of which are de-facto > abandoned by the previous maintainer, erikos, who has not authenticated with

Re: Orphaned packages looking for new maintainers

On Mon, 2021-02-08 at 17:00 +, José Abílio Matos wrote: > On Monday, February 8, 2021 3:54:29 PM WET Miro Hrončok wrote: > > python-blinker orphan, pjp, sundaram 0 weeks > > ago > > I took python-blinker that is required by nikola. In particular it means that >

Re: Orphaned packages looking for new maintainers

On Monday, February 8, 2021 3:54:29 PM WET Miro Hrončok wrote: > python-blinker orphan, pjp, sundaram 0 weeks > ago I took python-blinker that is required by nikola. In particular it means that the following users/groups are covered: abompard: python-blinker

Fedora 34 Mass Branching

Hello All, Fedora 34 will be branched from rawhide on Feb 09th 2021 as per the Fedora 34 schedule[1]. The process takes about a day and everything should be ready by Feb 10th 2021. You can still be able to build packages normally until then, but after the mass branching, rawhide and F34 will be

Fedora 34 Mass Branching

Hello All, Fedora 34 will be branched from rawhide on Feb 09th 2021 as per the Fedora 34 schedule[1]. The process takes about a day and everything should be ready by Feb 10th 2021. You can still be able to build packages normally until then, but after the mass branching, rawhide and F34 will be

Fedora rawhide compose report: 20210208.n.0 changes

OLD: Fedora-Rawhide-20210207.n.0 NEW: Fedora-Rawhide-20210208.n.0 = SUMMARY = Added images:1 Dropped images: 1 Added packages: 0 Dropped packages:0 Upgraded packages: 95 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:0 B Size

Re: Orphaned packages looking for new maintainers

What's the magic deep dependency for uw-imap? Is it PHP? -- Tomasz .. oo o. oo o. .o .o o. o. oo o. .. Torcz.. .o .o .o .o oo oo .o .. .. oo oo o.o.o. .o .. o. o. o. o. o. o. oo .. .. o. ___ devel mailing list --

Re: /usr/include/c++/11/type_traits:3164:1: error: template with C linkage

On 2/6/21 18:06, Florian Weimer wrote: * Kalev Lember: On 2/6/21 16:08, Antonio T. sagitter wrote: Hi all. I can't compile IceCat on Fedora 33+ since some days because of these errors: ... /usr/include/c++/11/type_traits:3164:1: error: template with C linkage .. Any idea why they occur?

Orphaned packages looking for new maintainers

The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life Note: If

Re: Continuously trim SWAP in Fedora guest over virtio-scsi controller

On Sat, Feb 06, 2021 at 04:11:46PM +0100, Pavel Raiskup wrote: > I'm trying to overcommit storage space on one our hypervisors (and reclaim > space if possible after memory peak times) and it seems like kernel in > Fedora 33 isn't doing automatic discard on swap partitions? The swap is > enabled

Orphaned packages looking for new maintainers

The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life Note: If

Re: Policy proposal (draft): Don't push knowingly broken or work-in-progress work to dist git

Jonathan Wakely wrote: > You've completely misunderstood the suggestion. No, sorry, I understood it completely. I think that you are the one who completely misunderstood my objection, and also missed the point of the original post. Let me explain: > I'm suggesting that everybody pushes to

Re: Update on Modular Obsoletes and EOL change

On Mon, Feb 08, 2021 at 04:09:19PM +0100, Martin Curlej wrote: > It would be great if we could start a discussion about how modular > obsoletes will be used in Fedora? Where will be they stored? Who will be > able to change them? Just a couple of questions to get the discussion > started. Any

Re: Update on Modular Obsoletes and EOL change

On 08. 02. 21 16:09, Martin Curlej wrote: It would be great if we could start a discussion about how modular obsoletes will be used in Fedora? Where will be they stored? Who will be able to change them? Just a couple of questions to get the discussion started. Any involvement of the Fedora

Update on Modular Obsoletes and EOL change

Hello All, This is an update about the Module obsoletes and EOL [1] change which we proposed for F34. We have a little bit of a good news/bad news situation here. The good news is that the groundwork for the Obsoletes and EOL has been done. DNF, libmodulemd and createrepo_c accept the format and

Re: Fedora 34 Mass Rebuild

On Mon, 2021-02-01 at 15:03 -0500, Mohan Boddu wrote: > Fedora 34 mass rebuild of rpms is done Hi, I just noticed that syncevolution built just fine on the January 30th, but it is failing to build right now, using the same sources as releng. I opened [1] for it. It kind of scares me, I

[389-devel] 389 DS nightly 2021-02-05 - 95% PASS

https://fedorapeople.org/groups/389ds/ci/nightly/2021/02/05/report-389-ds-base-2.0.2-20210205gitf38b124f0.fc33.x86_64.html ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to

[389-devel] 389 DS nightly 2021-02-03 - 95% PASS

https://fedorapeople.org/groups/389ds/ci/nightly/2021/02/03/report-389-ds-base-2.0.2-20210203gitf38b124f0.fc33.x86_64.html ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to

[389-devel] 389 DS nightly 2021-02-08 - 95% PASS

https://fedorapeople.org/groups/389ds/ci/nightly/2021/02/08/report-389-ds-base-2.0.2-20210208gitf38b124f0.fc33.x86_64.html ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to

[389-devel] 389 DS nightly 2021-02-07 - 95% PASS

https://fedorapeople.org/groups/389ds/ci/nightly/2021/02/07/report-389-ds-base-2.0.2-20210207gitf38b124f0.fc33.x86_64.html ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to

[389-devel] 389 DS nightly 2021-02-04 - 95% PASS

https://fedorapeople.org/groups/389ds/ci/nightly/2021/02/04/report-389-ds-base-2.0.2-20210204gitf38b124f0.fc33.x86_64.html ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to

Copr/mock centos-stream => centos-stream-8 rename?

The configuration for CentOS Stream 8 was renamed in mock-core-configs so it makes more sense now (currently the updated package is getting to updates-testing), and we'll have to adjust Fedora Copr to comply with that layout. The idea now is to try script the movement on backend (built results),

Re: Fedora 34 Change: fbrnch (Self-Contained Change proposal)

On Wed, Jan 20, 2021 at 11:31 PM Jens-Ulrik Petersen wrote: > On Tue, Jan 19, 2021 at 1:38 AM Zbigniew Jędrzejewski-Szmek < > zbys...@in.waw.pl> wrote: > >> > ** Submit and complete package review(s). >> > I still need one more package review completed before I can build fbrnch in Rawhide and

[EPEL-devel] Re: Proposal: EPEL9 timeline

On Sun, 7 Feb 2021 at 18:26, Kevin Fenzi wrote: > Overall this seems fine to me, a few nitpicks inline... > > On Fri, Feb 05, 2021 at 01:51:15PM -0800, Troy Dawson wrote: > > This is a proposal. It's mainly writing down what I think most of us > > agreed on at last weeks EPEL Steering Committee

License field change: wdiff (“GPLv3+” to “GPLv3+ and Latex2e”)

The License field for wdiff has been corrected from “GPLv3+” to “GPLv3+ and Latex2e”; the latter applies to the texinfo documentation. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to

[Bug 1926184] New: bugzilla-5.0.6-11.fc34 FTBFS: Can't exec "make": No such file or directory at docs/makedocs.pl line 56.

https://bugzilla.redhat.com/show_bug.cgi?id=1926184 Bug ID: 1926184 Summary: bugzilla-5.0.6-11.fc34 FTBFS: Can't exec "make": No such file or directory at docs/makedocs.pl line 56. Product: Fedora Version: rawhide

Re: Policy proposal (draft): Don't push knowingly broken or work-in-progress work to dist git

On 04/02/21 05:03 +0100, Kevin Kofler via devel wrote: Dominik 'Rathann' Mierzejewski wrote: On Wednesday, 03 February 2021 at 14:29, Kevin Kofler via devel wrote: But it means that provenpackagers who want to bump and rebuild have to actually manually look at another branch (rawhide-build).

Re: Policy proposal (draft): Don't push knowingly broken or work-in-progress work to dist git

On 03/02/21 14:29 +0100, Kevin Kofler via devel wrote: Jonathan Wakely wrote: Instead of force pushing or reverting anything in the rawhide branch, why not just have two branches? Maintainers commit to one branch, and if the build is successful that branch is automatically merged (as a

[Bug 1925899] perl-JavaScript-Minifier-XS-0.14 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1925899 Jitka Plesnikova changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version|

Re: New memory tester application potentially to replace memtest86+: PCMemTest

Being devils advocate, but should we have the memtest86 or similar by default? I have certainly not used this feature in my 10+ yeas with Fedora. Vít Dne 07. 02. 21 v 10:07 Neal Gompa napsal(a): Hey all, I discovered today that there's a new replacement for memtest86+ that appears to even

Fedora-Cloud-32-20210208.0 compose check report

No missing expected images. Soft failed openQA tests: 1/7 (x86_64), 1/7 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-32-20210207.0): ID: 771735 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL:

[Bug 1922738] perl-CSS-Minifier-XS-0.13 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1922738 Emmanuel Seyman changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version|

[Bug 1925797] perl-Mojolicious-8.73 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1925797 Emmanuel Seyman changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version|

[Bug 1922738] perl-CSS-Minifier-XS-0.13 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1922738 Bug 1922738 depends on bug 1922774, which changed state. Bug 1922774 Summary: Review Request: perl-Test-DiagINC - List modules and versions loaded if tests fail https://bugzilla.redhat.com/show_bug.cgi?id=1922774 What|Removed

[Bug 1925899] perl-JavaScript-Minifier-XS-0.14 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1925899 Jitka Plesnikova changed: What|Removed |Added Status|NEW |ASSIGNED

[Bug 1925837] perl-Log-Log4perl-1.54 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1925837 Jitka Plesnikova changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version|