Hi Mattia, We went through the list and met one issue,
dpkg-genchanges: warning: package osptoolkit-dbgsym listed in files list but not in control info dpkg-genchanges: warning: package libosptk4-dbgsym listed in files list but not in control info All others look fine. The updated packages have been uploaded to mentors. BTW, we believe #555877 have been fixed in 3.4.2-1.1 by explicitly linking external libraries. Thanks, Di-Shi Sun. -----Original Message----- From: 'Mattia Rizzolo' [mailto:mat...@debian.org] Sent: Thursday, June 23, 2016 6:47 PM To: Di-Shi Sun Cc: 825...@bugs.debian.org; 'Support of Transnexus' Subject: Re: Bug#825701: should osptoolkit be removed from Debian? On Thu, Jun 23, 2016 at 05:26:12PM +0800, Di-Shi Sun wrote: > Sorry for the delay. We just fixed the upload issues on > mentors.debian.net. You can find it at > https://mentors.debian.net/package/osptoolkit > > There are several thing about the warning messages on > mentors.debian.net 1. no-upstream-changelog. The upstream source package includes RELNOTES.txt for its changes. I am not sure if we must put all the change info into debian/changelog. https://www.debian.org/doc/debian-policy/ch-docs.html#s-changelogs There is a dh_installchangelog utility, you should use it to install RELNOTES.txt *but* that file clearly has not been updated in a long time, so it's probably more harmful than anything to ship it, so ignore that message. > 3. A watch file is present but doesn't work. We tested the watch file on our boxes. I do not know why mentors.debian.net thought it does not work. Because mentors.d.n runs on wheezy, and there uscan is not newer enough to work with version=4 files. > BTW, we did not see any of these warning when we run lintian on our boxes. Depends on level of "pendicness" you ask lintian. > Please let us know if there is anything should be modified. I'd like to ask you a few things, following newer best practise in debian packaging: * drop the -dbg package: nowdays debhelper automatically builds -dbgsym packages (though they are not installed in the main debian archive, but in a separate "debug archive") https://wiki.debian.org/AutomaticDebugPackages * try dropping all the debian/*dirs files: they are usually useless, as debhelper tools take care of creating needed directories before installing files; is my personal belief that if you need such files thare are good chances your build system is buggy. I tried and it fails to build, so I suggest you to put on your todo to make your build system more clever and create the needed directories. * d/patches/test_app.c.patch: I can't think why that would be 'Forwarded: not-needed', why can't you apply that upstream? * please rename d/docs to d/osptoolkit.docs: d/docs is a very confusing file name because it makes you think that it install the docs in all produced binaries, while instead it only install them in the first package list in d/control... (I had a lot of people thinking it wrong, so I now advocate for renaming) * versioned -dev packages usually bring only pain during transitions, as they require source changes to all reverse-dependency to change build-depends. I appreciate that you don't have this problem as you don't have reverse-depends, but I wonder if you can take this occasion to rename the -dev package to just 'libosptk-dev'. BTW, in both cases you should add a Conflicts: against the old -dev package, as both ship the same files, and so can't be installed toghether (I prefer a Conflicts (or Conflicts+Replace) in this occasion, rather than a Breaks+Replaces, since you should prefer the removal of the old binary before installing this). See https://www.debian.org/doc/debian-policy/ch-relationships.html#s-conflicts (and ยง7.6). * do you think you can close #555877 too? * in d/rules: + that `ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))`... is not needed: with a new enough dpkg and if you obeys dpkg-buildflags (which you do) is obsolete + can you convert your d/rules to use the dh sequencer instead? + please just remove the .la file. I'm sure it's not used inside debian. Do you instead have any use for it? (as a OS developer I dislike static libraries by a great deal) * d/*.install: they are all useless: thanks to that different sequence of `make install` in d/rules files are already installed in their final location, so dh_install (the program that reads those files) has nothing to do. So, they can go away. I appreciate that's quite some list of things, so I've done some of them, attached a debdiff. Please ping me as soon as you have an updated package, following my suggestions :) -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
