[Bug]: install-qt-official search fails — "Failed to find package information in installer output"

[paulmasri]

Bug description

install-qt-official with valid commercial credentials fails for Qt 6.8.5 and 6.8.6 on Linux x64 (GitHub Actions ubuntu-latest). The same workflow previously succeeded for 6.8.5 several months ago — the failure appeared without any changes on our side, after the Qt online installer was updated.

The installer runs search qt.qt6.686 but produces no parseable <availablepackages> XML output, causing commercial.py's gather_packages() to raise "Failed to find package information in installer output".

Likely cause: The Qt online installer binary is always fetched fresh (latest version — currently IFW 4.10.0). Since IFW 4.8.0 (May 2024), the search command defaults to searching aliases first, only falling back to packages if no alias matches (IFW CLI docs):

--type: Sets the type of the given arguments for commands supporting multiple argument types, like "search". By default aliases are searched first, and if no matching aliases are found, then packages are searched with the same search pattern.

It appears that with newer IFW versions, the fallback from alias search to package search no longer reliably produces the <availablepackages> XML that commercial.py expects.

A possible fix would be for aqtinstall to pass --type package to the installer's search command to bypass alias resolution. The relevant code is in commercial.py around gather_packages().

Related issues: #893 (same error, closed as environmental), #965 (search term type mismatch), #990 (PR for search term handling), #792 (IFW path changes)

Workaround: Fall back to open-source Qt 6.8.3 (the last non-commercial-only 6.8.x release) using the non-official installer path.

Expected behavior

The search qt.qt6.686 command should produce <availablepackages> XML output that aqtinstall can parse, leading to successful installation of Qt 6.8.6.

aqt and python version

aqtinstall(aqt) v3.3.0 on Python 3.12.13 [CPython GCC 13.3.0]

Operating System

Linux/Unix

Relevant log output

python3 -m aqt install-qt-official desktop linux_gcc_64 6.8.6 \
  --outputdir /home/runner/work/repo/repo/Qt/Qt --email *** --pw *** --modules qtmultimedia

INFO    : aqtinstall(aqt) v3.3.0 on Python 3.12.13 [CPython GCC 13.3.0]
INFO    : Downloading Qt installer to /home/runner/.local/share/aqt/tmp/qt-online-installer-linux-x64-online.run
INFO    : Redirected: qt.mirror.constant.com
INFO    : Running: ['/home/runner/.local/share/aqt/tmp/qt-online-installer-linux-x64-online.run',
          '--accept-licenses', '--accept-obligations', '--confirm-command', '--default-answer',
          '--email', '***', '--pw', '***', 'search', 'qt.qt6.686']
ERROR   : Installation failed: Failed to get package information: Failed to find package information in installer output
INFO    : Qt installation completed successfully
ERROR   : Error installing official installer: Failed to get package information: Failed to find package information in installer output
INFO    : Done
Error: Error: Failed to locate a Qt installation directory in /home/runner/work/repo/repo/Qt/Qt

[pzhlkj6612]

Hi. Can you please re-run your workflow and post the related content from "aqtinstall.log"? For console, the default log level is "INFO", while the "DEBUG" one will be saved in the log file, so the actual output of the "search" call goes there:

aqtinstall/aqt/commercial.py

Lines 168 to 171 in 75ea794

	else:
	# Log the actual output for debugging
	self.logger.debug(f"Installer output: {output_text}")
	raise RuntimeError("Failed to find package information in installer output")

That log file is written incrementally as each aqtinstall run, so you should move or remove it before the run.

Please redact email and password!

[pzhlkj6612]

Link to #986 due to the same log output in "INFO" level.

---

...
Error: Error: Failed to locate a Qt installation directory in /home/runner/work/repo/repo/Qt/Qt

Oh, you're using jurplel/install-qt-action. The log file should be in the default CWD.

$ find . -name 'aqtinstall.log'
./aqtinstall.log

[paulmasri]

Thanks @pzhlkj6612 — captured the DEBUG aqtinstall.log from the failing CI runner, and it identifies the root cause. It's environmental, but it also exposes a diagnosability gap in aqt that I think is worth fixing (details at the end).

Root cause: "Too many installations" on the Qt account

The installer logs in successfully and retrieves the license, but then the licensing service refuses with too_many_installation, so the search never runs and no <availablepackages> XML is ever produced:

