Bug#931967: buster-pu: package libtk-img/1:1.4.8+dfsg-1+deb10u1 pre-approval

[Sergei Golovan <sgolovan@nes.ru>]

Hi Adam,

On Fri, Jul 26, 2019 at 10:32 PM Adam D. Barratt
<adam@adam-barratt.org.uk> wrote:
> On 2019-07-13 01:19, Sergei Golovan wrote:
> > I'd like to fix #931422 (see [1]) for buster (the bug is already fixed
> > in unstable and prospectively in testing).
> >
> > The diff with the current 1:1.4.8+dfsg-1 is attaced, it's fairly small.
>
> What are the implications of the change on functionality and consumers
> of the library?

To my knowledge, the functionality doesn't change. It definitely
doesn't change on a script level,
on a C level there are a few internal symbols that won't be available
in the fixed library
(e.g. TkimgTIFFInitJpeg), though they aren't exported, they aren't
listed in `objdump -T libtkimgtiff*.so`,
and they aren't supposed to be used by a caller to this library (and
noone calls them indeed).

>
> > Also, I'd like to ask if I should make a source-only or binary upload
> > to
> > stable (and/or oldstable) now?
>
> Source-only would be preferred, so long as the .changes filename is
> sensible (i.e. *not* _amd64.changes when no amd64 binaries are actually
> included).

I see, thank you for the info.

>
> If the issue also affects stretch and you would like to update the
> package there, please open a separate appropriately-tagged request to
> discuss that.

Yes, I did open a separate report, and you've already answered to it.
In fact, the
original bug was reported to stretch.

Cheers!
-- 
Sergei Golovan