I wrote a large post of a reply but I've deleted it. Instead I'm just going to say this.

Chiefly package repository priorities need to work correctly in mixed and layered repositories through a well designed system, something that eopkg currently lacks.
Given the amount of engineering effort required to make this nice in solbuild, and the obvious limitations in eopkg it would work around, the ROI is practically nil compared
to integrating directly with the Makefile system (which could do with overhauling)

OK, but its not working as intended at all. Mentioning eopkg in a package patch does and has happened (I literally am the voice of experience here.)
The rule is clearly too crude. As for solbuild having the functionality I don't directly object, but the entire process needs review tbqh.

FWIW if you want to hold on this, I might be able to continue tomorrow. UK/EU is insane right now so I can't make any promises.

Read the thread @kyrios123, I guided the user to create a task. Abandoning the revision is super hostile, given the context, and wastes everyones time.

FWIW I was working on some kernel updates locally but I gotta go out for a fair few hours.

I saw some firmware updates in upstream git, trialing them locally..

Exactly :) should be some links in the sidebar on how to do this. Just think of it as boring accounting xD

Usually as it just makes life easier for the team, basically its a "why do we need this" justification. i.e. what value does it add, can it be distributed, that kinda thing. Then we typically
link a diff to the issue to make it easier to see what problem the patch solves. Welcome though, nice first contribution. I know the process can sometimes be awkward but its just a case
of transparency and documentation :)

From my perspective it looks ok now, so I'll hand off to the team.

Apart from the incorrect version the patch looks OK - just wondering though has there been a packaging request for this

I'll hold off looking into this too much until new kernel and GNOME stack land as it might just disappear.

Remove debug cat

Note the large dependency change is a result of our LD_AS_NEEDED stuff existing stack wide now.

From my own perspective docker is an administrative tool, thus our documentation should explain the user needs to add themselves to the docker group
to bypass sudo requirement. This is typical of most distributions and I wouldn't want to change that.

As for the presence of the Intel DDX, it is needed for older chipsets as the KMS driver will cause issues there (real hangs). Fedora carried patches to explicitly use KMS on newer generations and fallback to the Intel DDX in all
other cases. May be worth looking into.

OK just to add fuel to the fire I've been getting the same issue, I have to switch to tty1 and full reset. This is why I don't think its a KMS issue otherwise my tty would be locked out and trying to perform
a reset would hit a kernel panic. I get this several times a day when working at the library so I have to save often or risk losing all my work. It seems, in my case at least, explicitly tied to the alt+tab window.
Personally I think some of the UB changes in git are somewhat untested and are causing runaway issues, and would need review (mutter/daemon/etc) as they're causing full X server locks.

Additionally I'd glob the 32-bit ICD file into the 32bit subpackage..

I may be wrong but I believe the suffix convention for Vulkan ICDs is .i686 and .x86_64

In that case, use a git source in the ypkg so that submodules are fetched. Make sure to use a specific tag or commit - not master.

A nice touch for packaging it would be a link to push it to the explicitly enabled layers, as a subpackage of mangohud. This would then enable mangohud for all vulkan
applications OOTB. Something like mangohud, mangohud-32bit, mangohud-config-enable

FWIW - working upstream to add build support in git https://github.com/flightlessmango/MangoHud/pull/41