An updated copy of ddcutil has been uploaded to mentors reflecting
Andrey's review. Comments interspersed.
On 08/20/2017 12:02 PM, Andrey Rahmatullin wrote:
The package FTBFS:
dh_install
dh_install: Cannot find (any matches for) "/usr/bin" (tried in ., debian/tmp)
dh_install: ddcutil missing files: /usr/bin
dh_install: Cannot find (any matches for) "/usr/share/man" (tried in .,
debian/tmp)
dh_install: ddcutil missing files: /usr/share/man
dh_install: Cannot find (any matches for) "/usr/share/ddcutil/data/*rules"
(tried in ., debian/tmp)
dh_install: ddcutil missing files: /usr/share/ddcutil/data/*rules
dh_install: Cannot find (any matches for) "/usr/share/ddcutil/data/*conf"
(tried in ., debian/tmp)
dh_install: ddcutil missing files: /usr/share/ddcutil/data/*conf
dh_install: missing files, aborting
debian/rules:9: recipe for target 'binary' failed
Fixed. Deleted file debian/ddcutil.install
Please run lintian (with -EI --pedantic and against the binary .changes) and
review its output.
After executing pdebuild on buster for distribution buster, the lintian
output is as follows:
W: ddcutil source: newer-standards-version 4.1.0 (current is 4.0.0)
See below.
I: ddcutil source: testsuite-autopkgtest-missing
ddcutil has no test suite.
P: ddcutil source: debian-watch-may-check-gpg-signature
There is no signature checking. Simply put I haven't been able to
get it to work.
P: ddcutil: no-upstream-changelog
To be added in a future point release and installed in
/usr/share/doc/ddcutil. However, in the spirit of DRY entries will
basically just point to the web site for detail.
W: ddcutil: new-package-should-close-itp-bug
Should a mentors upload close the ITP bug?
Please update to the current Standards-Version (you've missed that in the
previous review).
Was at 3.9.8, the highest version recognized by lintian in mentors.
I've now changed it to 4.1.0, the version in the 2017-08-21 policy
manual. Of course, this means that no release of lintian I've yet
encountered recognizes the version.
The first line of License: GPL-2.0+ block in d/copyright contradicts everything
else (and is not actually needed).
First line deleted.
Why do you need
DPKG_EXPORT_BUILDFLAGS = 1
include /usr/share/dpkg/default.mk
?
Historic cruft. Deleted.
Vcs-* don't point to the packaging repo.
Now we come to what I think is a substantive issue. The Vcs-* entries
pointed to the upstream repository. Though it wasn't clear from the
policy manual, I gather from your comment that the Vcs-* entries need to
point to a debianized repository. There currently is no such
repository. Trying to support the increasing number of variants for
dpkg and rpm packaging in the upstream repository under autotools became
an unwieldy mess. It is being factored out. The role of the upstream
repo is simply to produce a distribution agnostic tarball.
Accordingly, I have deleted the Vcs-* entries. The tarballs produced
by upstream are published at http://www.ddcutil.com/releases/, and the
watch file has been changed to point to that page instead of the git
repository.
Are tarballs sufficient or is a debianized repo required? Page
https://wiki.debian.org/PackagingWithGit#pbuilder describes a process
for maintaining one. Is this the proper method?
