Exact revision numbers in bugreports (was Re: pre-releases of rc1)
Lubos Lunak
l.lunak at suse.cz
Mon Jun 29 16:52:59 CEST 2009
Moving to kde-core-devel.
On Monday 29 of June 2009, Pierre Schmitz wrote:
> On Monday 29 June 2009 13:52:34 Sebastian Kügler wrote:
> > It's not so much stress, but usefulness of the RC for us. If people
> > report against RC1, and it isn't what RC1 is, the bugreport (which is in
> > principle exactly why we do an RC) becomes less useful.
...
> If there would be a way to have drkonqi sent the build date or even better
> the svn revision number this "problem" would be solved.
Piece of cake :). Copy e.g. your libkdecore.so.5.3.0 somewhere and do:
$ echo -n 'r1234567' >r.txt
$ objcopy libkdecore.so.5.3.0
libkdecore.so.5.3.0.tmp --add-section .note.kde=r.txt
$ mv libkdecore.so.5.3.0.tmp libkdecore.so.5.3.0
Now the binary has the given revision number recorded in it as a separate
section. To print it, 'objdump -s -j .note.kde libkdecore.so.5.3.0', and cut
out only the relevant part.
When creating a release tarball from SVN (we have a script for that, don't
we?), the revision number of the checkout could be added to the tarball as a
specifically-named file or recorded somewhere in CMakeLists.txt or wherever.
During building and installing for packaging binaries could be modified this
way. Normal SVN checkouts and source builds wouldn't do this.
And when drkonqi handles a crash, it knows what binary it is and it gets a
full list of all needed libraries in the backtrace, so it can extract this
information and add it to the backtrace for the bugreport.
This is all ELF-specific, but I don't think we can get more generic than
this, and doing this at compile time only doesn't seem to be easily possible
to me.
Now, this all sounds like an interesting thing to do, but I'm afraid I don't
have the time. Does somebody else want the pleasure?
--
Lubos Lunak
KDE developer, magic whenever needed, miracles at a request ;)
More information about the release-team
mailing list