[Bug 1985169] perl-Encode-3.11 is available

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

[Bug 1985169] New: perl-Encode-3.11 is available

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

[Bug 1981927] APC::ThreadMutex is not available on x86_64 mod_perl

https://bugzilla.redhat.com/show_bug.cgi?id=1981927 Fedora Update System changed: What|Removed |Added Fixed In Version|mod_perl-2.0.11-9.fc35 |mod_perl-2.0.11-9.fc35

[Bug 1981927] APC::ThreadMutex is not available on x86_64 mod_perl

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

Re: Fedora 35 Mass Rebuild

On 7/22/21 12:13 PM, Tomas Hrcka wrote: > They haven't finished building, so if we cancel both of these, then it > would work: > >> https://koji.fedoraproject.org/koji/taskinfo?taskID=72392389 >> https://koji.fedoraproject.org/koji/taskinfo?taskID=72392356 >> > > > I have canceled both tasks.

[EPEL-devel] Re: python-unversioned-command for epel8 (provides /usr/bin/python)

On 22. 07. 21 23:58, Troy Dawson wrote: On Thu, Jul 22, 2021 at 2:45 PM Miro Hrončok > wrote: On 22. 07. 21 22:33, Troy Dawson wrote: > > > On Thu, Jul 22, 2021 at 12:50 PM Miro Hrončok mailto:mhron...@redhat.com> >

[EPEL-devel] Updated KDE Plasma Desktop ready for testing on CentOS Stream 8

An updated qt5 in CentOS Stream 8 allowed us to update KDE Plasma Desktop. I believe everything is in place and ready for use and/or testing. This is for CentOS Stream 8 only, at this time. ===How to Install [1] = Install epel-release dnf install

[EPEL-devel] Re: python-unversioned-command for epel8 (provides /usr/bin/python)

On Thu, Jul 22, 2021 at 2:45 PM Miro Hrončok wrote: > On 22. 07. 21 22:33, Troy Dawson wrote: > > > > > > On Thu, Jul 22, 2021 at 12:50 PM Miro Hrončok > > wrote: > > > > On 22. 07. 21 21:47, Miro Hrončok wrote: > > > On 22. 07. 21 21:25, Troy Dawson wrote:

[EPEL-devel] Re: python-unversioned-command for epel8 (provides /usr/bin/python)

On 22. 07. 21 22:33, Troy Dawson wrote: On Thu, Jul 22, 2021 at 12:50 PM Miro Hrončok > wrote: On 22. 07. 21 21:47, Miro Hrončok wrote: > On 22. 07. 21 21:25, Troy Dawson wrote: >> I've been bitten by this yet again.  A package needing

[EPEL-devel] Re: python-unversioned-command for epel8 (provides /usr/bin/python)

On Thu, Jul 22, 2021 at 12:50 PM Miro Hrončok wrote: > On 22. 07. 21 21:47, Miro Hrončok wrote: > > On 22. 07. 21 21:25, Troy Dawson wrote: > >> I've been bitten by this yet again. A package needing /usr/bin/python > and > >> not python2 or python3. And it's way down in the code so it's hard

[EPEL-devel] Re: python-unversioned-command for epel8 (provides /usr/bin/python)

On 22. 07. 21 21:47, Miro Hrončok wrote: On 22. 07. 21 21:25, Troy Dawson wrote: I've been bitten by this yet again.  A package needing /usr/bin/python and not python2 or python3.  And it's way down in the code so it's hard to patch.  But, it works fine on Fedora. Is anyone in the middle of

[EPEL-devel] Re: python-unversioned-command for epel8 (provides /usr/bin/python)

On 22. 07. 21 21:25, Troy Dawson wrote: I've been bitten by this yet again.  A package needing /usr/bin/python and not python2 or python3.  And it's way down in the code so it's hard to patch.  But, it works fine on Fedora. Is anyone in the middle of porting python-unversioned-command over to

