Bug#897780: Bug#897785: Bug#897784: Bug#897780: Now gcc-8 errors caused by non-fitting symbols file became serious

[Julien Yann Dutheil]

Dear Andreas,

I'm so sorry, forgot (again) to push --all and --tags... this should now be
fixed.

Best,

Julien.

On Wed, Aug 22, 2018 at 3:59 PM Andreas Tille  wrote:

> [CC only bug of libbpp-core to reduce the noise on the mailing list a bit]
>
> Dear Julien,
>
> On Wed, Aug 22, 2018 at 09:14:49AM +0200, Julien Yann Dutheil wrote:
> >
> > Library updates should be now done and pushed.
>
> I've just checked libbpp-core and realised that pristine-tar information
> is missing.  Did you simply forgot to push or it is not imported.  I
> recently gave some hints about this[1] here on this list.  Feel free to
> ask if you have no idea what to do anyway.
>
> > Some notes:
> > - I referred to the bug numbers in commits and changelogs, but did not
> > close them, as the report says to only close them once the packages build
> > properly.
>
> Please use Close statements.  I'm building those packages here at my
> side in a chroot and if they will not upload - but if it builds the bug
> can be closed.  I like your good style to add some extra care but in
> this case it is not needed.
>
> > - I am regularly facing random issues like package "bpp-*-dev not found"
> or
> > "library symbols contain debian version number". I came to realise that
> > changing d-shlibs (>= 0.80) or (>=0.82) solves the problem: if it fails
> > with one, I change the number and it works. When it fails again, I change
> > the number back and it works again.
>
> That's strange.  When building in an up to date unstable chroot you
> should get d-shlibs 0.82+nmu1 whatever Build-Depends you are using.  The
> Build-Depends is only useful for backports to other systems where some
> lower version of d-shlibs might be used and the build would fail.  So
> you are probably building on a different system than Debian unstable and
> moreover you have some interesting effect in your preferences which are
> able to pick different versions of d-shlibs (I've never seen this but
> who knows).
>
> > I have no idea what's going on and I
> > must obviously be doing sthg wrong... would you mind checking I did not
> > mess anything in the control files?
>
> I do not think that the problem is inside the control file but in your
> build system.  If you want more detailed help I need the exact package
> and the positive + negative versioned Build-Depends.
>
> Summary of the blockers for an upload:
>
>1. pristine-tar
>2. s/Ref:/Closes:/ in d/changelog
>
> Once you are touching the packages again please also set latest
> Standards-Version:
>
>3. Standards-Version: 4.2.0
>
> Kind regards and thanks for the preparation of the packages
>
>Andreas.
>
>
> [1]
> https://alioth-lists.debian.net/pipermail/debian-med-packaging/2018-August/064878.html
>
> --
> http://fam-tille.de
>


-- 
Julien Y. Dutheil, Ph-D
0 (+49) 6421 178 986

§ Max Planck Institute for Evolutionary Biology
Molecular Systems Evolution
Department of Evolutionary Genetics
Plön -- GERMANY

§ Institute of Evolutionary Sciences - Montpellier
University of Montpellier 2 -- FRANCE

Bug#897780: Bug#897784: Bug#897780: Now gcc-8 errors caused by non-fitting symbols file became serious

[Julien Yann Dutheil]

Dear Andreas,

Library updates should be now done and pushed. Some notes:
- I referred to the bug numbers in commits and changelogs, but did not
close them, as the report says to only close them once the packages build
properly.
- I am regularly facing random issues like package "bpp-*-dev not found" or
"library symbols contain debian version number". I came to realise that
changing d-shlibs (>= 0.80) or (>=0.82) solves the problem: if it fails
with one, I change the number and it works. When it fails again, I change
the number back and it works again. I have no idea what's going on and I
must obviously be doing sthg wrong... would you mind checking I did not
mess anything in the control files?

Best regards,

Julien.

On Sun, Aug 19, 2018 at 10:36 AM Andreas Tille  wrote:

> Hi Julien,
>
> On Sun, Aug 19, 2018 at 09:39:59AM +0200, Julien Yann Dutheil wrote:
> > Thanks for your answer. One more silly question: how can I get rid of the
> > previous symbol files, build the package, and generate new ones?
> Currently
> > does not want to build because of the symbol mismatch, and I could not
> > figure out how to solve that... any pointer welcome.
>
> Just remove the old file and create a new one according to
>
> https://wiki.debian.org/UsingSymbolsFiles
>
> May be there is some script which automates the two step procedure
> (I always wanted to write some but the pressure was to low but
> usually people in Debian do such things ... ;-) )
>
> Hope this helps
>
>   Andreas.
>
> --
> http://fam-tille.de
>
>

-- 
Julien Y. Dutheil, Ph-D
0 (+49) 6421 178 986

§ Max Planck Institute for Evolutionary Biology
Molecular Systems Evolution
Department of Evolutionary Genetics
Plön -- GERMANY

§ Institute of Evolutionary Sciences - Montpellier
University of Montpellier 2 -- FRANCE

Bug#897780: Now gcc-8 errors caused by non-fitting symbols file became serious

[Julien Yann Dutheil]

Dear Andreas,

Thanks for your answer. One more silly question: how can I get rid of the
previous symbol files, build the package, and generate new ones? Currently
does not want to build because of the symbol mismatch, and I could not
figure out how to solve that... any pointer welcome.

Thanks a lot,

Julien.

On Sat, Aug 18, 2018 at 3:03 AM Andreas Tille  wrote:

> Dear Julien,
>
> On Fri, Aug 17, 2018 at 03:00:12PM +0200, Julien Yann Dutheil wrote:
> > Update is (almost) ready upstream.
> :-)
>
> > Have a question though: when a program
> > has not changed but needs to be rebuilt against the newest version of the
> > library, can I just increase the package version number, or should I also
> > increase the program version number?
>
> If it is just a rebuild only the Debian revision will be bumped like
>
> -1will become-2
>
> with a changelog entry
>
> * Rebuild due to ...
>
> > Example: physamp is currently in version 1.1.0. No changes has been made
> > but it needs to be recompiled to work with Bio++ 2.4.1. (Was 2.4.0
> before).
> > Should the new physamp package be called 1.1.0-2 or 1.1.1-1 ?
>
> So this is
>
>   1.1.0-2
>
> > PS: autopkgtests are on the TODO list...
>
> Very cool!
>
> Kind regards
>
>   Andreas.
>
> --
> http://fam-tille.de
>
>

-- 
Julien Y. Dutheil, Ph-D
0 (+49) 6421 178 986

§ Max Planck Institute for Evolutionary Biology
Molecular Systems Evolution
Department of Evolutionary Genetics
Plön -- GERMANY

§ Institute of Evolutionary Sciences - Montpellier
University of Montpellier 2 -- FRANCE

Bug#897781: Now gcc-8 errors caused by non-fitting symbols file became serious

[Julien Yann Dutheil]

Dear Andreas,

Update is (almost) ready upstream. Have a question though: when a program
has not changed but needs to be rebuilt against the newest version of the
library, can I just increase the package version number, or should I also
increase the program version number?

Example: physamp is currently in version 1.1.0. No changes has been made
but it needs to be recompiled to work with Bio++ 2.4.1. (Was 2.4.0 before).
Should the new physamp package be called 1.1.0-2 or 1.1.1-1 ?

Best,

Julien.

PS: autopkgtests are on the TODO list...


On Thu, Jul 19, 2018 at 10:48 AM Andreas Tille  wrote:

> Dear Julien,
>
> On Thu, Jul 19, 2018 at 09:19:50AM +0200, Julien Yann Dutheil wrote:
> > Will make a new release then, but I will only be able to start the
> process
> > in the second week of August.
>
> While this will mean that the packages will be autoremoved from testing
> after 10 days I do not think that this is big harm in general since they
> will come back later.  BTW, if you would add some autopkgtest the
> migration time will be reduced to 2 days.
>
> Another note: In the second week of August I'm back from DebConf.
> That's the time where I restrict my computertime drastically to recover
> a bit from that intense time. :-)
>
> Kind regards
>
> Andreas.
>
> > On Thu, Jul 19, 2018 at 7:04 AM Andreas Tille  wrote:
> > > On Wed, Jul 18, 2018 at 11:33:33PM +0200, Julien Yann Dutheil wrote:
> > > > Many thanks for your email. I have fixed gcc8 warnings upstream some
> time
> > > > ago. Would it make things easier if I would just make a new minor
> release
> > >
> > > Since the packaging might become more easy since no patches will be
> > > needed I'd regard this the most simple solution packaging wise (no idea
> > > how much effort it might be on your side).  May be also non-Debian
> users
> > > might profit from full gcc-8 compatibility.
> > >
> > > > (there will be no interface break, due to a new management strategy
> > > > upstream... hopefully we learn from our mistakes :) ) ?
>
> --
> http://fam-tille.de
>


-- 
Julien Y. Dutheil, Ph-D
0 (+49) 6421 178 986

§ Max Planck Institute for Evolutionary Biology
Molecular Systems Evolution
Department of Evolutionary Genetics
Plön -- GERMANY

§ Institute of Evolutionary Sciences - Montpellier
University of Montpellier 2 -- FRANCE

Bug#894751: Another upload of libbpp* packages with complete CeCILL license is needed

[Julien Yann Dutheil]

On Fri, Apr 6, 2018 at 10:41 AM, Andreas Tille  wrote:

>
>
> > I have notice the ABI errors
> > but have to admit I did not know how to handle it.
>
> What exact error do you mean?
>

I was referring to this one [1].
Seems to be sthg with the new symbol files...?

Julien.

[1]
https://buildd.debian.org/status/fetch.php?pkg=libbpp-core=ppc64el=2.4.0-2=1522864679=log

-- 
Julien Y. Dutheil, Ph-D
0 (+49) 6421 178 986

§ Max Planck Institute for Evolutionary Biology
Molecular Systems Evolution
Department of Evolutionary Genetics
Plön -- GERMANY

§ Institute of Evolutionary Sciences - Montpellier
University of Montpellier 2 -- FRANCE

Bug#894751: Another upload of libbpp* packages with complete CeCILL license is needed

[Julien Yann Dutheil]

Dear Andreas,

Once more, thanks a lot for all the support! I have notice the ABI errors
but have to admit I did not know how to handle it. All libs should be
ready, with the exception of libbpp-qt which I still need to release. I
will include the full CeCILL text in that one too and check your changes in
the other libs. Next will be the bppsuite, bppphyview, physamp and
maffilter program, also on my todo list (hopefully next week). MafFilter
and PhySamp are under GPL3, do I understand right that I do not need to
upload the full License for these ones as it should already be present in
the distribution?

All the best,

Julien.

On Fri, Apr 6, 2018 at 8:08 AM, Andreas Tille  wrote:

> Hi Julien,
>
> as you might have noticed I fixed #894751 quickly to enable progress in
> the libbpp* library set.  I agreed with ftpmaster Thorsten Alteholz that
> we'll do so in all other libbpp packages as soon as possible and he
> agreed to my argument that it is better than rejecting the packages since
> the new packages might trigger some other issues after the ABI change
> we could fix as well in another upload.  I just fixed the licence in Git
> of all libbpp* packages.  Please let me know whether you might plan some
> other change in the next couple of days.  Otherwise I'll go for a quick
> upload to fullfill my promise to ftpmaster. ;-)
>
> BTW, please check all other packages of yours.  The CeCILL license needs
> to be included in full text to fullfill the "isolated island" criterion
> which means that the user needs to be able to read the full text of a
> license even when beeing offline.  Since Debian is not providing a copy
> of the CeCILL license a full copy is needed.
>
> Kind regards
>
>  Andreas.
>
> --
> http://fam-tille.de
>



-- 
Julien Y. Dutheil, Ph-D
0 (+49) 6421 178 986

§ Max Planck Institute for Evolutionary Biology
Molecular Systems Evolution
Department of Evolutionary Genetics
Plön -- GERMANY

§ Institute of Evolutionary Sciences - Montpellier
University of Montpellier 2 -- FRANCE

Bug#890400: Any news about a new upstream version with new SONAME?

[Julien Yann Dutheil]

Dear Andreas,

bpp-phyl-omics pushed (once more had committed and forgotten to push, sorry
about that).

Best,

Julien.

On Sat, Mar 31, 2018 at 5:59 PM, Andreas Tille <ti...@debian.org> wrote:

> Hi Julien,
>
> On Sat, Mar 31, 2018 at 08:32:26AM +0200, Julien Yann Dutheil wrote:
> > Continuing to upload new versions, but keep getting messages like this
> one
> > when running debuild:
> > devlibs error: There is no package matching [libbpp-core-dev]
> >
> > Updating my packages + setting dhlibs > 0.82 in rules solved the issue
> for
> > some packages,
>
> Yes, since I added some overrides to  dhlibs = 0.82  and uploaded. :-)
>
> > but I keep facing it in libbpp-phyl-omics, and I ave no clue
> > why :s
> >
> > Any hint welcome,
>
> Just push and I'll check.
>
> Kind regards
>
> Andreas.
>
>


-- 
Julien Y. Dutheil, Ph-D
0 (+49) 6421 178 986

§ Max Planck Institute for Evolutionary Biology
Molecular Systems Evolution
Department of Evolutionary Genetics
Plön -- GERMANY

§ Institute of Evolutionary Sciences - Montpellier
University of Montpellier 2 -- FRANCE

Bug#890400: Any news about a new upstream version with new SONAME?

[Julien Yann Dutheil]

Hi

Continuing to upload new versions, but keep getting messages like this one
when running debuild:
devlibs error: There is no package matching [libbpp-core-dev]

Updating my packages + setting dhlibs > 0.82 in rules solved the issue for
some packages, but I keep facing it in libbpp-phyl-omics, and I ave no clue
why :s

Any hint welcome,

Julien.

On Mon, Mar 26, 2018 at 8:44 AM, Julien Yann Dutheil <
julien.duth...@univ-montp2.fr> wrote:

> This was actually a fresh clone... yet everything looks in order
> https://salsa.debian.org/med-team/libbpp-seq/branches ... is it safe to
> move forward?
>
> J.
>
> On Sun, Mar 25, 2018 at 11:21 PM, Andreas Tille <ti...@debian.org> wrote:
>
>> Looks strange.  May be you create a fresh clone and try again?
>>
>> On Sun, Mar 25, 2018 at 08:51:11PM +0200, Julien Yann Dutheil wrote:
>> > Dear Andreas,
>> >
>> > I moved forward with libbpp-seq, but after pushing I got the following
>> > message:
>> >
>> > remote: Resolving deltas: 100% (172/172), completed with 152 local
>> objects.
>> > remote:
>> > remote: To create a merge request for pristine-tar, visit:
>> > remote:
>> > https://salsa.debian.org/med-team/libbpp-seq/merge_requests/
>> new?merge_request%5Bsource_branch%5D=pristine-tar
>> > remote:
>> > remote: To create a merge request for upstream, visit:
>> > remote:
>> > https://salsa.debian.org/med-team/libbpp-seq/merge_requests/
>> new?merge_request%5Bsource_branch%5D=upstream
>> > remote:
>> >
>> > Clicking on the suggested links leads to a 404 error (I do not have
>> > permission to access this page).
>> >
>> > Is everything ok or did I somehow do sthg wrong?
>> >
>> > Best,
>> >
>> > Julien.
>> >
>> > On Thu, Mar 22, 2018 at 11:17 AM, Julien Yann Dutheil <
>> > julien.duth...@univ-montp2.fr> wrote:
>> >
>> > > Hi Andreas,
>> > >
>> > > On Thu, Mar 22, 2018 at 10:17 AM, Andreas Tille <ti...@debian.org>
>> wrote:
>> > >
>> > >> Hi Julien,
>> > >>
>> > >> On Wed, Mar 21, 2018 at 09:26:01PM +0100, Julien Yann Dutheil wrote:
>> > >> > I could somehow udate the symbols list, but still get a lintian
>> warning
>> > >> > [1].
>> > >>
>> > >> That was just a typo (see commit 06beb6872bb0c773aff727c25dfe07
>> > >> 77a7c401ca).
>> > >>
>> > >> Ok, thanks.
>> > >
>> > >
>> > >> > I have pushed my commits, would you mind giving them a look? Will
>> > >> > proceed with other libs once I have confirmation that everything
>> is ok.
>> > >>
>> > >> I've just uploaded.  I think the following lintian *infos* (lintian
>> -I)
>> > >> will be interesting for you:
>> > >>
>> > >> I: libbpp-core source: testsuite-autopkgtest-missing
>> > >> N:
>> > >> N:This package does not declare a test suite. Having a test suite
>> > >> helps
>> > >> N:with automated QA in response to changes in the archive. For
>> > >> example, if
>> > >> N:your package has a test suite, it is possible to re-execute
>> that
>> > >> test
>> > >> N:suite when any of the package dependencies has a new version
>> and
>> > >> check
>> > >> N:whether that update caused problems for your package.
>> > >> N:
>> > >> N:To declare a test suite, please add a debian/tests/control
>> file to
>> > >> your
>> > >> N:package.
>> > >> N:
>> > >> N:For more information on how to add functional tests to your
>> package,
>> > >> N:browse to https://ci.debian.net/doc/.
>> > >> N:
>> > >> N:Severity: wishlist, Certainty: certain
>> > >> N:
>> > >> N:Check: testsuite, Type: source
>> > >>
>> > >> May be you see a chance to tweak the build time test into an
>> autopkgtest.
>> > >>
>> > >> Humm... not sure how that integrates with our existing series of unit
>> > > tests at build time?
>> > >
>> > > I: libbpp-core4: spelling-error-in-binary
>> usr/lib/x86_64-linux-gnu/libbpp-core.so.4.0.0
>> > >> colums columns
>> > >> I:

Bug#890400: Any news about a new upstream version with new SONAME?

[Julien Yann Dutheil]

This was actually a fresh clone... yet everything looks in order
https://salsa.debian.org/med-team/libbpp-seq/branches ... is it safe to
move forward?

J.

On Sun, Mar 25, 2018 at 11:21 PM, Andreas Tille <ti...@debian.org> wrote:

> Looks strange.  May be you create a fresh clone and try again?
>
> On Sun, Mar 25, 2018 at 08:51:11PM +0200, Julien Yann Dutheil wrote:
> > Dear Andreas,
> >
> > I moved forward with libbpp-seq, but after pushing I got the following
> > message:
> >
> > remote: Resolving deltas: 100% (172/172), completed with 152 local
> objects.
> > remote:
> > remote: To create a merge request for pristine-tar, visit:
> > remote:
> > https://salsa.debian.org/med-team/libbpp-seq/merge_
> requests/new?merge_request%5Bsource_branch%5D=pristine-tar
> > remote:
> > remote: To create a merge request for upstream, visit:
> > remote:
> > https://salsa.debian.org/med-team/libbpp-seq/merge_
> requests/new?merge_request%5Bsource_branch%5D=upstream
> > remote:
> >
> > Clicking on the suggested links leads to a 404 error (I do not have
> > permission to access this page).
> >
> > Is everything ok or did I somehow do sthg wrong?
> >
> > Best,
> >
> > Julien.
> >
> > On Thu, Mar 22, 2018 at 11:17 AM, Julien Yann Dutheil <
> > julien.duth...@univ-montp2.fr> wrote:
> >
> > > Hi Andreas,
> > >
> > > On Thu, Mar 22, 2018 at 10:17 AM, Andreas Tille <ti...@debian.org>
> wrote:
> > >
> > >> Hi Julien,
> > >>
> > >> On Wed, Mar 21, 2018 at 09:26:01PM +0100, Julien Yann Dutheil wrote:
> > >> > I could somehow udate the symbols list, but still get a lintian
> warning
> > >> > [1].
> > >>
> > >> That was just a typo (see commit 06beb6872bb0c773aff727c25dfe07
> > >> 77a7c401ca).
> > >>
> > >> Ok, thanks.
> > >
> > >
> > >> > I have pushed my commits, would you mind giving them a look? Will
> > >> > proceed with other libs once I have confirmation that everything is
> ok.
> > >>
> > >> I've just uploaded.  I think the following lintian *infos* (lintian
> -I)
> > >> will be interesting for you:
> > >>
> > >> I: libbpp-core source: testsuite-autopkgtest-missing
> > >> N:
> > >> N:This package does not declare a test suite. Having a test suite
> > >> helps
> > >> N:with automated QA in response to changes in the archive. For
> > >> example, if
> > >> N:your package has a test suite, it is possible to re-execute that
> > >> test
> > >> N:suite when any of the package dependencies has a new version and
> > >> check
> > >> N:whether that update caused problems for your package.
> > >> N:
> > >> N:To declare a test suite, please add a debian/tests/control file
> to
> > >> your
> > >> N:package.
> > >> N:
> > >> N:For more information on how to add functional tests to your
> package,
> > >> N:browse to https://ci.debian.net/doc/.
> > >> N:
> > >> N:Severity: wishlist, Certainty: certain
> > >> N:
> > >> N:Check: testsuite, Type: source
> > >>
> > >> May be you see a chance to tweak the build time test into an
> autopkgtest.
> > >>
> > >> Humm... not sure how that integrates with our existing series of unit
> > > tests at build time?
> > >
> > > I: libbpp-core4: spelling-error-in-binary usr/lib/x86_64-linux-gnu/
> libbpp-core.so.4.0.0
> > >> colums columns
> > >> I: libbpp-core4: spelling-error-in-binary usr/lib/x86_64-linux-gnu/
> libbpp-core.so.4.0.0
> > >> controled controlled
> > >> I: libbpp-core4: spelling-error-in-binary usr/lib/x86_64-linux-gnu/
> libbpp-core.so.4.0.0
> > >> wih with
> > >>
> > >> Please verify your code and simply fix with next upstream release if
> > >> these are no false positives.
> > >>
> > >> Wow, impressive! Fixed upstream. fortunately, no interface break :)
> > >
> > >>
> > >> Kind regards and thanks for your cooperation
> > >>
> > >> Thanks a lot for your patience and advice!
> > >
> > > Julien.
> > >
> > >>Andreas.
> > >>
> > >> --
> > >> http://fam-tille.de
> > >>
> > >>
> > >
> > >
> > > --
> > > Julien Y. Dutheil, Ph-D
> > > 0 (+49) 6421 178 986 <+49%206421%20178986>
> > >
> > > § Max Planck Institute for Evolutionary Biology
> > > Molecular Systems Evolution
> > > Department of Evolutionary Genetics
> > > Plön -- GERMANY
> > >
> > > § Institute of Evolutionary Sciences - Montpellier
> > > University of Montpellier 2 -- FRANCE
> > >
> >
> >
> >
> > --
> > Julien Y. Dutheil, Ph-D
> > 0 (+49) 4522 763 298
> >
> > § Max Planck Institute for Evolutionary Biology
> > Molecular Systems Evolution
> > Department of Evolutionary Genetics
> > Plön -- GERMANY
> >
> > § Institute of Evolutionary Sciences - Montpellier
> > University of Montpellier 2 -- FRANCE
>
> --
> http://fam-tille.de
>
>


-- 
Julien Y. Dutheil, Ph-D
0 (+49) 6421 178 986

§ Max Planck Institute for Evolutionary Biology
Molecular Systems Evolution
Department of Evolutionary Genetics
Plön -- GERMANY

§ Institute of Evolutionary Sciences - Montpellier
University of Montpellier 2 -- FRANCE

Bug#890400: Any news about a new upstream version with new SONAME?

[Julien Yann Dutheil]

Dear Andreas,

I moved forward with libbpp-seq, but after pushing I got the following
message:

remote: Resolving deltas: 100% (172/172), completed with 152 local objects.
remote:
remote: To create a merge request for pristine-tar, visit:
remote:
https://salsa.debian.org/med-team/libbpp-seq/merge_requests/new?merge_request%5Bsource_branch%5D=pristine-tar
remote:
remote: To create a merge request for upstream, visit:
remote:
https://salsa.debian.org/med-team/libbpp-seq/merge_requests/new?merge_request%5Bsource_branch%5D=upstream
remote:

Clicking on the suggested links leads to a 404 error (I do not have
permission to access this page).

Is everything ok or did I somehow do sthg wrong?

Best,

Julien.

On Thu, Mar 22, 2018 at 11:17 AM, Julien Yann Dutheil <
julien.duth...@univ-montp2.fr> wrote:

> Hi Andreas,
>
> On Thu, Mar 22, 2018 at 10:17 AM, Andreas Tille <ti...@debian.org> wrote:
>
>> Hi Julien,
>>
>> On Wed, Mar 21, 2018 at 09:26:01PM +0100, Julien Yann Dutheil wrote:
>> > I could somehow udate the symbols list, but still get a lintian warning
>> > [1].
>>
>> That was just a typo (see commit 06beb6872bb0c773aff727c25dfe07
>> 77a7c401ca).
>>
>> Ok, thanks.
>
>
>> > I have pushed my commits, would you mind giving them a look? Will
>> > proceed with other libs once I have confirmation that everything is ok.
>>
>> I've just uploaded.  I think the following lintian *infos* (lintian -I)
>> will be interesting for you:
>>
>> I: libbpp-core source: testsuite-autopkgtest-missing
>> N:
>> N:This package does not declare a test suite. Having a test suite
>> helps
>> N:with automated QA in response to changes in the archive. For
>> example, if
>> N:your package has a test suite, it is possible to re-execute that
>> test
>> N:suite when any of the package dependencies has a new version and
>> check
>> N:whether that update caused problems for your package.
>> N:
>> N:To declare a test suite, please add a debian/tests/control file to
>> your
>> N:package.
>> N:
>> N:For more information on how to add functional tests to your package,
>> N:browse to https://ci.debian.net/doc/.
>> N:
>> N:Severity: wishlist, Certainty: certain
>> N:
>> N:Check: testsuite, Type: source
>>
>> May be you see a chance to tweak the build time test into an autopkgtest.
>>
>> Humm... not sure how that integrates with our existing series of unit
> tests at build time?
>
> I: libbpp-core4: spelling-error-in-binary 
> usr/lib/x86_64-linux-gnu/libbpp-core.so.4.0.0
>> colums columns
>> I: libbpp-core4: spelling-error-in-binary 
>> usr/lib/x86_64-linux-gnu/libbpp-core.so.4.0.0
>> controled controlled
>> I: libbpp-core4: spelling-error-in-binary 
>> usr/lib/x86_64-linux-gnu/libbpp-core.so.4.0.0
>> wih with
>>
>> Please verify your code and simply fix with next upstream release if
>> these are no false positives.
>>
>> Wow, impressive! Fixed upstream. fortunately, no interface break :)
>
>>
>> Kind regards and thanks for your cooperation
>>
>> Thanks a lot for your patience and advice!
>
> Julien.
>
>>Andreas.
>>
>> --
>> http://fam-tille.de
>>
>>
>
>
> --
> Julien Y. Dutheil, Ph-D
> 0 (+49) 6421 178 986 <+49%206421%20178986>
>
> § Max Planck Institute for Evolutionary Biology
> Molecular Systems Evolution
> Department of Evolutionary Genetics
> Plön -- GERMANY
>
> § Institute of Evolutionary Sciences - Montpellier
> University of Montpellier 2 -- FRANCE
>



-- 
Julien Y. Dutheil, Ph-D
0 (+49) 4522 763 298

§ Max Planck Institute for Evolutionary Biology
Molecular Systems Evolution
Department of Evolutionary Genetics
Plön -- GERMANY

§ Institute of Evolutionary Sciences - Montpellier
University of Montpellier 2 -- FRANCE

Bug#890400: Any news about a new upstream version with new SONAME?

[Julien Yann Dutheil]

Hi Andreas,

On Thu, Mar 22, 2018 at 10:17 AM, Andreas Tille <ti...@debian.org> wrote:

> Hi Julien,
>
> On Wed, Mar 21, 2018 at 09:26:01PM +0100, Julien Yann Dutheil wrote:
> > I could somehow udate the symbols list, but still get a lintian warning
> > [1].
>
> That was just a typo (see commit 06beb6872bb0c773aff727c25dfe07
> 77a7c401ca).
>
> Ok, thanks.


> > I have pushed my commits, would you mind giving them a look? Will
> > proceed with other libs once I have confirmation that everything is ok.
>
> I've just uploaded.  I think the following lintian *infos* (lintian -I)
> will be interesting for you:
>
> I: libbpp-core source: testsuite-autopkgtest-missing
> N:
> N:This package does not declare a test suite. Having a test suite helps
> N:with automated QA in response to changes in the archive. For
> example, if
> N:your package has a test suite, it is possible to re-execute that test
> N:suite when any of the package dependencies has a new version and
> check
> N:whether that update caused problems for your package.
> N:
> N:To declare a test suite, please add a debian/tests/control file to
> your
> N:package.
> N:
> N:For more information on how to add functional tests to your package,
> N:browse to https://ci.debian.net/doc/.
> N:
> N:Severity: wishlist, Certainty: certain
> N:
> N:Check: testsuite, Type: source
>
> May be you see a chance to tweak the build time test into an autopkgtest.
>
> Humm... not sure how that integrates with our existing series of unit
tests at build time?

I: libbpp-core4: spelling-error-in-binary
usr/lib/x86_64-linux-gnu/libbpp-core.so.4.0.0
> colums columns
> I: libbpp-core4: spelling-error-in-binary 
> usr/lib/x86_64-linux-gnu/libbpp-core.so.4.0.0
> controled controlled
> I: libbpp-core4: spelling-error-in-binary 
> usr/lib/x86_64-linux-gnu/libbpp-core.so.4.0.0
> wih with
>
> Please verify your code and simply fix with next upstream release if
> these are no false positives.
>
> Wow, impressive! Fixed upstream. fortunately, no interface break :)

>
> Kind regards and thanks for your cooperation
>
> Thanks a lot for your patience and advice!

Julien.

>Andreas.
>
> --
> http://fam-tille.de
>
>


-- 
Julien Y. Dutheil, Ph-D
0 (+49) 6421 178 986

§ Max Planck Institute for Evolutionary Biology
Molecular Systems Evolution
Department of Evolutionary Genetics
Plön -- GERMANY

§ Institute of Evolutionary Sciences - Montpellier
University of Montpellier 2 -- FRANCE

Bug#890400: Any news about a new upstream version with new SONAME?

[Julien Yann Dutheil]

Dear Andreas,

I could somehow udate the symbols list, but still get a lintian warning
[1]. I have pushed my commits, would you mind giving them a look? Will
proceed with other libs once I have confirmation that everything is ok.

Best,

Julien.

[1]
https://lintian.debian.org/tags/symbols-declares-dependency-on-other-package.html

On Wed, Mar 21, 2018 at 6:15 PM, Andreas Tille <ti...@debian.org> wrote:

> Hi Julien,
>
> On Wed, Mar 21, 2018 at 05:25:10PM +0100, Julien Yann Dutheil wrote:
> > I'm starting to package libbpp-core4 from upstream. It works fine but I
> > have a warning because of the symbol files which are not matching. My
> > understanding is that this is due to your previous (unreleased) patch
> which
> > was incrementing the interface number for version 2.3.2. How can I solve
> > that? (basically, discard the previous symbols and use the new one
> instead,
> > as they correspond to the new "official" .so.4 version?).
>
> The build log contains a diff you can use as patch.
>
> > I have not pushed
> > my commits yet, let me know if you need them already.
>
> Feel free to push and ping me in case of trouble so I can fix it.
>
> Kind regards
>
>Andreas.
>
> --
> http://fam-tille.de
>
>


-- 
Julien Y. Dutheil, Ph-D
0 (+49) 6421 178 986

§ Max Planck Institute for Evolutionary Biology
Molecular Systems Evolution
Department of Evolutionary Genetics
Plön -- GERMANY

§ Institute of Evolutionary Sciences - Montpellier
University of Montpellier 2 -- FRANCE

Bug#890400: Any news about a new upstream version with new SONAME?

[Julien Yann Dutheil]

Dear Andreas,

I'm starting to package libbpp-core4 from upstream. It works fine but I
have a warning because of the symbol files which are not matching. My
understanding is that this is due to your previous (unreleased) patch which
was incrementing the interface number for version 2.3.2. How can I solve
that? (basically, discard the previous symbols and use the new one instead,
as they correspond to the new "official" .so.4 version?). I have not pushed
my commits yet, let me know if you need them already.

Thanks,

Julien.

On Wed, Mar 14, 2018 at 9:38 AM, Andreas Tille <ti...@debian.org> wrote:

> Hi Julien,
>
> On Wed, Mar 14, 2018 at 09:19:51AM +0100, Julien Yann Dutheil wrote:
> > I am almost done! As we were to change the soname, I took the chance to
> fix
> > another gcc7 issue, that is to remove all dynamic exception
> specifications
> > in all libraries. Got interupted by some travelling, but I plan to finish
> > this by the end of this week.
> > Sorry again for the delay,
>
> That's fine - thanks for the update
>
>  Andreas.
>
> --
> http://fam-tille.de
>
>


-- 
Julien Y. Dutheil, Ph-D
0 (+49) 6421 178 986

§ Max Planck Institute for Evolutionary Biology
Molecular Systems Evolution
Department of Evolutionary Genetics
Plön -- GERMANY

§ Institute of Evolutionary Sciences - Montpellier
University of Montpellier 2 -- FRANCE

Bug#890400: Any news about a new upstream version with new SONAME?

[Julien Yann Dutheil]

Hi Andreas,

I am almost done! As we were to change the soname, I took the chance to fix
another gcc7 issue, that is to remove all dynamic exception specifications
in all libraries. Got interupted by some travelling, but I plan to finish
this by the end of this week.
Sorry again for the delay,

Cheers,

Julien.

On Wed, Mar 14, 2018 at 7:45 AM, Andreas Tille  wrote:

> Hi Julien,
>
> I wonder whether you've found a solution upstream or whether it might be
> better to upload my proposed soname bump inside the Debian package.
>
> Kind regards
>
>Andreas.
>
> --
> http://fam-tille.de
>
>


-- 
Julien Y. Dutheil, Ph-D
0 (+49) 6421 178 986

§ Max Planck Institute for Evolutionary Biology
Molecular Systems Evolution
Department of Evolutionary Genetics
Plön -- GERMANY

§ Institute of Evolutionary Sciences - Montpellier
University of Montpellier 2 -- FRANCE

Bug#890400: Soname bump + symbols file in Git - please verify: Bug#890400: physamp: autopkgtest failure

[Julien Yann Dutheil]

Dear Andreas,

Thanks a lot for the proposal. I would like to fix that one upstream to, so
I will probably upload a new version.
More generally, we'e thinking of some ways to improve things upstream,
because a minor version update should not lead to an interface break in my
opinion...

Best,

Julien.

On Thu, Feb 15, 2018 at 4:00 PM, Andreas Tille  wrote:

> Control: tags -1 pending
>
> Hi Julien,
>
> I've commited a *proposal* in Git.  I did not uploaded yet since I have
> no idea whether you as upstream would prefer a different solution to
> solve this issue.
>
> In any case I also added a symbols file.  If we had this before it would
> have ringed a bell for the symbols change.
>
> Please let me know what you think.
>
> Kind regards
>
>Andreas.
>
> --
> http://fam-tille.de
>



-- 
Julien Y. Dutheil, Ph-D
0 (+49) 6421 178 986

§ Max Planck Institute for Evolutionary Biology
Molecular Systems Evolution
Department of Evolutionary Genetics
Plön -- GERMANY

§ Institute of Evolutionary Sciences - Montpellier
University of Montpellier 2 -- FRANCE

Bug#890400: physamp: autopkgtest failure

[Julien Yann Dutheil]

Will do, also for maffilter.

J.

On 14 Feb 2018 13:15, "Andreas Tille"  wrote:

> Hi Graham,
>
> I guess Julien Dutheil will care for a patch.
>
> Kind regards
>
>Andreas.
>
> On Wed, Feb 14, 2018 at 02:00:18PM +0200, Graham Inggs wrote:
> > Source: physamp
> > Version: 1.0.3-1
> > Severity: serious
> > User: ubuntu-de...@lists.ubuntu.com
> > Usertags: origin-ubuntu bionic autopkgtest
> >
> > Hi Maintainer
> >
> > Since the upload of libbpp-core 2.3.2-1, physamp's autopkgtests have been
> > failing [1] with the following error:
> >
> > autopkgtest [03:46:54]: test run-unit-test: [---
> > bppalnoptim: symbol lookup error: bppalnoptim: undefined symbol: _
> ZN3bpp16ApplicationTools18getDoubleParameterERKNSt7__
> cxx1112basic_stringIcSt11char_traitsIcESaIcEEERSt3mapIS6_S6_
> St4lessIS6_ESaISt4pairIS7_S6_EEEdS8_bi
> > autopkgtest [03:46:55]: test run-unit-test: ---]
> > autopkgtest [03:46:55]: test run-unit-test:  - - - - - - - - - - results
> - -
> > - - - - - - - -
> > run-unit-testFAIL non-zero exit status 127
> >
> >
> > It looks like a symbol was dropped and a transition is needed.
> >
> > Regards
> > Graham
> >
> >
> > [1] https://ci.debian.net/packages/p/physamp/unstable/amd64/
> >
> > ___
> > Debian-med-packaging mailing list
> > debian-med-packag...@lists.alioth.debian.org
> > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/
> debian-med-packaging
> >
>
> --
> http://fam-tille.de
>

Bug#889953: libbpp-phyl FTBFS on 32bit: RegisterRatesSubstitutionModel.h:154:36: error: invalid covariant return type

[Julien Yann Dutheil]

Hi,

I have committed a patch. But there are other errors like:

In file included from /usr/include/c++/7/bits/stl_algobase.h:67:0,
 from /usr/include/c++/7/bits/char_traits.h:39,
 from /usr/include/c++/7/string:40,
 from /usr/include/Bpp/Numeric/VectorExceptions.h:46,
 from /usr/include/Bpp/Numeric/VectorTools.h:43,
 from
/usr/include/Bpp/Numeric/Prob/DiscreteDistribution.h:43,
 from
/usr/include/Bpp/Io/IoDiscreteDistributionFactory.h:43,
 from
/usr/include/Bpp/Io/BppODiscreteDistributionFormat.h:43,
 from
/<>/src/Bpp/Phyl/Io/BppORateDistributionFormat.h:43,
 from
/<>/src/Bpp/Phyl/Io/BppORateDistributionFormat.cpp:40:
/usr/include/c++/7/bits/stl_iterator.h: In function 'decltype
(std::__miter_base(__it.base()))
std::__miter_base(std::move_iterator<_IteratorL>) [with _Iterator =
double*]':
/usr/include/c++/7/bits/stl_iterator.h:1241:5: note: parameter passing for
argument of type 'std::move_iterator' changed in GCC 7.1
 __miter_base(move_iterator<_Iterator> __it)
 ^~~~

which I am unsure how to handle...

Julien.

On Fri, Feb 9, 2018 at 8:41 AM, Adrian Bunk  wrote:

> Source: libbpp-phyl
> Version: 2.3.2-1
> Severity: serious
>
> https://buildd.debian.org/status/package.php?p=libbpp-phyl=sid
>
> ...
> In file included from /<>/src/Bpp/Phyl/Io/
> BppOSubstitutionModelFormat.cpp:113:0:
> /<>/src/Bpp/Phyl/Io/../Model/RegisterRatesSubstitutionModel.h:154:36:
> error: invalid covariant return type for 'virtual std::vector int> bpp::RegisterRatesSubstitutionModel::getModelStates(int) const'
>  std::vector getModelStates(int i) const
> ^~
> In file included from /<>/src/Bpp/Phyl/Io/../Model/Codon/../
> AbstractBiblioSubstitutionModel.h:44:0,
>  from /<>/src/Bpp/Phyl/
> Io/../Model/Codon/MG94.h:43,
>  from /<>/src/Bpp/Phyl/Io/
> BppOSubstitutionModelFormat.cpp:50:
> /<>/src/Bpp/Phyl/Io/../Model/Codon/../AbstractWrappedModel.h:77:25:
> error:   overriding 'virtual std::vector
> bpp::AbstractWrappedModel::getModelStates(int) const'
>  std::vector getModelStates(int code) const { return
> getModel().getModelStates(code); }
>  ^~
>
>


-- 
Julien Y. Dutheil, Ph-D
0 (+49) 4522 763 298

§ Max Planck Institute for Evolutionary Biology
Molecular Systems Evolution
Department of Evolutionary Genetics
Plön -- GERMANY

§ Institute of Evolutionary Sciences - Montpellier
University of Montpellier 2 -- FRANCE

Bug#874835: [bppphyview] Future Qt4 removal from Buster

[Julien Yann Dutheil]

Dear Andreas,

Sorry, I only did push and not push --all, this is now corrected. libbpp-qt
now works, but I had to split the regex in 3 to get it to work. The dev
package is apparently now named qtdeclarative5-dev.

I still need to proceed the 2 omics libs and the program packages, I will
pas a message to the list when everything is ready.

Cheers,

Julien.

On Wed, Feb 7, 2018 at 8:41 AM, Andreas Tille <ti...@debian.org> wrote:

> On Tue, Feb 06, 2018 at 10:24:58PM +0100, Julien Yann Dutheil wrote:
> > Hi,
> >
> > While trying to update the libbpp-qt package to use Qt5 instead of Qt4,
> I'm
> > getting this error (using debuild -us -uc):
> >
> > devlibs error: There is no package matching [libQt5Core5-dev] and noone
> > provides it, please report bug to d-shlibs maintainer
> > devlibs error: There is no package matching [libQt5Gui5-dev] and noone
> > provides it, please report bug to d-shlibs maintainer
> > devlibs error: There is no package matching [libQt5Widgets5-dev] and
> noone
> > provides it, please report bug to d-shlibs maintainer
> >
> > Any idea of what is going on?
>
> Yes, that's caused by d-shlibs.  D-shlibs is verifying the existence of
> the library and assumes that a package is named like the library.  If
> the package name is different from the library name you sometimes need
> an override (several overrides are contained in d-shlibs - I'll sent a
> patch once we found the correct one to simplify the rules file).
>
> I commited an **untested** override which hopefully works - may be the
> regexp needs some adjustment.  I was not able to test since I would have
> needed to build all the other libs which I do not have time right now.
> If you confirm that the other libbpp* packages are ready for upload I'll
> do so step by step and then I'll check libbpp-qt.
>
> Hint: For libbpp-qt pristine-tar was not updated.  I did so now but
> please make sure the other libbpp* repositories are updated as well
> since this simplifies my work. :-)
>
> > The code otherwise compiles smoothly. I can
> > see the packages for Qt5 changed names (no more libqt5-dev, etc), and I
> am
> > probably missing sthg :s Git repos is updated to reproduce the error.
> >
> > Any insight welcome!
>
> Hope this hint was sufficiently helpful
>
>  Andreas.
>
> --
> http://fam-tille.de
>



-- 
Julien Y. Dutheil, Ph-D
0 (+49) 6421 178 986

§ Max Planck Institute for Evolutionary Biology
Molecular Systems Evolution
Department of Evolutionary Genetics
Plön -- GERMANY

§ Institute of Evolutionary Sciences - Montpellier
University of Montpellier 2 -- FRANCE

Bug#874835: [bppphyview] Future Qt4 removal from Buster

[Julien Yann Dutheil]

Hi,

While trying to update the libbpp-qt package to use Qt5 instead of Qt4, I'm
getting this error (using debuild -us -uc):

devlibs error: There is no package matching [libQt5Core5-dev] and noone
provides it, please report bug to d-shlibs maintainer
devlibs error: There is no package matching [libQt5Gui5-dev] and noone
provides it, please report bug to d-shlibs maintainer
devlibs error: There is no package matching [libQt5Widgets5-dev] and noone
provides it, please report bug to d-shlibs maintainer

Any idea of what is going on? The code otherwise compiles smoothly. I can
see the packages for Qt5 changed names (no more libqt5-dev, etc), and I am
probably missing sthg :s Git repos is updated to reproduce the error.

Any insight welcome!

Julien.


On Wed, Dec 13, 2017 at 11:09 AM, Julien Yann Dutheil <
julien.duth...@univ-montp2.fr> wrote:

> Dear Andreas,
>
> The fix was made upstream on the master branch, but has not been released
> yet. We have recently discussed a change in our release strategies: we will
> release more frequently "minor" updates based on the master branch (version
> x.y.1, x.y.2 etc) which will only be distributed as source archives. I will
> only package the x.1, x.2, etc more serious updates. Maybe the watch file
> could only check for these new updates? Or should we use a distinct tagging
> system for the minor updates?
>
> Best,
>
> Julien.
>
> On Wed, Dec 13, 2017 at 10:43 AM, Andreas Tille <ti...@debian.org> wrote:
>
>> Dear Julien,
>>
>> thanks for the information.  The watch file did not catched any new
>> upstream version.  May be this needs to be adapted as well?
>>
>> Thanks for your quick response
>>
>>  Andreas.
>>
>> On Wed, Dec 13, 2017 at 10:08:18AM +0100, Julien Yann Dutheil wrote:
>> > Dear Andreas,
>> >
>> > The software was ported to Qt5 upstream, but still need to make a new
>> > package version. Will try do that asap.
>> >
>> > Best,
>> >
>> > Julien.
>> >
>> > On Wed, Dec 13, 2017 at 10:03 AM, Andreas Tille <ti...@debian.org>
>> wrote:
>> >
>> > > Hi Julien,
>> > >
>> > > could you please have a look?
>> > >
>> > > Kind regards
>> > >
>> > >  Andreas.
>> > >
>> > > On Sat, Sep 09, 2017 at 08:58:21PM +0200, Lisandro Damián Nicanor
>> Pérez
>> > > Meyer wrote:
>> > > > Source: bppphyview
>> > > > Version: 0.5.1-1
>> > > > Severity: wishlist
>> > > > User: debian-qt-...@lists.debian.org
>> > > > Usertags: qt4-removal
>> > > >
>> > > >
>> > > > Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
>> > > > as [announced] in:
>> > > >
>> > > > [announced] <https://lists.debian.org/debi
>> an-devel-announce/2017/08/
>> > > msg6.html>
>> > > >
>> > > > Currently Qt4 has been dead upstream and we are starting to have
>> problems
>> > > > maintaining it, like for example in the [OpenSSL 1.1 support] case.
>> > > >
>> > > > [OpenSSL 1.1 support] <https://bugs.debian.org/cgi-
>> > > bin/bugreport.cgi?bug=828522>
>> > > >
>> > > > In order to make this move, all packages directly or indirectly
>> > > depending on
>> > > > the Qt4 libraries have to either get ported to Qt5 or eventually get
>> > > > removed from the Debian repositories.
>> > > >
>> > > > Therefore, please take the time and:
>> > > > - contact your upstream (if existing) and ask about the state of a
>> Qt5
>> > > > port of your application
>> > > > - if there are no activities regarding porting, investigate whether
>> > > there are
>> > > > suitable alternatives for your users
>> > > > - if there is a Qt5 port that is not yet packaged, consider
>> packaging it
>> > > > - if both the Qt4 and the Qt5 versions already coexist in the Debian
>> > > > archives, consider removing the Qt4 version
>> > > >
>> > > > = Porting =
>> > > >
>> > > > Some of us where involved in various Qt4 to Qt5 migrations
>> [migration]
>> > > and we
>> > > > know for sure that porting stuff from Qt4 to Qt5 is much much
>> easier and
>> > > less
>> > > > painful than it was from Qt3 to Qt4.
>&

Bug#874835: [bppphyview] Future Qt4 removal from Buster

[Julien Yann Dutheil]

Dear Andreas,

The fix was made upstream on the master branch, but has not been released
yet. We have recently discussed a change in our release strategies: we will
release more frequently "minor" updates based on the master branch (version
x.y.1, x.y.2 etc) which will only be distributed as source archives. I will
only package the x.1, x.2, etc more serious updates. Maybe the watch file
could only check for these new updates? Or should we use a distinct tagging
system for the minor updates?

Best,

Julien.

On Wed, Dec 13, 2017 at 10:43 AM, Andreas Tille <ti...@debian.org> wrote:

> Dear Julien,
>
> thanks for the information.  The watch file did not catched any new
> upstream version.  May be this needs to be adapted as well?
>
> Thanks for your quick response
>
>  Andreas.
>
> On Wed, Dec 13, 2017 at 10:08:18AM +0100, Julien Yann Dutheil wrote:
> > Dear Andreas,
> >
> > The software was ported to Qt5 upstream, but still need to make a new
> > package version. Will try do that asap.
> >
> > Best,
> >
> > Julien.
> >
> > On Wed, Dec 13, 2017 at 10:03 AM, Andreas Tille <ti...@debian.org>
> wrote:
> >
> > > Hi Julien,
> > >
> > > could you please have a look?
> > >
> > > Kind regards
> > >
> > >  Andreas.
> > >
> > > On Sat, Sep 09, 2017 at 08:58:21PM +0200, Lisandro Damián Nicanor Pérez
> > > Meyer wrote:
> > > > Source: bppphyview
> > > > Version: 0.5.1-1
> > > > Severity: wishlist
> > > > User: debian-qt-...@lists.debian.org
> > > > Usertags: qt4-removal
> > > >
> > > >
> > > > Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
> > > > as [announced] in:
> > > >
> > > > [announced] <https://lists.debian.org/debian-devel-announce/2017/08/
> > > msg6.html>
> > > >
> > > > Currently Qt4 has been dead upstream and we are starting to have
> problems
> > > > maintaining it, like for example in the [OpenSSL 1.1 support] case.
> > > >
> > > > [OpenSSL 1.1 support] <https://bugs.debian.org/cgi-
> > > bin/bugreport.cgi?bug=828522>
> > > >
> > > > In order to make this move, all packages directly or indirectly
> > > depending on
> > > > the Qt4 libraries have to either get ported to Qt5 or eventually get
> > > > removed from the Debian repositories.
> > > >
> > > > Therefore, please take the time and:
> > > > - contact your upstream (if existing) and ask about the state of a
> Qt5
> > > > port of your application
> > > > - if there are no activities regarding porting, investigate whether
> > > there are
> > > > suitable alternatives for your users
> > > > - if there is a Qt5 port that is not yet packaged, consider
> packaging it
> > > > - if both the Qt4 and the Qt5 versions already coexist in the Debian
> > > > archives, consider removing the Qt4 version
> > > >
> > > > = Porting =
> > > >
> > > > Some of us where involved in various Qt4 to Qt5 migrations
> [migration]
> > > and we
> > > > know for sure that porting stuff from Qt4 to Qt5 is much much easier
> and
> > > less
> > > > painful than it was from Qt3 to Qt4.
> > > >
> > > > We also understand that there is still a lot of software still using
> Qt4.
> > > >
> > > > Don't forget to take a look at the C++ API changes page [apichanges]
> > > whenever
> > > > you start porting your application.
> > > >
> > > > [migration] http://pkg-kde.alioth.debian.
> org/packagingqtbasedstuff.html
> > > > [apichanges] http://doc.qt.io/qt-5/sourcebreaks.html
> > > >
> > > > For any questions and issues, do not hesitate to contact the Debian
> > > Qt/KDE
> > > > team at debian-qt-...@lists.debian.org
> > > >
> > > > The removal is being tracked in <https://wiki.debian.org/Qt4Removal>
> > > >
> > > > Lisandro,
> > > > on behalf of the Qt4 maintainers
> > > >
> > > > ___
> > > > Debian-med-packaging mailing list
> > > > debian-med-packag...@lists.alioth.debian.org
> > > > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/
> > > debian-med-packaging
> > > >
> > >
> > > --
> > > http://fam-tille.de
> > >
> >
> >
> >
> > --
> > Julien Y. Dutheil, Ph-D
> > 0 (+49) 6421 178 986
> >
> > § Max Planck Institute for Evolutionary Biology
> > Molecular Systems Evolution
> > Department of Evolutionary Genetics
> > Plön -- GERMANY
> >
> > § Institute of Evolutionary Sciences - Montpellier
> > University of Montpellier 2 -- FRANCE
>
> --
> http://fam-tille.de
>



