Re: (not) simplifying dpkg-shlibdeps with readelf
On Thu, Apr 22, 2010, Jonathan Nieder wrote: - readelf is tiny and works for all ELF targets. By contrast, multi-target objdump is large and its Debian package only supports the targets that were considered worth the trouble when it was last built. I guess you mean binutils-multiarch here; I submitted a patch in Debian #578365 to use a cross-objdump when cross-building. I expect objdump or cross-objdump should support the binaries which you're about to ship in a .deb. The only other case I can think of is when a package's build calls a non-default (cross-)compiler to generate a specific file, e.g. a firmware, in which case it might not be ELF at all. [1] To discover SONAME, NEEDED, RUNPATH, and RPATH, one could parse ‘eu-readelf --dynamic $file’ output. You might want to consider symbols as well as to have dpkg-shlibdeps and dpkg-gensymbols rely on the same underlying tool. -- Loïc Minier -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100426115011.ga14...@bee.dooz.org
Re: (not) simplifying dpkg-shlibdeps with readelf
Loïc Minier l...@dooz.org writes: On Thu, Apr 22, 2010, Jonathan Nieder wrote: - readelf is tiny and works for all ELF targets. By contrast, multi-target objdump is large and its Debian package only supports the targets that were considered worth the trouble when it was last built. I guess you mean binutils-multiarch here; I submitted a patch in Debian #578365 to use a cross-objdump when cross-building. I expect objdump or cross-objdump should support the binaries which you're about to ship in a .deb. The only other case I can think of is when a package's build calls a non-default (cross-)compiler to generate a specific file, e.g. a firmware, in which case it might not be ELF at all. For Lintian purposes, we've also found readelf to just generally be a much nicer tool. We have a lot of logic right now to patch around various problems with objdump, such as inferior error reporting, and I hope to eventually replace all that code with readelf, which always works the way that I expect it to work. This isn't a very persuasive argument for changing code that already works, of course, but if you do extensive work around the code that uses objdump, you may want to take a look at readelf. It's quite nice. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87sk6h3iqd@windlord.stanford.edu
Can the DEBIAN and SPECS subdirectories be unified? How about BIGJUJU?
The DEBIAN and and SPECS sub directories perform very similar and possibly identical functions among .deb and .rpm package managers. For the sake of saving developer time and make the two systems more compatible can a common name for these be agreed upon like for example PACK? Failing that how about BIGJUJU? A SOURCES subdirectory for .deb would also be advantageous. Between the two changes a higher degree of conceptual and actual similarity can be achieved. Can't we all get along? Nah. -- IV -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/z2t311679a81004262059j51e4c681z2285323c1d3d2...@mail.gmail.com
Processed: unarchiving 574024
Processing commands for cont...@bugs.debian.org:
unarchive 574024
Bug #574024 {Done: Raphael Hertzog hert...@debian.org} [dpkg-dev]
/usr/bin/dpkg-genchanges: dpkg-genchanges -v looks for exact version, not
strictly later
Unarchived Bug 574024
thanks
Stopping processing here.
Please contact me if you need assistance.
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--
To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Processed: reopening 574024
Processing commands for cont...@bugs.debian.org:
reopen 574024
Bug #574024 {Done: Raphael Hertzog hert...@debian.org} [dpkg-dev]
/usr/bin/dpkg-genchanges: dpkg-genchanges -v looks for exact version, not
strictly later
thanks
Stopping processing here.
Please contact me if you need assistance.
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--
To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#574024: /usr/bin/dpkg-genchanges: dpkg-genchanges -v looks for exact version, not strictly later
reopen 574024 thanks Hi! * Raphael Hertzog hert...@debian.org [2010-03-28 23:35:21 CEST]: On Mon, 15 Mar 2010, Raphael Hertzog wrote: It does, at least here. Can you show me where it doesn't work as expected? Can you verify with dpkg-dev 1.15.6 from experimental too? No answer, so closing for now. You told me it might be a bad pbuilder interaction on IRC. Feel free to reopen and reassign if necessary. It just happened again, and according to the build log of cowbuilder dpkg-genchanges is called properly: dpkg-genchanges -sa -v1:1.6.5-1~bpo50+1 ../wesnoth-1.8_1.8-3~bpo50+1_i386.changes Still, I have changelog entries in the changes file back until to the very first one, which is versioned 0.4.8-1 - clearly lower than 1:1.6.5-1~bpo50+1. The changelog though, like written, doesn't contain 1:1.6.5-1~bpo50+1 itself, so it clearly can't do a strictly later comparison on the version. Enjoy, Rhonda -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#574024: /usr/bin/dpkg-genchanges: dpkg-genchanges -v looks for exact version, not strictly later
On Mon, 26 Apr 2010, Gerfried Fuchs wrote: No answer, so closing for now. You told me it might be a bad pbuilder interaction on IRC. Feel free to reopen and reassign if necessary. It just happened again, and according to the build log of cowbuilder dpkg-genchanges is called properly: dpkg-genchanges -sa -v1:1.6.5-1~bpo50+1 ../wesnoth-1.8_1.8-3~bpo50+1_i386.changes Still, I have changelog entries in the changes file back until to the very first one, which is versioned 0.4.8-1 - clearly lower than 1:1.6.5-1~bpo50+1. The changelog though, like written, doesn't contain 1:1.6.5-1~bpo50+1 itself, so it clearly can't do a strictly later comparison on the version. Surely you're using dpkg-genchanges of inside the chroot and you're using the lenny version that is indeed not fixed? From changelog of 1.15.1: * Fix dpkg-buildpackage/dpkg-genchanges to properly interpret option -v0. Closes: #475916 If that's the case please close it again with version 1.15.1 as the version fixing it. Cheers, -- Raphaël Hertzog Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/ My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#574024: /usr/bin/dpkg-genchanges: dpkg-genchanges -v looks for exact version, not strictly later
* Raphael Hertzog hert...@debian.org [2010-04-26 16:34:47 CEST]: On Mon, 26 Apr 2010, Gerfried Fuchs wrote: dpkg-genchanges -sa -v1:1.6.5-1~bpo50+1 ../wesnoth-1.8_1.8-3~bpo50+1_i386.changes Still, I have changelog entries in the changes file back until to the very first one, which is versioned 0.4.8-1 - clearly lower than 1:1.6.5-1~bpo50+1. The changelog though, like written, doesn't contain 1:1.6.5-1~bpo50+1 itself, so it clearly can't do a strictly later comparison on the version. Surely you're using dpkg-genchanges of inside the chroot and you're using the lenny version that is indeed not fixed? Erm, yes. When building packages for lenny-backports that obviously happens inside a lenny chroot. :) From changelog of 1.15.1: * Fix dpkg-buildpackage/dpkg-genchanges to properly interpret option -v0. Closes: #475916 If that's the case please close it again with version 1.15.1 as the version fixing it. Actually I haven't tested in squeeze, but reading that bugreport it seems like it is about something different? And scanning the linked commit doesn't really point like this is the cause of the issue neither somehow. Thanks anyway for the headsup, it is clearly reproducible over here. Rhonda -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#574024: /usr/bin/dpkg-genchanges: dpkg-genchanges -v looks for exact version, not strictly later
On Mon, 26 Apr 2010, Gerfried Fuchs wrote: From changelog of 1.15.1: * Fix dpkg-buildpackage/dpkg-genchanges to properly interpret option -v0. Closes: #475916 If that's the case please close it again with version 1.15.1 as the version fixing it. Actually I haven't tested in squeeze, but reading that bugreport it seems like it is about something different? And scanning the linked commit doesn't really point like this is the cause of the issue neither somehow. It's the same really, your version doesn't exist in the changelog exactly like version 0 usually never exists. Cheers, -- Raphaël Hertzog Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/ My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/ -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
