[Pkg-ime-devel] Bug#750623: Bug#750623: Bug#750623: What is the hold-up of uploadin new package

[Guo Yixuan]

On Sun, Jun 29, 2014 at 8:32 AM, Osamu Aoki <osamu_aoki_home at 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_home at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-ime-devel/attachments/20140629/670dce75/attachment-0003.html>