qt@5 5.15.5

[MehdiChinoune]

• Have you followed the guidelines for contributing?
• Have you ensured that your commits follow the commit style guide?
• Have you checked that there aren't other open pull requests for the same formula update/change?
• Have you built your formula locally with brew install --build-from-source <formula>, where <formula> is the name of the formula you're submitting?
• Is your test running fine brew test <formula>, where <formula> is the name of the formula you're submitting?
• Does your build pass brew audit --strict <formula> (after doing brew install --build-from-source <formula>)? If this is a new formula, does it pass brew audit --new <formula>?

---

[danielnachun]

A few things to think about for Qt5:

1. One thing we need to check here is if we have to disable QtWebEngine on Monterey. I think it still requires Python 2 to build and that is no longer available in Monterey. There are actually patches from Arch Linux for Python 3 support: https://github.com/archlinux/svntogit-packages/blob/packages/qt5-webengine/trunk/qt5-webengine-chromium-python3.patch, https://github.com/archlinux/svntogit-packages/blob/packages/qt5-webengine/trunk/qt5-webengine-python3.patch which I am thinking about upstreaming if someone isn't already working on that.

2. It also seems like Apple Silicon may now be supported for QtWebEngine as well: https://code.qt.io/cgit/qt/qtwebengine.git/commit/?h=5.15.10&id=d6512f48b86ccce1ce04784791576034acf641de. That seems like something we could try at least for Apple Silicon on Big Sur.

3. A user reported that the location module is not being built Project ERROR: Unknown module(s) in QT: location #102555. This is something I think we really should try to fix, as it hopefully does not require patching.

4. There is also an outstanding issue with Cellar references on Linux: qt@5: qtwebengine 5.15.9 #98765 (comment). This seems to arise because the pkg-config files for a lot of Qt5 dependencies return the full Cellar path rather than the opt dir. As discussed in that thread, the likely solution to replace Cellar references with opt dirs for Cellars outside of the current formula. This would ideally be fixed in brew as I think that manually fixing it here would take a huge amount of code.

[danielnachun]

We can see on Intel Monterey QtWebEngine is now skipped due to a lack of Python 3:

2022-06-10T13:19:44.5656230Z WARNING: Python version 2 (2.7.5 or later) is required to build QtWebEngine.
2022-06-10T13:19:44.5656250Z 
2022-06-10T13:19:44.5656600Z WARNING: Python version 2 (2.7.5 or later) is required to build QtPdf.
2022-06-10T13:19:44.5656620Z 
2022-06-10T13:19:44.5656880Z WARNING: QtWebEngine will not be built.
2022-06-10T13:19:44.5656910Z 
2022-06-10T13:19:44.5657200Z WARNING: QtPdf will not be built.

It looks like the patches I took from Arch Linux are working for building QtWebEngine with Python 3, at least on local testing with Linux. I did discover that QtWebEngine for Qt5 needs libxml2 to be build with icu support, which I am going to handle in a separate PR. I'm also encountering a failure at the end of the build due to a bug in binutils 2.37 that I think will be fixed in 2.38. We are are nearly ready to ship binutils so this latter issue will be handled shortly.

In order to get a full run in of trying to build QtWebEngine on all platforms, I will need to temporarily commit the changes to update libxml2 and binutils. I will disable dependent testing during that run to avoid having to test the libxml2 and binutils dependents. In the interim, I'd like to ask that once we finish the current CI run here that we not do any more runs until I've had a chance to finish local testing and push all the necessary commits to try to build QtWebEngine. We know in the current state of the formula that it's not going to build on any platform except Catalina and Intel Big Sur. I also suspect that Intel Monterey failure may be tied to it no longer building QtWebEngine, but I'm not sure yet.

[chenrui333]

only failed on 12

[danielnachun]

I've now gotten QtWebEngine to build on Linux and Monterey using the Python 3 patches I've taken from Arch Linux and added to formula-patches. As I had suspected, the Monterey failure seems to happen because QtWebEngine was no longer being built because it needed Python 2 and in my local test after patching in Python 3 support the Monterey build now succeeds.

