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
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.
Osamu
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
