QT 5.12 introduced a regression, where a QT program wouldn't show its
tray icon, if there was no tray bar during program startup. (QTBUG-73459)
QT 5.12 introduced a regression, where qtwebengine applications would
freeze in some wayland compositors if a surface from the instance was not
visible (for example having a qutebrowser window on another workspace in
sway would freeze all qutebrowser windows).
Both got fixed already in Qt 5.12.4, but according to #57042 and its
sibling issues/PRs it doesn't seem to get fixed in near future for
nixpkgs.
Some executables are built as PIEs (e.g. keepassxc) and are technically
isELFDyn, not isELFExec. Without this change those executables will not
be wrapped.
GCC 8 introduced a new type of warning `-Wclass-memaccess` which
is included in `-Wall`. This warnings spits out *a million* of warnings
like the following:
```
[...]
/build/source/Source/WTF/wtf/Vector.h:128:15: warning: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'class WTF::RefPtr<WebCore::TransformOperation>' with no trivial copy-assignment; use copy-assignment or copy-initialization instead [-Wclass-memaccess]
memcpy(dst, src, reinterpret_cast<const char*>(srcEnd) - reinterpret_cast<const char*>(src));
[...]
``
Logs demonstrating the issue:
https://hydra.nixos.org/build/100205478/nixlog/1
While I don't think disabling warnings is the best way to deal with this,
there is alrady precedent for this package and I don't feel confident enough
to either patch or bump this package.
Please view this as a low-friction sub-optimal suggestion in case nobody else
has a better fix.
There ver very many conflicts, basically all due to
name -> pname+version. Fortunately, almost everything was auto-resolved
by kdiff3, and for now I just fixed up a couple evaluation problems,
as verified by the tarball job. There might be some fallback to these
conflicts, but I believe it should be minimal.
Hydra nixpkgs: ?compare=1538299
unfortunately, some private headers making the logging hard to handle.
Specifically, os/activity.h that is included does not match what Qt5
is expected. This removes the activity logging (while keeping the
other logging methods) on macOS.
Fixes#63528
The previous code using substituteInPlace was broken for both 5.9 and
5.11 (latter was broken after a minor release bump). Using patches
should make things fail loudly and prevent modules/qtwebengine.nix from
being littered with version checks.
The patch for 5.12 is only tested to apply.
This introduces usingAnnulenWebkitFork variable. Using version
check for qtbase.version is misleading because annulen's fork is not
tied to a specific qt5 release.
The impure library was introduced in
775531c1e3 ('qt58: extend darwin compatibility')
cmake-based build can use a non-apple ICU if -DMACOS_USE_SYSTEM_ICU=OFF
is set.
QtWebEngine's build system is setup to perform certain platform checks
(see mkspecs/features/platform.prf). But a failed check will not cause
configuration phase to fail, but instead it configures no build targets.
So in such case the build will successfully perform build and install
phases. An empty output directories will are produced and the build
succeeds.
This patches qtwebengine qmake files to properly fail during
configuration phase.
This doesn't touch qt56 as it doesn't have this mechanism.
Comments on conflicts:
- llvm: d6f401e1 vs. 469ecc70 - docs for 6 and 7 say the default is
to build all targets, so we should be fine
- some pypi hashes: they were equivalent, just base16 vs. base32
This adds the "missing" qtvirtualkeyboard module of qt56. I just add
this so I can apply (& test) the patches for a CVE in the next commit.
This might seem strange but in case anyone decided to add / use this in
the future we are on the safe(r) side.
In Qt-5.12, the order of the dependency between these two packages
flipped.
A symptom of the problem is an error like, `module
"QtQuick.XmlListModel" is not installed`.
The upstream changes that this reflects are in qtxmlpatterns
<8c6e24329e>
and qtdeclarative <0477a057fd>
This package contains several CMake files used for setting up its
provided tools for use in other projects build with CMake.
While packaging *ktouch* I found out that the ${_qt5Core_install_prefix}
variable doesn't expand at all, rendering the path to the `qmlcachegen`
binary useless. As a fix, the command itself is used instead of the path
to the binary.
Undefined symbols for architecture x86_64:
"_OBJC_CLASS_$_NSData", referenced from:
objc-class-ref in qmacfunctions.o
"_OBJC_CLASS_$_NSMutableArray", referenced from:
objc-class-ref in qmactoolbar.o
objc-class-ref in qmactoolbardelegate.o
ld: symbol(s) not found for architecture x86_64
Why is qtmultimedia only needed on Darwin? Why does it only fix 5.9, not
5.11? These things I do not know. What I do know is that, for some
reason, this makes qt59.qtwebkit build on Darwin.
I think the reason it hasn't also fixed 5.11 might be something to do
with the version of qtmultimedia, but I don't know enough about Qt or
cmake to figure it out. The error when trying to build qt511.qtwebkit
(with or without these changes) is:
CMake Error at Source/cmake/OptionsQt.cmake:739 (find_package):
Could not find a package configuration file provided by "Qt5Multimedia"
(requested version 5.2.0) with any of the following names:
Qt5MultimediaConfig.cmake
qt5multimedia-config.cmake
Add the installation prefix of "Qt5Multimedia" to CMAKE_PREFIX_PATH or set
"Qt5Multimedia_DIR" to a directory containing one of the above files. If
"Qt5Multimedia" provides a separate development package or SDK, be sure it
has been installed.
Call Stack (most recent call first):
Source/cmake/WebKitCommon.cmake:50 (include)
CMakeLists.txt:137 (include)
-- Configuring incomplete, errors occurred!
See also "/tmp/nix-build-qtwebkit-5.212-alpha-01-26-2018.drv-0/source/build/CMakeFiles/CMakeOutput.log".
See also "/tmp/nix-build-qtwebkit-5.212-alpha-01-26-2018.drv-0/source/build/CMakeFiles/CMakeError.log".
b785d4813e introduced breakage in Qt
modules for 5.6 and 5.9, especially visible is Qt Webkit.
This was manifested by having a non-sensical build log where it is using
the top-level `src` attribute as source instead of Qt Webkit's own
source.
Were it not for the `src` top-level attribute (which is a legit
package), the error would have been made obvious by passing `null` to
`src`.
This partily reverts newly introduced way `src` can be passed to a
qtModule, instead relying on extending the `srcs` attrset.
For ZHF #45960
On aarch64, linking against the vendored ffmpeg fails. Including ffmpeg
as a dependency and passing -system-ffmpeg to qmake fixes this.
Slightly odd conditional in qmakeFlags to avoid altering the list on
non-arm platforms, so that the change doesn't trigger an unneccessary
rebuild.
We use MACOSX_DEPLOYMENT_TARGET=10.10 in nixpkgs and some darwin
packages like CoreFoundation are based on the 10.10 sources from
opensource.apple.com.
This is the first time since 5.9 that we also update `qtwebkit`.
`qtwebkit` is not maintained by Qt anymore and thus, we switch to the
community port as for example arch has done. To prevent pulling in
single patches, we just stick to the latest git version.
This commit was too aggressive in adding configure flags. Only qtbsea
needs the -no-framework flag to work correctly. Qmake will handle
everything else for us.
Before this change:
$ readelf --notes /nix/store/zf5yja02g8n8dzgs25pqfd8w3myfzgzc-qtbase-5.10.1/lib/libQt5Core.so
Displaying notes found at file offset 0x004a7778 with length 0x00000020:
Owner Data size Description
GNU 0x00000010 NT_GNU_ABI_TAG (ABI version tag)
OS: Linux, ABI: 3.17.0
After:
$ readelf --notes /nix/store/sg1s9hdw0b7p6h0dwg09g4lxy1acq7y6-qtbase-5.10.1/lib/libQt5Core.so
Displaying notes found at file offset 0x004a7dcc with length 0x00000020:
Owner Data size Description
GNU 0x00000010 NT_GNU_ABI_TAG (ABI version tag)
OS: Linux, ABI: 2.6.28
-----------
The above paths were before rebasing the commit onto staging,
and it'd probably be good to have someone confirm the same happens
when built on a hydra builder or other non-dtzWill machine :).
[dezgeg: added comments]
We prefer to have $out/include & $out/lib installed so that things
like multiple outputs can work. There is no way to do this in Qt
currently without also disabling the ‘framework’ install. Not sure if
this will break anything but it will fix issues we run into on some
projects like python2.7-pyside:
Linux: https://hydra.nixos.org/build/73219181
macOS: https://hydra.nixos.org/build/73059550
Hopefully this gives us consistency between the two.
Fixes#39334
and Fixes#36729
Also, Fixes#36932 (hopefully it's still building)
(This might be able to be able to be cherry-picked to 18.03 but be
careful - chromium is extremely touchy. Probably best to wait for it
to be built successfully on Hydra a few times.)
