Outdated Linphone packets

[Simon Morlat]

Hi Bernhard,

I'm following up on our last exchange about packaging of Linphone in Debian.
Thanks to Julien we've made huge progress and we are now on track to 
make a new release very shortly (let's say end of this month). The 
stability of the our last beta versions (from master branch of 
linphone-sdk) is currently very good.
The Minizip dependency that was giving your headaches is now dropped, so 
I guess there is no blocking point to make Linphone re-enter Debian.
We have also recently adopted semantic versionning for all our 
components, which should help a bit with the management of packages.

My goal with this email is mainly to put you in contact with Julien (in 
cc) so that you he can assist you, should you face any issue (build or 
whatever) while creating the Debian packages, or should you want to give 
us back some patches you've made already. Don't hesitate to contact him 
and feel free to let us know how we can help you.

Best regards,

Simon



Le 1/9/20 à 15:08, Simon Morlat a écrit :
> 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