Re: [Linphone-users] backport built for Debian 10 (buster), but...

[Daniel Pocock]

On 01/07/2021 19:47, Dennis Filder wrote:
> On Thu, Jul 01, 2021 at 12:36:51AM +0200, Daniel Pocock wrote:
> 
> Debian Linphone maintainer team member here.
> 
>> I had a look at how to build the latest Linphone for Debian buster
> 
> Did you start with the Debian packages or did you package from
> scratch?

I cloned the repositories from salsa.debian.org and created
debian/buster-backports branches for all of them.  I pushed them here so
you can see them, please see the debian/buster-backports branch in each
repository, you can see exactly what I had to tweak for each package to
build on buster:

https://gitlab.com/debify

I do a lot of development on Debian and SIP, most of my work is in
reSIProcate and it is important for me to test it against Linphone on an
almost daily basis.
https://github.com/resiprocate/resiprocate/graphs/contributors

I'd like to push my backport branches back to Salsa but Debian is a bit
like Hong Kong right now, some Debian oligarchs are smearing and
obstructing all the people who don't kneel before Google / China /
whatever so I can't push my branches.


>> All the dependency libraries build successfully, there are some very
>> minor tweaks in CPPFLAGS and CMake settings
>>
>> The only problem I found is in the linux-desktop component (the GUI)
>>
>> It requires Qt 5.12.  Debian buster has 5.11.  I tweaked the settings to
>> use 5.11.  With this change, it compiles successfully
>>
>> However, the Settings window doesn't work.  Q_ASSERT from App.cxx:235 at
>> startup.  I commented out the Q_ASSERT and I found that the rest of the
>> application is working, it is only a problem with the Settings window
> 
> It would be somewhat important to know what parameters to
> createSubWindow() trigger the assertion.

I ran

  linphone -V

and it didn't give me sufficient details to respond to that.

Please feel free to try my packages or tell me what commands to run to
get extra debug output.

>> Looking at the qml files, I found that three of them need a more recent
>> Qt Quick Controls.  Debian with Qt 5.11 supports Qt Quick Controls 2.4.
>> These are the files wanting newer versions:
>>
>>
>> linphone-app/ui/modules/Common/Window/VirtualWindow.qml
>>
>> import QtQuick.Controls 2.5
>>
>>
>>
>> linphone-app/ui/views/App/Calls/Dialogs/MultimediaParameters.qml
>>
>> import QtQuick.Controls 2.4
>>
>>
>> linphone-app/ui/views/App/Settings/SettingsAudio.qml
>>
>> import QtQuick.Controls 2.4 as Core
>>
>>
>> Would it be possible to avoid using newer features in those three qml
>> files so that people can use the latest Linphone on Debian buster?
> 
> Are those your changes already?  On my machine
> linphone-desktop-4.2.5/linphone-app/ui/views/App/Settings/SettingsAudio.qml
> contains this line:
> 
>     ...
>     import QtQuick.Controls 2.7 as Core
>     ...
> 

Oops, I copied the files after I patched them.  You are correct,
SettingsAudio.qml wants 2.7, I patched it to try 2.4 but it wouldn't
work.  The original email had a typo in it, 2.4 was a mistake.

> Which is strange because QtQuick.Controls 2.5 and 2.7 were never
> released/never existed: According to the version list
> <https://doc.qt.io/qt-5/qtquickcontrols-index.html#versions> there was
> a version jump from 2.4 (Qt 5.11) to 2.12 (Qt 5.12), so they probably
> were development versions.  If you haven't already, it could be worth
> a try to just lower these version numbers to "2.4", compile and see
> what happens.  If it doesn't build, though, you'd have to patch the
> necessary features out yourself.

That is exactly what I did (you can see that in my branch)

It compiles successfully, the qml versions are not checked during the
compile

At runtime, I get the Q_ASSERT for the SettingsWindow

I made another hack to suppress the Q_ASSERT, you can see that in the
last commit on the debian/buster-backports branch, it opens the main
window successfully and I can dial a SIP address

Therefore, I suspect the only problems for users on Buster:

- Quick Controls API features

- for people not using x86, the __linux issue in my other email.
Personally, I'm using Open hardware, the Talos II, so it is important to
get things like that fixed

https://danielpocock.com/talos-II-quickstart/