Created attachment 461092 [details] full output of ldd /opt/teamspeak3-client/ts3client teamspeak client got an update to version 3.1.0.1 upstream. i managed to bump the version local. teamspeak client now needs qtwebengine libQt5WebEngineCore.so.5 => /usr/lib64/libQt5WebEngineCore.so.5 (0x00007f8a60352000) libQt5WebEngineWidgets.so.5 => /usr/lib64/libQt5WebEngineWidgets.so.5 (0x00007f8a6031a000) added "dev-qt/qtwebengine[widgets]" to RDEPEND. works for me.
Created attachment 461094 [details] my ebuild for version 3.1.0.1
Version 3.1.1.1 is available
version 3.1.2 is available - will attach working ebuild
Created attachment 467984 [details] working ebuild for teamspeak-client-bin-3.1.2
Created attachment 468310 [details] Update teamspeak-client-bin to version 3.1.3. This is a complete approach at the current 3.1.3 version. I went ahead and added proper dependencies upon all new libraries, unbundling them all. Also created a symlink to QtWebEngineProcess in case TeamSpeak does actually ever need it. Changes include pulling in qtgui with dbus and xcb support, qtwebengine with geolocation and widgets support, adding proper dependencies on qtwebchannel, bumping all Qt dependencies to version 5.6 at a minimum and adding a default-on system-openssl USE flag, that either deletes the bundled OpenSSL version or keeps it around. Disabling it manually would drop the dependency upon openssl-1.0.x, which allows users to upgrade to openssl-1.1 without being blocked by teamspeak-client-bin. Currently, we can leave system-openssl the default, though, as OpenSSL 1.1 is still hard-masked.
(In reply to Mihai Moldovan from comment #5) > Created attachment 468310 [details] > Update teamspeak-client-bin to version 3.1.3. > > This is a complete approach at the current 3.1.3 version. > > I went ahead and added proper dependencies upon all new libraries, > unbundling them all. Also created a symlink to QtWebEngineProcess in case > TeamSpeak does actually ever need it. > > Changes include pulling in qtgui with dbus and xcb support, qtwebengine with > geolocation and widgets support, adding proper dependencies on qtwebchannel, > bumping all Qt dependencies to version 5.6 at a minimum and adding a > default-on system-openssl USE flag, that either deletes the bundled OpenSSL > version or keeps it around. Disabling it manually would drop the dependency > upon openssl-1.0.x, which allows users to upgrade to openssl-1.1 without > being blocked by teamspeak-client-bin. Currently, we can leave > system-openssl the default, though, as OpenSSL 1.1 is still hard-masked. I get the following that seems to be due to the EAPI=6 when I try to merge this: * Messages for package media-sound/teamspeak-client-bin-3.1.3: * ERROR: media-sound/teamspeak-client-bin-3.1.3::local failed (prepare phase): * eapply_user (or default) must be called in src_prepare()! * * Call stack: * ebuild.sh, line 767: Called __ebuild_main 'prepare' * phase-functions.sh, line 1007: Called __dyn_prepare * phase-functions.sh, line 382: Called die * The specific snippet of code: * die "eapply_user (or default) must be called in src_prepare()!" * * If you need support, post the output of `emerge --info '=media-sound/teamspeak-client-bin-3.1.3::local'`, * the complete build log and the output of `emerge -pqv '=media-sound/teamspeak-client-bin-3.1.3::local'`. * The complete build log is located at '/var/tmp/portage/media-sound/teamspeak-client-bin-3.1.3/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/media-sound/teamspeak-client-bin-3.1.3/temp/environment'. * Working directory: '/var/tmp/portage/media-sound/teamspeak-client-bin-3.1.3/work' * S: '/var/tmp/portage/media-sound/teamspeak-client-bin-3.1.3/work' If I change it to EAPI="5" it seems to merge properly but the openssl and qt libraries aren't found when the command runs.
(In reply to Martin McCourt from comment #6) > (In reply to Mihai Moldovan from comment #5) > > Created attachment 468310 [details] > > Update teamspeak-client-bin to version 3.1.3. > > ... > I get the following that seems to be due to the EAPI=6 when I try to merge > this: > * Messages for package media-sound/teamspeak-client-bin-3.1.3: > > * ERROR: media-sound/teamspeak-client-bin-3.1.3::local failed (prepare > phase): > * eapply_user (or default) must be called in src_prepare()! ... > If I change it to EAPI="5" it seems to merge properly but the openssl and qt > libraries aren't found when the command runs. fixed by adding default to src_prepare() diff teamspeak-client-bin-3.1.3.ebuild.broken teamspeak-client-bin-3.1.3.ebuild 4c4 < EAPI="6" --- > EAPI=6 50a51 > default when using system-openssl teamspeak launches but i get: /opt/teamspeak3-client/ts3client: /usr/lib64/libcrypto.so.1.0.0: no version information available (required by /opt/teamspeak3-client/ts3client) /opt/teamspeak3-client/ts3client: /usr/lib64/libssl.so.1.0.0: no version information available (required by /opt/teamspeak3-client/ts3client) /opt/teamspeak3-client/ts3client: /usr/lib64/libssl.so.1.0.0: no version information available (required by /opt/teamspeak3-client/ts3client)
(In reply to kaersten.m from comment #7) > fixed by adding default to src_prepare() ACK, I missed calling default which handles PATCHES (unused by this ebuild, but still good to have around) and eapply_user, which is mandatory since EAPI 6. My package manager is not strict enough and doesn't bail out if eapply_user isn't being called (which is a bug, really.) Will update the attachment. > when using system-openssl teamspeak launches but i get: > /opt/teamspeak3-client/ts3client: /usr/lib64/libcrypto.so.1.0.0: no version > information available (required by /opt/teamspeak3-client/ts3client) > /opt/teamspeak3-client/ts3client: /usr/lib64/libssl.so.1.0.0: no version > information available (required by /opt/teamspeak3-client/ts3client) > /opt/teamspeak3-client/ts3client: /usr/lib64/libssl.so.1.0.0: no version > information available (required by /opt/teamspeak3-client/ts3client) This is normal, since ts3client has been built against a different OpenSSL version. You're free to ignore these warnings, it should still work fine. Nothing to worry about.
Created attachment 468940 [details] Update teamspeak-client-bin to version 3.1.3 Added default to src_prepare for PATCHES and mandatory eapply_user support.
(In reply to Martin McCourt from comment #6) > If I change it to EAPI="5" it seems to merge properly but the openssl and qt > libraries aren't found when the command runs. Please retry with the latest ebuild file (and without changing it.) Do you still get startup failures with that? If so, please provide more information so that I can reproduce or understand it.
(In reply to Mihai Moldovan from comment #10) > (In reply to Martin McCourt from comment #6) > > If I change it to EAPI="5" it seems to merge properly but the openssl and qt > > libraries aren't found when the command runs. > > Please retry with the latest ebuild file (and without changing it.) > > Do you still get startup failures with that? If so, please provide more > information so that I can reproduce or understand it. The latest ebuild for 3.1.3 merged successfully but it looks like it didn't properly find libraries for Qt5 xcb support: $ teamspeak3 /opt/teamspeak3-client/ts3client: /usr/lib64/libcrypto.so.1.0.0: no version information available (required by /opt/teamspeak3-client/ts3client) /opt/teamspeak3-client/ts3client: /usr/lib64/libssl.so.1.0.0: no version information available (required by /opt/teamspeak3-client/ts3client) /opt/teamspeak3-client/ts3client: /usr/lib64/libssl.so.1.0.0: no version information available (required by /opt/teamspeak3-client/ts3client) QCoreApplication::applicationDirPath: Please instantiate the QApplication object first This application failed to start because it could not find or load the Qt platform plugin "xcb" in "". Available platform plugins are: xcb. Reinstalling the application may fix this problem. Aborted $
I believe that to be a problem with your specific system. Something about your xcb or Qt libraries seems to be broken. The output of: emerge -p qtgui:5 equery f qtgui:5 ldd /usr/lib64/qt5/plugins/platforms/libqxcb.so ldd /usr/lib/libxcb.so Might be helpful to determine what's wrong.
Created attachment 470204 [details] Update teamspeak-client-bin to version 3.1.4 Updated to 3.1.4. No functional ebuild changes.
Created attachment 491050 [details] Update teamspeak-client-bin to version 3.1.6 Changes: - update to newest upstream release. - Qt5Svg now required, bundled copy removed.
3.1.7 is out. Any plan to bump it to main tree?
Created attachment 525156 [details] Update teamspeak-client-bin to version 3.1.8. No changes necessary compared to 3.1.6.
@Karol, @Sami: Do you still proxy maintain this package? If not, I can take it otherwise, as I am proxy maintaining the server already. @ Mihai: Of course, unless you would like to proxy maintain, since you were already so kind to provide several ebuilds here.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=4ab46a87ab9666af549c437c1aff208c0f8e9c39 commit 4ab46a87ab9666af549c437c1aff208c0f8e9c39 Author: Conrad Kostecki <conrad@kostecki.com> AuthorDate: 2018-05-04 09:05:55 +0000 Commit: Thomas Deutschmann <whissi@gentoo.org> CommitDate: 2018-05-04 14:52:57 +0000 media-sound/teamspeak-client-bin: Bump to version 3.1.8 Closes: https://bugs.gentoo.org/606934 Package-Manager: Portage-2.3.33, Repoman-2.3.9 media-sound/teamspeak-client-bin/Manifest | 2 + .../teamspeak-client-bin/files/ts3client-bin | 10 +++ media-sound/teamspeak-client-bin/metadata.xml | 36 ++++++--- .../teamspeak-client-bin-3.1.8.ebuild | 92 ++++++++++++++++++++++ 4 files changed, 127 insertions(+), 13 deletions(-) Additionally, it has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=163961d9a2480aab02f5c4c7bb6778e9a0376a34 commit 163961d9a2480aab02f5c4c7bb6778e9a0376a34 Author: Conrad Kostecki <conrad@kostecki.com> AuthorDate: 2018-05-04 09:06:40 +0000 Commit: Thomas Deutschmann <whissi@gentoo.org> CommitDate: 2018-05-04 14:52:59 +0000 media-sound/teamspeak-client-bin: Drop old version Closes: https://github.com/gentoo/gentoo/pull/8252 Bug: https://bugs.gentoo.org/606934 Package-Manager: Portage-2.3.33, Repoman-2.3.9 media-sound/teamspeak-client-bin/Manifest | 2 - media-sound/teamspeak-client-bin/files/teamspeak3 | 10 --- .../teamspeak-client-bin-3.0.19.4-r1.ebuild | 78 ---------------------- 3 files changed, 90 deletions(-)
Uhm, yeah, mostly okay - I see you went the other way and opted to just installed subparts instead of removing bundled stuff first and then installing everything. What about the minimum Qt requirements, though? AFAIK Qt has no forwards-compatibility for minor releases (i.e., there's no guarantee that older versions than what the client was compiled against will work). It does have backwards-compatibility, so assuming anything released later in the "5" slot will continue to work with the client is sane.
(In reply to Mihai Moldovan from comment #19) > Uhm, yeah, mostly okay - I see you went the other way and opted to just > installed subparts instead of removing bundled stuff first and then > installing everything. IMO it's the better way. > What about the minimum Qt requirements, though? AFAIK Qt has no > forwards-compatibility for minor releases (i.e., there's no guarantee that > older versions than what the client was compiled against will work). It does > have backwards-compatibility, so assuming anything released later in the "5" > slot will continue to work with the client is sane. Good question. Since 5.6 hit already in early 2016 in portage and isn't even anymore in portage, does it still make sense so set the minimum qt requirements?
(In reply to Conrad Kostecki from comment #20) > (In reply to Mihai Moldovan from comment #19) > > Uhm, yeah, mostly okay - I see you went the other way and opted to just > > installed subparts instead of removing bundled stuff first and then > > installing everything. > > IMO it's the better way. As long as it's equivalent, sure, why not. Easier to maintain, I guess, unless you forgot to stage something, but that should be failing while testing anyway. > Good question. Since 5.6 hit already in early 2016 in portage and isn't even > anymore in portage, does it still make sense so set the minimum qt > requirements? Good question right back. Technically, if the tree does not contain older versions, omitting the minimum requirement is fine. If third-party repos get stuff wrong... it's their fault. Personally though, I'd make a minimum requirement explicit. If the application is updated to require, say, 5.9 as a minimum and 5.7 is still in-tree, that will easily be overlooked. It's harder to miss it if the ebuild already states minimum requirements... though even then it requires the maintainer to know what is up with this version there. So, right, not a technical issue at all, if anything just an uncritical style/maintenance thing.
> As long as it's equivalent, sure, why not. Easier to maintain, I guess, > unless you forgot to stage something, but that should be failing while > testing anyway. I am doing anyway for each new version a diff, so see, if there is something new :) > Personally though, I'd make a minimum requirement explicit. If the > application is updated to require, say, 5.9 as a minimum and 5.7 is still > in-tree, that will easily be overlooked. It's harder to miss it if the > ebuild already states minimum requirements... though even then it requires > the maintainer to know what is up with this version there. I guess, thats my job to have a look, what happens with that package ;-)
