Outdated Linphone packets

[Simon Morlat]

Hi Bernard,

Thank you for your efforts. Unfortunately on our side we still stuck, as 
Elisa said we have been quite unlucky. The developer we've hired to 
re-born the project last year suddenly stopped to work for personal 
reasons two months ago. There is quite important work in progress in a 
development branch but still no release.
The good news is that next wednesday we have new developer (Julien) who 
will join us, and he will work full time on the app. Let's hope he will 
be the good one.
Regarding minizip, I just perform a quick investigation about why we use 
it: actually only to uncompress BSD-licensed H264 codec from 
http://openh264.org . It is provided in binary form (shared library for 
GNU/Linux). This H264 codec is optional, video can work as well with VP8 
codec.
I will ask Julien to modify the source code to simply drop this 
dependency on GNU/Linux: indeed a quick shell call to bunzip2 will do 
the job as well. Integrating minizip just for this was really overkill. 
At the end all you'll have to do is to add a dependency to bunzip2 
package inside the Linphone debian package.

I will put you in contact with Julien so that you can exchange directly 
on these technical aspects.

Best regards,

Simon

Le 1/6/20 à 14:49, Bernhard Schmidt 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
>>

-- 
Simon Morlat, manager and co-founder
Belledonne-Communications SARL
https://linphone.org
Phone  +33 952636505