I've been building unofficial wine-unstable packages for some time now and the amount of people apparently using them has become noticable (not only traffic-wise). Thus the amount of questions send to me has also risen quite a bit. In this post I try to address most of the questions in the hope it'll help people understand my motives for building these packages and potential pit falls for users.

First of all: I'll stop building those packages as soon as Debian has a – for my purposes – recent enough version in the archives. This is expected to happen soon as most/all of the blocking issues should be sorted out now/soon. See e.g. #557783 for some insight into the problems. It might happen after updated packages are in Debian, that I'll build one version or the other occasionally to test a certain patch or version. The bottom line of this is: don't rely on me to provide always the latest packages. (This, by the way, is also explanation enough to the question, whether I'm going to build the "official" (I consider only those entering Debian's archives official) Debian packages for upstream (WineHQ).)

Another question, which is seen every now and then in my inbox, is, whether I could add patch xyz to the packages. The answer is no. I maintain those packages for myself and if you want to use them, you're welcome. If you need another patch applied, just download the source package and add the patch with quilt to the series.

When a certain version/build doesn't work for you, you can ask me for help, but please don't expect me to handle "doesn't work" reports like I would handle bug reports for my packages. The wine-unstable packages are for myself and if they work for me, that's all I aim for.

Before spreading the word about my packages, make sure, you and those who read your post/message/whatever about my packages understand, that it is generally a very bad idea to install third-party packages, even though I'm a Debian Developer. Make also sure everybody understands that only the source package is signed with my key.

Please don't download all packages (binary and source), unless you really need all of them. Please pick the ones, you need and just download them.

Even though this might sound like begging, which I'm not, it'd be nice, if you could consider donating (via PayPal) something, to help cover the traffic costs. The traffic for just the wine-unstable packages has risen dramatically in the last few months. Thanks!

Now, I hope I've answered most questions, if not, feel free to contact me.

Just a short note, as I've already got e-mails about this: the binary packages are built ASAP, but currently one Build-Depends (openssl) isn't satisfiable for all platforms. The reason is simple: a new OpenSSL package (1.0.0d-1) was uploaded into unstable just recently and not all builds made it into the archive yet, some are still in incoming (please note, that they might not be there anymore, when you click the previous link).

So please be patient, the builds are done, when possible. Thanks. ;-)

As I got some e-mails about this: if you're on amd64 and Wine complains that it couldn't find a 3D acceleration card, then this is no bug in my wine-unstable packages but #614805.

