Hi, Gianfranco Costamagna wrote: > (well, you might want to ask upstream to call it 1.4.2.1 maybe?)
[Changing hats.] I am the upstream myself. .pl01 is tradition. What's wrong with it ? [Changing hats again.] (Upstream is not unteachable. Just would need to be convinced.) i wrote: > > The binary package which actually bears the bug is cdrskin_1.4.2-1. > mmm ok, so a sort of shared library issue. Rather in contrary. Upstream libburn-*.gz contains code for libburn.so and for the executable binary /usr/bin/cdrskin, which offers a CLI roughly compatible to wodim and cdrecord. It uses libburn.so to operate an optical drive. The bug is in the code of cdrskin, outside of libburn.so. So technically, the binary packages libburn4, libburn-dbg, libburn-dev, and libburn-doc do not need to be changed. But they are all derived together with cdrskin from https://tracker.debian.org/pkg/libburn > ABI/API safe, The last (inadverted) wreakage of ABI was in february 2007. I got the SONAME numbering right not before january 2008. Since then i broke many things, but neither API nor ABI. > dpkg --compare-versions You mean this test ? $ dpkg --compare-versions 1.4.2.pl01-1 gt 1.4.2-1 && echo yes yes $ dpkg --compare-versions 1.4.2.pl01-1 lt 1.4.4-1 && echo yes yes $ So it would fit between the current package and the first one of the future upstream release libburn-1.4.4. (1.4.3 is for development between releases.) I am waiting for the new upstream tarball to be recognized by uscan and reported to the package tracker. Hopefully it will be found until tomorrow evening CET. If no objections arise until then, i will go for 1.4.2.pl01-1 from upstream tarball libburn-1.4.2.pl01.tar.gz. Have a nice day :) Thomas
