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.
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 ...
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
-- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294
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
Matthias Klose doko@ubuntu.com wrote:
Note that these values are overridden when configuring --with-pkgversion
and
--with-bugurl.
Yes, of course -- for the Ubuntu build they *should* refer to Ubuntu, instead of Linaro. But those defaults are intended for people who build the Linaro GDB from our source releases ...
But this looks fine (and maybe should be used for the Linaro GCC too).
OK, thanks.
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.
I wasn't refering to the configury files (which are already present in the bzr/cvs repository and will not be regenerated during packaging), but to files like c-exp.c (generated via bison/flex), the gdb.info files (generated via texinfo) or the gdb.pot files (generated via gettext). These are not even present at all in the repository (users building from the repository need to have all those tools installed), but will get generated when packaging up a release source tarball ...
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
-- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294
On Wed, Sep 22, 2010 at 4:20 AM, Ulrich Weigand Ulrich.Weigand@de.ibm.com 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?
These all sound good. Andrew, are there any other changes you can think of?
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?
We should use the tools that come with Lucid. This does cause a bigger diff but is easier to reproduce and less of a maintenance problem.
I'm not happy with generated files being checked in, but we have to do that to be drop-in replacement for the upstream GDB.
If it's straight forward then I'd like to avoid checking in the generated files if the change is only due to tool changes. We will regenerate everything as part of the release process but it would be nice to keep the branch clean.
-- Michael
Michael Hope michael.hope@linaro.org wrote on 09/21/2010 11:44:14 PM:
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?
We should use the tools that come with Lucid. This does cause a bigger diff but is easier to reproduce and less of a maintenance problem.
OK, sounds good. We'll need to make sure to test the final released tarball, to verify that there's no problem with those versions of generated files ...
I'm not happy with generated files being checked in, but we have to do that to be drop-in replacement for the upstream GDB.
If it's straight forward then I'd like to avoid checking in the generated files if the change is only due to tool changes. We will regenerate everything as part of the release process but it would be nice to keep the branch clean.
They'll not be checked into the branch; they'll be generated on the fly and simply become part of the tarballs.
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
-- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294
On 21/09/10 22:44, Michael Hope wrote:
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?
These all sound good. Andrew, are there any other changes you can think of?
GDB seems fine, except that I'd prefer that it didn't say "2010.10-0" until we actually spin the release. GCC is currently set to "development 2010.09-2", even though there probably never will be such a release. Basically, if somebody takes a snapshot, I'd like the --version string to be different from the official release.
What does gdbserver say?
Andrew
Andrew Stubbs ams@codesourcery.com wrote:
GDB seems fine, except that I'd prefer that it didn't say "2010.10-0" until we actually spin the release. GCC is currently set to "development 2010.09-2", even though there probably never will be such a release. Basically, if somebody takes a snapshot, I'd like the --version string to be different from the official release.
Agreed. I was showing how the output of the release build would look like.
In the Bazaar repository, I was planning to set the version string to 7.2-2010.10-0-bzr which is similar to what upstream does, except we use -cvs instead of -bzr, and there's a daily date stamp -- but I don't really think we need that for Linaro.
What does gdbserver say?
The same:
GNU gdbserver (Linaro GDB) 7.2-2010.10-0 Copyright (C) 2010 Free Software Foundation, Inc. gdbserver is free software, covered by the GNU General Public License. This gdbserver was configured as "i686-pc-linux-gnu"
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
-- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294
linaro-toolchain@lists.linaro.org
-
Andrew Stubbs -
Matthias Klose -
Michael Hope -
Ulrich Weigand