[EPEL-devel] python-unversioned-command for epel8 (provides /usr/bin/python)

I've been bitten by this yet again. A package needing /usr/bin/python and not python2 or python3. And it's way down in the code so it's hard to patch. But, it works fine on Fedora. Is anyone in the middle of porting python-unversioned-command over to epel8? If not, does anyone object to me

[EPEL-devel] Re: Proposed change to bodhi days to stable for epel

On Thu, 22 Jul 2021 at 14:42, Troy Dawson wrote: > > Currently the default days to stable for EPEL is 14 days. > I believe when it was first put in it was set to that time because we wanted > things more stable and better tested. But experience has found that if a > package is going to get

[EPEL-devel] Proposed change to bodhi days to stable for epel

Currently the default days to stable for EPEL is 14 days. I believe when it was first put in it was set to that time because we wanted things more stable and better tested. But experience has found that if a package is going to get tested, it usually is in the first few days of when it was built.

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

No missing expected images. Compose FAILS proposed Rawhide gating check! 1 of 43 required tests failed openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 5/199 (x86_64), 11/138 (aarch64) New failures (same test not failed in

Re: Fedora 35 Mass Rebuild

They haven't finished building, so if we cancel both of these, then it would work: > https://koji.fedoraproject.org/koji/taskinfo?taskID=72392389 > https://koji.fedoraproject.org/koji/taskinfo?taskID=72392356 > I have canceled both tasks. -- Tomas Hrcka role: CPE Team - Senior Software

Re: Fedora 35 Mass Rebuild

On 7/20/21 12:02 PM, Tomas Hrcka wrote: > Per the Fedora 35 schedule[1] we will start a mass rebuild for Fedora 35 > on Jul 21st, 2021. We will run a mass rebuild for Fedora 35 for the > changes listed in: > > https://pagure.io/releng/issues?status=Open=mass+rebuild F35 rebase to libffi 3.4

Fedora-IoT-35-20210722.0 compose check report

No missing expected images. Failed openQA tests: 1/15 (aarch64) Old failures (same test failed in Fedora-IoT-35-20210721.0): ID: 933618 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi URL: https://openqa.fedoraproject.org/tests/933618 Soft failed openQA tests: 3/16 (x86_64), 1/15

Fedora rawhide compose report: 20210722.n.0 changes

OLD: Fedora-Rawhide-20210721.n.0 NEW: Fedora-Rawhide-20210722.n.0 = SUMMARY = Added images:1 Dropped images: 1 Added packages: 2 Dropped packages:4 Upgraded packages: 115 Downgraded packages: 0 Size of added packages: 230.44 KiB Size of dropped packages

Re: An unsuccessful case study: Using pyproject-rpm-macros with PyQt-builder and sip 5

If by “are using PEP-517 build systems” you just mean those that use pyproject-rpm-macros in their spec files, I can also offer python-asyncpg and python-pyrsistent as examples. If you mean that upstream does not use setuptools in setup.py, but instead uses flit or poetry via pyproject.toml,

Re: Why so long for EPEL-8?

On Thu, Jul 22, 2021 at 7:21 AM Neal Gompa wrote: > > On Thu, Jul 22, 2021 at 1:56 AM Nico Kadel-Garcia wrote: > > > > On Mon, Jul 19, 2021 at 7:04 AM Fabio Valentini > > wrote: > > > > > > On Mon, Jul 19, 2021 at 12:06 PM Jiri Vanek wrote: > > > > > > > > On 7/17/21 11:15 PM, Ron Olson

Re: Permanent Updates Policy exception for PrusaSlicer, Cura, Black, tox, HTTPie and ownCloud Desktop Client

On Sat, Jul 17, 2021 at 7:00 AM Dan Čermák wrote: > Otto Urpelainen writes: > > I am however unsure what the exact rules are, because I also pushed an > upgrade of Emacs from 26 to 27 to Fedora 33 and received a few > complaints there (to my surprise). > I guess I am too. I haven't looked at

Re: Why so long for EPEL-8?

On Thu, Jul 22, 2021 at 1:56 AM Nico Kadel-Garcia wrote: > > On Mon, Jul 19, 2021 at 7:04 AM Fabio Valentini wrote: > > > > On Mon, Jul 19, 2021 at 12:06 PM Jiri Vanek wrote: > > > > > > On 7/17/21 11:15 PM, Ron Olson wrote: > > > > Hey all- > > > > > > > > I’m curious as to why submitting a

Re: Java packaging issue on EPEL7

On Thu, Jul 22, 2021 at 6:28 AM Vitaly Zaitsev via devel wrote: > > On 22/07/2021 00:02, Nico Kadel-Garcia wrote: > > Even if COPR guidelines allow it, Vitaly, it's a bad idea. > > Yes, I know. Even Flathub uses pre-built binaries[1]. Aaaggh. While I sympathize with your difficulty as someone

Re: Java packaging issue on EPEL7

On 22/07/2021 00:02, Nico Kadel-Garcia wrote: Even if COPR guidelines allow it, Vitaly, it's a bad idea. Yes, I know. Even Flathub uses pre-built binaries[1]. I'm startled that the jar files can compile in COPR if they don't compile in the normal Fedora environment. I suspect they can't, the

[Bug 1941704] perl-Net-Server-2.010 is available

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

Fedora-Cloud-34-20210722.0 compose check report

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-20210721.0): ID: 933249 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL:

