[Pkg-ime-devel] Bug#675657: Bug#675657: libskk: Please switch to vala 0.16
osamu at debian.org
Sat Jun 16 11:10:42 UTC 2012
I think I had this stack in my sstem ... resending ...
On Sun, Jun 03, 2012 at 01:30:00PM +0200, Michael Biebl wrote:
> 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),
> - valac-0.14 (>= 0.14.2),
> - libvala-0.14-dev (>= 0.14.2),
> + valac (>= 0.14.2),
> 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: 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: Refer to http://wiki.debian.org/Hardening for details.
N: Severity: normal, Certainty: certain
N: Check: binaries, Type: binary, udeb
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: 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: Refer to Debian Policy Manual section 7.4 (Conflicting binary packages -
N: Conflicts) for details.
N: Severity: normal, Certainty: wild-guess
N: Check: fields, Type: binary, udeb, source
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>
Although we are expecting freeze very soon, with some serious bugs in
dpkg, I do not see it happen very quickly.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1186 bytes
Desc: not available
More information about the Pkg-ime-devel