qtModule was defined outside of addPackages, which caused it to use a self
variable that isn't affected by updates using overrideScope. This caused
overrides to qtbase to be incompletely applied. I also entirely removed the
outer self variable to prevent it from being accidently used again.
Since NixOS 21.11 it seems as if QT uses Wayland if possible[1].
However, my `pinentry-qt` flavor stopped floating because it's now
running in Wayland-mode rather than in XWayland mode where this seems to
be fine.
I wanted to add a rule to my `sway(1)`-config for that, but realized
that `pinentry` is missing an `app_id` to match:
$ swaymsg -t get_tree | jq '.nodes[2].nodes[1].nodes[1].nodes[1].app_id'
""
This is because `QWaylandWindow::initWindow()` uses the application's
`baseName` to determine the app window. Unfortunately the `baseName`
drops all chars of the filename after the first dot[2]. This means that
every wrapped Nix package (i.e. `pkgs.foo` with `$out/bin/.foo-wrapped`)
will have an empty-string as baseName because the first character of the
filename is a dot. Since we're using the `wrapQtAppsHook` quite
excessively, a lot of programs are affected by this.
In order to work around this, I implemented a small patch for
`qtwayland` that strips away the `nixpkgs`-specific `.(name)-wrapped` of
a filename if needed and then sets the `app_id` to the expected
`baseName`. This is useful to make e.g. `sway`-configs with
`for_window`[3]-expressions from other distros compatible.
With this change, the `app_id` is set as I'd expect it:
$ swaymsg -t get_tree | jq '.nodes[2].nodes[1].nodes[1].nodes[1].app_id'
"pinentry-qt"
Even though we'll need the patch to get e.g. `foo` from `.foo-wrapped`,
I decided to file a bug-report against upstream[4].
[1] https://nixos.org/manual/nixos/stable/release-notes.html#sec-release-21.11
[2] https://doc.qt.io/qt-5/qfileinfo.html#baseName
[3] https://man.archlinux.org/man/sway.5.en
[4] https://bugreports.qt.io/browse/QTBUG-99137
Qt Base is built with LLVM 5 on Darwin. LLVM 11 causes problems for
WebEngine because of the "version" includes in libc++abi. LLVM 7 would
work but since parts are built with LLVM 5 anyway it seemed like a more
straightforward option.
Make Qt applications work on macOS Big Sur even if they're built with
an older version of the macOS SDK (<10.14 - we're currently using
10.12). This issue is fixed in 5.12.11, but it requires macOS SDK
10.13 to build. See https://bugreports.qt.io/browse/QTBUG-87014 for
more info.
Qt 5.15.3 does not have an official open source release, but the KDE team
maintains a collection of patches (pulled from Qt upstream) that they expect us
to carry.
Without this patch, a MariaDB upgrade to 10.6.3 will break Qt's MySQL
support, as it was using version-based feature flags instead of
functional tests.
This breaks the conversion of QDateTime values in queries, resulting in
the breakage of e.g. Akonadi.
Co-authored-by: Sandro <sandro.jaeckel@gmail.com>
As it is currently it's almost impossible to accomplish something like:
```nix
...
(qt5.callPackage (
{ qtModule, qtbase, qtdeclarative }:
qtModule {
pname = "qt3d";
qtInputs = [ qtbase qtdeclarative ];
outputs = [ "out" "dev" "bin" ];
}
) { })
...
```
because all the required variables such as qtModule are internal-only.
By exposing these it's easier for external projects not to be bound
exactly by the module definitions explicitly listed in nixpkgs.
I hope this will improve the situation on aarch64-linux.
I don't think it could make anything worse.
Recent staging-next timeouts:
https://hydra.nixos.org/build/141551270https://hydra.nixos.org/build/141547098
For now let's not touch meta.timeout, as there's less consensus and the
setting seems less reliable in practice, too.
This hack reduces the source derivation size from 3.7G to 450M by
removing the src/3rparty submodule .git directory and compressing
the whole directory. This is needed to avoid the 2G limit on hydra.
Without a number of important Qt libraries (all of those with a "dev"
derivation) are not included in the bundled package, and qmake can't
find them.
Fixes#110199
The default 10h timeout caused the cancellation of builds on
aarch64-linux builders.
Perhaps counterintuitively, this wastes resources because it
requires a restart, but never completes.
https://hydra.nixos.org/build/136917190
