Hi,
at WineConf we discussed about providing binary packages and the idea was that Sebastian and I take care of this, since we already build packages for Wine Staging. We now altered our build system to work in a more general way and you can now try out the first packages. We already tested them shortly, but since we do not use all those distros on a daily basis, we might still have missed something.
Before I tell you the distribution specific installation instructions, first a more general overview about how the packages work. There are already a lot of different Wine packages out there, so our goal was to choose names which are not yet used on any system. To keep the risk of name collisions as small as possible, we decided for the following approach:
winehq-devel winehq-staging
These are the names of the packages which are most suitable for average users. The package will provide programs in /usr/bin (or some other distro-specific default installation path) and provide all the usual wine-specifc commands, like "wine", "winegcc", "wineserver", ... and so on. It will also contain the manpages, and desktop files.
In the background, those packages do not really contain the binaries but instead pull in additional dependencies, on Debian/Ubuntu the "wine-devel" package and on Fedora/Mageia the "wine-development" package. Those packages install wine in /opt/wine-devel. On the one hand this makes clear, that its not a distribution provided package, as all files reside in /opt, on the other hand it gives much more flexibility. A user can now decide whether to install the winehq-devel package, which symlinks all files to their usual locations in /usr/{bin, share} etc. or whether he wants to install multiple wine versions at the same time by using the underlying wine-devel/wine-development package. Besides the possibility of having multiple wine versions installed at the same time, this way we could even ship additional dynamically linked libraries without messing around with the rest of the system, for example if distribution packages are incompatible with wine.
Below are the instructions how to install those packages on various distributions. Executing wine --version (or /opt/wine-devel/bin/wine --version) should afterwards show 1.8rc-1. If you find any bugs, please report them so that we can fix them. You can also take a look at the packaging files at https://github.com/wine-compholio/wine-packaging (or send a pull request if you want to contribute with your improvements). In case everything is working fine, we should add those packages on the download page, so that more users can try out the release candidates for 1.8.
So, as a short summary, about what is already working, and what still needs to be done: - We'll now be able to provide 8 Ubuntu, 8 Debian, 4 Mageia and 2 Fedora packages per release (which means about 44 build tasks per week). - Fedora 23 packages are still missing, but will be added soon. - Crosscompiled Mac OS X packages will also be added soon. - Additional distributions can be added on request - but please try to contact your distribution first!
---- Ubuntu ----
# Add repository sudo add-apt-repository ppa:wine/wine-builds
# Update packages sudo apt-get update
sudo apt-get install --install-recommends winehq-devel
# Advanced users can instead install the wine-devel package # directly, in parallel to their regular Wine versions.
---- Debian ----
# Enable 32 bit packages sudo dpkg --add-architecture i386
# Install key which was used to sign packages wget https://dl.winehq.org/wine-builds/Release.key sudo apt-key add Release.key
# Add repository to /etc/apt/sources.list or create a *.list # under /etc/apt/sources.list.d/ with the following content: deb https://dl.winehq.org/wine-builds/debian/ DISTRO main # with DISTRO being either wheezy, jessie, stretch or sid
# Update packages sudo apt-get update
sudo apt-get install winehq-devel
# Advanced users can instead install the wine-devel package # directly, in parallel to their regular Wine versions.
---- Fedora ----
# Currently only Fedora 22 is supported, 23 will be added soon
# Add repository dnf config-manager --add-repo https://dl.winehq.org/wine-builds/fedora/22/winehq.repo
dnf apt-get install winehq-devel
# Advanced users can instead install the wine-development package # directly, in parallel to their regular Wine versions.
---- Mageia ----
# Install key which was used to sign packages wget https://dl.winehq.org/wine-builds/Release.key sudo rpm --import Release.key
# If you are using Mageia 4 sudo urpmi.addmedia "WineHQ 32-bit" https://dl.winehq.org/wine-builds/mageia/4/i586/
# If you are using 64-bit Mageia 4, also add sudo urpmi.addmedia "WineHQ 64-bit" https://dl.winehq.org/wine-builds/mageia/4/x86_64/
# If you are using Mageia 5 sudo urpmi.addmedia "WineHQ 32-bit" https://dl.winehq.org/wine-builds/mageia/5/i586/
# If you are using 64-bit Mageia 5, also add sudo urpmi.addmedia "WineHQ 64-bit" https://dl.winehq.org/wine-builds/mageia/4/x86_64/
sudo urpmi.update -a sudo urpmi winehq-devel
# Advanced users can instead install the wine-development package # directly, in parallel to their regular Wine versions.
------------------
Regards, Michael
Thanks for the instructions! This will definitely help others to quickly get up to speed with the binary packages.
How long until the cross compiled OSX packages arrive? Could you put up the scripts on GitHub or does it have to be fully working before you do so?
Cheers, Aaryaman
On Fri, Nov 27, 2015 at 7:07 AM, Michael Müller michael@fds-team.de wrote:
Hi,
at WineConf we discussed about providing binary packages and the idea was that Sebastian and I take care of this, since we already build packages for Wine Staging. We now altered our build system to work in a more general way and you can now try out the first packages. We already tested them shortly, but since we do not use all those distros on a daily basis, we might still have missed something.
Before I tell you the distribution specific installation instructions, first a more general overview about how the packages work. There are already a lot of different Wine packages out there, so our goal was to choose names which are not yet used on any system. To keep the risk of name collisions as small as possible, we decided for the following approach:
winehq-devel winehq-staging
These are the names of the packages which are most suitable for average users. The package will provide programs in /usr/bin (or some other distro-specific default installation path) and provide all the usual wine-specifc commands, like "wine", "winegcc", "wineserver", ... and so on. It will also contain the manpages, and desktop files.
In the background, those packages do not really contain the binaries but instead pull in additional dependencies, on Debian/Ubuntu the "wine-devel" package and on Fedora/Mageia the "wine-development" package. Those packages install wine in /opt/wine-devel. On the one hand this makes clear, that its not a distribution provided package, as all files reside in /opt, on the other hand it gives much more flexibility. A user can now decide whether to install the winehq-devel package, which symlinks all files to their usual locations in /usr/{bin, share} etc. or whether he wants to install multiple wine versions at the same time by using the underlying wine-devel/wine-development package. Besides the possibility of having multiple wine versions installed at the same time, this way we could even ship additional dynamically linked libraries without messing around with the rest of the system, for example if distribution packages are incompatible with wine.
Below are the instructions how to install those packages on various distributions. Executing wine --version (or /opt/wine-devel/bin/wine --version) should afterwards show 1.8rc-1. If you find any bugs, please report them so that we can fix them. You can also take a look at the packaging files at https://github.com/wine-compholio/wine-packaging (or send a pull request if you want to contribute with your improvements). In case everything is working fine, we should add those packages on the download page, so that more users can try out the release candidates for 1.8.
So, as a short summary, about what is already working, and what still needs to be done:
- We'll now be able to provide 8 Ubuntu, 8 Debian, 4 Mageia and 2 Fedora packages per release (which means about 44 build tasks per week).
- Fedora 23 packages are still missing, but will be added soon.
- Crosscompiled Mac OS X packages will also be added soon.
- Additional distributions can be added on request - but please try to
contact your distribution first!
---- Ubuntu ----
# Add repository sudo add-apt-repository ppa:wine/wine-builds
# Update packages sudo apt-get update
sudo apt-get install --install-recommends winehq-devel
# Advanced users can instead install the wine-devel package # directly, in parallel to their regular Wine versions.
---- Debian ----
# Enable 32 bit packages sudo dpkg --add-architecture i386
# Install key which was used to sign packages wget https://dl.winehq.org/wine-builds/Release.key sudo apt-key add Release.key
# Add repository to /etc/apt/sources.list or create a *.list # under /etc/apt/sources.list.d/ with the following content: deb https://dl.winehq.org/wine-builds/debian/ DISTRO main # with DISTRO being either wheezy, jessie, stretch or sid
# Update packages sudo apt-get update
sudo apt-get install winehq-devel
# Advanced users can instead install the wine-devel package # directly, in parallel to their regular Wine versions.
---- Fedora ----
# Currently only Fedora 22 is supported, 23 will be added soon
# Add repository dnf config-manager --add-repo https://dl.winehq.org/wine-builds/fedora/22/winehq.repo
dnf apt-get install winehq-devel
# Advanced users can instead install the wine-development package # directly, in parallel to their regular Wine versions.
---- Mageia ----
# Install key which was used to sign packages wget https://dl.winehq.org/wine-builds/Release.key sudo rpm --import Release.key
# If you are using Mageia 4 sudo urpmi.addmedia "WineHQ 32-bit" https://dl.winehq.org/wine-builds/mageia/4/i586/
# If you are using 64-bit Mageia 4, also add sudo urpmi.addmedia "WineHQ 64-bit" https://dl.winehq.org/wine-builds/mageia/4/x86_64/
# If you are using Mageia 5 sudo urpmi.addmedia "WineHQ 32-bit" https://dl.winehq.org/wine-builds/mageia/5/i586/
# If you are using 64-bit Mageia 5, also add sudo urpmi.addmedia "WineHQ 64-bit" https://dl.winehq.org/wine-builds/mageia/4/x86_64/
sudo urpmi.update -a sudo urpmi winehq-devel
# Advanced users can instead install the wine-development package # directly, in parallel to their regular Wine versions.
Regards, Michael
We added Fedora 23 yesterday and uploaded all builds for 1.8-rc2. The instructions for Fedora 23 are basically the same as for Fedora 22, just replace the version number in the url:
dnf config-manager --add-repo https://dl.winehq.org/wine-builds/fedora/23/winehq.repo dnf apt-get install winehq-devel
Am 27.11.2015 um 20:19 schrieb Aaryaman Vasishta:
How long until the cross compiled OSX packages arrive? Could you put up the scripts on GitHub or does it have to be fully working before you do so?
All scripts can be found in the following two repositories: https://github.com/wine-compholio/wine-packaging https://github.com/wine-compholio/wine-build-tools
We are planning to wait until the Mac OS X builds for wine-devel work, before we add the scripts. Our current solution is to cross compile Wine on Debian as host distribution and this requires a lot of additional tools plus dependencies. Currently most of the tools and dependencies we use for Wine Staging are precompiled binaries that were manually compiled some time ago. This is not really a good solution as it somewhat obfuscates the build process. We would like to find a better solution for this. When we are done, we will add everything necessary (excluding the OS X 10.8 SDK), but it might be a bit difficult to setup, especially if you don't want to use a VM for building.
Am 29.11.2015 um 16:05 schrieb Rosanne DiMesio:
Any chance of adding RHEL/CentOS/Scientific Linux packages that will
actually work (WoW64)? Red Hat has already refused.
We might want to consider this at a later point, but from my experience with CentOS 6 and Wine Staging, you don't gain much by supporting CentOS. The main repositories didn't provide all dependencies for Wine (for example OpenAL) and the packages were often outdated and caused crashes which were not reproducible on other distros. Many of these problems were most probably solved in CentOS 7, but I think we should prioritize our efforts. More people can benefit from OS X builds than CentOS at the moment, so I think we should fix them first.
On Sun, Nov 29, 2015 at 4:25 PM, Michael Müller michael@fds-team.de wrote:
We added Fedora 23 yesterday and uploaded all builds for 1.8-rc2. The instructions for Fedora 23 are basically the same as for Fedora 22, just replace the version number in the url:
dnf config-manager --add-repo https://dl.winehq.org/wine-builds/fedora/23/winehq.repo dnf apt-get install winehq-devel
Am 27.11.2015 um 20:19 schrieb Aaryaman Vasishta:
How long until the cross compiled OSX packages arrive? Could you put up the scripts on GitHub or does it have to be fully working before you do so?
All scripts can be found in the following two repositories: https://github.com/wine-compholio/wine-packaging https://github.com/wine-compholio/wine-build-tools
We are planning to wait until the Mac OS X builds for wine-devel work, before we add the scripts. Our current solution is to cross compile Wine on Debian as host distribution and this requires a lot of additional tools plus dependencies. Currently most of the tools and dependencies we use for Wine Staging are precompiled binaries that were manually compiled some time ago. This is not really a good solution as it somewhat obfuscates the build process. We would like to find a better solution for this. When we are done, we will add everything necessary (excluding the OS X 10.8 SDK), but it might be a bit difficult to setup, especially if you don't want to use a VM for building.
I'm not sure where you plan on installing wine on OS X, but be aware that 10.11/El Capitan forbids installing into /usr (except /usr/local): https://support.apple.com/en-us/HT204899
I ran into that recently in my day job..You may also want to consider getting an Apple Developer Key so that packages can be signed and users can avoid scary warnings, but I don't know if that would work in your cross-compile setup.
Am 29.11.2015 um 16:05 schrieb Rosanne DiMesio:
Any chance of adding RHEL/CentOS/Scientific Linux packages that will
actually work (WoW64)? Red Hat has already refused.
We might want to consider this at a later point, but from my experience with CentOS 6 and Wine Staging, you don't gain much by supporting CentOS. The main repositories didn't provide all dependencies for Wine (for example OpenAL) and the packages were often outdated and caused crashes which were not reproducible on other distros. Many of these problems were most probably solved in CentOS 7, but I think we should prioritize our efforts. More people can benefit from OS X builds than CentOS at the moment, so I think we should fix them first.
Absolutely, having Mac OS X packages of vanilla Wine would be a huge help. Thanks for your work on this.
Am 30.11.2015 um 03:21 schrieb Austin English:
I'm not sure where you plan on installing wine on OS X, but be aware that 10.11/El Capitan forbids installing into /usr (except /usr/local): https://support.apple.com/en-us/HT204899
I ran into that recently in my day job.
Currently we install wine staging into /opt/wine-staging which seems to work. I would prefer to install the new packages into the home directory, so that also users without admin rights can install the package. The only problem are the dependencies since they usually do not use relative rpaths and they might contain the prefix embedded in the executables. Not sure if this is a problem, I need to test this.
You may also want to consider getting an Apple Developer Key so that packages can be signed and users can avoid scary warnings, but I don't know if that would work in your cross-compile setup.
It is indeed difficult to sign executables without using any proprietary tools by Apple, but it seems like I found one which works. "codesign -vd wine" seems to like my signature, except that the tool slightly messed up the timestamp of the signature which now lies before the creation date of my self signed certificate. I am sure this can be fixed though ;-). Signing the whole package is most probably a bit more difficult than just signing one executable, but I am sure this is doable.
I guess it is necessary to pay 99$/year for the developer program to get your key signed, right?
On Mon, Nov 30, 2015 at 1:27 PM, Michael Müller michael@fds-team.de wrote:
Am 30.11.2015 um 03:21 schrieb Austin English:
I'm not sure where you plan on installing wine on OS X, but be aware that 10.11/El Capitan forbids installing into /usr (except /usr/local): https://support.apple.com/en-us/HT204899
I ran into that recently in my day job.
Currently we install wine staging into /opt/wine-staging which seems to work. I would prefer to install the new packages into the home directory, so that also users without admin rights can install the package. The only problem are the dependencies since they usually do not use relative rpaths and they might contain the prefix embedded in the executables. Not sure if this is a problem, I need to test this.
You may also want to consider getting an Apple Developer Key so that packages can be signed and users can avoid scary warnings, but I don't know if that would work in your cross-compile setup.
It is indeed difficult to sign executables without using any proprietary tools by Apple, but it seems like I found one which works. "codesign -vd wine" seems to like my signature, except that the tool slightly messed up the timestamp of the signature which now lies before the creation date of my self signed certificate. I am sure this can be fixed though ;-). Signing the whole package is most probably a bit more difficult than just signing one executable, but I am sure this is doable.
Typically the .pkg installer is signed.
I guess it is necessary to pay 99$/year for the developer program to get your key signed, right?
Unfortunately yes.
Am 30.11.2015 um 20:29 schrieb Austin English:
Typically the .pkg installer is signed.
You are right. Signing the xar archive is sufficient to make OS X happy (I installed my self signed certificate):
$ pkgutil --check-signature wine-staging-1.7.55-osx.pkg Package "wine-staging-1.7.55-osx.pkg": Status: signed by a certificate trusted on this system Certificate Chain: 1. Test SHA1 fingerprint: A9 95 25 95 [...]
From a technical point of view I don't see a problem in signing the
packages. We already have all required tools on the build system.
Am 30.11.2015 um 21:22 schrieb Hin-Tak Leung:
Can you tell me more about the open tool used for signing Mac OS X
executables?
I have been working on font signing in the recently open-sourced microsoft font validator (there is an official windows-only tool for signing fonts, but apparently an open-toolchain based tool also exist in somebody's hard disk)
The tool I used for sining the executables is ldid (http://gitweb.saurik.com/ldid.git). The program calculates the checksums for all code sections, signs the checksums and then embeds the signature into the Mach-O executable. It is unlikely that this will help you with font files.
On Fri, 27 Nov 2015 02:37:04 +0100 Michael Müller michael@fds-team.de wrote:
- Additional distributions can be added on request - but please try to contact your distribution first!
Any chance of adding RHEL/CentOS/Scientific Linux packages that will actually work (WoW64)? Red Hat has already refused. https://bugzilla.redhat.com/show_bug.cgi?id=1117422
-
Aaryaman Vasishta -
Austin English -
Michael Müller -
Rosanne DiMesio