On Thu, Dec 14, 2017 at 02:30:53PM +0100, Mattia Rizzolo wrote:
>
> ACK, should be all good to go now.
Thanks for the careful review. That's really appreciated
Andreas.
--
http://fam-tille.de
On Thu, Dec 14, 2017 at 02:26:46PM +0100, Andreas Tille wrote:
> I've tested a local build and the means of
> 765419270800864fd29cea90db233a60cd46aea8 can all be droped. I pushed
> two commits - hopefully better documented than before.
ACK, should be all good to go now.
--
regards,
Hi Mattia,
On Thu, Dec 14, 2017 at 01:31:35PM +0100, Mattia Rizzolo wrote:
> On Wed, Dec 13, 2017 at 04:49:36PM +0100, Andreas Tille wrote:
> > Thanks for your careful checking. Would you mind just commiting your
> > prefered solution to make sure I've correctly understood what you mean?
> > (The
On Wed, Dec 13, 2017 at 04:49:36PM +0100, Andreas Tille wrote:
> Thanks for your careful checking. Would you mind just commiting your
> prefered solution to make sure I've correctly understood what you mean?
> (There is no real policy in the med team here.)
I could do that, but I'm unsure as to w
Hi Mattia,
On Wed, Dec 13, 2017 at 04:40:46PM +0100, Mattia Rizzolo wrote:
>
> One thing: I noticed that in htslib's tracker page an important
> multiarch issue is reported: libhts-dev is marked ma:same, but there is
> a static library in a non-multiarch path.
> The options to fix it are:
> * don
On Wed, Dec 13, 2017 at 01:03:21PM +0100, Andreas Tille wrote:
> To come back to the initial discussion: You would agree that uploading
> to unstable is fine? The reason why I've choosen experimental initially
> was also that we have lots of packages depending from python-pysam which
> sometimes
Hi Mattia,
On Wed, Dec 13, 2017 at 12:53:48PM +0100, Mattia Rizzolo wrote:
> > What is the argument in favour of considering clearly unsupported
> > undocumented internal functions to be part of a library's interface
> > just because symbols are visible — in the binary but not the headers?
>
> I'
On Tue, Dec 12, 2017 at 11:17:22PM +, John Marshall wrote:
> But in short, upstream's guiding principle is this: API and ABI are
> tightly related. If functions that are not declared within htslib/*.h
> (therefore are not part of HTSlib's documented public API) are
> changed, we do not consider
On 13 Dec 2017, at 10:47, Mattia Rizzolo wrote:
> These three symbols are from fuctions that are clearly aimed at debug.
> The functions do dumb fprintf() of some data structures to stderr,
> clearly something that nobody would ever use in a production system.
> The fuctions themselves are still t
So, I had a closer look at it:
On Mon, Dec 11, 2017 at 05:23:19PM +0100, Mattia Rizzolo wrote:
> 1) you happily removed symbols: why so? removing symbols is a ABI
> break, and that would usually call for a SONAME bump that upstream
> didn't do. Those things need to be investigated singularly, wh
Hi Mattia,
On Mon, Dec 11, 2017 at 06:29:26PM +0100, Mattia Rizzolo wrote:
> On Mon, Dec 11, 2017 at 05:44:53PM +0100, Andreas Tille wrote:
> > Sorry for not beeing more verbose. This was the result of the patch
> > I've got when trying to build the package *including* the symbols. :-(
> > These
On Mon, Dec 11, 2017 at 05:44:53PM +0100, Andreas Tille wrote:
> Sorry for not beeing more verbose. This was the result of the patch
> I've got when trying to build the package *including* the symbols. :-(
> These were marked as "# MISSING #".
>
> Feel free to try your luck without removing ...
On Mon, Dec 11, 2017 at 05:23:21PM +0100, Mattia Rizzolo wrote:
>
> Although, looking at
> https://anonscm.debian.org/cgit/debian-med/htslib.git/commit/?id=ca55c40f2a3154004d6e55eac4bdc2cdffa413b3
> I noticed that:
>
> 1) you happily removed symbols: why so? removing symbols is a ABI
> break, an
On Mon, Dec 11, 2017 at 04:13:39PM +0100, Andreas Tille wrote:
> since we frequently observed issues with incompatibilities of samtools I
> uploaded the new version to experimental first. Strictly speaking we
> should check whether a transition is needed.
Of course a transition (given the definit
Hi folks,
since we frequently observed issues with incompatibilities of samtools I
uploaded the new version to experimental first. Strictly speaking we
should check whether a transition is needed. Are there any known issues
with incompatibilities of packages listed when you do
apt-cache rde
15 matches
Mail list logo