-- 
Julien Y. Dutheil, Ph-D
0 (+49) 6421 178 986

§ Max Planck Institute for Evolutionary Biology
Molecular Systems Evolution
Department of Evolutionary Genetics
Plön -- GERMANY

§ Institute of Evolutionary Sciences - Montpellier
University of Montpellier 2 -- FRANCE

Bug#874835: [bppphyview] Future Qt4 removal from Buster

[Julien Yann Dutheil]

Dear Andreas,

The software was ported to Qt5 upstream, but still need to make a new
package version. Will try do that asap.

Best,

Julien.

On Wed, Dec 13, 2017 at 10:03 AM, Andreas Tille  wrote:

> Hi Julien,
>
> could you please have a look?
>
> Kind regards
>
>  Andreas.
>
> On Sat, Sep 09, 2017 at 08:58:21PM +0200, Lisandro Damián Nicanor Pérez
> Meyer wrote:
> > Source: bppphyview
> > Version: 0.5.1-1
> > Severity: wishlist
> > User: debian-qt-...@lists.debian.org
> > Usertags: qt4-removal
> >
> >
> > Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
> > as [announced] in:
> >
> > [announced]  msg6.html>
> >
> > Currently Qt4 has been dead upstream and we are starting to have problems
> > maintaining it, like for example in the [OpenSSL 1.1 support] case.
> >
> > [OpenSSL 1.1 support]  bin/bugreport.cgi?bug=828522>
> >
> > In order to make this move, all packages directly or indirectly
> depending on
> > the Qt4 libraries have to either get ported to Qt5 or eventually get
> > removed from the Debian repositories.
> >
> > Therefore, please take the time and:
> > - contact your upstream (if existing) and ask about the state of a Qt5
> > port of your application
> > - if there are no activities regarding porting, investigate whether
> there are
> > suitable alternatives for your users
> > - if there is a Qt5 port that is not yet packaged, consider packaging it
> > - if both the Qt4 and the Qt5 versions already coexist in the Debian
> > archives, consider removing the Qt4 version
> >
> > = Porting =
> >
> > Some of us where involved in various Qt4 to Qt5 migrations [migration]
> and we
> > know for sure that porting stuff from Qt4 to Qt5 is much much easier and
> less
> > painful than it was from Qt3 to Qt4.
> >
> > We also understand that there is still a lot of software still using Qt4.
> >
> > Don't forget to take a look at the C++ API changes page [apichanges]
> whenever
> > you start porting your application.
> >
> > [migration] http://pkg-kde.alioth.debian.org/packagingqtbasedstuff.html
> > [apichanges] http://doc.qt.io/qt-5/sourcebreaks.html
> >
> > For any questions and issues, do not hesitate to contact the Debian
> Qt/KDE
> > team at debian-qt-...@lists.debian.org
> >
> > The removal is being tracked in 
> >
> > Lisandro,
> > on behalf of the Qt4 maintainers
> >
> > ___
> > Debian-med-packaging mailing list
> > debian-med-packag...@lists.alioth.debian.org
> > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/
> debian-med-packaging
> >
>
> --
> http://fam-tille.de
>



-- 
Julien Y. Dutheil, Ph-D
0 (+49) 6421 178 986

§ Max Planck Institute for Evolutionary Biology
Molecular Systems Evolution
Department of Evolutionary Genetics
Plön -- GERMANY

§ Institute of Evolutionary Sciences - Montpellier
University of Montpellier 2 -- FRANCE

Bug#875009: [libbpp-qt] Future Qt4 removal from Buster

[Julien Yann Dutheil]

Hi,

Just ported bpp-qt and bppphyview to Qt5 upstream. Dependency to Qt4 will
therefore be removed in next release.

Best,

Julien.

On Sun, Sep 10, 2017 at 8:47 AM, Julien Yann Dutheil <
julien.duth...@univ-montp2.fr> wrote:

> Hi Andreas, Lisandro,
>
> Will port libbpp-qt and bppphyview to Qt5, this is planned. I cannot
> commit myself to any delay however. As these two packages have no further
> dependencies, they can temporarily be removed without too much hassle.
>
> Best,
>
> Julien.
>
> On Sat, Sep 9, 2017 at 11:35 PM, Andreas Tille <ti...@debian.org> wrote:
>
>> control: forwarded -1 Julien Dutheil <julien.duth...@univ-montp2.fr>
>> control: tags -1 upstream
>>
>> Hi Julien,
>>
>> could you please have a look.
>>
>> Kind regards
>>
>>   Andreas.
>>
>> On Sat, Sep 09, 2017 at 10:08:55PM +0200, Lisandro Damián Nicanor Pérez
>> Meyer wrote:
>> > Source: libbpp-qt
>> > Version: 2.3.1-4
>> > Severity: wishlist
>> > User: debian-qt-...@lists.debian.org
>> > Usertags: qt4-removal
>> >
>> >
>> > Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
>> > as [announced] in:
>> >
>> > [announced] <https://lists.debian.org/debi
>> an-devel-announce/2017/08/msg6.html>
>> >
>> > Currently Qt4 has been dead upstream and we are starting to have
>> problems
>> > maintaining it, like for example in the [OpenSSL 1.1 support] case.
>> >
>> > [OpenSSL 1.1 support] <https://bugs.debian.org/cgi-b
>> in/bugreport.cgi?bug=828522>
>> >
>> > In order to make this move, all packages directly or indirectly
>> depending on
>> > the Qt4 libraries have to either get ported to Qt5 or eventually get
>> > removed from the Debian repositories.
>> >
>> > Therefore, please take the time and:
>> > - contact your upstream (if existing) and ask about the state of a Qt5
>> > port of your application
>> > - if there are no activities regarding porting, investigate whether
>> there are
>> > suitable alternatives for your users
>> > - if there is a Qt5 port that is not yet packaged, consider packaging it
>> > - if both the Qt4 and the Qt5 versions already coexist in the Debian
>> > archives, consider removing the Qt4 version
>> >
>> > = Porting =
>> >
>> > Some of us where involved in various Qt4 to Qt5 migrations [migration]
>> and we
>> > know for sure that porting stuff from Qt4 to Qt5 is much much easier
>> and less
>> > painful than it was from Qt3 to Qt4.
>> >
>> > We also understand that there is still a lot of software still using
>> Qt4.
>> >
>> > Don't forget to take a look at the C++ API changes page [apichanges]
>> whenever
>> > you start porting your application.
>> >
>> > [migration] http://pkg-kde.alioth.debian.org/packagingqtbasedstuff.html
>> > [apichanges] http://doc.qt.io/qt-5/sourcebreaks.html
>> >
>> > For any questions and issues, do not hesitate to contact the Debian
>> Qt/KDE
>> > team at debian-qt-...@lists.debian.org
>> >
>> > The removal is being tracked in <https://wiki.debian.org/Qt4Removal>
>> >
>> > Lisandro,
>> > on behalf of the Qt4 maintainers
>> >
>> > ___
>> > Debian-med-packaging mailing list
>> > debian-med-packag...@lists.alioth.debian.org
>> > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debi
>> an-med-packaging
>> >
>>
>> --
>> http://fam-tille.de
>>
>>
>
>
> --
> Julien Y. Dutheil, Ph-D
> 0 (+49) 6421 178 986 <+49%206421%20178986>
>
> § Max Planck Institute for Evolutionary Biology
> Molecular Systems Evolution
> Department of Evolutionary Genetics
> Plön -- GERMANY
>
> § Institute of Evolutionary Sciences - Montpellier
> University of Montpellier 2 -- FRANCE
>



-- 
Julien Y. Dutheil, Ph-D
0 (+49) 6421 178 986 <+49%206421%20178986>

§ Max Planck Institute for Evolutionary Biology
Molecular Systems Evolution
Department of Evolutionary Genetics
Plön -- GERMANY

§ Institute of Evolutionary Sciences - Montpellier
University of Montpellier 2 -- FRANCE

Bug#875009: [libbpp-qt] Future Qt4 removal from Buster

[Julien Yann Dutheil]

Hi Andreas, Lisandro,

Will port libbpp-qt and bppphyview to Qt5, this is planned. I cannot commit
myself to any delay however. As these two packages have no further
dependencies, they can temporarily be removed without too much hassle.

Best,

Julien.

On Sat, Sep 9, 2017 at 11:35 PM, Andreas Tille  wrote:

