Re: Full lintian run started
On Sat, 2008-08-30 at 21:52 +0200, Frank Lichtenheld wrote:
> Hmm:
> readelf: Warning: Virtual address 0x970c not located in any PT_LOAD segment.
> readelf: Error: Out of memory allocating 0xffff8c1f bytes for symbols
[...]
> Not sure which packages these were in due to the fact that we do not get
> stderr and stdout together.
In order to see if I can reproduce the problem locally, I'm running a
full archive lintian run using just the binaries / files / shared-libs
checks (i.e. those which use the objdump-info collection script) and a
slightly tweaked copy of the script which outputs lines beginning
"readelf" to a separate file in the laboratory. Unfortunately the only
i386 machines I have access to at the moment don't have a local mirror
easily available so it's running on my local mirror which is an armel
box; it could be some time before it's finished - in a little under 24
hours it's processed the udebs and reached "l" in source packages.
There are two tags relating to objdump failures for which the new
readelf code would be called - apparently-corrupted-elf-binary and
binary-with-bad-dynamic-table. With 1.24.4, lintian.d.o no longer issues
either tag for any packages.
All of the packages for which apparently-corrupted-elf-binary was
previously being issued were 64-bit binaries which should now be
correctly parsed; for example, both shared libraries
in /usr/lib64/fakeroot now generate shlib-with-executable-bit instead.
There were four packages which were causing binary-with-bad-dynamic-
table whereas there now appear to be none; checking the packages using
current git on sid/amd64 also causes those tags to be issued.
I'm not sure how easy testing the packages in question by hand on gluck
to see if they generate the errors when checked outside the harness is,
but for reference they are crystalspace, libqt4-dbg, libqt4-webkit-dbg
and libqt4-xmlpatterns-dbg.
Adam
Reply to: