[Pkg-ime-devel] RFS: scim-waitzar, libwaitzar (re-submission) Attn: Paul Wise

[S'orlok Reaves]

Good evening,
  I am re-submitting my packages scim-waitzar and libwaitzar for sponsorship, after making the changes requested after my last submission. (One of these changes involved splitting the package into two.)

  Thanks again for your corrections; I learned a lot about packaging as I implemented them, and although it took longer than expected, I think the scim-waitzar package is now a much stronger candidate because of them.

> In general you should not embed copies of code from other
> projects (such as waitzar or kanaung), instead build a new package
> for the other project instead (and then depend/build-depend on it).
I have split libwaitzar off from scim-waitzar and built a separate package:
http://mentors.debian.net/debian/pool/main/s/scim-waitzar/
http://mentors.debian.net/debian/pool/main/l/libwaitzar/

...but I cannot do the same for KaNaung. There are several reasons for this:
 1) KaNaung was developed specifically for Windows. Most of the code I borrowed had to be modified up before it would compile under Linux.
 2) I used SVN revision 700 of kanaung's source; the upstream developer has since closed the source for later revisions. (I have written permission of the copyright holder to use the newest source of kanaung, but I chose to only include kanaung code which is covered under the GPL.) 


> please read the best practices for package descriptions
I've read both links provided, and cleaned up the description accordingly. I've applied these best practices to the libwaitzar package description, too.


> Much of src/waitzar-lib/ is non-free and non-redistributable (you are
> illegally distributing it), please remove that before asking for an
> upload.
My apologies; I realize that I forgot to mention the license (GPL 2) in the boilerplate comments. I've added boilerplate comments, and included additional information int he "copyright" file.


> debian/dirs isn't nessecary
Thanks; I used "scim-waitzar.install" instead, and found it much more fitting.

> It would be nice if the user guide were distributed in a less
> proprietary format. I'd suggest plain UTF-8 text or if
> you need fonts or images, DocBook, HTML or ODF. 
> The advantage of using DocBook for that would be that 
> it is easily transformable to a variety of formats.
Thanks, that's exactly what I was looking for! I also generated and distributed a pdf with the xml version of the User's Guide.


> Is scim-waitzar directly derived from the Windows WaitZar?
> The user manual seems to indicate that you relicensed parts of it
> from BSD to GPL, which you usually aren't allowed to do unless 
> you wrote them.
Yes, I wrote both scim-waitzar and Windows WaitZar. In order to make the line clearer, I removed all of the Windows WaitZar code from scim-waitzar and put it into the libwaitzar package. The libwaitzar package is licensed under Apache 2.0, but please let me know if the licenses conflict and I will dual-license it.


> (re: myanmar 3 support)
> Why is that, shouldn't any Unicode font with Burmese
> work? For instance we have ttf-sil-padauk in Debian.
Fixed. I was using an older version of Padauk, which composed characters improperly. Now, I just recommend any Unicode 5.1+ font


> http://waitzar.googlecode.com/svn/trunk/release_1.5+_beta/Myanmar3.ttf
> http://waitzar.googlecode.com/svn-history/r219/trunk/release_1.5/Zawgyi-One.ttf
> 
> If these are DFSG-free and are Unicode fonts, you might
> want to join the Debian Fonts Task Force and package them too.
I'll consider it, but I've had a hard time contacting the developers of Myanmar3 and Zawgyi-One. I know that Zawgyi-One is free software, but I can't get my hands on a license. Moreover, Zawgyi-One is a "partial Unicode font" (which is a misleading term: it actually commits the sin of over-writing reserved code points).