Re: Java packaging issue on EPEL7

On 22/07/2021 05:18, Mikolaj Izdebski wrote: You can disable osgi requires generator or filter osgi requires (with eg. __requires_exclude or __requires_exclude_from macros). Only EPEL7 has an osgi requirement. EPEL8 and Fedora - don't. Already applied filters: %global __provides_exclude_from

Re: problem to compile fedora kernel: BTF/pahole

* Marius Schwarz: > while trying to recompiling  fedora 5.12.17 kernel, I got a final error: > > scripts/link-vmlinux.sh: Line 214: 273523 Killed > LLVM_OBJCOPY="${OBJCOPY}" ${PAHOLE} -J ${1} Check the journal/dmesg. Maybe it's just an out-of-memory error? Thanks, Florian

[Bug 1984246] perl-App-cpm-0.997006 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1984246 Jitka Plesnikova changed: What|Removed |Added Depends On||1984793 Referenced Bugs:

Re: Permanent Updates Policy exception for PrusaSlicer, Cura, Black, tox, HTTPie and ownCloud Desktop Client

On 12. 07. 21 13:30, Miro Hrončok wrote: Hello, I happen to maintain some applications in Fedora where I am strongly confident our users would prefer "latest and greatest" over 100 % "stability" of the user interface and/or results. For some of them, I've been more or less silently breaking

Fedora-Cloud-33-20210722.0 compose check report

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-33-20210721.0): ID: 933210 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL:

[Bug 1984744] perl-DBD-SQLite-1.68 is available

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

[Bug 1984744] perl-DBD-SQLite-1.68 is available

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

problem to compile fedora kernel: BTF/pahole

Hi, while trying to recompiling  fedora 5.12.17 kernel, I got a final error: scripts/link-vmlinux.sh: Line 214: 273523 Killed LLVM_OBJCOPY="${OBJCOPY}" ${PAHOLE} -J ${1} "dwarves" is installed, so this should not happen. The config file is taken from /boot/ and adjusted via "make

[Bug 1984246] perl-App-cpm-0.997006 is available

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

[Bug 1984744] New: perl-DBD-SQLite-1.68 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1984744 Bug ID: 1984744 Summary: perl-DBD-SQLite-1.68 is available Product: Fedora Version: rawhide Status: NEW Component: perl-DBD-SQLite Keywords: FutureFeature, Triaged