Bug#963832: RFS: iotop-c/1.0-1 [ITP] -- iotop-c - simple top-like I/O monitor (implemented in C)
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.
Reply to: