Hope you all had a good holiday season. I've finally gotten some free time, so I've addressed & implemented (most of) the changes you (Paul) suggested. Sorry for such a long turnaround-time; I've had a lot of Debian policy reading to do. ;)
Packages uploaded to mentors: http://mentors.debian.net/debian/pool/main/l/libwaitzar/ http://mentors.debian.net/debian/pool/main/s/scim-waitzar/ First, the discussion questions: > If you are able to get later but still GPLed revisions from > upstream, that might be a good idea. The KaNaung library is used to convert WaitZar's words from one encoding to another. Every time it I link in a new version, I have to manually check all 2426 of WaitZar's words for conversion errors. I'll eventually automate this task, but for now, SVN version 700 works, and I don't have time to check any later version. > 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.... > Thanks for the info. At least things have moved on since > the days of Burmese using ASCII and a special font. I heartily agree; thank goodness! > I think something like khmeros.org would be a great way to > promote adherence to Unicode and other standards. Building a community is the best way; I agree. I'll float the idea on the Myanmar IT Pros web site after the first release of scim-waitzar comes out. And now, for the package fixes: > In your case, the SONAME is determined by libwaitzar_1_0_la_LDFLAGS. Thanks, I finally got it. (Fixed) > 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? > Seems to me like you should merge libwaitzar1-dev into libwaitzar-dev. Good call. (Done) > With libraries, usually they are automatically installed... > ...and the library package can be minimalistic (say just > the last sentence of the current desc). Done. > Similarly you probably don't need the upstream > changelog in the library package. Done. Since the two changelogs for libwaitzar were nearly identical, I simply removed upstream's changelog from both libwaitzar1 and libwaitzar-dev. > Generally a static library isn't needed in > distributions like Debian Done. I also removed the .a file from the scim-waitzar package. > 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. 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. > The .so symlink should be shipped in the dev package but > not the library package. Done. > Personally I would expect /usr/include/waitzar-1.0/waitzar > to be /usr/include/waitzar, since it is that way for most > packages. Same for the pkgconfig file. Done and done. (But please double-check this.) > 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. 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. 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? 3) I kept both packages at version 1.0.0, since these were not heavily distributed and only cosmetic changes were made. Thanks again for helping me through these rookie mistakes. I truly am grateful for all the mentoring and guidance. -->Seth -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
