We're not currently building armhfp as UEFI images, I plan that as a feature for F-34 but there's some fixes needed first, so please just do this as aarch64 and I'll co-ordinate for the move.

Actually, no, scratch that, it's fine. LGTM over all.

Is the aarch64 disk image going to be release blocking?

@pwhalen Yes, it will be.

@pwhalen Yes, it will be.

OK, the change needs to be updated.

How so?

How so?

I don't think it's clear that this is intended to block the release.

@pwhalen Yes, it will be.

That's no my understanding and I don't see it stated in the change, was it discussed in the FESCo meeting? If so got a link to the meeting notes?

Did it need to be stated in the change? Myself and the KDE SIG assumed the blocking status will carry over from x86_64 to aarch64.

Did it need to be stated in the change? Myself and the KDE SIG assumed the blocking status will carry over from x86_64 to aarch64.

It would be good to get FESCo's explicit assent to this. Some deliverables are only blocking on a subset of available architectures or formats.

I'll add this to the docs I'm going to write/update RSN on spins/labs.

Did it need to be stated in the change? Myself and the KDE SIG assumed the blocking status will carry over from x86_64 to aarch64.

It didn't for workstation or any of the other artefacts for aarch64 and given that KDE on aarch64 has had little testing I suspect it would be useful to do it in two steps 1) get it supported as an image and stable 2) request it to be promoted to blocking.

@pbrobinson I've made all newly added ARM images allow to fail to build (even though that is not the intent of the KDE SIG).

LGTM