You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Cross-platform static builds of qBittorrent-nox with the latest dependencies
8
8
9
-
The `qbittorrent-nox-static` project is a `bash` build script that compiles a static `qbittorrent-nox` binary using the latest available dependencies from their source. These statically linked binaries can run on any matching CPU architecture and are not OS specific. This means you can run a `x86_64` Alpine edge build on any Linux based OS of like CentOS | Fedora | OpenSuse | Debian | Ubuntu and more.
9
+
[📦 Latest Release](https://github.com/userdocs/qbittorrent-nox-static/releases/latest) • [📖 Documentation](https://userdocs.github.io/qbittorrent-nox-static/introduction/) • [🏷️ All Releases](https://github.com/userdocs/qbittorrent-nox-static/tags)
> You don't need to use the script to access the binaries it creates, just use the [release tag](https://github.com/userdocs/qbittorrent-nox-static/tags) you need or [latest release page](https://github.com/userdocs/qbittorrent-nox-static/releases/latest)
26
+
> Access the WebUI at `http://localhost:8080`
13
27
14
-
See here for how to [install the latest release](https://github.com/userdocs/qbittorrent-nox-static?tab=readme-ov-file#install-the-latest-release)
28
+
### What You Get
15
29
16
-
## Linked Github repositories
30
+
✅ **No installation hassles** - Single static binary
> Visit the [documentation](https://userdocs.github.io/qbittorrent-nox-static/introduction/) for in depth information on using this project and script usage.
50
+
The `qbittorrent-nox-static` project provides a bash build script that compiles static `qbittorrent-nox` binaries using the latest available dependencies from their source. These statically linked binaries offer several advantages:
29
51
30
-
## WSL2
52
+
-**Universal compatibility**: Run on any Linux distribution with matching CPU architecture
53
+
-**No dependencies**: All required libraries are statically linked
54
+
-**Latest versions**: Built with the most recent stable releases of all dependencies
55
+
-**Multiple architectures**: Support for x86, x86_64, ARM variants
31
56
32
-
> [!TIP]
33
-
> These static builds can be used on WSL2 and accessed via `localhost:8080` using the download instructions below
57
+
## ✨ Features
34
58
35
-
## Install the latest release
59
+
- 🔧 **Static compilation** - No external dependencies required
> Libtorrent `v1.2` is currently the main branch supported by qBittorrent since a change with the release of [4.4.5](https://www.qbittorrent.org/news.php)
113
+
> **Libtorrent v1.2** is currently the main branch supported by qBittorrent since the release of [4.4.5](https://www.qbittorrent.org/news.php). However, both v1.2 and v2.0 builds are provided.
114
+
115
+
This project automatically builds and releases binaries for both Libtorrent versions:
86
116
87
-
Libtorrent `v2.0` builds are still released as latest releases as it it does not really matter to this project as it always builds and releases for both `v1.2` and `v2.0`. See the next section for how to get the version you need via the latest release URL.
117
+
-**Libtorrent v1.2**: Stable and widely supported (recommended)
118
+
-**Libtorrent v2.0**: Latest features and improvements
88
119
89
120
> [!TIP]
90
-
> You can view the current latest and prereleases and tags here<https://github.com/userdocs/qbittorrent-nox-static/tags>
121
+
> You can view all current releases and pre-releases at<https://github.com/userdocs/qbittorrent-nox-static/tags>
91
122
92
-
## Getting the Version you want via the latest release URL
123
+
## 🎯 Version Management
93
124
94
-
Since this project builds and releases both v1.2 and v2.0 builds simultaneously we can use the commands below to always get the latest version of the related pre release via the latest release `dependency-version.json` asset.
125
+
### Getting Version-Specific Releases
95
126
96
-
Using this method it does not matter which version is the latest release or pre release as the commands will provide you the version specific info you need for the twinned latest/pre releases.
127
+
Since this project builds both v1.2 and v2.0 simultaneously, you can target specific libtorrent versions using these commands:
The build has 5 main dependencies tracked that will trigger a rebuild on an update being available.
143
+
The build system tracks 5 main dependencies that trigger automatic rebuilds:
113
144
114
-
-qBittorrent
115
-
-Libtorrent
116
-
-Qt
117
-
-Boost
118
-
- Openssl
145
+
- qBittorrent
146
+
- Libtorrent
147
+
- Qt
148
+
- Boost
149
+
-OpenSSL
119
150
120
-
When a new build is triggered for updating `qBittorrent` or `Libtorrent` a new release will be generated as the release tags will be updated.
151
+
**Revision Tracking:**
121
152
122
-
Since I do not append revision info to tags `Qt` - `Boost` - `Openssl` or patched builds it will only update the existing release assets.
153
+
- New releases start at revision `0`
154
+
- Incremented by `1` for each rebuild
155
+
- Updates to Qt, Boost, or OpenSSL only update existing release assets
156
+
- Updates to qBittorrent or Libtorrent create new releases
123
157
124
-
Revisions values are incremented in the `dependency-version.json` of the release. All new releases start at a revision of `0` and increment by `1` per revised build.
There are times when the revision counts may differ between `v2.0` and `v1.2` builds as the `dependency-version.json` is unique to the release but has some shared values that won't change. In this case you need to track them as independent values unique to their release.
166
+
For independent tracking of v1.2 and v2.0 revisions:
137
167
138
-
To do this you start by getting the current release version value first, for example, getting the `v1.2` prerelease revision value.
Now you have tracked the current revision of the latest release of the libtorrent v1.2 binary.
180
+
## 📊 Dependency Tracking
151
181
152
-
## Dependency json
182
+
Each release includes a `dependency-version.json` file that provides version information shared across latest and pre-releases. This helps overcome API limitations for consistent access to version data.
153
183
154
-
From `release-4.4.5` each release contains a `dependency-version.json` file that provide some key version information for that is shared across the latest release and the twinned pre release. This helps to overcome some limitations of the API for consistently and directly accessing this information.
@@ -174,26 +202,22 @@ Will output a result like this:
174
202
}
175
203
```
176
204
177
-
As demonstrated above by using the latest release URL we can construct the tag of the twinned pre release and therefore the asset URL with no margin for error.
178
-
179
205
> [!IMPORTANT]
180
-
> From the release of qBittorrent v5 configurebased builds will be unsupported and we will only be able to use cmake to build qBittorrent v5 onwards. All releases from that point on will drop Qt5 builds as at this point cmake,Qt6 and v5 should be the default and preferred build combination with Qt5 being a legacy dependency.
206
+
> Starting with qBittorrent v5, configure-based builds will be unsupported. Only CMake builds will be available, with Qt6 as the default. Qt5 builds will be considered legacy and eventually dropped.
181
207
182
-
## gh attestation verify
208
+
## 🛡️ Build Attestation
183
209
184
-
Binaries built from the release of release `release-5.0.0_v2.0.10` and `release-5.0.0_v1.2.19` revision `1` use [actions/attest-build-provenance](https://github.com/actions/attest-build-provenance)
210
+
Binaries built from `release-5.0.0_v2.0.10` and `release-5.0.0_v1.2.19` revision `1`onwards use [actions/attest-build-provenance](https://github.com/actions/attest-build-provenance) for cryptographic verification.
185
211
186
-
Verify the integrity and provenance of an artifact using its associated cryptographically signed attestations.
0 commit comments