On 21.09.2010 18:20, Ulrich Weigand wrote:
Hello Michael,
I'm looking into "branding" changes needed for a Linaro GDB release. So far I've made the following changes:
- Set default PKGVERSION to "Linaro GDB" instead of "GDB"
- Set default BUGURL to "http://bugs.launchpad.net/gdb-linaro/" instead of
"http://www.gnu.org/software/gdb/bugs/"
- Set version number according to Linaro version scheme
- Update release script to generate tarballs/directories named
"gdb-linaro-$VERSION" instead of "gdb-$VERSION".
As a result, the default GDB startup output now reads:
GNU gdb (Linaro GDB) 7.2-2010.10-0 Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu". For bug reporting instructions, please see: http://bugs.launchpad.net/gdb-linaro/.
Do you agree that this is the way we should go? Have I overlooked anything?
Unless there are objections, I'm planning to check these changes in later this week.
Note that these values are overridden when configuring --with-pkgversion and --with-bugurl. But this looks fine (and maybe should be used for the Linaro GCC too).
As a related question, the generated files in a standard GDB 7.2 release seem to have been built on a relatively old system (RHEL 4 ?), which is visible through the versions of tools like bison, flex, texinfo, and gettext used to build those files. When building our Linaro GDB release tarballs, should we:
- just use the tools as installed on a recent build system (say, Ubuntu
Lucid), or
- attempt to rebuild the release with the exact same set of tools used for
the GDB 7.2 release?
The second option has the advantage of reducing the amount of changes, e.g. visible in a full diff of the release tarballs. However, it has the disadvantage that reconstructing those exact set of tools (including Red Hat patches, it seems) is somewhat difficult, and can in addition lead to somewhat outdated results ...
for the GCC packages I'm using the versions required by upstream (autoconf2.64, automake1.11), there even is an autoconf2.64 package for this purpose in the archives. The binutils and GCC toplevel configuries are kept in sync, not sure about the gdb one.
Matthias