Qt6 PrintSupport records Cups::Cups as a third-party dependency
(qprint_p.h includes <cups/ppd.h>), so find_package(Qt6 PrintSupport)
runs FindCups at configure time and fails without the CUPS headers.
Build-time only, nothing is staged.
windows-build.yml:
- Remove the Qt5 build job (build-windows). Qt6 is now the sole
Windows track built in CI.
- publish-nightly-assets: only delete/replace .exe and .zip assets
tagged "qt6" on the nightly release. Assets without "qt6" in the
name (the last Qt5 build ever published) are left untouched and
stay downloadable indefinitely as a frozen legacy build.
- Release notes: drop the "Try Qt6 — soon the only track" notice,
add a line explaining the Qt5 (frozen) vs Qt6 (maintained) split.
windows-msi.yml:
- Matrix reduced to the single "qt6" entry (flavor string kept as
"qt6", not renamed, since it seeds the MSI ProductCode and a
rename would break upgrade detection for existing installs).
- Sign the Qt6 MSI via SignPath (previously Qt5-only). Guard is now
just the upstream-repo fork check; no per-flavor exclusion left.
- deploy-pages: also detect legacy (non-"qt6") release assets and
pass them to generate-page.py as LEGACY_INSTALLER_URL /
LEGACY_PORTABLE_URL / LEGACY_MSI_URL.
generate-page.py:
- Drop the old Qt5/Qt6 dual-track rendering; INSTALLER_URL /
PORTABLE_URL / MSI_URL now point at the Qt6 build directly.
- Add an optional "Windows — x86_64 — Qt5 (legacy, unmaintained)"
card, rendered only when LEGACY_* URLs are set, with a frozen/
no-longer-updated notice.
Before merging: manually trigger the current (pre-merge) "Windows
Build" + "Windows MSI" workflows once to publish an up-to-date,
signed Qt5 snapshot — that run becomes the frozen legacy reference,
since the Qt5 job won't exist to re-run afterwards.
No changes to QElectroTech.wxs (Qt5/Qt6-agnostic, only
QtPlatformArgs varies and is already handled at the CI level).
The Windows Qt5 build is going to be removed from CI/CD soon (Qt6/KF6
is becoming the sole supported track). Replace the 'experimental'
warning wording on the nightly download page and in the nightly
release body with a call to action inviting users to switch to Qt6
now and report issues, ahead of the Qt5 removal.
switch runtime/sdk to org.kde.Platform/org.kde.Sdk 6.10
migrate qelectrotech module from qmake to cmake buildsystem
add config-opts: QT_VERSION_MAJOR=6, BUILD_WITH_KF=ON, BUILD_KF=OFF,
PACKAGE_TESTS=OFF, BUILD_PUGIXML=OFF, QET_EXPORT_PROJECT_DB=ON
drop fix-the-installation-paths.patch (qmake-only, obsolete under cmake)
re-attach fix-appdata.patch, previously unreferenced in sources
document open verification points for Qt6 private headers and the
SQLite driver, which have no Flatpak build-depends equivalent
a) using a system provided KF6
b) downloading and compiling KF6
c) using the vendored-in re-creation of the functionality
The behaviour for both Qt5 and Qt6 is steered with the same two variables which were renamed to become version agnostic:
a) BUILD_WITH_KF=ON BUILD_KF=OFF
b) BUILD_WITH_KF=ON BUILD_KF=ON
c) BUILD_WITH_KF=OFF
The version is automatically derived from the chosen Qt major version.
The MSI registers both shortcuts with the arguments QET needs to find its
data ("Point directly to qelectrotech.exe with all required arguments"),
but the QElectroTech.Document\shell\open\command registry value was
written without them:
"[INSTALLDIR]bin\qelectrotech.exe" "%1"
Launching from the Start Menu therefore works, while double-clicking a
.qet file does not: Explorer sets the working directory to the document's
folder, and the compiled-in data paths are relative, so nothing is found
there. The most visible symptom is the interface always coming up in
French, because no translation loads and the source strings are French.
Give the file association the same arguments as the shortcuts.
Reported by mr-rfh in #554, who diagnosed it and arrived at exactly this
registry value by hand.
Qt 5.15.x added libxcb-cursor0 as a hard runtime dependency of the xcb
platform plugin (libqxcb.so). The kf5-5-110-qt-5-15-11-core22 content
snap does not bundle this library, so when the snap runs on an Ubuntu 24.04
host the dlopen() of the plugin fails with:
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in ""
even though it was found.
Staging libxcb-cursor0 from the Ubuntu 22.04 archive satisfies the
dependency without changing the snap base, Qt version, or any other
dependency. No ABI mismatch: the plugin and the staged library are
both built against the core22 (22.04) ABI.
Fixes issue #373.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Without a source-tag or source-commit, snapcraft pulls the latest
HEAD of qet_tb_generator-plugin on every build. This makes builds
non-reproducible and risks breakage whenever the upstream repo changes.
Pin to the only published release tag (v1.31, commit d6ee3cf) so
the snap always builds against a known-good version of the plugin.
Closes#202
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
+ AllowSameVersionUpgrades="yes" to <MajorUpgrade>
windows-msi.yml — in the ‘Extract version’ step, calculate a unique GUID
based on the commit’s SHA, then pass -d ‘ProductCode=$productGuid’ to the WIX build
This ensures that each build will have a different ProductCode → MajorUpgrade will always be triggered
- Use SetProperty + WixQuietExec two-step pattern to pass runtime
INSTALLDIR to a deferred CustomAction (fixes WIX1077 and WIX0400)
- Add WixToolset.Util.wixext/7.0.0 extension (required for WixQuietExec)
- Fix condition syntax: collapse multi-line conditions to single line
- Add -ext WixToolset.Util.wixext to wix build command in windows-msi.yml
**`build-aux/windows/QElectroTech.wxs`**
- Desktop and Start Menu shortcuts now point directly to `bin\qelectrotech.exe` with all required arguments (`--common-elements-dir`, `--common-tbt-dir`, `--lang-dir`, `-style windowsvista`) — no `.bat` wrapper needed
- Added a deferred `CustomAction` that runs after `InstallFiles` and recursively sets all files in `elements\` to read-only using an inline PowerShell command
**`.github/workflows/windows-msi.yml`**
- Replaced the step that created `Lancer QET.bat` with a step that removes it from the artifact before the WiX build, so it is not embedded in the MSI
- The `.bat` file remains untouched in the ZIP portable build (managed by `windows-build.yml`)
- No console window flashing when launching QElectroTech from the MSI shortcuts
- The `elements\` directory is properly set to read-only after installation, as required
- Cleaner MSI package — no `.bat` file shipped to end users installing via MSI
Laurent Trinques