mtr: Fix compile with libcap

[neheb]

Selecting libcap in addition to mtr causes it to error with

Package mtr is missing dependencies for the following libraries:
libcap.so.2

Signed-off-by: Rosen Penev [email protected]

Maintainer: @jmccrohan
Compile tested: ar71xx

[notnyt]

This fixes the compile, but you also need to adjust the makefile to install mtr-packet. Also, the version comes up as unknown for some reason

root@rooter:~# mtr -v
mtr UNKNOWN

[neheb]

I don't maintain mtr. But I will fix those issues in a few hours.

[neheb]

Fixed the first issue. I don't think I fixed the second as it depends on the actual git repository being present.

I tried switching to the official tarball but that just gave an error saying wrong version of automake.

[flipreverse]

Can you please merge this pull request?
I'm currently stuck at building my own OpenWRT image, because it contains mtr.

[neheb]

Ask @hnyman

[flipreverse]

@hnyman Thx! Works. :)

[stintel]

This PR should not have been merged for various reasons:
The commit contains several unrelated changes - they should each have gone in a separate commit.
Disabling libcap support could have been done with CONFIGURE_VARS += ac_cv_lib_cap_cap_set_proc=no instead - no hackish patch needed.
No maintainer approval.
And since the configure script strongly recommends libcap support for security, I would have actually preferred to add libcap as a dependency instead of disabling libcap support.

Please do proper reviews, especially if you merge PRs without maintainer approval!

[hnyman]

We have a growing problem of disappearing maintainers.

In general, if there are PRs from regular submitters, there is maintainer timeout, the commit works in Travis, I have not been too picky on the coding style lately. Too many missing maintainers, even from among the Openwrt main repo committers...

It is really disappointing to PR authors that there is no action regarding their PRs.

Feel free to take part of reviewing and merging PRs. I can gladly stop participating in doing that and will let you handle the pile ;-)

[neheb]

Second.

Related: #6584

Patch vs. CONFIGURE_VARS was due to my unfamiliarity with autotools. The proper solution is to make it configurable, which I gave up on after failing.

I am not an mtr user and as such, I do not see the value in adding a new dependency.