[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#604047: warning: collect info objdump-info about package PACKAGE failed



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

clone 604047 -1
severity 604047 important
tags 604047 confirmed
retitle -1 lintian: running jobs are not always stopped
owner -1 !
severity -1 important
tags -1 confirmed
thanks

Hey Andreas


Thanks for the bug reports.  I have split your original report into two.
 #604047 will trace the progress of handling the experimental binutils
and the new one will be handling the race-conditions you also noticed.



The issue with the experimental binutils affects some packages, but I
have successfully tested some packages.
  The cause of the issue is that objdump -T returns 0 in unstable and 1
in experimental when examining nvidia.ko[1] in the deb package.  The
actual output appears to be identical, namely (modulo linewraps):

"""
$ objdump -T unpacked/lib/modules/2.6.32-5-amd64/nvidia/nvidia.ko

unpacked/lib/modules/2.6.32-5-amd64/nvidia/nvidia.ko:     file format
elf64-x86-64

objdump: unpacked/lib/modules/2.6.32-5-amd64/nvidia/nvidia.ko: not a
dynamic object
DYNAMIC SYMBOL TABLE:
no symbols
""""

objdump -T --headers --private-headers looks the same as well in both
cases (but it still exits 1 in experimental).  Removing the -T will make
it succeed and I found the following entry in the upstream changelog:

2010-10-05  Alan Modra  <amodra@gmail.com>

[...]
        * objdump.c (free_only_list): Formatting.
        (slurp_dynamic_symtab): Non-zero exit status for "not a dynamic
        object".
[...]
	(main): Return non-zero exit status on bad options.
[...]

I guess objdump has become a bit more strict with its exit codes :)

~Niels

[1] ./lib/modules/2.6.32-5-amd64/nvidia/nvidia.ko

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJNMs2hAAoJEAVLu599gGRCA/UQAJaABFgxu5GGgFGJGI7YkOWY
yPF1fvto3iut9PdPFVhfMgkJQ/YHN9RLDXFzprDTkKoZbavk5EaYx1yY2B2uE9Q3
DbLN0cx1zQshOmfGAGKkCh5baxj50hscn1chn6ilO1Sji7j0zlOL+wgVXORToPnl
AdlVWvJxl4LdZoZlXUlcRb0qAP7gubWLhbz/IUtDXEfRpiGaYYXD+yN20yxmdAQk
4+nbfnf7YpMqFhe7CIw99CHw4rbzvfnkTaVe41nz+uL5XWKyh2YwYiROeHCNgFVJ
9c4x1doQSoWEhAVA7Cp3yS79nFOFt3NEQgpambc5/9SxT5BsBB3Niv69koy4jgrn
5sKuxeU+exe0QOgKJ15JzoftzBAW0Rs06xwtcEFUMW07BcjdSgmZB8PhXZhygC4I
GK877DZb13uaU1kQDxfl6H9pTxx9ZL6OzvkA5Mi5FeY3ITpKh59jQKl01Cz2ENRq
GMjLoKSKdU83cI14t5tieNeyc9aTIee5eJmaa/8xNYTXx7TJVmFRVe4K+xqiHy9U
UNpKq/83zKitnqrgA7uk/3Oa/LyewhnMUu2Oy2FsHn6qzUTdMWfRmvMBIMnxzgKD
RbZGPicf0NF0vIIE2RePvLu2ewk24zuEc5ictIxWYrOCm1HEEs0wGBuTAAEcLAzO
kO3iLMNrSDwm/55To3Sk
=7J3C
-----END PGP SIGNATURE-----



Reply to: