qt5 5.5.1 breaks PyQt5 (QtDBus) #45114
Comments
Yes, this is quite likely because of the mentioned commit. Can you rebuild I'll also have a look. Maybe that's not the only formula that needs a revision bump. |
The build seems to fail:
|
I wonder why the CI didn't break on testing PyQt5 for the Qt5 bump in this case 😕. |
It only runs the tests of dependent formulae to check that nothing breaks, right? And it does so by using whatever is in a bottle of a formula. For this specific case, it only tries to Seems like Possible solutions to the breakage:
I'd favor the first solution if there's someone willing to deal with upstream. (Not me, I'm just not a Python guy.) I'd gladly forward all the knowledge I gathered while debugging this. Otherwise, let's just revert the offending commit. Opinions? |
@The-Compiler Thanks for reporting this and for attempting to build from source! If your main priority is to get back to a working setup, you could:
|
Building Qt with I notified upstream - judging from my past experience, the answer will probably be "fixed in tonight's snapshot" in a few hours 😉 Is there an easy way I can install from that branch with |
I just got an answer from Phil, the guy behind PyQt:
Seems like the proper fix is: --- PyQt-gpl-5.5/configure.py 2015-07-17 13:45:40.000000000 +0200
+++ PyQt-gpl-5.5.1-snapshot-13f9ece29d02/configure.py 2015-10-19 03:31:39.000000000 +0200
@@ -2478,9 +2504,25 @@
pro_lines.append('LIBS += %s' % libs)
if not target_config.static:
- # Make sure these frameworks are already loaded by the time the
- # libqcocoa.dylib plugin gets loaded.
- extra_lflags = 'QMAKE_LFLAGS += "-framework QtPrintSupport -framework QtDBus -framework QtWidgets"\n ' if mname == 'QtGui' else ''
+ # For Qt v5.5 and later, Make sure these frameworks are already loaded
+ # by the time the libqcocoa.dylib plugin gets loaded. This problem is
+ # due to be fixed in Qt v5.6.
+ extra_lflags = ''
+
+ if mname == 'QtGui':
+ # Note that this workaround is flawed because it looks at the PyQt
+ # configuration rather than the Qt configuration. It will fail if
+ # the user is building a PyQt without the QtDBus module against a
+ # Qt with the QtDBus library. However it will be fine for the
+ # common case where the PyQt configuration reflects the Qt
+ # configuration.
+ fwks = []
+ for m in ('QtPrintSupport', 'QtDBus', 'QtWidgets'):
+ if m in target_config.pyqt_modules:
+ fwks.append('-framework ' + m)
+
+ if len(fwks) != 0:
+ extra_lflags = 'QMAKE_LFLAGS += "%s"\n ' % ' '.join(fwks)
shared = '''
win32 { I haven't tested this yet, and there are loads of other changes to Patching the print("Patching PyQt formula...")
brew_path = subprocess.check_output(['brew', '--prefix']).strip()
pyqt_file = os.path.join(brew_path, 'Library', 'Formula', 'pyqt5.rb')
os.remove(pyqt_file)
urllib.urlretrieve(
'https://raw.githubusercontent.com/UniqMartin/homebrew/0f78553c1cfc26963ea0681374e50b378207f875/Library/Formula/pyqt5.rb',
pyqt_file) |
This seems to make most sense to me. |
My worry here is that if there's silent breakage the CI didn't pick up on there may well be elsewhere in similar situations. I'd be tempted to agree about reenabling |
@The-Compiler Thanks for contacting upstream! It's great to have a proper fix as quickly as this. The change you highlighted is the one we need and it applies cleanly, so I prepared a new branch for you to test: the branch, just the formula. Will create a PR once I have your confirmation that it works. @MikeMcQuaid @DomT4 Since we have a proper upstream fix, I strongly prefer that. We can still revert the @DomT4 I have a proposal about how the CI could detect those kinds of breakages automatically, though that won't be an immediate or short-term solution. I'll make sure to CC you once I've posted the proposal as a new issue. |
Travis is building here, let's see if this works: https://travis-ci.org/The-Compiler/qutebrowser/jobs/86205210 You didn't re-add the |
So yup, seems to work fine for me 👍 |
This wasn't intentional. I agree and will make sure to re-add these before submitting the PR. |
This is to circumvent Homebrew/legacy-homebrew#45114 The build takes a lot longer now, but at least it works.
Submitted PR #45145. Travis is already happy with it. 😉 |
Upstream fix for hard-coded dependencies in `PyQt-gpl-5.5.tar.gz`, among them `QtDBus`, that is no longer provided by a default `qt5` build in Homebrew. Extracted from `PyQt-gpl-5.5.1-snapshot-13f9ece29d02.tar.gz`. See also Homebrew/legacy-homebrew#45114.
Using PyQt5 or something else? |
Yep. It's a fontforge replacement
|
Ah, interesting! Looks like it's based off a Qt backend, which will be quite a departure from the land of Quartz. If you hit the problem seen in PyQt5 anywhere else let us know and we'll try and hunt that down as well. |
Since the Qt5 update to 5.5.1, it seems PyQt5 is broken.
When doing
import PyQt5.QtGui
, I get:I'd guess this is because of 0c6557f?
/cc @UniqMartin @MikeMcQuaid
The text was updated successfully, but these errors were encountered: