[Pkg-ime-devel] Bug#675657: Bug#675657: libskk: Please switch to vala 0.16

[Osamu Aoki]

Hi,

I think I had this stack in my sstem ... resending ...

On Sun, Jun 03, 2012 at 01:30:00PM +0200, Michael Biebl wrote:
> Hi,
> 
> On 03.06.2012 05:03, Osamu Aoki wrote:
> 
> > Instead of "Build-Depends: valac-0.16 (>= 0.16.0), libvala-0.16-dev (>= 0.16.0)",
> > why not to use: "Build-Depends: valac, libvala-dev"?
> > 
> > You already provide valac. Why not provide libvala-dev pointing to
> > libvala-0.16-dev?  Then you could have dealt this via binNMU.  Of course
> > if there is major non-compatible changes happen, we could chose to
> > change name of virtual package (Something like python to python3).
> > 
> > Vala seems to be fast changing with mostly forward compatible feature
> > additions, this seems to be viable option.  I may be totally wrong on
> > understanding of vala situation though....
> 
> If you only require valac, then yes, build-depending on
> valac (>= ...) instead of valac-X.XX is what I would recommend.
> 
> It's a bit different with libvala-X.XX-dev. E.g. libvala-0.16-dev ships
> libvala-0.16.pc, i.e. the pkg-config file is versioned, so you need to
> update the configure check explicitly to support that version.
> 
> As for libssk, I actually don't know, why you have the libvala-0.14-dev
> build dependency. It seems you can safely drop it.
> In your case a simple patch like
> 
> diff --git a/debian/control b/debian/control
> index 57fb782..1e5dab3 100644
> --- a/debian/control
> +++ b/debian/control
> @@ -7,8 +7,7 @@ Build-Depends: debhelper (>= 8.1.3~),
>                 dh-autoreconf (>= 4),
>                autotools-dev,
>                intltool,
> -               valac-0.14 (>= 0.14.2),
> -               libvala-0.14-dev (>= 0.14.2),
> +              valac (>= 0.14.2),
>                libgee-dev,
>                libjson-glib-dev,
>                gobject-introspection,
> 
> would probably be ok.

Thanks for your comment and patch.  It builds OK without libvala-0.14-dev in
pbuilder (chrooted build environment).

As I rebuild this package just to test, I saw few lintian warnings.

W: libskk-dev: hardening-no-relro usr/bin/skk
N:
N:    This package provides an ELF binary that lacks the "read-only
N:    relocation" link flag. This package was likely not built with the
N:    default Debian compiler flags defined by dpkg-buildflags. If built using
N:    dpkg-buildflags directly, be sure to import LDFLAGS.
N:
N:    Refer to http://wiki.debian.org/Hardening for details.
N:
N:    Severity: normal, Certainty: certain
N:
N:    Check: binaries, Type: binary, udeb
N:
W: libskk0: hardening-no-relro usr/lib/x86_64-linux-gnu/libskk.so.0.0.0
I: libskk0: conflicts-with-version ibus-skk (<< 1.4.0)
N:
N:    An earlier-than version clause is normally an indication that Breaks
N:    should be used instead of Conflicts. Breaks is a weaker requirement that
N:    provides the package manager more leeway to find a valid upgrade path.
N:    Conflicts should only be used if two packages can never be unpacked at
N:    the same time, or for some situations involving virtual packages (where
N:    a version clause is not appropriate). In particular, when moving files
N:    between packages, use Breaks plus Replaces, not Conflicts plus Replaces.
N:
N:    Refer to Debian Policy Manual section 7.4 (Conflicting binary packages -
N:    Conflicts) for details.
N:
N:    Severity: normal, Certainty: wild-guess
N:
N:    Check: fields, Type: binary, udeb, source
N:

Attached patch fixes these warnings.

Daiki-san, are you busy now?  I will do 1 day delayed team upload since
this is IME Packaging Team <pkg-ime-devel at lists.alioth.debian.org>
maintained.

Although we are expecting freeze very soon, with some serious bugs in
dpkg, I do not see it happen very quickly.

Osamu

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-lintian-warning-fixes-default-Build-Breaks.patch
Type: text/x-diff
Size: 1186 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-ime-devel/attachments/20120616/d9192765/attachment.patch>