On Tue, Jan 6, 2009 at 4:02 PM, S'orlok Reaves <sorlok_rea...@yahoo.com> wrote:
> Packages uploaded to mentors: > http://mentors.debian.net/debian/pool/main/l/libwaitzar/ > http://mentors.debian.net/debian/pool/main/s/scim-waitzar/ Review, replies below. >> It might be a good idea to produce a kanaung fork with a >> new name and focusing on keeping it suitable for use in a free software >> distribution. > KaNaung is a big library, so I am hesitant to fork it. The good news is, I've > talked to the developer of KaNaung, and he's said he's not against > open-sourcing the project; he just doesn't want to maintain the code & > programming. He is much more knowledgeable than I am about encoding, so my > goal is to keep him in the loop (perhaps I can offer to deal with packaging > and bug reports?) Consider this a WIP.... Good stuff. >> I: libwaitzar1: no-symbols-control-file >> usr/lib/libwaitzar-1.0-1.0.so.1.0.0 >> Please see these links... > I read as much as I could, and here's what I did: > - Ran dpkg-gensymbols to get a list of symbols in my library > - Removed all "private" class methods, and all methods that I use privately > (i.e., templated global methods). > - Removed all symbols from the kanaung library (except convertFont). > - Stored the resulting symbols in libwaitzar1.symbols > This got rid of the warning, but I am very inexperienced at symbols > versioning --is this sufficient? Sounds about right. Would it be possible to make the private/removed symbols not exported, so that applications cannot link against them and dpkg-gensymbols doesn't find them? >> What is the preferred form of modification for >> Myanmar.model? Do you modify it directly? > ..and.. >> About /usr/share/waitzar, it might be a good idea to >> version that directory with the SONAME so that >> libwaitzar1 will be co-installable > Myanmar.model is at version 2. The file is generated from a full > specification which itself is voted on by the Myanmar community. This process > takes 3 months. Every new version of the model completely obviates the old > one, and generates a major version change. Are you able to ship the spec in the source package and generate Myanmar.model from the spec at build time? Or ship a myanmar-spec source package that builds and installs the the Model file? > mywords.txt is updated with every new release of libwaitzar. It only affects > about 1% of all Myanmar words, and is intended to fix mostly cosmetic > changes; it is NOT a problem if this file gets constantly over-written. > That said, I decided to put both files into the /usr/share/waitzar/model2 > directory. The only people who will want to use an outdated model are those > who are doing research in the field; they will not care about mywords.txt in > general, and will probably load their own local models anyway. > I expect all future ABIs to be backwards-compatible with the file format of > Myanmar.model, so I think this solution is sufficient. Ok. >> Also, Makefile.in and any other generated files should not >> be stored in your version control repository. > For now, I would like to leave them in, for my own reasons. If this is a > deal-breaker, let me know. Not a deal-breaker, feels icky though. > And now, some new issues: > > 1) There's a lintian warning: > I: scim-waitzar: arch-dep-package-has-big-usr-share 1216kB > ...Please let me explain. Scim-waitzar ships a 600KB user's guide, and the > 630KB docbook source needed to compile it. This USED to be offset by a 838KB > static library file (the dynamic files total only 563KB), but I removed the > static library file, as you recommended. > I could solve this warning by making a -common package, but I really don't > see the need. Is 1.2MB * (total_architectures) of server space too much? I > only found this warning by slimming down the rest of the install. > Of course, just say the word if this is a big deal. 1.2Mb * 13 arches * ??? mirrors adds up to a lot. Maybe you could drop the docbook source from the binary package? I really hope that multi-arch addresses this issue at some point; > 2) The copyrights in the files all say 2008, since all changes to them since > my last RFS were effectively cosmetic. I feel the copyright rests in 2008, > but I don't know the legal details. Is it better to change the date in > debian/copyright? In all the source files? I don't know enough about copyright to answer this correctly; I agree with your feeling though. Other stuff: libwaitzar: debian/README doesn't appear to be nessecary or should be moved into the upstream README? In debian/watch, [.] is just like \. but slightly longer. It appears that the GNU GPL v2 and Apache 2.0 licences are incompatible (GPLv3 is though): http://www.fsf.org/licensing/licenses/#apache2 http://www.apache.org/licenses/GPL-compatibility.html scim-waitzar: debian/README doesn't appear to be nessecary or should be moved into the upstream README? Should you add ttf-sil-padauk to Suggests? http://wiki.debian.org/Proposals/CopyrightFormat need to handle DEB_BUILD_OPTIONS="parallel=n" in debian/rules, see policy for an example. In debian/watch, [.] is just like \. but slightly longer. I note that you ship waitzar_users_guide.pdf instead of generating it at build time, wouldn't it be better to generate it? Not sure I like how you put all the images in a tarball instead of a subdirectory either. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