I'm going to push a commit with what I believe are the necessary commits for QtWebEngine to now build on all platforms. It turns out the commits to enable Apple Silicon support were already added to 5.15.10, so we just have to enable it in the formula. Once we have a successful CI run, 3 things will need to happen before we can ship this:

1. Upstream the Python 3 patches (and two other much smaller unrelated patches) and add the relevant Qt Code Review links in comments above each patch.
2. Open a pull request to enable ICU support in libxml2. This is necessary because the bundled copy of libxml2 shipped with Chromium doesn't build on Linux and we should be using the system libxml2. Arch Linux at least builds libxml2 with ICU support and I'm going to check if other distros are doing the same.
3. Ship binutils: Build using glibc@2.13 on Linux #92329 with binutils updated to 2.38 - QtWebEngine fails to build because of bug in binutils 2.37 that is fixed 2.38 (I've confirmed this in local testing).

In order to test this efficiently, I have temporarily disabled dependent testing as I don't want test-bot to try to test all the dependents of libxml2 and binutils given that these changes will be handled in separate PRs. The purpose of this next CI run is just to make sure everything will work correctly once those changes are made, after which I will rebase this PR and re-enable dependent testing.

Thanks everyone for your patience - this is a complex PR but it should make it a lot easier for us to maintain qt@5 while packages transition from Qt 5 to Qt 6.

[Bo98]

Should also update pyside@2 here too, enabling WebEngineWidgets in the test there too.

Ship #92329 with binutils updated to 2.38 - QtWebEngine fails to build because of bug in binutils 2.37 that is fixed 2.38 (I've confirmed this in local testing).

If that's still a while away, I can do a build for 2.38 on Wheezy like I did for the zlib security update.

[danielnachun]

Ship #92329 with binutils updated to 2.38 - QtWebEngine fails to build because of bug in binutils 2.37 that is fixed 2.38 (I've confirmed this in local testing).

If that's still a while away, I can do a build for 2.38 on Wheezy like I did for the zlib security update.

Let's get 2.38 built on on Wheezy for now so it doesn't have to block this. I'm going to push commits to the PR to build binutils with glibc@2.13 to move that along but I'll still need feedback on whether my approach for splitting out gold from binutils is acceptable and that could take a bit.

[danielnachun]

Should also update pyside@2 here too, enabling WebEngineWidgets in the test there too.

The only issue we'll have with this is that I've had no luck building pyside@2 on Linux, and I don't want to get bogged down trying to fix that here. Ironically it's been substantially easier (albeit very tedious) to build Chromium from source for QtWebEngine twice (I also had to figure this out for Qt 6.3.0) than it has been to build either pyside or pyside@2. As we know all too well, Python packaging leaves a lot to be desired, especially when native code gets involved.

I was able to locally test enabling QtWebEngine in pyqt@5 and that worked with no issues so we could fold that into this PR as well. But for pyside@2 I think we'll have to be okay with not fixing the build on Linux for now if we decide to update it here, unless the fix is obvious.

[Bo98]

The only issue we'll have with this is that I've had no luck building pyside@2 on Linux, and I don't want to get bogged down trying to fix that here.

It doesn't need to? Any build failure will be a warning if there's no existing bottle - not an error.

[Bo98]

Ship #92329 with binutils updated to 2.38 - QtWebEngine fails to build because of bug in binutils 2.37 that is fixed 2.38 (I've confirmed this in local testing).

If that's still a while away, I can do a build for 2.38 on Wheezy like I did for the zlib security update.

Let's get 2.38 built on on Wheezy for now so it doesn't have to block this. I'm going to push commits to the PR to build binutils with glibc@2.13 to move that along but I'll still need feedback on whether my approach for splitting out gold from binutils is acceptable and that could take a bit.

Ok I'll get that done later today.

[danielnachun]

The only issue we'll have with this is that I've had no luck building pyside@2 on Linux, and I don't want to get bogged down trying to fix that here.

It doesn't need to? Any build failure will be a warning if there's no existing bottle - not an error.

Ah right I keep forgetting we just get a warning. We can just ignore it for now and deal with the Linux fix later.

[danielnachun]

Ship #92329 with binutils updated to 2.38 - QtWebEngine fails to build because of bug in binutils 2.37 that is fixed 2.38 (I've confirmed this in local testing).

