Taking this review.

> %global debug_package %{nil}
> %{?mingw_package_header}

Do we still want to do it this way? This would mean that the native subpackage doesn't get proper debuginfo, I think?

> Requires(posttrans):   %{_sbindir}/alternatives wine-core%{?_isa} >= 6.8

Can you break this up into one per line, please?

(In reply to Neal Gompa from comment #2)
> > %global debug_package %{nil}
> > %{?mingw_package_header}
> 
> Do we still want to do it this way? This would mean that the native
> subpackage doesn't get proper debuginfo, I think?

@manisandro Do you have any ideas here? Whenever I drop out %global debug_package %{nil} I get "error: Empty %files file /builddir/build/BUILD/dxvk-2.0/debugsourcefiles.list".

(Note that I am moving the .dll files in the spec around a bit and the package isn't mingw- prefixed, compared to other mingw packages).

I'll look into it. FWIW, %{?mingw_package_header} is empty nowadays.

You need

%{?mingw_debug_package}

and after %install

%mingw_debug_install_post

(In reply to Sandro Mani from comment #6)
> You need
> 
> %{?mingw_debug_package}
> 
> and after %install
> 
> %mingw_debug_install_post

Thanks!

It, however, ended the same way. Posting here the updated section of the spec:

%description wine-d3d9
%{summary}

%{?mingw_debug_package}

%prep
%autosetup -n dxvk-%{version} -p1

# Copy out system include directories for spirv, vulkan and DirectX
mkdir -p ./include/vulkan/include && cp -R /usr/include/vulkan ./include/vulkan/include
mkdir -p ./include/spirv/include && cp -R /usr/include/spirv ./include/spirv/include

%build
### Wine
%mingw_meson --buildtype=plain --wrap-mode=nodownload --auto-features=enabled --cross-file ../build-win%{target_x86_type}.txt --buildtype release
%mingw_ninja

%install
### Wine
%mingw_ninja_install
%mingw_debug_install_post


If I get %mingw_debug_install_post at the absolute end of the install section, the error is different...
Processing files: mingw64-dxvk-debuginfo-2.0-1.fc38.noarch
error: Could not open %files file /builddir/build/BUILD/dxvk-2.0/mingw64-debugfiles.list: No such file or directory

The problem is that /usr/lib/rpm/mingw-find-debuginfo.sh expects any windows binaries to exist below the respective mingw prefix (say /usr/x86_64-w64-mingw32). Here however, the binaries are installed to a native prefix, say

/usr/lib64/wine/x86_64-windows/dxvk-d3d11.dll

The problem with the binaries being placed outside a mingw prefix is that mingw-find-debuginfo.sh wouldn't be able to easily figure out whether they belong to mingw32, mingw64 or ucrt64 (at least, without inspecting the binaries themselves to figure out 32 vs 64 vs ucrt).

A hacky solution here would be to manually generate the mingw64-debugfiles.list file with

%{buildroot}/usr/lib/debug/usr/lib64/wine/x86_64-windows/dxvk-d3d9.dll.debug
%{buildroot}/usr/lib/debug/usr/lib64/wine/x86_64-windows/dxvk-d3d10core.dll.debug
%{buildroot}/usr/lib/debug/usr/lib64/wine/x86_64-windows/dxvk-d3d11.dll.debug
%{buildroot}/usr/lib/debug/usr/lib64/wine/x86_64-windows/dxvk-dxgi.dll.debug

since you can be sure that these dlls are mingw64 (resp mingw32-debugfiles.list in the 32bit case).

(In reply to Sandro Mani from comment #8)
> A hacky solution here would be to manually generate the
> mingw64-debugfiles.list file with
> 
> %{buildroot}/usr/lib/debug/usr/lib64/wine/x86_64-windows/dxvk-d3d9.dll.debug
> %{buildroot}/usr/lib/debug/usr/lib64/wine/x86_64-windows/dxvk-d3d10core.dll.
> debug
> %{buildroot}/usr/lib/debug/usr/lib64/wine/x86_64-windows/dxvk-d3d11.dll.debug
> %{buildroot}/usr/lib/debug/usr/lib64/wine/x86_64-windows/dxvk-dxgi.dll.debug


Thanks, this did the trick, -debuginfo processing went fine, however, I am now back to "Empty %files file /builddir/build/BUILD/dxvk-2.0/debugsourcefiles.list" with -debugsource :'(

Out of curiosity, how is this related to wine-dxvk[1]?

[1] https://src.fedoraproject.org/rpms/wine-dxvk

(In reply to Dominik 'Rathann' Mierzejewski from comment #10)
> Out of curiosity, how is this related to wine-dxvk[1]?
> 
> [1] https://src.fedoraproject.org/rpms/wine-dxvk

This is intended to replace that package and dxvk-native.

František, can you please refresh this package and update this to the latest version?

This is an automatic action taken by review-stats script.

The ticket submitter failed to clear the NEEDINFO flag in a month.
As per https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews
we consider this ticket as DEADREVIEW and proceed to close it.