Bug#895574: lintian: binary-compiled-with-profiling-enabled test fails on Ubuntu's armhf
Hey Niels!
On Mon, Apr 23, 2018 at 05:42:00AM +0000, Niels Thykier wrote:
>
>When you write that it is a lot of effort to debug the lintian tests,
>then I wonder if it is because our documentation is lacking. Like:
>
> * We can run the test in isolation (i.e. you don't have to run all the
> tests).
No problem, I found that OK.
> * The output artefacts are left in the test directory (debian/test-out
> by default) for manual analysis.
Ditto.
> * Lintian has a --keep-lab (-v) that leaves the lab behind (and prints
> where it left it) for manual analysis.
> * Lintian can be run directly from the checkout (with any local
> modifications) to able to experimental with changes. Including
> running it on the test artefacts to shave some overhead in the test
> runner.
>
>Is there any of the above points, that would have made your debugging if
>you had known it ahead of time? Or any of it, that we should have made
>more easily available in the documentation?
I've never done anything beyond the trivial with lintian before; my
normal initial approach of "grep the code for the error message"
didn't help very much when trying to find how things are run. Driving
thing from the "debuild" level (as I started) feels like you're 3 or 4
steps removed from the action, with *very* little clue as to where to
go next.
I started trying to find out how the binary "basic" was built, as that
was the target that was showing test problems. But I couldn't find any
output *anywhere* in the lintian build to show the compiler command
lines used for the test packages.
So I changed tack - I found where it was built by searching for it,
and manually ran readelf to check it. Fine, that showed it was ok and
I then found the Makefile for it.
However, going from there to the problem was still non-obvious. In my
case, it was difficult to work out exactly the commands run when a
test is performed. The particular example here comes from running
objdump against some binaries, then comparing error and warning
results against an expected set of results.
In the end, my path was:
* dig, dig, dig
* hack t/runtests to add "--debug" to the lintian invocation
* that told me to run "t/runtests -v -v -k t
.../lintian-2.5.83/debian/test-out binaries-general"
* then I could add some simple printf-style debugging in the code for
the profiling regex match
* profit!
Some way of getting lintian to print the *actual commands run* for
its test would be helpful here.
--
Steve McIntyre, Cambridge, UK. steve@einval.com
< Aardvark> I dislike C++ to start with. C++11 just seems to be
handing rope-creating factories for users to hang multiple
instances of themselves.
Reply to: