Updating Build-Depends for R packages

[Graham Inggs]

Hi!

I noticed the following build failures in Ubuntu recently:

r-bioc-genomicfeatures 1.30.0+dfsg-1
Error : package ‘GenomicRanges’ 1.28.6 was found, but >= 1.29.14 is
required by ‘GenomicFeatures’

r-bioc-genomicalignments 1.14.0-1
Error : package ‘GenomicRanges’ 1.28.6 was found, but >= 1.29.14 is
required by ‘GenomicAlignments’

r-bioc-bsgenome 1.46.0-1
Error : package ‘GenomicRanges’ 1.28.6 was found, but >= 1.29.14 is
required by ‘BSgenome’

r-bioc-delayedarray 0.4.1-1
Error : package ‘IRanges’ 2.10.5 was found, but >= 2.11.17 is required
by ‘DelayedArray’

Simply giving back these builds was sufficient since the new packages
had been published, but should the Build-Depends of these packages be
updated?  I'm happy to make the changes in git, given the go-ahead.

Do we have a tool that can update the Build-Depends, or at least warn
of new / updated versioned dependencies?

Regards
Graham

Re: Bug#879886: libhts2: libhts2 needs to handle ABI changes

[Diane Trout]

> As a gotcha, remember that this bug was born out of the fact that
> there
> was a package requiring a >= 1.5 dependency.  I recommend you compile
> the symbol file with something << 1.5 (i.e. 1.4 or just re-add the
> file
> that was removed) and then update it appropriately so there will be
> not
> so tight versions.

Done.

I dug out the previous symbols files, which appeared to have been built
up to 1.3.1, then I applied changes from 1.4.1 and then finally 1.5.

There were a few symbols changes that were not clear cut and so they're
currently removed but were done in a separate commit.

There from 1.3.1 to 1.4.1 three symbols ks_destroy, ks_getuntil2,
ks_init that disappeared from the library, but are in the headers as
macros. The header macros look like they haven't changed much from even
the 1.0 release, so I don't know why they were removed.

From 1.4.1 to 1.5 there was a block of zf* functions that were removed.
However those are from the "private" cram headers and so 1.5 is likely
to cause issues for the programs that are using the cram support.

Anyone want to review? or should I go ahead and release?

Diane

signature.asc
Description: This is a digitally signed message part

Re: Bug#879886: libhts2: libhts2 needs to handle ABI changes

[Mattia Rizzolo]

On Thu, Nov 09, 2017 at 03:14:27AM -0500, Afif Elghraoui wrote:
> >If you find issues getting stuff sponsored, please do point me to it
> >privately (I know you are on IRC, that tends to often work best for
> >me).
> 
> Diane's a DD.

Oops, sorry!
Then I take back my offer to sponsor, but still happy to help with the
symbols file (and other things) after the first sketch :)

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Re: Bug#879886: libhts2: libhts2 needs to handle ABI changes

[Afif Elghraoui]

On November 9, 2017 3:06:32 AM EST, Mattia Rizzolo  wrote:
>On Wed, Nov 08, 2017 at 04:58:49PM -0800, Diane Trout wrote:
>> > > I was wondering if we should split the cram headers into a
>> > > libhts-private-dev so we can at least track what is depending on
>> > > the
>> > > non-public api.
>
>Can I recommend dealing with the public/non-public API *after* adding
>the symbols file and doing other general stuff?

+1

>
>In general, I recommend against doing dozens of (possibly hard, like in
>this case) changes in a single huge upload, let's split them out :)
>
>Upstream kindly opened #881170 to track other issues as well, perahps
>clone that bug to track all those issues separately (as they all
>require
>changes to other packages, so need to be coordinated separately, and
>need not to be done at the same time either).

Also +1
>
>
>If you find issues getting stuff sponsored, please do point me to it
>privately (I know you are on IRC, that tends to often work best for
>me).

Diane's a DD.

thanks and regards
Afif

Re: [Debian-med-packaging] Bug#879886: libhts2: libhts2 needs to handle ABI changes

[Mattia Rizzolo]

On Wed, Nov 08, 2017 at 11:32:56PM -0800, Diane Trout wrote:
> I think we'd need to use the Built-Using tag? I haven't used that
> before.

No, that's needed when doing static linking for GPL compliance (and
other kind of things, but all related to static linking that thanks god
is not a topic here...

> (Though doing that would push htslib into NEW).

Please worry not about NEW, I've got contacts with ftp-master and can
get stuff out fairly quick (after a respectful time passed, like a week
at least).

> > And there is another action item--
> > TODO update the htslib package to the latest release.
> 
> Very true I did try building 1.6 and there was a problem with
> running tests that I haven't investigated yet.

Let me recommend adding the symbols file and getting it right before
doing 1.6, so symbols new in 1.6 are correctly versioned.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Re: [Debian-med-packaging] Bug#879886: libhts2: libhts2 needs to handle ABI changes

[Afif Elghraoui]

On November 9, 2017 2:32:56 AM EST, Diane Trout  wrote:
>On Thu, 2017-11-09 at 02:03 -0500, Afif Elghraoui wrote:
>> > - TODO Split private cram headers off into a new libhts-private-dev
>> > package
>> 
>> I'd rather be in favor of restoring the bundled htslib to seqlib as
>> the short term solution. Putting a private package in the archive may
>> exacerbate the problem and is odd nevertheless.
>
>The no convenience copies of libraries is a pretty strong rule of
>Debian, and there are good maintenance reasons for it.

Yes, I understand that, but we don't have good options right now. I don't see 
the maintenance advantages for seqlib as worth requiring a transition for every 
htslib update to make sure it doesn't break--in addition to putting a package 
in the archive and telling users/developers not to install it.

> Although I'm not
>opposed to it I'd like several people to agree that its the best option
>first.
>
>On the plus side overriding it would allow us to drop the patch that is
>making the cram symbols public, on the downside we'd have to remember
>that bugs involving htslib also impact libseqlib.

If this whole situation is primarily seqlib's problem, I think it's only fair 
for it to bear the kludges required for its approach. Otherwise, we have the 
kludge in htslib and the need for a htslib transition with every update, right?

In fact, lofreq never entered Debian because it needs to use samtools as a 
library and we were not going to bundle it [1]. I felt that would be an RC bug.

>
>I think we'd need to use the Built-Using tag? I haven't used that
>before.
>
>On the other hand upstream did suggest that the private-dev library was
>a viable temporary solution. (Though doing that would push htslib into
>NEW).

Well, I think they were saying that if we were going to go so far as to 
misrepresent htslib, we should at the very least make a division and distribute 
htslib proper as such. I read that as saying anything would be better than the 
current situation--not necessarily that they're equally better.

>
>> 
>> And there is another action item--
>> TODO update the htslib package to the latest release.
>
>Very true I did try building 1.6 and there was a problem with
>running tests that I haven't investigated yet.
>

Regards
Afif

1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=808895

Re: Bug#879886: libhts2: libhts2 needs to handle ABI changes

[Mattia Rizzolo]

On Wed, Nov 08, 2017 at 04:58:49PM -0800, Diane Trout wrote:
> - TODO Recommit symbols file
> 
> > Symbols file are strange to work with because their update usually
> > goes
> > through a build failure that outputs a patch, which is not very
> > intuitive.  And then the patched symbols file has to be edited to
> > remove
> > the Debian minor version, otherwise it complicates backports etc.
> > Perhaps it can be simplified, better explained and streamlined.  In
> > any
> > case, I think that for the htslib it is worth the effort.
> 
> The KDE team had some nice utilities that downloaded the symbols files
> for all the architectures and could do batch patches.
> 
> Unfortunately I think they're KDE specific.
> 
> I'll commit my rebuilt symbols files the next time I'm not spending my
> day writing emails to everyone else. I need a chance to look more
> carefully if the missing symbols were actually not part of the private
> api.

The KDE tool is not kde-specific at all.
Nonetheless, I don't really advocate for it: it might make easier to
update the symbols file and stuff, but IMHO it also makes too easy to
just "automatically update symbols file" and overlook what the actual
changes are.  In particular, C++ symbols tends to be way way more
tedious than plain C ones.
If your upstream is sane and does a decent job at dealing with symbols,
manually taking care of a symbol file is very easy.  Please just commit
your first shot at it, and I'll happily help out in shaping it (and
making it right for all the other architectures if there are
arch-specific symbols).

As a gotcha, remember that this bug was born out of the fact that there
was a package requiring a >= 1.5 dependency.  I recommend you compile
the symbol file with something << 1.5 (i.e. 1.4 or just re-add the file
that was removed) and then update it appropriately so there will be not
so tight versions.

> > > I was wondering if we should split the cram headers into a
> > > libhts-private-dev so we can at least track what is depending on
> > > the
> > > non-public api.

Can I recommend dealing with the public/non-public API *after* adding
the symbols file and doing other general stuff?

In general, I recommend against doing dozens of (possibly hard, like in
this case) changes in a single huge upload, let's split them out :)

Upstream kindly opened #881170 to track other issues as well, perahps
clone that bug to track all those issues separately (as they all require
changes to other packages, so need to be coordinated separately, and
need not to be done at the same time either).


If you find issues getting stuff sponsored, please do point me to it
privately (I know you are on IRC, that tends to often work best for me).
-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature