Has anyone tried libdxfrw 1.1.0-rc1?

Ok, well that's better at least. Do you have bandwidth? Or I can do it later as I'm still technically "at work".

Well... That's not good. That was a lot of work. Any options for manual intervention from infra?

Can I rebuild ffmpeg before this goes stable? I forget how that works. Or do I need a buildroot override?

Sorry about that, I keep forgetting there are other consumers for codec2 these days beyond Ham Radio (FreeDV).

This update has been unpushed.

You don't push to testing, that's automatic, as is stable most of the time. Guessing it's part of the F33 release freeze.

I usually check for dependent packages using repoquery, but somehow missed this one. The maintainer has submitted an update.

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

I have contacted the maintainer for CubicSDR about rebuilding the f31 package.

A little late for negative karma to be meaningful. Unfortuantley wsjtx needs the 4.0 pre-release, so the question is who wins? Hopefully a simple rebuild fixes it.

Fixed the actual problem, but running the command rpkg by itself still produces confusing output:

$ rpkg 'Namespace' object has no attribute 'command'

With the .2 package? I tested installing all of the packages and it worked fine in mock.

While not ideal since it can pick up other packages, I used --enablerepo=updates-testing in a mock build to get the update and it worked fine.

Yes, that's a common use for Qt5 applications and is support on X11 but not Wayland. Looks like it's not a show stopper though. Nonetheless I'll report upstream. Thanks.

Strange situation indeed. If we go the module route then it should be in the "cmake" dist-git not "cmake3", but do we need an epel8 branch? If so how do we ask? I assume if we requested one it would get denied as it exists in RHEL/CentOS...

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

Ok, this is where CentOS is just repackaging RHEL, so really this is a RHEL bug.

Reported:

https://bugs.centos.org/view.php?id=17318

Worse, the CentOS package provides "3" versions of all the binaries:

 Error: Transaction check error:
 file /usr/bin/ccmake3 from install of cmake-3.11.4-3.el8.x86_64 conflicts with file from package cmake3-3.17.2- 1.el8.x86_64
 file /usr/bin/cmake3 from install of cmake-3.11.4-3.el8.x86_64 conflicts with file from package cmake3-3.17.2-1.el8.x86_64
 file /usr/bin/cpack3 from install of cmake-3.11.4-3.el8.x86_64 conflicts with file from package cmake3-3.17.2-1.el8.x86_64
 file /usr/bin/ctest3 from install of cmake-3.11.4-3.el8.x86_64 conflicts with file from package cmake3-3.17.2-1.el8.x86_64

This is going to conflict with the CentOS cmake package as it currently "provides" cmake3... And mock is being stupid. Even if I manually install this package in the buildroot, mock still tries to install "cmake"

# dnf repoquery --provides cmake
Last metadata expiration check: 0:13:16 ago on Sun 03 May 2020 07:25:33 AM CDT.
bundled(kwsys)
bundled(md5-deutsch)
cmake = 3.11.4-3.el8
cmake(x86-64) = 3.11.4-3.el8
cmake3 = 3.11.4-3.el8

I assume this is a leftover from EL 7 where cmake was on version 2.