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