Get Gentoo!
gentoo.org sites
gentoo.org Wiki Bugs Forums Packages
Planet Archives Sources
Infra Status
summaryrefslogtreecommitdiff
path: root/app-emulation/dxvk
Commit message (Collapse)AuthorAgeFilesLines
* app-emulation/dxvk: enable py3.13Ionen Wolkens2024-05-102-2/+2
| | | | Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* app-emulation/dxvk: fix build with gcc14Ionen Wolkens2024-05-073-0/+9
| | | | Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* app-emulation/dxvk: drop 2.2-r1, 2.3Ionen Wolkens2024-05-073-379/+0
| | | | Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* app-emulation/dxvk: Stabilize 2.3.1-r1 amd64, #930780Sam James2024-04-271-1/+1
| | | | Signed-off-by: Sam James <sam@gentoo.org>
* app-emulation/dxvk: Stabilize 2.3.1-r1 x86, #930780Sam James2024-04-271-1/+1
| | | | Signed-off-by: Sam James <sam@gentoo.org>
* app-emulation/dxvk: filter -Wl,-z,* ... for C(XX)FLAGSIonen Wolkens2024-03-285-0/+25
| | | | | | | | | | | | | | | | | | | | | | | | strip-unsupported-flags handles this fine in LDFLAGS, but -Wl,* are no-ops during compile-only tests (thus not stripped) and then if a package compiles and links anything at same time it fails. This used not to be a big problem but now that 23.0 profiles do -Wl,-z,pack-relative-relocs (mingw ld has no -z) this is hitting bashrc-mv users that tend to do CFLAGS="${LDFLAGS}" by default. Tempting to ignore it because of how wrong it is, but well. An alternate route could be to eventually have strip-flags and/or strip-unsupported-flags remove -Wl,* from non-LDFLAGS given this could affect more than mingw (e.g. switching to bfd when there is a lld-only option). wrt bug #928038, this already been done a while ago for wine, mingw64-runtime, and mingw64-toolchain itself and there *should* have been only dxvk and vkd3d-proton left (now done). Closes: https://bugs.gentoo.org/928038 Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* app-emulation/dxvk: mark as LTO unsafeIonen Wolkens2024-03-275-0/+25
| | | | Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* app-emulation/dxvk: remove old -fstack-protector workaroundIonen Wolkens2024-03-245-31/+1
| | | | | | | | | mingw64-*-11 been gone for a while now. Was originally thinking to add the same workaround as mingw64-toolchain for -Wl,-z,* but meson does not need this. So isntead cleaning this up. Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* app-emulation/dxvk: sync liveIonen Wolkens2024-03-201-8/+11
| | | | Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* app-emulation/dxvk: add 2.3.1Ionen Wolkens2024-03-202-0/+190
| | | | Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* app-emulation/dxvk: "fix" VariableOrderWrongIonen Wolkens2024-03-203-8/+11
| | | | | | | More of an edge case, meant to keep it close to the 9999 block's SRC_URI. But fairly harmless to make pkgcheck happy by moving it down. Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* app-emulation/dxvk: add short comment for libdisplay-info fallbackIonen Wolkens2024-02-091-2/+2
| | | | | | | | | | | It may otherwise look odd at a glance. Bundled fallback is normally not something we want to do, but this is a special situation. Solving properly would essentially involve having PE multilib (abi_x86_pe32/64 or so) on libdisplay-info which is far too involved for little gain. Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* app-emulation/dxvk: Force fallback for libdisplay-info in 9999Mike Lothian2024-02-091-0/+1
| | | | | | | | | | | | Without this 64bit dxvk doesn't compile for me ionen's note: to clarify this is due to finding the system copy of libdisplay-info (if installed), but we're cross-compiling using mingw so we don't want the ELF one Signed-off-by: Mike Lothian <mike@fireburn.co.uk> Closes: https://github.com/gentoo/gentoo/pull/35245 Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* app-emulation/dxvk: Stabilize 2.3 amd64, #915004Sam James2023-10-011-1/+1
| | | | Signed-off-by: Sam James <sam@gentoo.org>
* app-emulation/dxvk: Stabilize 2.3 x86, #915004Sam James2023-10-011-1/+1
| | | | Signed-off-by: Sam James <sam@gentoo.org>
* app-emulation/dxvk: add 2.3Ionen Wolkens2023-09-042-0/+184
| | | | Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* app-emulation/dxvk: do not use -p to copy from distdirIonen Wolkens2023-08-162-2/+2
| | | | | Closes: https://bugs.gentoo.org/912373 Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* app-emulation/dxvk: fix setup script with wine[wow64]Ionen Wolkens2023-08-154-4/+27
| | | | | | | | | | | | | | | | Currently it will try to install both 32bit and 64bit dlls in system32. Very few likely use wow64 so far, but this could come biting later without a revbump. Ideally do not want to use these scripts anymore and write something new that could be packaged separately and shared between dxvk, vkd3d-proton, and potential new packages. Albeit haven't explored the cleanest way to do this yet, so just do a dirty sanity check + fallback for now (wish could just use these directly from system paths, but wine really does not seem to offer a way to do this). Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* app-emulation/dxvk: drop 2.0, 2.1Ionen Wolkens2023-08-153-354/+0
| | | | Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* app-emulation/dxvk: allow abi_x86_32 on no-multilib profilesIonen Wolkens2023-08-105-0/+5
| | | | Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* app-emulation/dxvk: update -mno-avx comment to match wineIonen Wolkens2023-06-265-13/+20
| | | | | | | | | | Unsure for the status of issues with dxvk, the old Tk-Glitch issue (who were building this with -march=native) is 404 given repos changed around and unsure what the reproducer is. But given seemingly bad code is being generated for recent Wine I think this is unsafe enough that should keep it for now. Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* app-emulation/dxvk: Stabilize 2.2 amd64, #908051Arthur Zamarin2023-06-081-1/+1
| | | | Signed-off-by: Arthur Zamarin <arthurzam@gentoo.org>
* app-emulation/dxvk: Stabilize 2.2 x86, #908051Arthur Zamarin2023-06-081-1/+1
| | | | Signed-off-by: Arthur Zamarin <arthurzam@gentoo.org>
* app-emulation/dxvk: USE=-debug -> global USE=strip in liveIonen Wolkens2023-06-021-2/+2
| | | | | | | | Will update the old ebuilds eventually but given this triggers a rebuild with --changed-use (default enabled), will wait till a bump and maybe stable to give a chance for people to update. Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* app-emulation/dxvk: enable py3.12Ionen Wolkens2023-05-253-3/+3
| | | | Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* app-emulation/dxvk: drop 2.1_p20230207Ionen Wolkens2023-05-122-182/+0
| | | | Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* app-emulation/dxvk: add 2.2Ionen Wolkens2023-05-122-0/+176
| | | | Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* app-emulation/dxvk: update flags filtersIonen Wolkens2023-04-295-10/+30
| | | | | | | | | | | | | | * -fstack-clash-protection (bug #758914): ICE was fixed, if still run into this then updating gcc to a newer _p* snapshot should sort it (alternatively, use released >=gcc-13.1.0) * -fstack-protector* (bug #870136): mingw64-runtime-11.0.0 adds its own (partial) ssp support, allowing -D_FORTIFY_SOURCE=3 and -fstack-protector-strong without libssp. Using these to build Wine currently still leads to failure, but we can allow it here. Bug: https://bugs.gentoo.org/758914 Bug: https://bugs.gentoo.org/870136 Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* app-emulation/dxvk: fix build w/ gcc13Ionen Wolkens2023-04-185-2/+35
| | | | Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* app-emulation/dxvk: add 2.1_p20230207Ionen Wolkens2023-04-172-0/+174
| | | | | | | | This matches the version used by Proton-8.0.1c, providing to match expectations of advertised proton bug fixes and will only be kept until there's a new dxvk release. Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* app-emulation/dxvk: stabilize 2.1 for amd64, x86Ionen Wolkens2023-02-131-1/+1
| | | | Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* app-emulation/dxvk: sync liveIonen Wolkens2023-01-241-5/+11
| | | | Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* app-emulation/dxvk: add 2.1Ionen Wolkens2023-01-242-0/+173
| | | | | | python is used by libdisplay-info at build time Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* app-emulation/dxvk: add ebuild comment about keeping <2.0Ionen Wolkens2022-12-151-0/+3
| | | | Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* app-emulation/dxvk: backport req use from liveIonen Wolkens2022-12-141-0/+1
| | | | | | | | | | | | | | | But keep the old too because lacks the meson rules changes from 9999 Aka need: 1.10.3 -> dxgi? ( d3d11 ) 9999 -> d3d11? ( dxgi ) 2.0 -> d3d11? ( dxgi ) dxgi? ( d3d11 ) But realistically nobody disables any of these either way, at best it just saves on build time. Closes: https://bugs.gentoo.org/885975 Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* app-emulation/dxvk: stabilize 1.10.3 for amd64, x86Ionen Wolkens2022-12-011-1/+1
| | | | | | | Will not keep it forever, but stabilizing this older version as well given 2.0 requires more recent vulkan drivers to function. Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* app-emulation/dxvk: stabilize 2.0 for amd64, x86Ionen Wolkens2022-12-011-1/+1
| | | | | | | No real reason to keep this ~arch only, and will be convenient for stable Wine users. Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* app-emulation/dxvk: fix ExcessiveLineLengthIonen Wolkens2022-12-011-3/+6
| | | | Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* app-emulation/dxvk: update live required useIonen Wolkens2022-11-291-1/+1
| | | | | | | meson logic was shifted around, standalone dxgi builds are now possible dxgi option is required for d3d11 Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* app-emulation/dxvk: temporarily restore setup_dxvk.shIonen Wolkens2022-11-292-9/+16
| | | | | | Better than nothing until come up with a solution. Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* app-emulation/dxvk: update liveIonen Wolkens2022-11-291-13/+16
| | | | | | | | | | Roughly anyway, this will need more attention. Ideally hoping upstream will provide some better options than raw instructions to the removed setup_dxvk.sh, or may have to make our own one given this is rather annoying to handle manually. Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* app-emulation/dxvk: cleanup wine check in old tooIonen Wolkens2022-11-101-7/+0
| | | | | | | | Does not really feel useful, ultimately this can be used in many ways (including custom wines, or perhaps not even wine) and trying to check does not mean much. Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* app-emulation/dxvk: sync liveIonen Wolkens2022-11-101-8/+25
| | | | Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* app-emulation/dxvk: add 2.0Ionen Wolkens2022-11-102-0/+159
| | | | Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* app-emulation/dxvk: filter -mfunction-return=thunk for mingwIonen Wolkens2022-10-302-0/+2
| | | | | | | | | Unfortunately mingw doesn't play well with many security/mitigation flags. May need to consider a mingw.eclass if keep adding more of these to every ebuilds using it. Bug: https://bugs.gentoo.org/878849 Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* app-emulation/dxvk: filter -fstack-clash-protectionIonen Wolkens2022-10-232-0/+2
| | | | | Bug: https://bugs.gentoo.org/758914 Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* app-emulation/dxvk: drop 1.10.1, 1.10.2Ionen Wolkens2022-09-273-278/+0
| | | | | | | | Unsure how long want to keep old versions for this (like wine it can be useful to handle regressions), but think patch releases can go. May keep 1.10.x for longer after 1.11.x Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* app-emulation/dxvk: filter ssp for mingwIonen Wolkens2022-09-144-0/+4
| | | | | Bug: https://bugs.gentoo.org/870136 Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* app-emulation/dxvk: Remove test option in 9999Mike Lothian2022-08-311-1/+0
| | | | | | | | This has been removed upstream Signed-off-by: Mike Lothian <mike@fireburn.co.uk> Closes: https://github.com/gentoo/gentoo/pull/27098 Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* app-emulation/dxvk: add 1.10.3Ionen Wolkens2022-08-022-0/+138
| | | | Signed-off-by: Ionen Wolkens <ionen@gentoo.org>