There's a few jobs that can use Qt5TextToSpeech like knotifications and kanagram.
Would be cool if it was available to increase CI code coverage.
There's a few jobs that can use Qt5TextToSpeech like knotifications and kanagram.
Would be cool if it was available to increase CI code coverage.
I can't find any sort of source for this. Is this a module for qt5? If so been has to add that to the mirror list I think...
Adding him.
QtTextToSpeech hasn't been released yet, but will be part of Qt 5.6 when it comes out.
That's why everything that depends on it is an optional dependency.
Ok, let's wait until then, wonder why we have so many dependencies on unrelease stuff :/
Qt 5.6 is out - I think we're waiting until 5.6.1 due to issues within Plasma hence why no request for a bump yet.
Qt 5.6 actually doesn't include QtTextToSpeech, it will be in Qt 5.7 instead as tech preview apparently :/
This is available in our SUSE image which is used for Plasma, the Fedora image used for Applications though lacks this currently.
Not directly related but, why do we use different images? Doesn't that make our live harder? What do we win from it?
Different images are used in order to provide different versions of non-KDE software (like Qt - Frameworks always wants an old version while Plasma wants the latest).
It also makes significant changes to the underlying images easier to manage (as less builds are performed with each one, meaning the amount of effort required in terms of fixing dependencies and triggering rebuilds is reduced)
Sorry, but I am unclear on how this is easier. There are applications that want QtTextToSpeech, and from what I understand, this is not possible?
It is possible, I just needed to get the right package name:
https://cgit.kde.org/sysadmin/ci-tooling.git/commit/?id=1a654ac9c070f5142fec9cd821bb1035f2f6da5d
Following that https://build-sandbox.kde.org/job/Applications%20kmouth%20kf5-qt5%20FedoraQt5.9/7/console is now a success, which resolves this.
It makes things easier because we don't have to worry about Qt based stuff which is outside of KDE, we can just rely on the distro packaging. That means less maintenance effort for us. Having the latest version shouldn't be too much of an issue, as we're using rolling distros which usually have the latest versions of things anyway (as long as people don't try to require betas or the like, but that is another issue altogether)