Inside your summary you should point to the task with
resolves Txxxx

@Girtablulu I see your comments and this will be corrected soon but I can't use the source tar here because the building process involve git submodule to fetch a specific git commit of imGui

Also it was mentioned here: https://dev.getsol.us/T8733 we could use some config-enable but I don't know how to handle this.

ah okay then it's fine but you still need to mention the task in your summary so it will be automatically closed when your patch gets accepted

Additional question, doesn't need the 32bit library a mangohud.json as well?

€: I looked at Ikeys comment in the Task and he asks for pattern the json file into a separate package and work with it over this, so it can be used for the 64bit and 32bit package

I started to check for mangohud32/64.json files and I have a package.yml version that does it. However, it relies on some bash posted below.
I believe this is far from what Ikey proposed with a different package for the json file. But I really have no clue how to handle this.
Side note, I use mangohud everyday with an incorrect json file and it works well. I wonder where it's used.

MANGOJSONDIR=$installdir/usr/share/vulkan/implicit_layer.d
sed -i -e 's|libMangoHud.so|%libdir%/&|g' $MANGOJSONDIR/mangohud.json
if [ $EMUL32BUILD ]; then
   mv $MANGOJSONDIR/mangohud.json $MANGOJSONDIR/mangohud32.json 
else
   mv $MANGOJSONDIR/mangohud.json $MANGOJSONDIR/mangohud64.json 
fi

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

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

Ok I checked icd.d related vulkan directory and you're correct for i686 and x86_64.
I 'll also checkout tomorrow if I can pack the i686 jsonfile with the 32 bit subpackage.

So um... mangohud.json is installed everytime ninja_install passes. I didn't find a way via package tools to force the file to be associated with the 32bits libs. :/

Many updates since first review. I've playing with mangohud package on my PC for some time now and tested it on many games. Still not convinced about the mangohud.i686 in /usr/bin

@DataDrake Can do. Let's just clarify some things before we start another revision.
The only diff between the 64 and 64 bit exec is this

< LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:/usr/lib32/mangohud"
---
> LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:/usr/lib64/mangohud"

LD_PRELOAD is in another variable and the same between 64/32 bits. I tested some games with opengl and vulkan and long story short some of them (ex: door kickers action squad) require the 32bits version. I don't know why however because some other (ex Hellblade) work ok with only the 64 bits exec installed. The 2 games listed in example are launched with exactly the same command and use the same proton/dxvk version.

Second point, a few days ago a new version was released, it changes nothing about the exec part but add nvctrl as optional dependency. I'm not familiar with nvidia in solus but it looks like this will bring a lot of heavy dependencies just for old nvidia card support. I plan on disable it, if that's ok.

Now everything is one package. I used to rename mangohud.x86 to mangohud.i686 to match solus scheme, but in order to make sure there is a full 32 bits compatibily I let the actual naming. There is a hardcoded reference to mangohud.x86 in mangohud (x86_64) which doesn't change a thing when in 64 bits but will go bork if full 32 which is not possible anymore since everything is in 1 package.
?

Patch looks good to me. Just to confirm before landing, is this needing libglvnd-devel or does it need mesalib-devel? @DataDrake performed a mesalib upgrade (including all the stuff around libglvnd-devel) and the gl pkgconfig was moved out of mesalib. If it's mesalib specific headers then the gbm pkgconfig should be used.

I'll check that ASAP.
Anyway you can merge this into unstable and if effectively I need to remove libglvnd I'll make sure this happen when I'll update mangohud. It should happen soon enough.

I built using this package.yml and verified it works with Steam games, so this is ready to be accepted into the repos