Bug 29387

Created attachment 12904 [details]
My version of the spec

Funny i recently make this for blogdrake repositories based on a spec from copr
No add wrappers and i have to "downgarde" the hardcoded flags as long as in my laptop and in copr builds it detects sse3 , also have to tweak the build and ld flags due some issues when builing

Created attachment 12905 [details]
Patch to disable sse3

This is the patch i mention before

Created attachment 12906 [details]
katnatek modified spec file

(In reply to katnatek from comment #1)
 I was kinda surprised to have one's cake and eat it too on both 8/cauldron :).
 To the point, my systems are up to date(release/updates/updates_testing repos enabled all) for both distros, so nothing special about the packages used, they are all defaults(at least for Mageia8, for Cauldron I got glslang-11.5.0 which I don't think it matters here) and I use wine 6.15 on both.
 On the side note, while I appreciate Fedora's easyer and safer way to install this package I like more to have the option to fiddle with these fixes for wine, as Suse does it. 

> No add wrappers and i have to "downgarde" the hardcoded flags as long as in
> my laptop and in copr builds it detects sse3 , also have to tweak the build
> and ld flags due some issues when builing

I took your spec file and disabled all the flags and the patch, see attached file, and it builds just fine. It looks like your build failures may be prone to your hardware or some other obscure setting/setup that may be hard to track.

copr?

These are the flags used by mingw32-g++ on my system during build if it helps:
-fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wnon-virtual-dtor -std=c++17 -O3 -DNOMINMAX -D_WIN32_WINNT=0xa00 -msse3

"A Vulkan-based translation layer for Direct3D 9/10/11 which allows running 3D applications on Linux using Wine."
Thank you for the request, and work you have done for it. (Also katnatek).

Assigning this package request to all packagers collectively. On a voluntary basis, one of them might, if there are no license or other legal issues, want to integrate it to the distribution and maintain it for bug and security fixes.

You Aurelian R might also want to join the packager team to maintain this piece of software: see https://wiki.mageia.org/en/Becoming_a_Mageia_Packager
Given the expertise you show, please consider this seriously.

Summary: wine-dxvk => wine-dxvk : allows running 3D applications on Linux using Wine [NEW PKG REQUEST] specs given
Priority: Low => Normal
Assignee: bugsquad => pkg-bugs

(In reply to Aurelian R from comment #3)
> (In reply to katnatek from comment #1)

> I took your spec file and disabled all the flags and the patch, see attached
> file, and it builds just fine. It looks like your build failures may be
> prone to your hardware or some other obscure setting/setup that may be hard
> to track.
> 
> copr?
> 
Not sure if you ask me if use copr or what is, the answer to first is yes for 64bit and for the second https://copr.fedorainfracloud.org/coprs/

> These are the flags used by mingw32-g++ on my system during build if it
> helps:
> -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch
> -Wnon-virtual-dtor -std=c++17 -O3 -DNOMINMAX -D_WIN32_WINNT=0xa00 -msse3

I will take note for next time/release, but -msse3 limit the cpus in where this can be used, that is why i use just -msse2 that is a few wider i think

(In reply to Aurelian R from comment #3)

> I took your spec file and disabled all the flags and the patch, see attached
> file, and it builds just fine. It looks like your build failures may be
> prone to your hardware or some other obscure setting/setup that may be hard
> to track.
> 
> copr?
> 
I think that is taking as a standard build instead of mingw, all the flags i got are the common to other standard builds, if i remember well i build in copr until i get it works on my system so may bet it works without hacks on copr; maybe its due i don't use iurt, mock or chroots and i install build deps and build with rpmbuild directly on my system so i need a way to indicate to use (force?) mingw flags

(In reply to katnatek from comment #6)

 Your flags are more conservative and ensure a larger hardware pool for which the spec file works, that's clear. You should try copr( now I know what it means, thanks, btw ) without the hacks and test the pkg on your hardware to see how it behaves. 

 Iurt is great if you got the hard drive space for a local rsynced repository otherwise it is really time consuming(for Cauldron at least), though there is a way to minimize the space and net bandwidth to only use the base system plus the packages required for one's builds but I never got patience/time to get it working with iurt (https://wiki.mageia.org/en/Urpmi-proxy). The rpmbuild command is fast and convenient, but running it on your customized/daily system does make it prone to false positives or even really bad/nonsense failures sometimes(very unlikely but it happens).

(In reply to katnatek from comment #6)
> so i need a way to indicate to use (force?) mingw flags
Check mingw64-filesystem-117-1.mga9 / macros.mingw*.

Created attachment 12907 [details]
Improved version of my spec

(In reply to Aurelian R from comment #7)
>  Your flags are more conservative and ensure a larger hardware pool for
> which the spec file works, that's clear. You should try copr( now I know
> what it means, thanks, btw ) without the hacks and test the pkg on your
> hardware to see how it behaves. 
> 
I have a old Laptop Compaq Presario C700 i don't have too much speciations for some type of works XD and try to use wine only if necessary so i don't have made any test regards of if correctly install (make that take me from the 2 to 4 release)

>  Iurt is great if you got the hard drive space for a local rsynced
> repository otherwise it is really time consuming(for Cauldron at least),
> though there is a way to minimize the space and net bandwidth to only use
> the base system plus the packages required for one's builds but I never got
> patience/time to get it working with iurt
> (https://wiki.mageia.org/en/Urpmi-proxy). The rpmbuild command is fast and
> convenient, but running it on your customized/daily system does make it
> prone to false positives or even really bad/nonsense failures sometimes(very
> unlikely but it happens).

I also read the documentation, the space is the main issue, if iurt works as mock and set a entire chroot i don't know if i have enough space for it and all the build process, after try once i avoid to even try to build chromium browser due that motive

> Check mingw64-filesystem-117-1.mga9 / macros.mingw*.
I do some research and with some help of fedora guides (https://docs.fedoraproject.org/en-US/packaging-guidelines/RPMMacros/ and https://fedoraproject.org/wiki/Packaging:MinGW ) and read the macros i get this spec, i already tested on my system and copr, works fine, it optionally apply the patch ;)

Attachment 12904 is obsolete: 0 => 1
Attachment 12906 is obsolete: 0 => 1

(In reply to katnatek from comment #8)
> I also read the documentation, the space is the main issue, if iurt works as
> mock and set a entire chroot i don't know if i have enough space for it and
> all the build process, after try once i avoid to even try to build chromium
> browser due that motive

For a small package build with iurt $du shows less than 2Gb to run a temporary chroot, while it stores an used instance setup in another ~1.5Gb.

(In reply to Aurelian R from comment #9)
> For a small package build with iurt $du shows less than 2Gb to run a
> temporary chroot, while it stores an used instance setup in another ~1.5Gb.

Interesting less that i think.

I like that my spec works if possible in all cases, help me like in this to learn new things

Created attachment 13221 [details]
spec updated for 1.10.1 version, also fix x86_64 installation

Finally i can test in x86_64 and have to make changes in spec to remove conflicts with and to install the i586 flavour in x86_64

For a official mageia package maybe you can considerate
1. disable the patch and warn to i586 users that it requires cpu with sse3

or

2. Build 2 i586 flavours one with sse2 and other with see3, i take this one and include the sse3 versions in our x86_64 repository but surely you will think in better solution ;)

Attachment 12903 is obsolete: 0 => 1
Attachment 12907 is obsolete: 0 => 1

Created attachment 13222 [details]
Updated patch to disable sse3

Upstream make change to their file so i did have to update this patch

Attachment 12905 is obsolete: 0 => 1