> control: forwarded -1 Julien Dutheil 
> control: tags -1 upstream
>
> Hi Julien,
>
> could you please have a look.
>
> Kind regards
>
>   Andreas.
>
> On Sat, Sep 09, 2017 at 10:08:55PM +0200, Lisandro Damián Nicanor Pérez
> Meyer wrote:
> > Source: libbpp-qt
> > Version: 2.3.1-4
> > Severity: wishlist
> > User: debian-qt-...@lists.debian.org
> > Usertags: qt4-removal
> >
> >
> > Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
> > as [announced] in:
> >
> > [announced]  msg6.html>
> >
> > Currently Qt4 has been dead upstream and we are starting to have problems
> > maintaining it, like for example in the [OpenSSL 1.1 support] case.
> >
> > [OpenSSL 1.1 support]  bin/bugreport.cgi?bug=828522>
> >
> > In order to make this move, all packages directly or indirectly
> depending on
> > the Qt4 libraries have to either get ported to Qt5 or eventually get
> > removed from the Debian repositories.
> >
> > Therefore, please take the time and:
> > - contact your upstream (if existing) and ask about the state of a Qt5
> > port of your application
> > - if there are no activities regarding porting, investigate whether
> there are
> > suitable alternatives for your users
> > - if there is a Qt5 port that is not yet packaged, consider packaging it
> > - if both the Qt4 and the Qt5 versions already coexist in the Debian
> > archives, consider removing the Qt4 version
> >
> > = Porting =
> >
> > Some of us where involved in various Qt4 to Qt5 migrations [migration]
> and we
> > know for sure that porting stuff from Qt4 to Qt5 is much much easier and
> less
> > painful than it was from Qt3 to Qt4.
> >
> > We also understand that there is still a lot of software still using Qt4.
> >
> > Don't forget to take a look at the C++ API changes page [apichanges]
> whenever
> > you start porting your application.
> >
> > [migration] http://pkg-kde.alioth.debian.org/packagingqtbasedstuff.html
> > [apichanges] http://doc.qt.io/qt-5/sourcebreaks.html
> >
> > For any questions and issues, do not hesitate to contact the Debian
> Qt/KDE
> > team at debian-qt-...@lists.debian.org
> >
> > The removal is being tracked in 
> >
> > Lisandro,
> > on behalf of the Qt4 maintainers
> >
> > ___
> > Debian-med-packaging mailing list
> > debian-med-packag...@lists.alioth.debian.org
> > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/
> debian-med-packaging
> >
>
> --
> http://fam-tille.de
>
>


-- 
Julien Y. Dutheil, Ph-D
0 (+49) 6421 178 986

§ Max Planck Institute for Evolutionary Biology
Molecular Systems Evolution
Department of Evolutionary Genetics
Plön -- GERMANY

§ Institute of Evolutionary Sciences - Montpellier
University of Montpellier 2 -- FRANCE

Bug#871085: [lu...@debian.org: Bug#871085: libbpp-phyl: FTBFS: collect2: error: ld returned 1 exit status]

[Julien Yann Dutheil]

Dear all,

I have committed a fix to the libraries. I propagated the
unforce-cxxflags.patch which was in libbpp-core to the other libs.
Hopefully this should remove the -Wall tags and allow the libraries to
compile smoothly. The deprecation warning is already addressed upstream and
modifications will be included in the next version.

Best,

Julien.

On Tue, Aug 8, 2017 at 4:09 PM, Andreas Tille <andr...@fam-tille.de> wrote:

> Hi Julien,
>
> On Mon, Aug 07, 2017 at 10:31:08PM +0200, Julien Yann Dutheil wrote:
> > These are deprecation warnings that we have now fixed upstream, but
> > including those fixes would mean making a new release. Would it be ok to
> > simply make a patch to remove the very strict -W g++ tags that we use
> > instead, for this version at least?
>
> Either way is fine.  If you think a new release is sensible - just do it
> as upstream.  A quilt patch fixing the actual problem in Debian is fine
> as well for sure.
>
> > Will investigate how to subscribe to the bug feeds.
>
> You can subscribe to single packages here:
>
>https://packages.qa.debian.org/common/index.html
>
> Alternatively you can subscribe the Debian Med maintainers list
>
>https://lists.alioth.debian.org/cgi-bin/mailman/listinfo/
> debian-med-packaging
>
> and get notification about all packages maintained by the Debian Med
> team which could be interesting but might be a bit noisy for your taste.
> Just check the archive of the list if you can bear that amount.
>
> Kind regards
>
>Andreas.
>
> --
> http://fam-tille.de
>



-- 
Julien Y. Dutheil, Ph-D
0 (+49) 6421 178 986

§ Max Planck Institute for Evolutionary Biology
Molecular Systems Evolution
Department of Evolutionary Genetics
Plön -- GERMANY

§ Institute of Evolutionary Sciences - Montpellier
University of Montpellier 2 -- FRANCE

Bug#868919: physamp: FTBFS: AlignmentOptimizer.cpp:39:32: fatal error: Bpp/Seq/Alphabet.all: No such file or directory

[Julien Yann Dutheil]

Hi Andreas,

On Thu, Jul 20, 2017 at 11:21 AM, Andreas Tille <andr...@an3as.eu> wrote:

> Hi Julien,
>
> On Thu, Jul 20, 2017 at 10:49:10AM +0200, Julien Yann Dutheil wrote:
> > Yes, should be. But I noticed some other problems... I have made a
> version
> > 1.0.2 addressing them. Then I synchronized the upstream branch
> accordingly,
> > and then merged the master branch and the upstream branch, is that the
> > correct way to do?
>
> Not really.
>

Humm, I should have suspected that, I went a bit too fast, sorry about
that. I have now proceeded as you said.

>
>
> > I also committed a patch for bppsuite on x32 arch.
>
> Two remarks:
>
>   1. Please leave the header information inside the patch
>  (Author, Description, etc.)
>

I am not sure I understand that point :s


>   2. x32 is not a released architecture.  So its for sure
>  fine to care for this as well but it is acceptable to
>  delay uploads until there are stronger reasons for
>  a new upload.  I'll upload now but may be will not in
>  future cases and keep the target "UNRELEASED" in Git.
>
> Sorry, one more point I was not aware of. Strangely, the underlying issue
was important, and it is surprising that it only led to an error on that
architecture.


> > Will now work on maffilter.
>
> Fine.
>

As maffilter only shows the same issue on the x32 arch, I leave it as is
for now. I will fix the underlying issue upstream so that it is fixed for
the next version, is that ok?

>
> Thanks again for your cooperation
>

Next on the list was the program called "comap" (also on
github.com/jydu/comap), but it is not on the debian git yet. Shall I try to
follow carefully the Debian Med policy and see if I can come to something
acceptable? With the experience I gained on the other packages, my chance
of success should be non null... (wishful thinking I know)

Best,

Julien.

>
>   Andreas.
>
> --
> http://fam-tille.de
>



-- 
Julien Y. Dutheil, Ph-D
0 (+49) 6421 178 986 <+49%206421%20178986>

§ Max Planck Institute for Evolutionary Biology
Molecular Systems Evolution
Department of Evolutionary Genetics
Plön -- GERMANY

§ Institute of Evolutionary Sciences - Montpellier
University of Montpellier 2 -- FRANCE

Bug#868919: physamp: FTBFS: AlignmentOptimizer.cpp:39:32: fatal error: Bpp/Seq/Alphabet.all: No such file or directory

[Julien Yann Dutheil]

Dear Andreas,

Yes, should be. But I noticed some other problems... I have made a version
1.0.2 addressing them. Then I synchronized the upstream branch accordingly,
and then merged the master branch and the upstream branch, is that the
correct way to do? Version 1.0.2-1 should then normally build fine.

I also committed a patch for bppsuite on x32 arch. Will now work on
maffilter.

Best,

Julien.

On Wed, Jul 19, 2017 at 6:15 PM, Andreas Tille  wrote:

> Hi Julien,
>
> I guess this issue is connected to our latest changes in the library
> packages.
>
> Kind regards
>
> Andreas.
>
> On Wed, Jul 19, 2017 at 05:52:18PM +0200, Lucas Nussbaum wrote:
> > Source: physamp
> > Version: 0.2.0-1
> > Severity: serious
> > Tags: buster sid
> > User: debian...@lists.debian.org
> > Usertags: qa-ftbfs-20170719 qa-ftbfs
> > Justification: FTBFS on amd64
> >
> > Hi,
> >
> > During a rebuild of all packages in sid, your package failed to build on
> > amd64.
> >
> > Relevant part (hopefully):
> > > cd /<>/obj-x86_64-linux-gnu/physamp && /usr/bin/c++
>  -Wall -Weffc++ -Wshadow -Wconversion   -o 
> CMakeFiles/bppalnoptim.dir/AlignmentOptimizer.cpp.o
> -c /<>/physamp/AlignmentOptimizer.cpp
> > > /<>/physamp/AlignmentOptimizer.cpp:39:32: fatal error:
> Bpp/Seq/Alphabet.all: No such file or directory
> > >  #include 
> > > ^
> > > compilation terminated.
> > > physamp/CMakeFiles/bppalnoptim.dir/build.make:65: recipe for target
> 'physamp/CMakeFiles/bppalnoptim.dir/AlignmentOptimizer.cpp.o' failed
> > > make[3]: *** [physamp/CMakeFiles/bppalnoptim.dir/AlignmentOptimizer.cpp.o]
> Error 1
> >
> > The full build log is available from:
> >http://aws-logs.debian.net/2017/07/19/physamp_0.2.0-1_unstable.log
> >
> > A list of current common problems and possible solutions is available at
> > http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to
> contribute!
> >
> > About the archive rebuild: The rebuild was done on EC2 VM instances from
> > Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
> > failed build was retried once to eliminate random failures.
> >
> > ___
> > Debian-med-packaging mailing list
> > debian-med-packag...@lists.alioth.debian.org
> > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/
> debian-med-packaging
> >
>
> --
> http://fam-tille.de
>



-- 
Julien Y. Dutheil, Ph-D
0 (+49) 6421 178 986

§ Max Planck Institute for Evolutionary Biology
Molecular Systems Evolution
Department of Evolutionary Genetics
Plön -- GERMANY

§ Institute of Evolutionary Sciences - Montpellier
University of Montpellier 2 -- FRANCE

Bug#866365: libbpp-phyl FTBFS with test failures

[Julien Yann Dutheil]

Hi Andreas,

But now at least these are all timeout issues, all numerical instabilities
seem to have now been solved. I have committed a fix that increases again
the timeout limit for the slow architectures (now 6s). This SHOULD now
work!

Best,

Julien.

On Mon, Jul 17, 2017 at 5:53 AM, Andreas Tille  wrote:

> Hi Julien,
>
> your last fix seems to have cured mipsel, but mips keeps
> on failing and now armhf has trouble:
>
> https://buildd.debian.org/status/package.php?p=libbpp-phyl
>
>
>
> --
> http://fam-tille.de
>
>


