Re: Suspicious file changes in -dbg between old and new packages

[Gianfranco Costamagna]

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

[Gianfranco Costamagna]

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

[Niels Thykier]

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

[Gianfranco Costamagna]

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

[Niels Thykier]

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

[Gianfranco Costamagna]

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.

Re: Suspicious file changes in -dbg between old and new packages

[Thomas Schmitt]

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

[Thomas Schmitt]

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

Suspicious file changes in -dbg between old and new packages

[Thomas Schmitt]

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=295=296

  "Switched from debhelper 8 to 9"
  
http://anonscm.debian.org/viewvc/pkg-libburnia/trunk/libburn/debian/libburn4.install?r1=297=296=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

[Ansgar Burchardt]

"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

[Thomas Schmitt]

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

[Andrey Rahmatullin]

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

[Thomas Schmitt]

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