As this is described at , I am concerned as to whether it's permissible under . At least from the toot, it sounds like the package is now essentially useless without an externally-provided component ("the Minetest game"), which seems on the face of it to violate "Software which downloads code bundles from the internet in order to be functional or useful is not acceptable for inclusion in Fedora (regardless of whether the downloaded code would be acceptable to be packaged in Fedora as a proper dependency)."

Willing to reverse my karma if my concern is unfounded, but please at least explain this.

One thing I don't understand - how did @crobinso 's original 8.2.0rc2 build work? I'm rather confused about that.

those things it's trying to use are defined (only) in include/hw/xen/interface/arch-arm.h, which is copied from Xen itself. that is (I guess) included when building on ARM, but not when building on x86. Trying to always include it in xen_arm.c (whatever platform we're building on) just causes failures because now lots of stuff has competing definitions. Not sure how to proceed there (aside from reverting the qemu 8.2.0 commit that caused the problem...)

qemu build is failing on something related to xen...

FAILED: libqemu-aarch64-softmmu.fa.p/hw_arm_xen_arm.c.o 
gcc -m64 -mcx16 -Ilibqemu-aarch64-softmmu.fa.p -I. -I.. -Itarget/arm -I../target/arm -Iqapi -Itrace -Iui -Iui/shader -I/usr/include/pixman-1 -I/usr/include/capstone -I/usr/include/spice-server -I/usr/include/spice-1 -I/usr/include/nss3 -I/usr/include/nspr4 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/cacard -I/usr/include/sysprof-6 -I/usr/include/PCSC -fdiagnostics-color=auto -Wall -Winvalid-pch -std=gnu11 -O2 -g -fstack-protector-strong -Wundef -Wwrite-strings -Wmissing-prototypes -Wstrict-prototypes -Wredundant-decls -Wold-style-declaration -Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined -Wimplicit-fallthrough=2 -Wmissing-format-attribute -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-psabi -Wshadow=local -isystem /builddir/build/BUILD/qemu-8.2.0-rc2/linux-headers -isystem linux-headers -iquote . -iquote /builddir/build/BUILD/qemu-8.2.0-rc2 -iquote /builddir/build/BUILD/qemu-8.2.0-rc2/include -iquote /builddir/build/BUILD/qemu-8.2.0-rc2/host/include/x86_64 -iquote /builddir/build/BUILD/qemu-8.2.0-rc2/host/include/generic -iquote /builddir/build/BUILD/qemu-8.2.0-rc2/tcg/i386 -Wno-unused-function -pthread -DSTAP_SDT_V2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -fno-strict-aliasing -fno-common -fwrapv -O2 -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Werror=implicit-function-declaration -Werror=implicit-int -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -O2 -fexceptions -g -grecord-gcc-switches -Wall -Wno-complain-wrong-lang -Werror=format-security -Werror=implicit-function-declaration -Werror=implicit-int -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -fPIE -isystem../linux-headers -isystemlinux-headers -DNEED_CPU_H '-DCONFIG_TARGET="aarch64-softmmu-config-target.h"' '-DCONFIG_DEVICES="aarch64-softmmu-config-devices.h"' -MD -MQ libqemu-aarch64-softmmu.fa.p/hw_arm_xen_arm.c.o -MF libqemu-aarch64-softmmu.fa.p/hw_arm_xen_arm.c.o.d -o libqemu-aarch64-softmmu.fa.p/hw_arm_xen_arm.c.o -c ../hw/arm/xen_arm.c
../hw/arm/xen_arm.c: In function ‘xen_create_virtio_mmio_devices’:
../hw/arm/xen_arm.c:74:5: error: ‘GUEST_VIRTIO_MMIO_SPI_LAST’ undeclared (first use in this function)
      |     ^~~~~~~~~~~~~~~~~~~~~~~~~~
