Suspicious file changes in -dbg between old and new packages
Hi, as mentioned in my other thread of today, my lib*-dbg*.deb packages do not contain the same files as their 2 year old predecessors. apt-file list from old libburn-dbg (1.3.2-1.1): libburn-dbg: /usr/lib/debug/usr/bin/cdrskin libburn-dbg: /usr/lib/debug/usr/lib/libburn.so.4.85.0 libburn-dbg: /usr/share/doc/libburn-dbg/AUTHORS libburn-dbg: /usr/share/doc/libburn-dbg/NEWS.gz libburn-dbg: /usr/share/doc/libburn-dbg/README.gz libburn-dbg: /usr/share/doc/libburn-dbg/changelog.Debian.gz libburn-dbg: /usr/share/doc/libburn-dbg/changelog.gz libburn-dbg: /usr/share/doc/libburn-dbg/copyright New libburn-dbg (1.4.0-2): libburn-dbg: /usr/lib/debug/.build-id/25/3fbbcf11829f90ddc91f8cf5194ac5278f804a.debug libburn-dbg: /usr/lib/debug/.build-id/8b/12591e70f8814691eb7ae38612fe396d63fd67.debug libburn-dbg: /usr/share/doc/libburn-dbg/AUTHORS libburn-dbg: /usr/share/doc/libburn-dbg/NEWS.gz libburn-dbg: /usr/share/doc/libburn-dbg/README.gz libburn-dbg: /usr/share/doc/libburn-dbg/changelog.Debian.gz libburn-dbg: /usr/share/doc/libburn-dbg/changelog.gz libburn-dbg: /usr/share/doc/libburn-dbg/copyright The new ones get installed in /usr/lib/debug/.build-id/. Is the new package content wrong ? If so, how to fix it ? I am not aware to have changed the content lists of libburn4 or the debian/rules file, except: "Removed dependency on doxygen" http://anonscm.debian.org/viewvc/pkg-libburnia/trunk/libburn/debian/rules?r1=296&r2=295&pathrev=296 "Switched from debhelper 8 to 9" http://anonscm.debian.org/viewvc/pkg-libburnia/trunk/libburn/debian/libburn4.install?r1=297&r2=296&pathrev=297 libburn-dbg has no own .install file and afaiks never had one. Where to learn more about -dbg packages and their production process ? Have a nice day :) Thomas
Re: Suspicious file changes in -dbg between old and new packages
"Thomas Schmitt" writes: > as mentioned in my other thread of today, my lib*-dbg*.deb > packages do not contain the same files as their 2 year old > predecessors. > > apt-file list from old libburn-dbg (1.3.2-1.1): > > libburn-dbg: /usr/lib/debug/usr/bin/cdrskin > libburn-dbg: /usr/lib/debug/usr/lib/libburn.so.4.85.0 [...] > New libburn-dbg (1.4.0-2): > > libburn-dbg: > /usr/lib/debug/.build-id/25/3fbbcf11829f90ddc91f8cf5194ac5278f804a.debug > libburn-dbg: > /usr/lib/debug/.build-id/8b/12591e70f8814691eb7ae38612fe396d63fd67.debug [...] > The new ones get installed in /usr/lib/debug/.build-id/. > > Is the new package content wrong ? > If so, how to fix it ? This is fine. debhelper installs detached debug symbols in a different location since compat level 9. From man:debhelper(7): | v9 This is the recommended mode of operation. | Changes from v8 are: | [...] | dh_strip puts separated debug symbols in a location based on their build-id. As far as I remember this was done to handle multi-arch better (to avoid having -dbg packages for different architectures install files to the same location so that they can be co-installed). > Where to learn more about -dbg packages and their production > process ? dh_strip handles most of it, but there are plans for larger changes in the future. Namely, building -dbg packages automatically. There should be a recent thread on -devel@ from this or last month; I think the subject mentioned "automated debug packages". Ansgar
Re: Suspicious file changes in -dbg between old and new packages
Hi, Ansgar Burchardt wrote: > This is fine. debhelper installs detached debug symbols in a different > location since compat level 9. Very good. My sponsor will love to hear that no action is needed. This raises the next question: How do i make use of libburn-dbg ? (E.g. for testing whether it works.) I installed it on amd64 Sid and run $ gdb /usr/bin/cdrskin ... Reading symbols from /usr/bin/cdrskin...(no debugging symbols found)...done. (gdb) q There seems to be no other "cdrskin" binary installed: $ find /usr -name cdrskin /usr/share/doc/cdrskin /usr/bin/cdrskin (I would also advise to compile -O1 or -O0 before debugging. Just adding symbols to the -O2 library might not give much opportunity for insight.) > [...] As far as I remember this was done to handle multi-arch better (to avoid > having -dbg packages for different architectures install files to the > same location so that they can be co-installed). I already wondered when i riddled about multi-arch and -dbg. But at that time i always stared at the old package listing. Then i saw the strange files and made a strange theory, which made Jakub say "Um". (Thanks for that.) > There should be a recent thread on -devel@ Still coping with the evolutionary step from "User:" to "Uploader:", i think that i'm not yet ready for -devel@. Have a nice day :) Thomas
Re: Suspicious file changes in -dbg between old and new packages
On Mon, Sep 21, 2015 at 06:25:07PM +0200, Thomas Schmitt wrote: > This raises the next question: How do i make use of libburn-dbg ? > (E.g. for testing whether it works.) > > I installed it on amd64 Sid and run > > $ gdb /usr/bin/cdrskin > ... > Reading symbols from /usr/bin/cdrskin...(no debugging symbols found)...done. > (gdb) q I get "Reading symbols from cdrskin...Reading symbols from /usr/lib/debug/.build-id/25/3fbbcf11829f90ddc91f8cf5194ac5278f804a.debug...done." ii libburn-dbg 1.4.0-2 amd64 debugging symbols for libburn and cdrskin ii libburn4 1.4.0-2 amd64library to provide CD/DVD writing functions ii cdrskin 1.4.0-2 amd64command line CD/DVD/BD writing tool -- WBR, wRAR signature.asc Description: PGP signature
Re: Suspicious file changes in -dbg between old and new packages
Hi, i wrote: > > $ gdb /usr/bin/cdrskin Andrey Rahmatullin wrote: > I get "Reading symbols from cdrskin...Reading symbols from > /usr/lib/debug/.build-id/25/3fbbcf11829f90ddc91f8cf5194ac5278f804a.debug... > done." A positive test. Thanks ! (Check on todo list) This gave me reason to do again dpkg -i cdrskin_1.4.0-3_amd64.deb from my locally built libburn packages. Suddenly it works: Reading symbols from /usr/bin/cdrskin...Reading symbols from /usr/lib/debug/.build-id/c0/66fcd4b56be0f2cc505c54b4ab566e582c8b1e.debug...done. But i am very sure to already have had installed cdrskin-1.4.0-3_amd64.deb (candidate package) together with libburn-dbg_1.4.0-3_amd64.deb. And why does it still work when i install back 1.4.0-2 ? Have a nice day :) Thomas
Re: Suspicious file changes in -dbg between old and new packages
Hi Thomas, >And why does it still work when i install back 1.4.0-2 ? well, if -2 and -3 didn't change symbols (e.g. you didn't patch the source code), why shouldn't it work? (I'm not sure to know how exactly the build.ids are mapped to the binary code, but I guess they work as long as the symbols table don't change)
Re: Suspicious file changes in -dbg between old and new packages
On 2015-09-22 07:30, Gianfranco Costamagna wrote: > Hi Thomas, > > > >> And why does it still work when i install back 1.4.0-2 ? > > > > > well, if -2 and -3 didn't change symbols (e.g. you didn't patch the source > code), > why shouldn't it work? > > (I'm not sure to know how exactly the build.ids are mapped to the binary > code, but I guess > they work as long as the symbols table don't change) > The debug package needs a strictly equal dependency on the original package, such as: "foo (= ${binary:Version})". That is orthogonal to the usage of build-ids (that is, you must use the strictly equal with or without build-id based debug paths). As for the build-id and how it is computed. It is based on the internals of the ELF binary including but not limited to: * The path where the binaries were compiled * The options given to gcc when compiled * Time and day, if such are included in the code (__DATE__ macros and such). Thanks, ~Niels signature.asc Description: OpenPGP digital signature
Re: Suspicious file changes in -dbg between old and new packages
Hi, i wrote: > > And why does it still work when i install back 1.4.0-2 ? Gianfranco Costamagna wrote: > well, if -2 and -3 didn't change symbols (e.g. you didn't patch the source > code), why shouldn't it work? I still wonder why it did not work on the first try. I had installed cdrskin and libburn-dbg multiple times since the change from debhelper 8 (.so in -dbg) to debhelper 9 (.build-id files in -dbg). Then Andrey reports success, i re-install cdrskin without a good reason, and suddenly the debugging symbols are found by gdb. The web tells me that there is gdb option -symbols=file and a startup file .gdbinit. But i did not use the option and the whole Sid disk does not have a file .gdbinit. The name of the symbol file is in the binary: $ strings /usr/bin/cdrskin | grep 66fcd4b56be0f2cc505c54b4ab566e582c8b1e 66fcd4b56be0f2cc505c54b4ab566e582c8b1e.debug So the feature seems to be based on a compile time trick. I was not able to break it by further installations. The initial riddle stays unsolved. Have a nice day :) Thomas
Re: Suspicious file changes in -dbg between old and new packages
On 2015-09-22 08:41, Gianfranco Costamagna wrote: > Hi Niels, > > [...] >> As for the build-id and how it is computed. It is based on the >> internals of the ELF binary including but not limited to: >> >> * The path where the binaries were compiled >> * The options given to gcc when compiled >> * Time and day, if such are included in the code (__DATE__ macros >> and such). > > > So how did it work for Thomas with the previous version installed? > > /me is confused :) > > cheers, > > G. > If the old and the new binary have the same build-id, they can reuse the same debug symbols - regardless of the debug symbols are installed by name or by build id. :) So if Thomas can use the old foo with the new foo-dbg, then I guess: * foo-dbg is missing the strict mandatory dependency (or Thomas passed force options to dpkg), and * Thomas built it in the same path as the previous location with the same options, and * upstream does not use any time based macros? On the plus side, this would imply that the ELF binaries are build reproducibly. :) Thanks, ~Niels
Re: Suspicious file changes in -dbg between old and new packages
Hi Niels, >The debug package needs a strictly equal dependency on the original >package, such as: "foo (= ${binary:Version})". That is orthogonal to >the usage of build-ids (that is, you must use the strictly equal with or >without build-id based debug paths). sure, I guess lintian even complains otherwise >As for the build-id and how it is computed. It is based on the >internals of the ELF binary including but not limited to: > >* The path where the binaries were compiled >* The options given to gcc when compiled >* Time and day, if such are included in the code (__DATE__ macros > and such). So how did it work for Thomas with the previous version installed? /me is confused :) cheers, G.
Re: Suspicious file changes in -dbg between old and new packages
Hi Niels, >If the old and the new binary have the same build-id, they can reuse the >same debug symbols - regardless of the debug symbols are installed by >name or by build id. :) > so the __TIME__ __DATE__ macros are not used, but *might* be used and not during the build-id computation, but during build, right? (I mean, it is a side-effect, not a requirement) >So if Thomas can use the old foo with the new foo-dbg, then I guess: > >* foo-dbg is missing the strict mandatory dependency (or Thomas passed > force options to dpkg), and >* Thomas built it in the same path as the previous location with the > same options, and >* upstream does not use any time based macros? > > >On the plus side, this would imply that the ELF binaries are build >reproducibly. :) Yes, I fully agree, this was the same conclusion. I guess it is a good empiric method for knowing if the build is reproducible :) thanks a lot! (that is a field where I don't touch if it isn't broken, and usually it worked so well that I never had to touch it :D ) cheers, G.
Re: Suspicious file changes in -dbg between old and new packages
Hi, Gianfranco Costamagna wrote: > So how did it work for Thomas with the previous version installed? The /usr/bin/cdrskin files of 1.4.0-2 and 1.4.0-3 are identical (at least their MD5s are). Curse or blessing of reproducible building. Niels Thykier wrote: > * The path where the binaries were compiled > * The options given to gcc when compiled These were identical. > * Time and day, if such are included in the code (__DATE__ macros and such). If i set such a thing at compile time then i don't get commended by the ReproducibleBuilds project. :)) (That's why i dropped my plan to add argument "buildstamped" to the debuild "make" run. One todo point less.) So it is explainable that symbol loading works between fewly different package versions. I would still like to know how i managed to break it. Just to be able to avoid this in future. Will watch this when i make packages of the future upstream releases. Have a nice day :) Thomas
Re: Suspicious file changes in -dbg between old and new packages
Hi, >So it is explainable that symbol loading works between >fewly different package versions. >I would still like to know how i managed to break it. >Just to be able to avoid this in future. as said before, the debug package should depend on binary:Version binary package. e.g. Package: foo Architecture: any Description: foo package this is the foo binary package! Package: foo-dbg Section: debug Architecture: any Depends: foo (= ${binary:Version}), ${misc:Depends}, ${shlibs:Depends} Description: Debug symbols for Foo This package contains debug symbols for the foo package. cheers, G.