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