Wine 1.5.10 Defaults To D3D Off-Screen Rendering

[gilboa]

Rebuilding Wine is hardly a good option in an environment with package managers...

True.
But as we are living in a OSS world, you're not supposed to.
In my case I generated a fixed Fedora 16 RPM (w/ the pulseaudio patch), tested it and posted an RFE bug report against the Fedora wine package with the necessary patches and maintained them until the Fedora wine package maintainer fixed the RFE.
Hopefully others will do the same in other distributions.

As the saying goes, in OSS you eat your own dog food

- Gilboa

[bobwya]

Hmmm, very interesting comments about PA vs. ALSA... The real answer of course is a crap tonne of dev time+money to completely rewrite of the entire audio subsystem!!

On the actual subject of the article... The "AlwaysOffScreen" registry key was something I stumbled across (a few months ago) that would fix the smeared skybox problems in S.T.A.L.K.E.R.: SOC (presumably due to a bug in the Xray engine). This fix works across both the ATI radeon/proprietary Catalyst drivers and the Nvidia blob driver. Just one practical example of when this setting is useful!!

ALSO!! as an AppDB maintainer for Steam (and other applications). A general comment... PLEASE, PLEASE can people actually visit and READ the AppDB page for the applications they are trying to run under Wine. The fix for the missing text (due to a recently stubbed .dll in the Wine Git tree) is well known/documented and requires no recompilation, etc.!!

Bob

[Ansla]

I never had any need to compile anything not in Portage on Gentoo so far, but does Portage really know how to solve dependencies of applications that are not in Portage? I highly doubt that. And if something else depends on what you manually compiled, you can be in trouble even there.

No, of course if it's not in portage and don't find any overlay for it you must write the ebuild yourself and add the dependencies in there. But your original post was about recompiling an app that already exists in portage with an extra patch. In general you would have to modify the ebuild for that app so that the patch is applied, but in the specific case of wine they actualy make this easier by using epatch_user so you just dump your patch in /etc/portage/patches/app-emulation/wine/ (you need to create that path first) and re-emerge wine.

[GreatEmerald]

Well, being able to patch it like that is the equivalent of having a PPA or a package prebuilt. I haven't seen one of those on OpenSUSE yet, however. And even then, it would be just that much simpler if the patch was accepted!

Hmmm, very interesting comments about PA vs. ALSA... The real answer of course is a crap tonne of dev time+money to completely rewrite of the entire audio subsystem!!

Except not really. There are what, three implementations of PulseAudio on Wine that exist already? All they need to do is accept one of those into mainline Wine. There were discussions about which one it should be - and in the mean while, we're stuck without a PA implementation to begin with.

[Ansla]

Except there are dozens of patches for a project and if you want a random combination of 2 or 3 of them at the same time there's a slim chance of finding a PPA with that combination (unless it's a very popular combination). But that's no different then your chances of finding a binary distro that builds "world" with the combination of USE flags you want.

[PeterKraus]

It's only a problem for environments with binary packages, not package managers. It's perfectly natural in Gentoo and the package manager even makes it easier instead of getting in the way.

That's not true. Using Gentoo's portage its quite straightforward to modify ebuilds, but for example Archlinux has abs (something like an ebuild database for all the included packages), so you can just copy the package data, add the patch, and recompile - and it's gonna be managed the same way as stock arch packages. And of course, Debian (and everything Debian based) supports this too, since... ever: http://www.debian-administration.org/articles/253

Source-based distros usually require the users to understand a bit more about package managers/management than binary based ones, that doesn't mean "patching a package" and installing it within the package manager is impossible.

[Ansla]

You missed the point about the epatch_user feature that allows you to still automatically get security updates from the distro's main repository while having your custom patch applied. That just can't be replicated on a binary distro.
Also, if the package you need to patch is a library and the patch is not easy to back-port to the version you are using and the newer version breaks ABI, then using the patch is going to involve a lot of manual rebuilds on any binary distro.

[crazycheese]

The best audio improvement that you can do in Linux is....remove PulseAudio in any Linux distro that uses it

I just did it in XUBUNTU 12.04 so i can play ETQW with it's native client and finally VOIP doesn't crashes the game.

In Slackware VOIP of ETQW never crashes the game (because Slackware doesn't use that abomination called PulseAudio) but in UBUNTU and derivates, as sure as the Sun goes up tomorrow, it does.

Remove PulseAudio was quite simple actually.

I use pulse audio in WINE, in normal apps, everywhere. And it works. On Gentoo, Ubuntu, Linux Mint Debian, Debian, Xubuntu.
If you can't cook it, feel free to throw it away inclusive all advantages it gives using only 20MiB of RAM. Its your problem.

[crazycheese]

That's not true. Using Gentoo's portage its quite straightforward to modify ebuilds, but for example Archlinux has abs (something like an ebuild database for all the included packages)

ABS is community-maintained pkgbuild repo, without any security. Gentoo's main tree is overwatched.

[ChrisXY]

ABS is community-maintained pkgbuild repo, without any security.

ABS is the arch build system with all the "official" PKGBUILDS from which the repositories are built.
AUR is the arch user repository where everyone can upload PKGBUILDS. The security is the user who reads the PKGBUILDS before installing them.