../hw/arm/xen_arm.c:87:21: note: in expansion of macro ‘NR_VIRTIO_MMIO_DEVICES’
   87 |     for (i = 0; i < NR_VIRTIO_MMIO_DEVICES; i++) {
      |                     ^~~~~~~~~~~~~~~~~~~~~~
../hw/arm/xen_arm.c:74:5: note: each undeclared identifier is reported only once for each function it appears in
      |     ^~~~~~~~~~~~~~~~~~~~~~~~~~
../hw/arm/xen_arm.c:87:21: note: in expansion of macro ‘NR_VIRTIO_MMIO_DEVICES’
   87 |     for (i = 0; i < NR_VIRTIO_MMIO_DEVICES; i++) {
      |                     ^~~~~~~~~~~~~~~~~~~~~~
../hw/arm/xen_arm.c:74:34: error: ‘GUEST_VIRTIO_MMIO_SPI_FIRST’ undeclared (first use in this function)
      |                                  ^~~~~~~~~~~~~~~~~~~~~~~~~~~
../hw/arm/xen_arm.c:87:21: note: in expansion of macro ‘NR_VIRTIO_MMIO_DEVICES’
   87 |     for (i = 0; i < NR_VIRTIO_MMIO_DEVICES; i++) {
      |                     ^~~~~~~~~~~~~~~~~~~~~~
../hw/arm/xen_arm.c:88:23: error: ‘GUEST_VIRTIO_MMIO_BASE’ undeclared (first use in this function)
   88 |         hwaddr base = GUEST_VIRTIO_MMIO_BASE + i * VIRTIO_MMIO_DEV_SIZE;
      |                       ^~~~~~~~~~~~~~~~~~~~~~

ah, yeah, that's a common gotcha...there's other ways around it, but that one looks like it'll work fine. thanks for investigating and fixing.

Oh, the tests are now failing for the same reason Bodhi is complaining - some of the builds in the update are now old and should be rebuilt again, I guess. is the greenwave issue here. Kevin has fixed the build and edited the update, so we're now seeing the test results and the gating status has updated. though, er, it probably shouldn't be 'passed'...hmm. I think it got sent to 'passed' immediately due to the previous test passes from when the tests ran days ago, and hasn't yet flipped to failed because tests are failing now, probably because they've been restarted...

@kevin says he caused this: "I mistakenly made that build from a src.rpm... (which you can accidentally do if you are a koji admin)"

so he'll fix that bit, and I'll see if it makes sense to have greenwave be a bit more robust or at least communicate the error through to Bodhi so we don't have to go schlep through greenwave logs...

We're not seeing test results and the gating status isn't changing because greenwave is giving us a 502 response with the error "Unexpected error while fetching remote policies". I actually thought I'd made Bodhi display these errors :( Will have to see why that's not working, and why we're getting the error in the first place.

In the failed test I see a lot of errors like this:

# actual (3 lines):
#   Error: crun: chdir `/usr/share/toolbox/test/system`: No such file or directory: OCI runtime attempted to invoke a command that was not found
#   Error: directory /usr/share/toolbox/test/system not found in container fedora-toolbox-40
#   Using /home/testuser instead.

OK, I got a qemu rebuild through - . When that goes stable it should resolve the problem.

The fact that the qemu build failure is not caused by capstone is not a valid reason to waive the failure. The fact remains that the current qemu package installed just fine with the previous capstone build; pushing this capstone build stable suddenly renders the current qemu package uninstallable.

Please don't waive failed tests without a thorough investigation. The bug is genuine. This update is missing a rebuild of qemu. rwmjones has tried to rebuild qemu now, but the build failed: . So now qemu is uninstallable in Rawhide, which breaks compose of Workstation.

There are also many other deps, it seems:

[adamw@xps13a tmp]$ sudo dnf repoquery --whatrequires ""

This is missing a rebuild of dependency qt5-qtimageformats:

 Problem: package qt5-qtimageformats-5.15.11-1.fc40.x86_64 from @System requires, but none of the providers can be installed

should be OK now.

huhh. that's an odd little sequence of events above. i need to see if bodhi has a bug there somewhere...

...okay, I lied, I ran out of time. I'll do it tomorrow.