Hi Brad,
Peters, Brad T wrote:
Hi Stéphane,
I'm a fervent believer in first-crash data capture, especially when you're
environment is
unstable to begin with (ie 3.0). Installing debug packages after the fact
requires
reproducing the issue, which may or may not happen and wastes time.
I agree with that. But we should note somewhere (in a bug, a feature on Jira for
example) that "releasing" implies a full strip of the binaries (it's easy to
forget that point when releasing). Perhaps this is something to be added earlier
in the release cycle, to have QA teams work on snapshots that would be as close
as possible to the release image.
Anyway, for TZ 3.0, we can keep rpm as is for the moment.
That said, it looks like 3.0 binaries are already partially stripped (check out
this patch:
https://review.tizen.org/gerrit/gitweb?p=platform/upstream/rpm.git;a=commit;h=343c985ee3f8e027386fec73da1c63f827e48a03
)
I investigated on "semi-stripped" binaries lately and found the same patch from
William Douglas. Duplicate brains ;-)
My discovery is that:
- checking if a binary is stripped with /usr/bin/file is approximative. I mean
that if a binary contains only symbol sections (and no debug), /usr/bin/file
will report the binary as 'non stripped'. This is not false, but that's not the
information we want :-) On the opposite, when /usr/bin/file says that a binary
is "stripped", it's right: no debug, no symbols.
- so we have to analyze further to detect the "badly" stripped binaries, those
stoll containing debug sections. One good candidate is webkit, that has 1.2GB in
debug sections !
=> there's at least a webkit specific bug to open.
Tomorrow, I'll check the "bad" binaries and report on this.
For 2.x, perhaps we could back-port this patch.
I recommend opening a bug for 2.2 and one for 2.1. We should definitely be
stripping binaries there,
even if retaining symbol information as with that patch
It makes sense.
Thanks for your feedback.
--
Stéphane Desneux
Intel OTC - Vannes/FR
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