-- 
Julien Y. Dutheil, Ph-D
0 (+49) 4522 763 298

§ Max Planck Institute for Evolutionary Biology
Molecular Systems Evolution
Department of Evolutionary Genetics
Plön -- GERMANY

§ Institute of Evolutionary Sciences - Montpellier
University of Montpellier 2 -- FRANCE

Bug#865552: libbpp-phyl FTBFS with test failures

[Julien Yann Dutheil]

Dear Andreas,

Please find attached a patch that sets the timeout to 1s (default was
1500). Hope this improves things...

Best,

Julien.

On Fri, Jun 23, 2017 at 9:43 PM, Andreas Tille <ti...@debian.org> wrote:

> Hi Julien,
>
> On Fri, Jun 23, 2017 at 09:02:30PM +0200, Julien Yann Dutheil wrote:
> > This is most strange indeed. The errors are all "time out" errors on unit
> > tests which take the longest time (several min or so). Looks like some
> > issues with the default value for the timeout setting in CTest... I would
> > suggest to simply skip the unit tests by running "cmake
> > -DBUILD_TESTING=FALSE ." .  Does this solve the problem?
>
> Hmmm, this would most probably lead to successfully built packages but I
> would prefer spending some additional thoughts on this.  It would
> explain the issue why the package has built before but does not any more
> without any visible change on "weak" architectures.  I could imagine
> that after stretch release the run on the build servers increased and
> that possibly parallel builds are happening which lead to performance
> loss for single packages.
>
> Do you see any chance to increase the timeout settings by one order of
> magnitude to test this hypothesis?
>
> Kind regards
>
>   Andreas.
>
> --
> http://fam-tille.de
>



-- 
Julien Y. Dutheil, Ph-D
0 (+49) 6421 178 986

§ Max Planck Institute for Evolutionary Biology
Molecular Systems Evolution
Department of Evolutionary Genetics
Plön -- GERMANY

§ Institute of Evolutionary Sciences - Montpellier
University of Montpellier 2 -- FRANCE
commit 1d8fb92514f7cacfcf158de80b99cc13483437e7
Author: Julien Y. Dutheil <duth...@evolbio.mpg.de>
Date:   Sat Jun 24 23:41:39 2017 +0200

Added longer timeout for tests.

diff --git a/test/CMakeLists.txt b/test/CMakeLists.txt
index 206cef39..5e8cf244 100644
--- a/test/CMakeLists.txt
+++ b/test/CMakeLists.txt
@@ -21,4 +21,6 @@ foreach (test_cpp_file ${test_cpp_files})
 WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}
 COMMAND ${test_name}
 )
+  set_tests_properties (${test_name} PROPERTIES TIMEOUT 1)
 endforeach (test_cpp_file)
+

Bug#865552: libbpp-phyl FTBFS with test failures

[Julien Yann Dutheil]

Dear Andreas, Adrian,

This is most strange indeed. The errors are all "time out" errors on unit
tests which take the longest time (several min or so). Looks like some
issues with the default value for the timeout setting in CTest... I would
suggest to simply skip the unit tests by running "cmake
-DBUILD_TESTING=FALSE ." .  Does this solve the problem?

Best regards,

Julien.

On Fri, Jun 23, 2017 at 1:38 PM, Andreas Tille  wrote:

> Hi Adrian,
>
> thanks a lot for your continuous QA effort (I have the feeling that 90%
> of the Debian Med bugs were issued by you ;-) ).
>
> Julien, do you have some explanation for the issue?  I made sure that
> cmake files were found also on i386 so the issue now concerns
>Version: 2.3.1-3
> but bpp-phyl seems to have issues for non-Intel architectures which
> should be dealt by upstream.  I admit that I have not checked version
> 2.3.1-1 but according to Git the diff is
>
>
> $ git diff debian/2.3.1-1..debian/2.3.1-2
> diff --git a/debian/changelog b/debian/changelog
> index 0bfd365..28fd024 100644
> --- a/debian/changelog
> +++ b/debian/changelog
> @@ -1,3 +1,9 @@
> +libbpp-phyl (2.3.1-2) unstable; urgency=medium
> +
> +  * Make sure cmake files will be installed also on i386
> +
> + -- Andreas Tille   Thu, 22 Jun 2017 08:03:24 +0200
> +
>  libbpp-phyl (2.3.1-1) unstable; urgency=medium
>
>* New upstream version
> diff --git a/debian/rules b/debian/rules
> index 9d1fe92..3a46afc 100755
> --- a/debian/rules
> +++ b/debian/rules
> @@ -15,5 +15,5 @@ override_dh_install:
> --override 
> 's/libbpp-\([-a-z]\+\)[0-9]\+-dev/libbpp-\1-dev/'
> \
> --exclude-la \
>  --movedev debian/tmp/usr/include/* usr/include \
> ---movedev debian/tmp/usr/lib/$(DEB_HOST_GNU_TYPE)/cmake
> usr/lib/$(DEB_HOST_GNU_TYPE) \
> +--movedev debian/tmp/usr/lib/*/cmake
> usr/lib/$(DEB_HOST_GNU_TYPE) \
>  debian/tmp/usr/lib/*/*.so
>
>
> So I can not see any explanation for the test failures since the test is
> run before dh_install anyway.  I suspect some deeper issue here.
>
> Kind regards
>
>   Andreas.
>
> On Thu, Jun 22, 2017 at 08:13:02PM +0300, Adrian Bunk wrote:
> > Source: libbpp-phyl
> > Version: 2.3.1-2
> > Severity: serious
> >
> > https://buildd.debian.org/status/package.php?p=libbpp-phyl=sid
> >
> > I do not see any obvious reason why 2.3.1-2 fails on so many
> > architectures where 2.3.1-1 built just a few hours earlier.
>
> --
> http://fam-tille.de
>



-- 
Julien Y. Dutheil, Ph-D
0 (+49) 6421 178 986

§ Max Planck Institute for Evolutionary Biology
Molecular Systems Evolution
Department of Evolutionary Genetics
Plön -- GERMANY

§ Institute of Evolutionary Sciences - Montpellier
University of Montpellier 2 -- FRANCE

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

[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 <vdanjean...@free.fr> 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* <b...@debian.org <mailto:b...@debian.org>>
> > Date: Tue, Jun 6, 2017 at 11:48 AM
> > Subject: Re: Bug#864188: libbpp-core2v5: symbols removed without soname
> bump
> > To: Julien Yann Dutheil <duth...@evolbio.mpg.de  duth...@evolbio.mpg.de>>
> > Cc: Andreas Tille <ti...@debian.org <mailto:ti...@debian.org>>,
> 864...@bugs.debian.org <mailto:864...@bugs.debian.org>, GINDRAUD FRANCOIS
> <francois.gindr...@univ-lyon1.fr <mailto:francois.gindr...@univ-lyon1.fr>>
> >
> >
> > 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 <ti...@debian.org
> <mailto:ti...@debian.org>> 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.htm

Bug#864188: libbpp-core2v5: symbols removed without soname bump

[Julien Yann Dutheil]

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??

J.

-- Forwarded message --
From: Adrian Bunk <b...@debian.org>
Date: Tue, Jun 6, 2017 at 11:48 AM
Subject: Re: Bug#864188: libbpp-core2v5: symbols removed without soname bump
To: Julien Yann Dutheil <duth...@evolbio.mpg.de>
Cc: Andreas Tille <ti...@debian.org>, 864...@bugs.debian.org, GINDRAUD
FRANCOIS <francois.gindr...@univ-lyon1.fr>


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 <ti...@debian.org> 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<char, std::char_traits,
> > std::allocator > const&, std::__cxx11::basic_string<char,
> > 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<char, std::char_traits,
> > std::allocator > const&, std::map<std::__cxx11::basic_string<char,
> > std::char_traits, std::allocator >,
std::__cxx11::basic_string<char,
> > std::char_traits, std::allocator >,
> > std::less<std::__cxx11::basic_string<char, std::char_traits,
> > std::allocator > >, std::allocator<std::pair > std::char_traits, std::allocator > const,
> > std::__cxx11::basic_string<char, std::char_traits,
> > std::allocator > > > >&)'
> > > /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/
libbpp-seq.so:
> > undefined reference to `bpp::ApplicationTools::
getStringParameter(std::__cxx11::basic_string<char,
> > std::char_traits, std::allocator > const&,
> > std::map<std::__cxx11::basic_string<char, std::char_traits,
> > std::allocator >, std::__cxx11::basic_string<char,
> > std::char_traits, std::allocator >,
> > std::less<std::__cxx11::basic_string<char, std::char_traits,
> > std::allocator > >, std::allocator<std::pair > std::char_traits, std::all

Bug#864188: libbpp-core2v5: symbols removed without soname bump

[Julien Yann Dutheil]

Dear Andreas, Adrian,

Just to be sure I get everything right:
- The error you found before was due to building against a previous version
of bpp-core
- 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?

Best,

Julien.

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 >,
> std::less std::allocator > >, 
> std::allocator std::char_traits, std::allocator > const,
> std::__cxx11::basic_string std::allocator > > > >&)'
> > /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libbpp-seq.so:
> undefined reference to 
> `bpp::ApplicationTools::getStringParameter(std::__cxx11::basic_string std::char_traits, std::allocator > const&,
> std::map std::allocator >, std::__cxx11::basic_string std::char_traits, std::allocator >,
> std::less std::allocator > >, 
> std::allocator std::char_traits, std::allocator > const,
> std::__cxx11::basic_string std::allocator > > > >&, std::__cxx11::basic_string std::char_traits, std::allocator > const&,
> std::__cxx11::basic_string std::allocator > const&, bool, int)'
> > collect2: error: ld returned 1 exit status
> > test/CMakeFiles/test_bowker.dir/build.make:99: recipe for target
> 'test/test_bowker' failed
> > make[3]: *** [test/test_bowker] Error 1
>
> --
> http://fam-tille.de
>



-- 
Julien Y. Dutheil, Ph-D
0 (+49) 4522 763 298

§ Max Planck Institute for Evolutionary Biology
Molecular Systems Evolution
Department of Evolutionary Genetics
Plön -- GERMANY

§ Institute of Evolutionary Sciences - Montpellier
University of Montpellier 2 -- FRANCE