WineHQ provides a build server for creating Wine Stable/Development/Staging builds. The system is used to create the official packages, but is also open for interested developers to test their patches or to attach a patched Wine version to a bug report. In order to create your own Wine builds, you first need to send a request as written below.
The easiest way to control the builder is through the webinterface available at https://dev.wine-staging.com. By default you will only be able to view or download existing builds. We first have to assign you the necessary permissions, before you can start your own jobs. Since patched Wine packages could be used to spread malicious software, only Wine developers are entitled to gain access. We also use a two factor authentication system, based on OTP tokens, to prevent starting builds through a hacked account.
In order to gain access you have to:
- Create an account at https://dev.wine-staging.com
- Send an email with your account name to firstname.lastname@example.org from a well known email address
We will then manually check the request, which might take up to one day. When your application gets approved, you will receive an email with an OTP secret and a QR code. The secret is used to generate a time based OTP token, which must be entered when starting a build. For optimal security, you should use an external device, like a smartphone, to generate the tokens. Here is a small list of Apps that be used for this purpose:
There are many more OTP Apps available and most of them should work just fine. Depending on the installed App, you should be able to scan the QR code or you have to manually copy the secret. After everything is set up correctly, you should be able to start your first build. In case you receive an error that your account is not yet enabled, just wait a couple of minutes until the build server has reloaded the user database.
Lost OTP secret
If you have lost access to your OTP secret, please drop us a mail at email@example.com. For security reasons, there is no way to read or change the secret through the web interface.
A build can consist of two steps. You start by creating a build job and, when everything compiles successfully, you may push the generated packages into a repository. Let's take a closer look at the first step.
When opening the "Request a build" menu, you have the choice between three types:
|VM updates||Used for internal purposes to keep the VM up-to-date. You should not need to care about it.|
|Wine builds||This is most probably what you are looking for. For a Wine build you just have to enter details about the Wine version and optionally attach any patches.|
|Custom builds||Allows you to upload an arbitrary tar archive containing a script, which is run as root. Used to build non-Wine packages (for example macOS Wine dependencies).|
The builds (Wine / Custom) only differ in their input data, which is described below, but otherwise they behave the same way. After filling out all build related fields, you will also have to type in the current OTP token. If you enter an invalid one repeatedly, your account gets temporarily disabled. Since OTP tokens are based on the current time stamp, you should make sure that your clock is set correctly.
When everything was entered correctly, the build should show up in the job list with its current status. You can now wait till the build has finished, take a look at the live log or cancel the job again. After the job ended, you can click on Downloads to get access to the build log and the compiled packages. The download link could now be posted into a bug report, to give other users the possibility to test the build.
To prevent polluting the server, builds are not stored forever. Successful builds are kept for one month and failed builds for 1 week. We might adjust these limits in the future, when we have more experience with the real world usage of the system. To keep a build for more than a month, you either have to push the packages into a repository (see below) or contact us (firstname.lastname@example.org).
In order to start a normal Wine build you have to fill out the following fields:
|Summary||An optional user defined title for the build (informative only)|
|Wine Version||A version ("2.4"), a tag ("wine-2.4"), a branch ("stable") or a full sha1 hash of a Wine commit.
The build system tries to resolve the reference using the official Wine repository and https://github.com/mstefani/wine-stable.git. The official repository has a higher priority in case a reference exists in both repositories.
|Staging Version||A version ("2.4"), a tag ("v2.4"), a branch ("master") or a full sha1 hash of a Wine Staging commit.
Can be left blank for a development / stable build. For a staging build, you don't have to specify a Wine version. The builder will automatically choose the correct development commit.
|Release number||This number is appended to the version string when building a package.
You will have to increase it when building the same Wine version multiple times. This ensures that a package manager knows which version is the most recent one.
|Build tests||Defines whether the Wine tests should be build.
Unless you want to check whether your patch breaks the compilation of a test, you should disable this option. Building the tests increases the build time and they are not added to the resulting packages anyway.
|Patches||An optional list of patches to apply before building Wine.
They are applied in alphabetic order, so make sure that they are numbered correctly.
|Machines||List of possible build targets.
In order to create a working WOW64 build, you have to enable the x64 and x86 machines. The only exception is the macOS cross build which will always create a 32 bit only + WOW64 build.
|OTP||Your OTP token.|
This is all you have to do. The build will automatically generate the correct packages for the target platform. You can download them after the build has finished.
By default, you only receive permissions to create Wine builds and clicking on "Custom Build" will result in an error. The option to create normal Wine builds should be sufficient for most use cases, but if there is a reason you need to create a custom build, you can write a mail to email@example.com. We might either give you the necessary permissions or run the build for you.
The build server provides the possibility to push builds into a repository. This allows you to keep packages (even if you build a new version) and users can receive updates through their package manager after adding the repository.
For most purposes it is sufficient to just download the resulting packages from the build overview page. You therefore don't get access to any repositories by default. If you think there is valid reason why you should get your own repository, write us an email and we might provide you one at https://repos.wine-staging.com/. Adding a new repository includes generating a GPG key to sign your packages. In case you want to customize the GPG info fields (name/email), you should include this information in the request email.
After you have pushed your first packages, you can add the repository by following the instructions at https://www.winehq.org/download. Just substitute "https://dl.winehq.org/wine-builds" with your repository url.