What is this?

Upstream gLabels 4 (glabels-qt) is cross-platform and builds fine on Windows, but the project does not currently ship Windows binaries — you are expected to install Visual Studio, Qt, CMake and a handful of libraries and build it yourself.

This repository does that for you, in public, on GitHub's own runners. Every release is produced by one workflow file from unmodified upstream sources, so you can read exactly how the binary you downloaded was made — and reproduce it yourself by forking this repo and pressing Run workflow.

Download

Grab the files from the latest release:

Requirements: 64-bit Windows 10 or 11. Nothing else — Qt and the C runtime are bundled.

Package managers

winget — ✅ live. Merged in winget-pkgs#406476 and published to the official index:

winget install ibsorn.gLabels

Chocolatey — submitted as glabels-qt, waiting in the moderation queue. Once approved, choco install glabels-qt will work.

Scoop — not eligible yet. The Extras bucket requires the latest stable version of a package, and gLabels 4 has no stable release. The manifest is written and ready in scoop/ for the day upstream tags 4.0.

Get-FileHash .\gLabels-3.99-master639-win64-setup.exe -Algorithm SHA256

What's inside

Every build runs the upstream unit tests plus a smoke test that renders a PDF from the packaged tree, so a release can only be published if the deployed binaries actually run.

Status

gLabels 4 is still under active development upstream — there is no final 4.0 release yet. What you get here are snapshots of the master branch, rebuilt weekly and whenever upstream changes are picked up. They are usable, but treat them as pre-release software and keep backups of your projects.

A published release is immutable: the weekly rebuild only publishes when upstream has actually moved (a new commit count means a new version and a new tag). It never overwrites the assets of a version that already exists, because a rebuild of the same commit is byte-different — MSVC and NSIS embed timestamps — and overwriting would change the SHA-256 that the winget and Chocolatey manifests pin.

Building it yourself

Fork this repository and use Actions → Build gLabels for Windows → Run workflow. You can point it at any upstream branch, tag or commit, and optionally have it publish a release in your own fork. Nothing besides a GitHub account is required.

Locally, follow the upstream Windows build instructions.

Note that the process is reproducible, not the bytes: MSVC and NSIS embed timestamps, so rebuilding the same commit gives you a working, equivalent binary with a different SHA-256. The published sums identify a specific release, they are not a build fingerprint.

Any local fixes needed to build a given upstream revision live in patches/ as plain git apply patches, each with a header explaining why it exists and what would make it removable. The packaging metadata (installer name, icons, file association) lives in packaging/. No gLabels source code is modified beyond those patches.

Bugs

• Something wrong with the installer, packaging, or a missing DLL → open an issue here.
• Something wrong with gLabels itself → report it upstream, where the people who can fix it are.

Credits and licence

gLabels is written by Jaye Evins and contributors. This repository contains no gLabels source code — only build automation — but the binaries it produces are gLabels and are distributed under the GNU General Public License v3 like the original. The corresponding source for every release is the upstream commit named in the release notes.

This is an unofficial community build and is not endorsed by or affiliated with the gLabels project.