Reference fixed ebuild, with workaround for qt5 [1]. [1] https://github.com/okias/ixit/tree/master/net-analyzer/wireshark Reproducible: Always Steps to Reproduce: 1. install qtcore:5 and qtgui:5 2. emerge -v wireshark 3. notice, that wireshark detect qt 5.x.y Actual Results: Wireshark use MOC from /usr/bin/moc and UIC from /usr/bin/uic, which refers to 4.8.x version. This behaviour end with compilation fail, because from .ui files is code generated by Qt:4 instead detected Qt:5 Expected Results: Wireshark should USE qt4 and qt5. In case QT5 use, for this moment I avoided fail by patching configure.ac and replacing path (hardcoding to qt5) Next, I'd like to propose dropping +gtk3 in favor gtk3, as wireshark developers start moving to Qt5 [2]. As replacement, I'd like to discuss +qt4 (until qt5 will be unmasked) [2] https://blog.wireshark.org/2013/10/switching-to-qt/
Created attachment 361356 [details, diff] wireshark-1.11.0.patch
Why would we support dependencies from overlays.
*** Bug 489614 has been marked as a duplicate of this bug. ***
*** Bug 490430 has been marked as a duplicate of this bug. ***
Could, for the time being, the Qt5 detection of wireshark be patched out?
(In reply to Dennis Schridde from comment #5) > Could, for the time being, the Qt5 detection of wireshark be patched out? That detection is going to fail anyway because, apparently, we're not Red Hat. The 1.11.3 ebuild has a sed script in src_prepare() for that: sed -i -e 's|Qt5||g' acinclude.m4 || die since I happened to be able to test the current state of Qt 5 through the [qt] overlay. The older branches do not support Qt 5 at all, even if we had a Red Hat like setup.
*** Bug 513476 has been marked as a duplicate of this bug. ***
Thanks for reminding me I already filled bug. It's been so long I forgot and not sure why bugzilla didn't find me this when I issued search "wireshark qt5" So, anyway I keeping version with working qt5 support in ::ixit overlay [1] feel free to improve, contribute and update. [1] https://github.com/okias/ixit/tree/master/net-analyzer/wireshark
(In reply to David Heidelberger (okias) from comment #8) > So, anyway I keeping version with working qt5 support in ::ixit overlay [1] Please _attach_ anything you want to contribute (and don't merely point to external resources), preferably a diff against an existing ebuild.
> Please _attach_ anything you want to contribute (and don't merely point to > external resources), preferably a diff against an existing ebuild. I'd like to improve my workflow to help you more guys, but at this moment it has few serious issues like * pasting diffs into bugzilla isn't much productive as comment, also copypaste is not much friendly * uploading it as file requires me to save diff into file and upload * wont allow users (and me) to be able test (and use in this case) changes out-of-box These days I work with things like git and gerrit, which make this work much more effective, but seems you guys didn't adapted to it yet. External resource as my overlay will persist per time (as long I use Gentoo) and if that time passes, there will be always git history. I though about improvement in way, that I could import original source from portage, commit it and then made change on it, which could be more nicer to see what changed. I'll try do that next time.
(In reply to David Heidelberger (okias) from comment #10) > I'd like to improve my workflow to help you more guys, but at this moment it Please stay on topic. Your personal workflow preferences obviously collide with the way this project does things and you can do nothing about that right now.
Qt5 is in tree at this moment.
(In reply to David Heidelberger (okias) from comment #12) > Qt5 is in tree at this moment. It's been there for a while, but I still don't see eclass support to conveniently find /usr/lib64/qt5/bin/moc and other needed tools and the build system still assumes it should be able to find something like uic-4 and moc-4 or /else/ it will assume Qt 5 is used. Quoting configure.ac: # Annoyingly, at least on Fedora 16, uic and moc are named XXX-qt4 # rather than just XXX, perhaps to allow Qt 3 and Qt 4 tools to be # installed; if they're still doing that in current Fedora releases, # perhaps there will also be XXX-qt5 when they pick up Qt 5. Annoyingly, the configure logic excludes perhaps every other distro. We might start to fix this by perhaps setting the UIC and MOC variables or by fixing all of that failed logic with a more elaborate "-gentoo.patch".
Created attachment 387038 [details, diff] 488640-wireshark-1.99.0-qt5.patch This fixes one problem, which is that the build system uses the wrong moc/uic. The major problem it does not fix is that with both Qt4 and Qt5 installed, the build system will prefer Qt5. Currently the configure script does not handle Qt the way it does GTK+ 2/3. Introducing a --with-qt[45] switch is probably the way to go, and would involve patching both acinclude.m4 and configure.ac.
Please try with 1.99.0-r1. It should properly enable/disable Qt4/Qt5 support.
*wireshark-1.12.1-r1 (06 Nov 2014) 06 Nov 2014; Jeroen Roovers <jer@gentoo.org> +wireshark-1.12.1-r1.ebuild: Add Qt 5 support to the stable branch (bug #488640).
(In reply to Jeroen Roovers from comment #13) > (In reply to David Heidelberger (okias) from comment #12) > > Qt5 is in tree at this moment. > > It's been there for a while, but I still don't see eclass support to > conveniently find /usr/lib64/qt5/bin/moc and other needed tools and the > build system still assumes it should be able to find something like uic-4 > and moc-4 or /else/ it will assume Qt 5 is used. Quoting configure.ac: Re-opening, as we now have such eclass support. Please use qt4_get_bindir and qt5_get_bindir from qmake-utils.eclass. This is especially important for Qt4, as the locations have changed in 4.8.6, to allow parallel installation with Qt5, and /usr/bin/moc (& friends) can now point to the Qt5 version, if that's how the user has configured it with qtchooser.
Fixed again.
