Random pointless housekeeping note: Does it really make sense to package both /usr/share/doc/mmv/README and /usr/share/doc/mmv/README.md, when they're byte-for-byte the exact same file?

@tyrbiter: Presumably that's true of the 8.3.0 package as well, though, right? I'm fine with upgrading F39 to 8.4.0, but it should at least be pushed as an enhancement release, rather than a bugfix that doesn't actually fix any bugs.

This update has been unpushed.

Withdrawing as this doesn't actually solve the problem, see bug 2249662 for more information.

One good thing: The blender-rpm-macros from this update can be installed without upgrading blender, to fix the dnf issue:

$ sudo dnf --enablerepo=updates-testing upgrade blender-rpm-macros
warning: /usr/lib/rpm/macros.d/macros.blender: line 200: Macro %y needs whitespace before body
[...109 lines snipped...]
Last metadata expiration check: 0:00:41 ago on Wed 10 May 2023 05:33:44 PM EDT.
Dependencies resolved.
================================================================================
 Package                Arch       Version            Repository           Size
================================================================================
Upgrading:
 blender-rpm-macros     noarch     1:3.5.1-2.fc38     updates-testing      16 k

Transaction Summary
================================================================================
Upgrade  1 Package

Total download size: 16 k
Is this ok [y/N]: y
Downloading Packages:
blender-rpm-macros-3.5.1-2.fc38.noarch.rpm      170 kB/s |  16 kB     00:00    
--------------------------------------------------------------------------------
Total                                            68 kB/s |  16 kB     00:00     
warning: /usr/lib/rpm/macros.d/macros.blender: line 200: Macro %y needs whitespace before body
[...54 lines snipped...]
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Preparing        :                                                        1/1 
  Upgrading        : blender-rpm-macros-1:3.5.1-2.fc38.noarch               1/2 
  Cleanup          : blender-rpm-macros-1:3.5.0-3.fc38.noarch               2/2 
  Running scriptlet: blender-rpm-macros-1:3.5.0-3.fc38.noarch               2/2 
  Verifying        : blender-rpm-macros-1:3.5.1-2.fc38.noarch               1/2 
  Verifying        : blender-rpm-macros-1:3.5.0-3.fc38.noarch               2/2 

Upgraded:
  blender-rpm-macros-1:3.5.1-2.fc38.noarch                                      

Complete!

^ Reported as https://bugzilla.redhat.com/show_bug.cgi?id=2183423

lxqt-config requires a rebuild, and has been blocking this update of libkscreen-qt5 since it hit stable.

 Problem: package lxqt-config-1.2.0-1.fc37.x86_64 requires libKF5Screen.so.7()(64bit), but none of the providers can be installed
  - cannot install both libkscreen-qt5-5.27.3-1.fc37.x86_64 and libkscreen-qt5-5.26.5-1.fc37.x86_64
  - cannot install both libkscreen-qt5-5.27.3-1.fc37.x86_64 and libkscreen-qt5-5.26.2-1.fc37.x86_64
  - cannot install the best update candidate for package lxqt-config-1.2.0-1.fc37.x86_64
  - cannot install the best update candidate for package libkscreen-qt5-5.26.5-1.fc37.x86_64

(The lxqt-config issue is already reported as bug 2175536.)

This seems fine, but lxqt-config didn't get rebuilt, it seems, and it depends on libkscreen-qt5. The new build's soversion bump from libKF5Screen.so.7 to libKF5Screen.so.8 causes a conflict with the current lxqt-config-1.2.0-1.

RapidJSON support can be confirmed, BTW, by using the built-in jsonencode() or jsondecode() functions from Octave. For example:

>> jsondecode('{"a": 1}')
ans =

  scalar structure containing the fields:

    a = 1

>>

Looks good, I can install python-CommonMark-utils without it conflicting with cmark, and I can install python3-CommonMark without needing python-CommonMark-utils at all. Thanks!

After spinning up a VM and installing along with my GEdit plugin package, everything is working perfectly. Thanks again for the quick response!

Confirmed, kernelshark-1:1.2-2.fc33.x86_64 successfully installs as an upgrade to kernelshark-2.8.3-4.fc33.x86_64

I've submitted rhbz 1909725 to track the kernelshark version-numbering issue.

I can confirm that manually forcing a dnf downgrade kernelshark-1.2-1.fc33 unblocks the trace-cmd update, allowing a dnf upgrade trace-cmd to successfully install 2.9.1-4.fc33. But that's going to continue to cause problems due to the existence of kernelshark-2.8.3-4.fc33 in the fedora repo for F33.

The only workable solutions are to either raise the kernelshark version numbering above 2.8.3, or add an 'Epoch: 1' to the kernelshark.spec and push out a new kernelshark-1:1.2-2.fc33 package as an upgrade from kernelshark-2.8.3-4.fc33.

@zsun: kernelshark is still conflicting with trace-cmd two months later, so I'm afraid something seems to have broken down with the updates chaining here.

The current F33 package is kernelshark-2.8.3-4.fc33 which requires 'trace-cmd(x86-64) = 2.8.3-4.fc33' and blocks the installation of trace-cmd-2.9.1-2.fc33.

If the kernelshark version numbering is going to be reset down to a lower value (I see kernelshark-1.2-1.fc33 attached to this update), then you'll need to set an Epoch number to get it to install in place of kernelshark-2.8.3-4.fc33, and to avoid it continually trying to upgrade itself to 2.8.3 after install.