On Sun, Jun 29, 2014 at 8:32 AM, Osamu Aoki <osamu_aoki_h...@nifty.com>
wrote:
> Hi,
>
> On Sun, Jun 29, 2014 at 02:11:18AM -0400, Guo Yixuan wrote:
> > On Mon, Jun 23, 2014 at 8:03 AM, Osamu Aoki <osamu_aoki_h...@nifty.com>
> > > You did not present rationale to do extrastep with the second option.
> >
> > There seems to be something more than ABI break.
> > librime 1.0 modified several struct member definitions, eg., in the
> > definition of RimeMenu in include/rime_api.h. Is it an API break?
> > If yes, then we should rename, in my opinion. (By the way, other
> > source code imcompatibilities may exist, as indicated in the
> > ChangeLog, "while source code compatibility is largely
> > maintained with the exception ...")
>
> Very good. this is what I wanted to hear.
>
> > > I see
> > > librime1 (>= ${source:Version}), librime1 (<< ${source:Version}+1~)
> > >
> > > This seems binNMU unsafe. Please drop max version limitation.
>
> Very good.
>
> I added few lines to debian/rules for stable build test with
> debian/rules etc.
>
> I also checked source with "debmake -k"
> === debian/copyright checked for 260 data ===
> Pattern #00: *
> File: thirdparty/src/opencc-windows/opencc.h
> thirdparty/src/opencc-windows/opencc_types.h
> - GPL-3
> + Apache-2.0
>
> Pattern #02: thirdparty/include/X11/*
> File: thirdparty/include/X11/keysymdef.h
> thirdparty/include/X11/keysym.h
> - MIT
> + ISC
>
> Pattern #03: thirdparty/include/msvc/*
> File: thirdparty/include/msvc/stdint.h
> - BSD-3-clause
> + BSD-3-Clause
>
> The first one is positively wrong. licensecheck command also agrees with
> me.
>
> Second one is one of the MIT but it is more like ISC than Expat.
> Usually Expat is marked as MIT. (Minor problem)
> Expat: Permission is hereby granted ...
> ISC: Permission to use, copy, modify, ...
> (Included MIT liocense does not match source having ISC.)
>
> The last one is a false positive. Minor case difference between:
> https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
> http://spdx.org/licenses/
>
> Also DEP-5 has been adoped as
> http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
>
> So I made minor adjustments in GIT for these.
>
> Also, what are you going to do with curl.exe etc. I can not sponsor
> upload of package with binary blob. In future, we need to consider
> automating this. Please read
> http://www.eyrie.org/~eagle/notes/debian/git.html
> https://wiki.debian.org/BenFinney/software/repack
For this, I think it's easier to add a Files-Excluded line to
debian/copyright
header, and let uscan do the repacking: [1]
Files-Excluded: thirdparty/bin/curl.exe
thirdparty/src/opencc-windows/opencc.dll
thirdparty/src/opencc-windows/opencc.exe
thirdparty/src/opencc-windows/opencc_dict.exe
In addition, we should add "+dfsg" to the package version, so it should
be "1.1+dfsg-1", and we need to add some mangle rules to debian/watch.
[1] https://wiki.debian.org/UscanEnhancements
(Sorry I didn't have the time to do this yet.)
I took care these manually for now.
>
> I will push this to GIT for now:
>
> Oops, lintian gives me:
>
> E: librime source: weak-library-dev-dependency librime1-dev on librime1
> (>= ${source:Version})
> N:
> N: The given package appears to be a shared library -dev package, but
> the
> N: dependency on what seems to be a corresponding shared library package
> N: does not force the same package version. To ensure that compiling and
> N: linking works properly, and that the symlinks in the -dev package
> point
> N: to the correct files in the shared library package, a -dev package
> N: should normally use (= ${binary:Version}) for the dependency on the
> N: shared library package.
> N:
> N: Sometimes, such as for -dev packages that are
> architecture-independent
> N: to not break binNMUs or when one doesn't want to force a tight
> N: dependency, a weaker dependency is warranted. Something like (>=
> N: ${source:Upstream-Version}), (<< ${source:Upstream-Version}+1~),
> N: possibly using ${source:Version} instead, is the right approach. The
> N: goal is to ensure that a new upstream version of the library package
> N: doesn't satisfy the -dev package dependency, since the minor version
> of
> N: the shared library may have changed, breaking the *.so links.
> N:
> N: Refer to Debian Policy Manual section 8.5 (Dependencies between the
> N: packages of the same library) for details.
> N:
> N: Severity: important, Certainty: possible
> N:
> N: Check: control-file, Type: source
>
> Let me think ... I may have been wrong.
>
> Now you also need to update ibus/fcits-rime.
I think these two packages are already updated to the new API.
I'll double check it soon, and update fcitx-rime to 0.3.1.
Cheers,
Yixuan
