Bug#864188: [Debian-med-packaging] Bug#864188: libbpp-core2v5: symbols removed without soname bump

2017-06-06 Thread Julien Yann Dutheil 
Thanks a lot for your answers. I understand. We will increase the interface
number. Is it ok to move the release tag on the git repository or is it
better to make a new (distinct) one?

I apologize for the "dummy" questions.

Julien.

On Tue, Jun 6, 2017 at 9:14 PM, Vincent Danjean  wrote:

> Le 06/06/2017 à 12:47, Julien Yann Dutheil a écrit :
> > Dear Adrian,
> >
> > These functions are now inline in the corresponding .h files, but their
> > interfaces have not changed as far as I know. Does making a function
> > inline break the interface??
>
>   It is the difference between the API and the ABI. The API
> (interface for the programmer) did not change. But the ABI
> (binary interface) changed.
>   Both (API and ABI) are related but not tightly coupled.
>
>   The API has a backward incompatibility when sources that
> compiled with the previous API do not compile any more with
> the new API (this is not the case here).
>   The ABI has a backward incompatibility when a program/lib
> compiled against an old library will not work with the new
> library. This is the case here: a (previously compiled) program
> can try to use symbols that are not present anymore in the
> new library. Recompiling the program would workaround the
> problem (as the API did not change and the new compiled program
> will not try to use the symbols anymore) but the correct fix is
> to bump the soname so that the user knows without looking for
> bugs if the program and the library are compatible.
>
>   Regards,
> Vincent
>
> > J.
> >
> > -- Forwarded message --
> > From: *Adrian Bunk* >
> > Date: Tue, Jun 6, 2017 at 11:48 AM
> > Subject: Re: Bug#864188: libbpp-core2v5: symbols removed without soname
> bump
> > To: Julien Yann Dutheil >
> > Cc: Andreas Tille >,
> 864...@bugs.debian.org , GINDRAUD FRANCOIS
> >
> >
> >
> > On Tue, Jun 06, 2017 at 11:35:57AM +0200, Julien Yann Dutheil wrote:
> >> Dear Andreas, Adrian,
> >>...
> >> - This error actually revealed an interface breakdown (essentially due
> to
> >> our upgrade to c++11), and your suggestion is to reflect this change by
> >> increasing the interface number (which would result in a change in
> package
> >> name, such as libbpp-core2 -> libbpp-core3), am I correct?
> >
> > This ABI breakage is unrelated to the C++ version used.
> >
> > RandomTools::lnGamma() was removed from src/Bpp/Numeric/Random/
> RandomTools.cpp
> > TextTools::startsWith() was removed from src/Bpp/Text/TextTools.cpp
> > ApplicationTools::parameterExists() was removed from
> src/Bpp/App/ApplicationTools.cpp
> > ...
> >
> > Removing any such function breaks the ABI in an incompatible way,
> > and therefore requires a soname bump.
> >
> >> Best,
> >>
> >> Julien.
> >
> > cu
> > Adrian
> >
> >> On Mon, Jun 5, 2017 at 9:50 AM, Andreas Tille  > wrote:
> >>
> >> > Hi Julien,
> >> >
> >> > while I made a mistake to upload libbpp-core to unstable rather than
> >> > experimental as it was planed this has probably lead to spot a bug
> >> > earlier.  The problem is that the soversion needs to be bumped due to
> >> > the ABI change.
> >> >
> >> >$ objdump -p ./libbpp-core.so.2.0.4   | sed -n 's/^.*SONAME *//p'
> >> >libbpp-core.so.2
> >> >
> >> > I think you should bump the SOVERSION to reflect that change.
> >> >
> >> > Kind regards
> >> >
> >> >  Andreas.
> >> >
> >> > On Mon, Jun 05, 2017 at 02:42:58AM +0300, Adrian Bunk wrote:
> >> > > Package: libbpp-core2v5
> >> > > Version: 2.3.0-1~exp1
> >> > > Severity: serious
> >> > > Control: affects -1 libbpp-seq9v5 src:libbpp-phyl
> >> > >
> >> > > 2.3.0-1~exp1 in unstable (sic) removes symbols without changing
> soname,
> >> > > causing the following FTBFS in libbpp-phyl:
> >> > >
> >> > > https://tests.reproducible-builds.org/debian/rb-pkg/ <
> https://tests.reproducible-builds.org/debian/rb-pkg/>
> >> > unstable/amd64/libbpp-phyl.html
> >> > >
> >> > > ...
> >> > > [ 93%] Linking CXX executable test_bowker
> >> > > cd /build/1st/libbpp-phyl-2.2.0/obj-x86_64-linux-gnu/test &&
> >> > /usr/bin/cmake -E cmake_link_script CMakeFiles/test_bowker.dir/
> link.txt
> >> > --verbose=1
> >> > > /usr/bin/c++   -Wall -Wshadow -Weffc++ -Wconversion  -Wl,-z,relro
> >> > CMakeFiles/test_bowker.dir/test_bowker.cpp.o  -o test_bowker
> -rdynamic
> >> > -lbpp-seq -lbpp-core -L../src -lbpp-phyl
> >> > > /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/
> libbpp-seq.so:
> >> > undefined reference to `bpp::RandomTools::lnGamma(double)'
> >> > > /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/
> libbpp-seq.so:
> >> > undefined reference to `bpp::TextTools::startsWith(
> >> > std::__cxx11::basic_string >> > std::allocator >

Bug#864188: [Debian-med-packaging] Bug#864188: libbpp-core2v5: symbols removed without soname bump

2017-06-06 Thread Vincent Danjean 
Le 06/06/2017 à 12:47, Julien Yann Dutheil a écrit :
> Dear Adrian,
> 
> These functions are now inline in the corresponding .h files, but their
> interfaces have not changed as far as I know. Does making a function
> inline break the interface??

  It is the difference between the API and the ABI. The API
(interface for the programmer) did not change. But the ABI
(binary interface) changed.
  Both (API and ABI) are related but not tightly coupled.

  The API has a backward incompatibility when sources that
compiled with the previous API do not compile any more with
the new API (this is not the case here).
  The ABI has a backward incompatibility when a program/lib
compiled against an old library will not work with the new
library. This is the case here: a (previously compiled) program
can try to use symbols that are not present anymore in the
new library. Recompiling the program would workaround the
problem (as the API did not change and the new compiled program
will not try to use the symbols anymore) but the correct fix is
to bump the soname so that the user knows without looking for
bugs if the program and the library are compatible.

  Regards,
Vincent

> J.
> 
> -- Forwarded message --
> From: *Adrian Bunk* >
> Date: Tue, Jun 6, 2017 at 11:48 AM
> Subject: Re: Bug#864188: libbpp-core2v5: symbols removed without soname bump
> To: Julien Yann Dutheil  >
> Cc: Andreas Tille >, 
> 864...@bugs.debian.org , GINDRAUD FRANCOIS 
> >
> 
> 
> On Tue, Jun 06, 2017 at 11:35:57AM +0200, Julien Yann Dutheil wrote:
>> Dear Andreas, Adrian,
>>...
>> - This error actually revealed an interface breakdown (essentially due to
>> our upgrade to c++11), and your suggestion is to reflect this change by
>> increasing the interface number (which would result in a change in package
>> name, such as libbpp-core2 -> libbpp-core3), am I correct?
> 
> This ABI breakage is unrelated to the C++ version used.
> 
> RandomTools::lnGamma() was removed from src/Bpp/Numeric/Random/RandomTools.cpp
> TextTools::startsWith() was removed from src/Bpp/Text/TextTools.cpp
> ApplicationTools::parameterExists() was removed from 
> src/Bpp/App/ApplicationTools.cpp
> ...
> 
> Removing any such function breaks the ABI in an incompatible way,
> and therefore requires a soname bump.
> 
>> Best,
>>
>> Julien.
> 
> cu
> Adrian
> 
>> On Mon, Jun 5, 2017 at 9:50 AM, Andreas Tille > > wrote:
>>
>> > Hi Julien,
>> >
>> > while I made a mistake to upload libbpp-core to unstable rather than
>> > experimental as it was planed this has probably lead to spot a bug
>> > earlier.  The problem is that the soversion needs to be bumped due to
>> > the ABI change.
>> >
>> >$ objdump -p ./libbpp-core.so.2.0.4   | sed -n 's/^.*SONAME *//p'
>> >libbpp-core.so.2
>> >
>> > I think you should bump the SOVERSION to reflect that change.
>> >
>> > Kind regards
>> >
>> >  Andreas.
>> >
>> > On Mon, Jun 05, 2017 at 02:42:58AM +0300, Adrian Bunk wrote:
>> > > Package: libbpp-core2v5
>> > > Version: 2.3.0-1~exp1
>> > > Severity: serious
>> > > Control: affects -1 libbpp-seq9v5 src:libbpp-phyl
>> > >
>> > > 2.3.0-1~exp1 in unstable (sic) removes symbols without changing soname,
>> > > causing the following FTBFS in libbpp-phyl:
>> > >
>> > > https://tests.reproducible-builds.org/debian/rb-pkg/ 
>> > > 
>> > unstable/amd64/libbpp-phyl.html
>> > >
>> > > ...
>> > > [ 93%] Linking CXX executable test_bowker
>> > > cd /build/1st/libbpp-phyl-2.2.0/obj-x86_64-linux-gnu/test &&
>> > /usr/bin/cmake -E cmake_link_script CMakeFiles/test_bowker.dir/link.txt
>> > --verbose=1
>> > > /usr/bin/c++   -Wall -Wshadow -Weffc++ -Wconversion  -Wl,-z,relro
>> > CMakeFiles/test_bowker.dir/test_bowker.cpp.o  -o test_bowker -rdynamic
>> > -lbpp-seq -lbpp-core -L../src -lbpp-phyl
>> > > /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libbpp-seq.so:
>> > undefined reference to `bpp::RandomTools::lnGamma(double)'
>> > > /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libbpp-seq.so:
>> > undefined reference to `bpp::TextTools::startsWith(
>> > std::__cxx11::basic_string> > std::allocator > const&, std::__cxx11::basic_string> > std::char_traits, std::allocator > const&)'
>> > > /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libbpp-seq.so:
>> > undefined reference to `bpp::ApplicationTools::
>> > parameterExists(std::__cxx11::basic_string> > std::allocator > const&, std::map> > std::char_traits, std::allocator >, 
>> > std::__cxx11::basic_string> > std::char_traits, std::allocator >,
>> >