Hi Gregor, On Thu, 2020-07-09 at 00:29 +0200, gregor herrmann wrote: > On Wed, 08 Jul 2020 20:09:03 +0300, Boian Bonev wrote:
> > should be fixed in the package - that option should come from dpkg- > > buildflags. > > It's not enabled by default, but you can add > > export DEB_BUILD_MAINT_OPTIONS = hardening=+bindnow > > to debian/rules to add the flag. > > Cf. dpkg-buildflags(1) -export LDFLAGS=-Wl,-z,now $(shell dpkg-buildflags --get LDFLAGS) +export DEB_BUILD_MAINT_OPTIONS=hardening=+bindnow Looks much cleaner in this way. > But I guess in this case a Breaks would be more appropriate than a > Conflicts. > > Cf. 7.3 and 7.4 in Debian Policy > https://www.debian.org/doc/debian-policy/ch-relationships.html#packages-which-break-other-packages-breaks > ff. I have changed Conflicts to Breaks+Replaces and it seems to work OK. Because both packages would install the same file, only Breaks wouldn't do, IMO, correct me if I am worng. > > > I: iotop-c source: testsuite-autopkgtest-missing > > Can't fix that. > > Well, you could write an autopkgtest :) > > Cf. https://ci.debian.net/doc/file.MAINTAINERS.html , > https://salsa.debian.org/ci-team/autopkgtest/raw/master/doc/README.package-tests.rst > etc. > > (But IMO that's not required for a first upload.) Writing a good test is quite far from trvial for this program. I will need some scartch space to write files to, run couple of processes that do IO in the scratch area according to some predefined pattern, collect the data via iotop (needs root) in batch mode and verify if the collected data matches the expected pattern... I would estimate that as about 2x the complexity of iotop itself. Thanks for your suggestions! With best regards, b.