If that's still a while away, I can do a build for 2.38 on Wheezy like I did for the zlib security update.

Let's get 2.38 built on on Wheezy for now so it doesn't have to block this. I'm going to push commits to the PR to build binutils with glibc@2.13 to move that along but I'll still need feedback on whether my approach for splitting out gold from binutils is acceptable and that could take a bit.

Ok I'll get that done later today.

One thing to watch out for - if you get a failure because it can't find makeinfo, rather than adding texinfo as a build time dependency, you can just pass MAKEINFO=true as I have done here to skip building the HTML documentation (I have no idea why it doesn't just skip this when makeinfo isn't found), though this should be Linux-only which I did not do in the commit here.

[danielnachun]

Now that we are using Python 3 in Qt5 on macOS, we've picked up some python@3.9/python@3.10 conflicts:

aqbanking
openmodelica
qca
synergy-core

For now I've added exceptions for these so we can pass the audit checks. We'll have to decide how to handle these conflicts later, though my guess is that they aren't going to be a problem.

[danielnachun]

Wow, Apple Silicon Monterey and Big Sur were a complete success! @Bo98 that was a great suggestion to test WebEngineWidgets on Apple Silicon in pyside@2 as it was guaranteed to fail if QtWebEngine wasn't built. Since it worked (as did pyqt@5, where I also enabled QtWebEngine), this means we'll be able to support QtWebEngine for all platforms in Qt5 like we do for Qt6.

[danielnachun]

Now that we are using Python 3 in Qt5 on macOS, we've picked up some python@3.9/python@3.10 conflicts:

aqbanking
openmodelica
qca
synergy-core

For now I've added exceptions for these so we can pass the audit checks. We'll have to decide how to handle these conflicts later, though my guess is that they aren't going to be a problem.

It looks like python@3.9 is only a build dependency for qt@5, and glib (which also pulls in python@3.9 as a dependency) is optional on macOS and could be made Linux-only like it was before. I think this would avoid the need for these audit exceptions, which in any event will go away when we're able to finish the python@3.10 migration.

[danielnachun]

I've upstreamed the 3 patches we are adding to QtWebEngine to Gerrit and they will be added in comments above the patch lines. When libxml2 PR is merged, I will rebase to update libxml2 and binutils, and add in the last few tweaks for what I hope is the final CI run:

1. Use python@3.10 as a build-time only dependency instead of python@3.9 as a run time dependency. If this still has a versioned dependency conflict, it will likely be because of glib, and that is a temporary issue being handled here libglib: split libraries from glib #103366.
2. Use brewed assimp so we don't have to use the bundled copy. This was previously failing on ARM so we had to disable assimp there, but the system copy should work fine as it's already bottled on ARM.

[danielnachun]

This is ready for the final CI run now that the libxml2 PR is merged. I decided to use glib as a dependency on macOS as well and just add the 4 formulae with conflicting versioned dependencies. It's become very clear that the glib conflict is spurious and can be ignored, and as I mentioned above once we split out the Python part from glib, we will not have these conflicts anyway.

[danielnachun]

assimp still doesn't work on ARM so I've gotten rid of that change and restarted

[danielnachun]

The failures now are:

• ARM Big Sur: clang is not found because of the weird way that gn finds paths for it on macOS. This is a known issue and we have a workaround for it in Qt6 I will backport here. I suspect this is actually due to a race condition that emerges on ARM because it is so fast, but we can avoid deparallelizing it by just fixing the path.
• Linux: shim references in pyside@2 - this must be specific to pyside@2 because I just bottled pyside on Linux and didn't run into this.

[danielnachun]

I pushed fixes for both of these so we can rerun this when a CI-long-timeout label is free.

[danielnachun]

One of the upstream commits we were using in 5.15.4 was included in 5.15.5 and is no longer needed.

[danielnachun]

The only failure we have here is a transient issue on 10.15 that is not related to this PR. There has been ample time for review here so I am going to publish the bottles now.

[BrewTestBot]

@danielnachun has triggered a merge.

[BrewTestBot]

⚠️ @danielnachun bottle publish failed.

bottle publish failed

[BrewTestBot]

@danielnachun has triggered a merge.