2026-07-08 11:03:39,985 - aqt.commercial - INFO - commercial *** Running: ['/home/runner/.local/share/aqt/tmp/qt-online-installer-linux-x64-online.run', '--accept-licenses', '--accept-obligations', '--confirm-command', '--default-answer', '--email', '***', '--pw', '***', 'search', 'qt.qt6.686']
2026-07-08 11:03:42,702 - aqt.commercial - DEBUG - commercial *** Installer output: [0] Arguments: ...
[4] Found 0 cached items.
[920] Warning: No QtAccount credentials found. Please login via the maintenance tool of the SDK.
[1800] Login completed to Qt Account: "***"
[2508] License added:
    License id [***]
    License schema [Full Commercial]
    ...
[2515] Saving Qt Account settings to file: "/home/runner/.local/share/Qt/qtaccount.ini"
[2680] "<p><b style='color: rgb(255, 0, 0);'>Too many installations</b></p><p style='font-size:10pt; font-weight:400;'>Maximum number of Qt installation reached, please manage your installations via <a href='https://account.qt.io/s/active-installation-list' target='_blank'><b>Qt Account</b></a> or contact support via <a href='mailto:license-management@qt.io' target='_blank'><b>email</b></a></p>" [ "too_many_installation" ]
[2680] Warning: No valid license found.
2026-07-08 11:03:42,702 - aqt.main - ERROR - commercial *** Installation failed: Failed to get package information: Failed to find package information in installer output

This retroactively explains everything in the report:

• Why it "broke without any changes on our side": our CI caches the Qt directory keyed on the Qt version, so after the initial commercial install (Dec 2025 — which registered the one and only CI-runner entry on the account's installation list) every green run restored from cache without installing. Bumping the Qt version in early March changed the cache key and forced the first fresh install in three months — which was refused with too_many_installation. Identical secrets, aqt version, and installer version on both sides of that line; the account had simply reached its installation limit in the meantime.
• The failure timing: the CI error lands ~2.2 s after the installer launches — login + license check, then exit. An actual search takes minutes on a cold cache (it fetches ~3,800 metadata items first), so a fast exit like this always means the installer never got past licensing.

Confirmed: after removing stale devices from https://account.qt.io/s/active-installation-list, the same workflow's commercial install of 6.8.6 succeeded with no other changes. (The version-keyed cache means CI only consumes a new registration when the Qt version changes, so recurrence should be slow.)

Withdrawing the alias-search hypothesis from my original report

To rule it out properly, I downloaded the archived IFW 4.10.0 (current at the time of the report) from https://download.qt.io/archive/online_installers/4.10/ and ran aqt's exact command with a valid, registered account. The alias→package fallback works fine — search qt.qt6.686 reports "No matching package aliases found", falls back to package search, and emits the full <availablepackages> XML (both warm and cold cache). Same with 4.11.0. So --type package was never the issue; please disregard that part of the report.

Suggested refinement: surface the installer's failure reason

The reason this took months to diagnose: gather_packages() reports every no-XML outcome as

Failed to find package information in installer output

at INFO/ERROR level, which reads as a search/parsing problem — while the actual reason (Authentication failed, No valid license found, Too many installations, the cache corruption in #986, ...) is only visible at DEBUG level in aqtinstall.log, which CI users typically never see (and on ephemeral runners it's gone unless explicitly dumped).

Since the installer's warning/disclaimer lines are already captured in output_text at that point (commercial.py, the else branch around line 160), a small change would make this class of failure self-diagnosing, e.g.:

• extract lines matching Warning: (and the [ "..." ] disclaimer tags like too_many_installation) from output_text, and
• include them in the raised RuntimeError / log them at ERROR level, instead of only the generic message.

With that, the original CI log would have shown Too many installations ... please manage your installations via Qt Account directly, and this issue (and probably #986 and #893) would have been answerable at a glance.

Happy to open a PR for that if you'd take it. Otherwise, feel free to close this as environmental.

---

One unrelated footnote from reproducing this locally: install-qt-official currently can't run on macOS at all — the online_installers directory now ships a single qt-online-installer-macOS-universal.dmg, which get_qt_installers() maps to the key mac (no x64/arm64 in the filename), while get_os_arch() returns mac-arm64/mac-x64, so get_qt_installer_name() dies with KeyError: 'mac-arm64'. I'll file that separately.

[paulmasri]

A correction to my footnote above: the macOS KeyError: 'mac-arm64' is already fixed on master — #1015 (merged 28 Jun) registers the universal installer under both mac-x64 and mac-arm64 keys. It just isn't in a release yet (latest is v3.3.0), so nothing to file.