emerge wine-staging-9999 fails at patch phase as follows: * Applying 0001-advapi32-tests-Add-more-tests-for-performance-counte.patch ... [ ok ] * Applying 0002-include-Add-more-definitions-for-performance-counter.patch ... [ ok ] * Applying 0003-advapi32-Add-initial-support-for-querying-performanc.patch ... [ ok ] * Applying 0004-winspool.drv-Add-performance-counters-service-stubs.patch ... [ ok ] * Applying 0005-advapi32-Performance-providers-Open-expects-to-see-t.patch ... [ ok ] * Applying 0006-advapi32-If-the-query-is-not-specified-the-default-q.patch ... [ ok ] * Applying 0007-advapi32-Read-the-configured-object-list-for-the-per.patch ... [ ok ] * Applying 0001-advapi32-Move-the-DACL-combining-code-into-a-separat.patch ... [ ok ] * Applying 0002-advapi32-Fix-the-initialization-of-combined-DACLs-wh.patch ... [ ok ] * Applying 0001-kernel32-Fallback-to-default-comspec-when-COMSPEC-is.patch ... [ ok ] * Applying 0001-kernel32-Add-a-bunch-of-kernel32-stubs.patch ... [ ok ] * Applying 0001-ntdll-Process-APC-calls-before-starting-process.patch ... [ ok ] * Applying 0001-ntdll-Remove-memory-limitation-to-32GB-on-64-bit-by-.patch ... 2 out of 2 hunks FAILED -- saving rejects to file dlls/ntdll/virtual.c.rej [ !! ] patch -p1 failed with /var/tmp/portage/app-emulation/wine-staging-9999/work/wine-staging-9999/patches/ntdll-Grow_Virtual_Heap/0001-ntdll-Remove-memory-limitation-to-32GB-on-64-bit-by-.patch [ !! ] * ERROR: app-emulation/wine-staging-9999::gentoo failed (prepare phase): * Failed to apply Wine-Staging patches I'm not sure where to find the file virtual.c.rej, and build.log doesn't say anything about why patching failed. Should I report this upstream, or is this a gentoo patch?
It's pretty standard for 9999s to fail patching. In this case, it's the wine-staging patchset that is failing. Typically, this means that they (wine-staging) need to rebase. The ebuild should have given you a STAGING_COMMIT variable to use that would ensure that the compilation succeeds. If THAT fails, then there is an issue worth reporting (upstream, but re-opening here is OK too).
(In reply to N. Andrew Walsh from comment #0) > emerge wine-staging-9999 fails at patch phase as follows: > patch -p1 failed with > /var/tmp/portage/app-emulation/wine-staging-9999/work/wine-staging-9999/ > patches/ntdll-Grow_Virtual_Heap/0001-ntdll-Remove-memory-limitation-to-32GB- > on-64-bit-by-.patch > [ !! ] > * ERROR: app-emulation/wine-staging-9999::gentoo failed (prepare phase): > * Failed to apply Wine-Staging patches That will fail because the Wine Development branch just integrated this patch - but Wine Staging will be rebased after a short delay. This sort of breakage happens so often that you basically can't build the Wine Staging Git Master against the Wine Git Master. But the reverse is kind of possible - with a hack... My ::bobwya Overlay Wine packages support building against the Wine Staging Git Master - as an alternative Git commit or branch target for the live ebuild. The env variables WINE_STAGING_COMMIT and WINE_STAGING_BRANCH can override the target of the app-emulation/wine-staging multislot package (or the legacy app-emulation/wine:0 package). Specifying these variables means that the package will build against the Wine Staging Git tree and then use the supplied reference to the supported Upstream Wine Git commit - to build against this. E.g.: /etc/portage/env/app-emulation/wine-staging:9999 EGIT_STAGING_BRANCH="master" Always build the =app-emulation/wine-staging-9999 package against the Wine Staging Git Master and refer back to the supported Wine Git commit. This will (in my experience) build and work 99% of the time - as the Wine Staging team are very careful to release commits in blocks and rebase frequently against stable(ish!) commits in the Upstream Wine Development Git tree. For QA reasons this hack cannot be included in the main Gentoo Wine packages! Just FYI...
