Hi kokoye, As I mentioned last year in several email communications, the packages you made contained some major issues and I sincerely hope that you are providing clean packaging this time. Please read those emails again and fix any remaining issues. Here are some of the general suggestions that I consider very important to you: * Improve your English, if ever possible; * Make a clear division between your roles as an upstream and a packager: - Please, do not mix your upstream development with the packaging efforts; - Do not ever use a "native" packaging format when packaging for Debian; - Clearly mark out your upstream development efforts using git tags with incremental version strings. * It is absolutely fine to fork another project and generate yours, like forking ibus-table-chinese to generate ibus-table-myanmar. However, please try your best to clean up all files that is useless to your new project. I saw some of such efforts like [1] but there's still lots of obsolete information left in the repository. * Do not include "debian/files" into your Git repository. This file is always automatically generated. For the question about version number below, it is very important to not mangle different version strings together. When you are acting as an upstream (developer), you are supposed to make development and later mark your product using version strings that do not contain any Debian revisions. This version string should also always be incremental. You may use the tagging function of Git to achieve that. By making an (upstream) tag, you are virtually making an (upstream) release for your software. When you are acting as a Debian packager (and not an upstream developer), you are supposed to work on top of existing upstream tags (upstream releases) by only adding Debian revisions and not touching the upstream version part (as well as files provided by upstream) at all. Even though the "upstream" and the "packager" here all refer to yourself, this split of roles is very important and I do hope you could understand it since it is fundamental to any packaging activity. * Upstream version strings are like 1.0, 1.1, 1.1.3; * Debian package version strings are upstream version strings concatenate with Debian's revision. For a certain upstream release like 1.1, the Debian's version string should be like 1.1-1, 1.1-2, 1.1-5. When you are making releases as upstream, you should only use upstream version strings; when you are making Debian packages as Debian packager, you should only use Debian package's version string and adjust the Debian revision part according to the packaging history. Please also read through packaging manuals, like debmake-doc[2]. [1] https://salsa.debian.org/kokoye2007-guest/ibus-table-myanmar/commit/2228a040b9a3dd2ebb53eb932b83f1d4efbc6f5c [2] https://www.debian.org/doc/manuals/debmake-doc/ -- Regards, Boyuan Yang 在 2019-03-25一的 21:40 +0630，Ko Ko Ye`写道： > Woo fast reply. > Thank you > > Thanks, I'll check them out. > > Also rebuild native to qulit package and reupload again. > > I am little confused with packages version number > > Eg 1.1 or 0.1 or 1.0-1 > > Which one is qulit version numbers. > I will learn and try tonight. > > > Thank for your time and consideration. > I will follow up with your guideline. > > Respectfully yours ... > > On Mon, Mar 25, 2019, 8:24 PM Osamu Aoki <osamu@debian.org> wrote: > > Hi, > > > > You know we are in freeze period ... this means no new package will > > migrate to testing. You have missed to release these packages for > > buster. But you have good chance for bullseye and bookworm ;-) > > > > Maybe chance to offer back port package for buster in future. > > > > So you are in no rush. > > > > On Mon, Mar 25, 2019 at 11:25:58AM +0630, Ko Ko Ye` wrote: > > > Hi Sir > > > > > > Please kindly check for our Myanmar Keyboard Package. > > > > > > I upload to mentor. > > > > > > ibus-table-myanmar is ibus-table base Myanmar Keyboard. > > > - ibus-table-zawgyi > > > - ibus-table-burmese > > > from 2010 to 2012 at Make file, > > > 2018 at try to upstream, but not get sponsor. > > > No implement form ibus-table-chinese source template. > > > https://salsa.debian.org/kokoye2007-guest/ibus-table-myanmar/ > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925442 > > > > OK > > > > > ibus-keymagic is keymagic smart keyboard for ibus engine > > > 50+ Language is using keymagic - 2009 ~ > > > its smart autocorrect, auto reorder with custom rules, can make custom > > > shortcut etc. > > > > OK > > > > > MacOS and Windows user is can download from Keymagic.net > > > i have PPA for Ubuntu 2012. but 2018 at Debian Mentor at fail with no > > > sponsor. > > > https://github.com/thantthet/keymagic > > > official keyboard list > > https://github.com/thantthet/keymagic/tree/master/ > > > LayoutScripts > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925333 > > > > Yah, we are very thin in resource. > > > > Why you make native package for ibus-table-myanmar. > > (Yah, I know its simple that way as a hack for local use but that may > > turn off sponsor. It looks sloppy. Even if you are now upstream, ... > > i > > Your watch file looks funny > > > > Are these packages lintian clean. > > > > Do you have prebuild package uploaded to https://mentors.debian.net/? > > > > I really don't have time but did you work with people to become DM? > > https://wiki.debian.org/DebianMaintainer > > https://mentors.debian.net/intro-maintainers > > > > If you give me a package in gbp-buildpackage ready with no lintian > > warning, I may consider uploading. > > > > This is simple enough package. Please read at least: > > https://www.debian.org/doc/manuals/debmake-doc/index.en.html and linked > > pages I wrote. > > > > Osamu
Attachment:
signature.asc
Description: This is a digitally signed message part