Looks like we know of at least four issues for this compose.

1. Live image composes hung due to rng-tools being rebuilt as part of the mass rebuild with the bad attempted fix for #1490632. I have rebuilt rng-tools now with that bad fix dropped, so that shouldn't be a problem any more.

2. KDE x86_64 live has a package dependency issue: qt5-qtwebengine needs rebuilding for the libevent soname bump. Unfortunately it does not currently build due to some kind of problem in the chromium build process that also affects the chromium package itself. See #1545936 on that one.

3. A dependency issue in an ARM image build :

   DEBUG util.py:439: Unable to create appliance : Failed to build transaction :
   DEBUG util.py:439: Problem: package anaconda-core-28.20-1.fc28.armv7hl requires /usr/bin/gjs-console, but none of the providers can be installed
   DEBUG util.py:439: - package anaconda-tui-28.20-1.fc28.armv7hl requires anaconda-core = 28.20-1.fc28, but none of the providers can be installed
   DEBUG util.py:439: - package gjs-1.51.90-2.fc28.armv7hl requires libgtk-3.so.0, but none of the providers can be installed
   DEBUG util.py:439: - package initial-setup-0.3.53-2.fc28.armv7hl requires anaconda-tui >= 25.20.3, but none of the providers can be installed
   DEBUG util.py:439: - package gtk3-3.22.26-4.fc28.armv7hl requires libxkbcommon.so.0, but none of the providers can be installed
   DEBUG util.py:439: - conflicting requests
   DEBUG util.py:439: - nothing provides xkeyboard-config needed by libxkbcommon-0.8.0-2.fc28.armv7hl

4. A dependency issue in a Docker container image build : nothing provides libusb-1.0.so.0()(64bit) needed by gnupg2-2.2.4-1.fc28.x86_64

I believe I've fixed 3) now. The problem was ultimately that anaconda-core had suddenly grown a dependency on /usr/bin/gjs-console, which turned out to be an unexpected consequence of mangling shebangs. I've suppressed the requirement in anaconda for now.

Looking into 4); gnupg2 hadn't been rebuilt for the mass rebuild, so I've done that, but I don't think it just needed a rebuild, as the libusb dependency didn't change with the rebuild. I think it's more about libusb not being available in the container build environment.

Looks like 4) isn't actually fatal, and has been happening for ages. It happened the same way in the Docker image builds for 20180204.n.0 (the last successful compose) too:

https://koji.fedoraproject.org/koji/taskinfo?taskID=24709998
https://koji.fedoraproject.org/koji/taskinfo?taskID=24710007

(I do not know why we have both 'Docker-Base' and 'Container-Minimal-Base'). Looking at nightlies, we haven't had a successful Docker_Base or Container_Minimal_Base since 20171108.

(I do not know why we have both 'Docker-Base' and 'Container-Minimal-Base')

One is the docker base image and the other is a hacked up minimal version that tries to rip out as much as possible. It doesn't have python, uses microdnf. etc..

Ah, right.

So, I think 4) was actually caused by a change in dnf/anaconda back in November, but I'll file that separately as it's not actually causing compose failure.