The short-term workaround for you is to use LIBGL_DRIVERS_PATH=/usr/lib32/dri. You can either put it in front of every Wine invocation or you can export the variable in a specific shell session (don't export it globally), in which you'll run Wine or other programs needing the 32 bit libraries.

#614805 should be fixed automatically by the next ia32-libs upload, if it contains a version of Mesa containing Git commit cdd1912f.

Yesterday I received another report for a game, which wasn't working with the wine-unstable packages built by me. The reason why the reporter wrote to me and suspected a bug in my builds was, that the same game worked on the system of a friend (using a different distribution). After some exchanged e-mails it became apparent that this was yet another installment of S3TC-compressed textures. And as this wasn't the first time I got such reports, I thought I blog about the solution today.

As S3TC is one of those patent-encumbered texture compression formats (don't ask me why one can get a patent for such things, it's, IMHO, a very bad thing and we'd be better off, with a lot less patents), Mesa doesn't support it out of the box. You need to install an additional library or the proprietary driver for your graphics card. Before installing the library, make sure, that it is legal in your jurisdiction (i.e. check whether the patent is valid in your jurisdiction). If that is the case, you can install libtxc-dxtn0 from the Debian Multimedia repository or compile it yourself from source. If the patent is valid in your jurisdiction, you're most likely required to get a license from the rights holder for using the library, but I'm no lawyer so you might want to consult one prior to making your decision.

For amd64 users, there is an additional caveat: Wine needs the 32 bit variant installed. At the moment, this means downloading the i386 package from debian-multimedia.org and extracting the library to /usr/lib32.

For users with the r600c/g driver it gets (currently) really tricky, as there is no fully working support for loading libtxc_dxtn.so (current status is WIP). Here the only solution I know, would be to use the proprietary driver or writing patches for r600g (last option preferred *g*).

Due to popular demand ("I would give you something, if you'd offer Flattr."), which really just came up after WineHQ started linking to the download page, I've added a Flattr link to the wine-unstable download page. I still wanted to keep it as unobtrusive as possible and just use a text link.

In other news I've uploaded 1.3.19 today, sorry that I didn't manage to do so before the weekend was over, but the upstream release happend after I went on a short trip to Bremen.

And since some people didn't seem to read the notes on the download page, I'll try it through this channel: the package download page is NOT an APT repository. I want people to carefully consider the pros and cons before installing software from a third party. So please don't point your sources.list to the download page. Thanks!

Just a short announcement for the impatient: Wine 1.3.20 packages are available. As of this writing it's only the source package, the binaries follow as soon as they're built.

As a small side note: this is, as far as I can remember, my quickest upload of a Wine version (only about 15 minutes after the release was tagged upstream).

I already blogged about S3TC support with Wine, but back then I wrote about problems to get that working on amd64 without a proprietary driver. Now I've figured out a way to get it working on amd64 with the free radeon drivers (Gallium versions).

It's actually pretty simple, as most things are, once you figured it out. For 64 bit applications, you just need a recent Mesa version and the package libtxc-dxtn0. If you're using a card supported by the r600g driver, you first need a version of the Mesa package, which is build with the Gallium version of the r600 driver (the classic driver should work too, but I haven't tested that), like my unofficial Mesa packages (those packages were built for testing r600g, see this e-mail to debian-x). r600g users also need to set R600_S3TC_ENABLE=1, otherwise the driver won't attempt to load libtxc-dxtn0.

For 32 bit applications (like Windows games run with Wine) the initial setup is a little bit more involved: in addition to the above you also need to update a few libraries under /usr/lib32: namely Mesa and libdrm (if you use my Mesa packages you need a i386 copy of libffi too). The quick and dirty approach is to download the i386 packages for libgl1-mesa-dri, libgl1-mesa-glx, libglu1-mesa, libdrm2, libdrm-intel1, libdrm-radeon1 and (if you use my Mesa build) libffi5. Unpack the packages (dpkg-deb -x) and move the files under /path/to/unpack/dir/usr/lib to /usr/lib32. Alternatively you can also build a new ia32-libs package (make sure you change the source.list file of ia32-libs to use at least testing as a base, otherwise you'll end up with basically the same versions as are in the current package).

No matter how you updated your drivers you now need the 32 bit version of libtxc-dxtn0. debian-multimedia.org offers a packaged version.

After installing all the previous packages, Wine should be able to display (most) S3TC-using programs (in case you use the r600g driver, make sure you have R600_S3TC_ENABLE=1 set). If you're using my Mesa builds you can drop the LIBGL_DRIVERS_PATH=/usr/lib32/dri part again from your Wine invocation.

Please note, that there might be some S3TC-using applications with graphical glitches, when using the above method, as the support for S3TC in r600g is still marked as WIP.

Just a short entry, as I've already got a few e-mails about this: the JPEG is broken at the moment for my unofficial wine-unstable packages on amd64. This is due to #638543 in ia32-libs-dev. Please see the bug report for a detailed explanation.

A rebuild with libjpeg62-dev isn't an option, as other build dependencies pull libjpeg8-dev in anyway. Thus forcing the older version on amd64 just generates a FTBFS.

Full multi-arch support in the toolchain (including dpkg) or an update for ia32-libs are the two viable solutions for this as far as I can tell.

Just a short entry: sorry for the 1.3.28 upload delay, but due to #640864 ([UPDATE]: a big "thank you" goes to the GCC maintainers for their fast response[/UPDATE]) I've been unable to do a build. The latest version is now available (binary packages might take a few minutes to appear after this post went up).

[UPDATE 2011-09-11]: All binary packages (i386 and amd64) built as of now. i386 took a little longer, because the i386 packages of gcc-4.6 (4.6.1-10) hadn't reached my mirror in time for yesterday's (CEST) last build run.[/UPDATE]

I just uploaded my unofficial wine-unstable packages to dev.carbon-project.org (I skipped 1.3.36 over the holiday period). These new packages come with an important and often-requested change: they use GCC 4.5 to build the binaries, this works around an upstream GCC bug, see WineHQ bug report #22053 for further details. Unfortunately that clashes with the recent multi-archification on Debian and can lead to FTBFS in an automated build environment (like pbuilder would set up). The reason is the missing symlink from /usr/include/asm to /usr/include/DEB_BUILD_MULTIARCH/asm which then leads to GCC not finding e.g. errno.h (see #638418 for further details). That gives you the following options to make your build work again:

• Change the source package back to using the default GCC (ie. 4.6 at the moment).
• Modify your base.tgz for pbuilder and add the symlink manually.
• Modify the build environment "on the fly". You can either do this with a script in your hook directory for pbuilder (see pbuilder(8) on how to do that) or by setting up the symlink manually while pbuilder is installing the dependencies for wine-unstable (the last option is fragile and requires "good timing").

Otherwise you can also use the pre-built binary packages.

This is an updated and consolidated post for/of two previous blog entries. Before I continue, let me make it clear, that this post isn't intended to criticise anybody. It is meant as a instruction leaflet to go with my unofficial (source) package(s).

The best idea, until all build dependencies of Wine have been made multiarch ready (we're almost there), is to create a base.tgz for pbuilder in which you make the required changes. So you don't have to remember applying them everytime (note, this is only needed for amd64 builds). After you created yourself a base.tgz for Wine, do the follwoing:

1. Log into the chroot stored in your base.tgz for Wine: pbuilder --login --save-after-login --basetgz /path/to/your/wine.base.tgz
2. Update the package list and installed packages with aptitude update && aptitude safe-upgrade unless you know, everything is updated.
3. Install ia32-libs-dev and libjpeg-dev: aptitude install ia32-libs-dev libjpeg-dev
4. Work around #638543:
   1. cd /usr/lib32
   2. rm libjpeg.so libjpeg.so.62* (you can also remove the libjpeg.a and libjpeg.la files)
   3. ln -s libjpeg.so.8 libjpeg.so
   4. cd /usr/include
   5. ln -s x86_64-linux-gnu/jconfig.h
5. As we build build with GCC 4.5 (due to a problem with GCC 4.6, see WineHQ bug #22053 for more details) on amd64 (i386 isn't using GCC 4.5 anymore (since the 1.5.0-0.2 packages), because that resulted in linking errors), we hit #638418. To work around that, you need to create the symlink yourself. Execute ln -s x86_64-linux-gnu/asm asm in /usr/include.
6. Exit the chroot, pbuilder should now update your base.tgz.
7. Build the source package with pbuilder.

For i386 users this shouldn't be required. Not even the symlinking of the asm directory, as we don't use GCC 4.5 anylonger on i386 (due to various linking errors). Though that comes at the cost of potential issues with e.g. Steam.

Even though I've been largely offline for the past year and a half, I'm still alive an plan on getting back to do more work for Debian in 2014 and onwards. As a first token of this I've updated the unofficial Debian Wine packages to follow the current Debian packaging and built upstream version 1.7.9.

See you soon!