On 3/20/14, Christian Kastner <[email protected]> wrote: > Hi, > > On 2014-03-13 05:57, Robert Ransom wrote: >> I am looking for a sponsor for my package "libb2": > > I'm not a DD so I can't sponsor your package, but here is a quick review: > > > Building > ======== > > There is one troublesome aspect of the upstream code: AFAICT, > CPU-specific optimizations such as MMX, SSE, etc. are detected and > enabled at compile-time. > > That is a problem because your binary packages will end up with > optimizations specific to the buildd they were built upon, but the > platforms they will run upon might lack support for those optimizations. > > I suggest you either verify that this is not a problem (eg run-time > support detection) or disable some of those optimizations. > > The [email protected] will probably be able to you which instruction > sets you are allowed to assume as always present in certain > architectures (eg "amd64 always has MMX" or some such).
The --enable-fat configure option enables libb2's run-time CPU feature detection code. > debian/control: > ============== > > Build-Depends: debhelper (>= 9), not debhelper (>= 9.0.0). IIRC there > exists a (written or unwritten) rule for when one can/should truncate > version numbers, but I can't find a source for that at the moment so I > could be wrong. Regardless, debhelper(7) recommends this. > > You do not need to specify the Section: for binary packages if the > intended Section matches the source package section, so the "Section: > libs" can be omitted from binary package libb2-1. dh-make-0.61 generated the duplicate Section field and a “debhelper (>= 8.0.0)” Build-Depends item. dh-make-0.63 appears to still generate these. When I upgraded the package to debhelper 9 for multi-arch support, I changed only the major version number, under the assumption that dh-make would not have added the “.0.0” unnecessarily. If the changes you suggest are worth making, they are worth making in dh-make first. > If you're using a VCS for your packaging, it would be nice if you could > include Vcs-* URLS pointing to the repository. This simplifies > contributing to your packaging. I am not using a version-control system for this package. I would not have a trustworthy place to publish a version-control repository for this package even if I were using a VCS. > debian/copyright: > ================= > > I'd add the Upstream-Contact field to the header section using the > address you specified in the ITP. * dh-make-0.61 and dh-make-0.63 do not include an Upstream-Contact field in the copyright files they generate. * The e-mail address specified in the ITP bug for this package is hosted on the same domain name as the upstream web site (which is specified in the copyright file and which lists more complete contact information for the upstream maintainers), so in the specific case of this package, I see no possible benefit to including that e-mail address in an Upstream-Contact field. > debian/rules: > ============= > > You can drop the "Sample debian/rules that uses debhelper" part. I'm not willing to remove the attribution from that file. If the dh-make template authors do not want their work attributed to them, they can modify dh-make to not copy that notice into its output. > Later releases (somewhat more advanced topics) > ============== > > You could generate minimal dependencies by creating using a symbols > file, see > > https://wiki.debian.org/UsingSymbolsFiles According to that page, adding a symbols file and maintaining it imperfectly is worse than not including a symbols file at all. Since this package is security-critical and I don't expect it to have frequent updates, I would prefer to not add a symbols file for it. If upstream does start to release new versions frequently, I will consider adding a symbols file. > You could install lintian overrides to silence a couple of informational > and pedantic warnings, see > > $ lintian -I --pedantic *.deb *.dsc It is inappropriate to add overrides for lintian messages at info level or below. Info-level messages might be of interest to other developers, or might be raised to warning or error level in the future due to policy changes. The lintian man page specifically recommends against adding overrides for ‘pedantic’ messages. Robert Ransom -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: https://lists.debian.org/cabqy+sruj_ch+qsbymghcrrveuhffj0gtodwe9o3ov+xo_d...@mail.gmail.com
