Paul Wise <p...@debian.org> writes: > You build-depend on libdb-dev, in sid that depends on libdb4.7-dev but > the current dnshistory package is built against libdb4.6. Should you > add another debian/NEWS entry about this? I'm not sure what to do in > this situation, could you investigate?
I am not quite sure how to deal with that one. Since Luk Claes NMUed the package to change the Build-Depends from libdb4.4-dev to libdb-dev I don't really have control over which libdb version dnshistory is built against. If it happens that a new libdb is uploaded before dnshistory has been built on all archs or if a binNMU is triggered by a libdb transition debian/NEWS will be outdated. I wonder how other packages build-depending on libdb-dev handle this. That entry in debian/NEWS is somewhat special in that the dependancy on libdb had been downgraded from 4.5 to 4.4 in order to allow dnshistory to migrate into testing (etch at the time) and libdb4.5 was being kept out. On upgrade I would expect db files to be migrated if necessary. > > Only the above is a blocker, some other things you may want to look at: > > Please use $(QUILT_STAMPFN) instead of patch in debian/rules. > > Please make build-stamp depend on configure-stamp. > > ./configure gets run twice on my machine in pbuilder due to the above > two issues. I will take care of that. > > For some reason the mktime test in ./configure takes ages and a lot of > CPU in pbuilder and then fails. As explained by Sven this is due to an outdated ./configure. What is the best way to deal with that? Ignore? Run autoconf from debian/rules? Bug upstream? > > I get one dpkg-shlibdeps warning, please ask upstream to remove -lm > from the link flags: > > dependency on libm.so.6 could be avoided if > "debian/dnshistory/usr/bin/dnshistory" were not uselessly linked > against it (they use none of its symbols). How important is this? I doubt upstream will release a new version just to fix those minor issues. > > I get one lintian pedantic complaint: > > P: dnshistory: copyright-refers-to-symlink-license > usr/share/common-licenses/GPL Good catch, I will fix that, too. > > You might want to review the debtags and upload a screenshot: Since this is a console application and not primarily meant to be run directly by the user a screenshot is probably not very beneficial. Thanks for reviewing my package. Matthias -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org