Outdated Linphone packets

Mon Jan 6 14:10:20 GMT 2020

Hi Bernhard,

Il will let my technical managers reply to you in more detail, but first of all I wanted to thank for your effort and your help. It would be wonderful for us if our coming version could be packaged and available to Debian users, and we will do our best to help you, according to your report. Please do not give up now :-) I am sure we will find a technical solution. Would you be available for a short call with one of our two co-founders (Simon Morlat or Jehan Monnier)? Maybe it could help, and we are willing to do our best to adapt to your requirements.

I confirm that there has been no release of Linphone for desktop since two years, the last one, 4.1, being outdated, and yes, it is a pity.
We unfortunately are a quite small company (10 people), and honestly had no chance with our desktop lead developers in the past two years. For internal reasons, we had to focus on the mobile apps for a while, but the desktop one is definitely very important for us. The work before we can officially release Linphone 4.2 for desktop is almost done. We have just hired new resources to focus on our desktop app in the coming weeks, so this will definitely be the right time to discuss with you, ans see how we shall adapt to be Debian-compatible.

We attended some open sources events last year, and saw that the interest in Linphone for desktop is still very high among the Linux community, and many Debian users mentioned the outdated packaged version, so we know we have to work on this, hopefully with your help. I hope that we can collaborate, without taking too much of your time.

Thanks again and happy new year!

Elisa Nectoux
Sales & Marketing

+33 (0)9 52 63 65 05
elisa.nectoux at belledonne-communications.com

Belledonne Communications, the company behind the Linphone project
https://www.linphone.org <https://www.linphone.org/>

> Le 6 janv. 2020 à 14:49, Bernhard Schmidt <berni at debian.org> a écrit :
> 
> Hi All,
> 
> I've been bored enough to update the whole linphone stack to 4.3.0 and I
> got packages that compiled on top of each other (bctoolbox, belle-sip,
> belcard, belr, bzrtp, ortp, mediastreamer2, linphone). These are not
> cleaned up and ready for integration, some of them need a trip through
> NEW, but overall it looks like it could work. Lack of bcunit in Debian
> was a bit of a bummer, as I had to disable unit tests for almost every
> package manually, otherwise it would try to link to some bctoolbox
> tester headers that simply are not installed.
> 
> However, I've hit a major blocker with linphone-desktop. First of all,
> there does not seem to be a release tagged for ages, with 4.1.1 still
> being the last one in July 2017.
> 
> I've tried the release/4.2 branch and got hit by linphone-desktop
> requiring a new external library, minizip. There is an old package
> called minizip in the distribution
> 
> https://tracker.debian.org/pkg/minizip
> 
> which according to
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843617 appears to be
> an outdated fork of the contrib/minizip directory in src:zlib, which is
> not installed at all.
> 
> https://gitlab.linphone.org/BC/public/external/minizip seems to be yet
> another fork, I think upstream is at https://github.com/nmoinvaz/minizip .
> 
> I currently do not have the energy to package this, so right now we're
> stuck. I can agree to push and polish the other packages, but I'm not
> going to package minizip.
> 
> Looking at the bugreports I don't think we're doing our users a favour
> in keeping linphone 3.12 with the old GTK+ frontend in Debian, and most
> of it has already dropped from testing due to FTBFS with GCC-9 or the
> dependency on Python2. So I'm considering dropping all of it from
> testing and calling it a day.
> 
> Bernhard
> 
> Am 13.08.19 um 11:19 schrieb Simon Morlat:
>> Hi Bernhard,
>> 
>> Thank you very much for your detailed answer.
>> I realize I was wrong about the need for a tarball.
>> 
>> This was the case for linphone-desktop ("git tag" gives you all latests
>> stable releases), but no longer for our dependencies, that were only
>> referenced as git submodule of linphone-desktop).
>> 
>> So we are going to setup a consistent tag policy for all our components.
>> 
>> You 're right about the need to be careful with ABIs, and I know well
>> what is the SO numbering policy. The next update will require to rebuild
>> kopete as we are going to increase the SONAME abruptly, but after this
>> one we will try to manage backward compatibility as best as we can to
>> ease the life of our downstream users.
>> I'll get back to you as soon as we have something ready. We plan to make
>> a 4.2 linphone-desktop release in september. Our objective will be that
>> this release will also be debian ready.
>> 
>> Best regards,
>> 
>> Simon
>> 
>> 
>> Le 8/9/19 à 22:44, Bernhard Schmidt a écrit :
>>> Hi,
>>> 
>>>>> - a linphone-sdk source tar.gz package containing all source code for
>>>>> libraries, with a cmake script that builds everything in one pass, but
>>>>> using debian included dependencies for our externals (soci, xerces,
>>>>> opus, libvpx, mbedtls...). Everything goes to a DESTDIR-like root-fs.
>>>>> - a linphone-desktop tar.gz package contaning the new QT5 graphical
>>>>> user
>>>>> interface, that depends on libraries built by linphone-sdk.
>>>>> Would this be helpful and sufficient for Debian developers to
>>>>> - create debian packages for all linphone subprojects (bctoolbox, belr,
>>>>> ortp, mediastreamer2, belle-sip, belcard, liblinphone)
>>>> Sounds okay, but please do not include checkouts of the foreign modules
>>>> into your tar.gz. Even if the actual compilation would be against the
>>>> system libraries, carrying those foreign projects in the source tarball
>>>> requires needless copyright examination. Or repacking, both is
>>>> cumbersome.
>>> Forgot to add:
>>> 
>>> Something that is also very important for Debian (and most other
>>> distributions) is proper maintenance of shared libraries. There can only
>>> be one version of each library in a release, so all reverse depencies
>>> need to be built against it. When there are foreign projects using these
>>> libraries, they need to be able to do it in a stable way. This means
>>> 
>>> - Don't easily change the API, because it might break existing projects
>>> to build against the new version. This would be a blocker for inclusion
>>> 
>>> Actually AFAIR this prevented having an updated linphone version in
>>> Stretch (Debian 9, released three years ago) because kopete did not
>>> build against the new version of mediastreamer, which blocked the update.
>>> 
>>> - Don't break the library ABI. Don't drop or change exported symbols. If
>>> absolutely necessary bump the SONAME.
>>> 
>>> See https://wiki.debian.org/UpstreamGuide for more information.
>>> 
>>> This is less of a concern if only the linphone-ecosystem uses the
>>> libraries, but right now there is at least kopete using libmediastreamer
>>> and libortp. If this is something you are absolutely unwilling to
>>> support, please document this and get in touch with Kopete upstream to
>>> get this dropped.
>>> 
>>> Bernhard
>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-voip-maintainers/attachments/20200106/659367de/attachment-0001.html>