From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH 1/7] binutils: upgrade from 2.21 to 2.21.1
Date: Fri, 08 Jul 2011 16:24:50 +0100 [thread overview]
Message-ID: <1310138690.20015.878.camel@rex> (raw)
In-Reply-To: <A64F9A3E-6359-4C99-B332-378FFE4F644C@gmail.com>
On Thu, 2011-07-07 at 17:42 -0700, Khem Raj wrote:
>
> On Jul 7, 2011, at 4:12 PM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote:
>
> > On Thu, 2011-07-07 at 14:39 -0700, Khem Raj wrote:
> >> On Thu, Jul 7, 2011 at 1:25 PM, <nitin.a.kamble@intel.com> wrote:
> >>> From: Nitin A Kamble <nitin.a.kamble@intel.com>
> >>>
> >>> Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
> >>> ---
> >>> ...n_2.21.bb => binutils-cross-canadian_2.21.1.bb} | 0
> >>> ...tils-cross_2.21.bb => binutils-cross_2.21.1.bb} | 0
> >>> ...rosssdk_2.21.bb => binutils-crosssdk_2.21.1.bb} | 0
> >>> .../110-arm-eabi-conf.patch | 0
> >>> .../binutils-2.19.1-ld-sysroot.patch | 0
> >>> .../binutils-poison.patch | 0
> >>> .../binutils-pr12366.patch | 0
> >>> .../binutils-uclibc-100-uclibc-conf.patch | 0
> >>> ...binutils-uclibc-300-001_ld_makefile_patch.patch | 0
> >>> ...binutils-uclibc-300-006_better_file_error.patch | 0
> >>> ...ils-uclibc-300-012_check_ldrunpath_length.patch | 0
> >>> .../binutils-uclibc-gas-needs-libm.patch | 0
> >>> .../binutils-x86_64_i386_biarch.patch | 0
> >>> .../libiberty_path_fix.patch | 0
> >>> .../libtool-2.4-update.patch | 1725 ++++++++++----------
> >>> .../libtool-rpath-fix.patch | 0
> >>> .../{binutils_2.21.bb => binutils_2.21.1.bb} | 7 +-
> >>> 17 files changed, 871 insertions(+), 861 deletions(-)
> >>> rename meta/recipes-devtools/binutils/{binutils-cross-canadian_2.21.bb => binutils-cross-canadian_2.21.1.bb} (100%)
> >>> rename meta/recipes-devtools/binutils/{binutils-cross_2.21.bb => binutils-cross_2.21.1.bb} (100%)
> >>> rename meta/recipes-devtools/binutils/{binutils-crosssdk_2.21.bb => binutils-crosssdk_2.21.1.bb} (100%)
> >>> rename meta/recipes-devtools/binutils/{binutils-2.21 => binutils}/110-arm-eabi-conf.patch (100%)
> >>> rename meta/recipes-devtools/binutils/{binutils-2.21 => binutils}/binutils-2.19.1-ld-sysroot.patch (100%)
> >>> rename meta/recipes-devtools/binutils/{binutils-2.21 => binutils}/binutils-poison.patch (100%)
> >>> rename meta/recipes-devtools/binutils/{binutils-2.21 => binutils}/binutils-pr12366.patch (100%)
> >>> rename meta/recipes-devtools/binutils/{binutils-2.21 => binutils}/binutils-uclibc-100-uclibc-conf.patch (100%)
> >>> rename meta/recipes-devtools/binutils/{binutils-2.21 => binutils}/binutils-uclibc-300-001_ld_makefile_patch.patch (100%)
> >>> rename meta/recipes-devtools/binutils/{binutils-2.21 => binutils}/binutils-uclibc-300-006_better_file_error.patch (100%)
> >>> rename meta/recipes-devtools/binutils/{binutils-2.21 => binutils}/binutils-uclibc-300-012_check_ldrunpath_length.patch (100%)
> >>> rename meta/recipes-devtools/binutils/{binutils-2.21 => binutils}/binutils-uclibc-gas-needs-libm.patch (100%)
> >>> rename meta/recipes-devtools/binutils/{binutils-2.21 => binutils}/binutils-x86_64_i386_biarch.patch (100%)
> >>> rename meta/recipes-devtools/binutils/{binutils-2.21 => binutils}/libiberty_path_fix.patch (100%)
> >>> rename meta/recipes-devtools/binutils/{binutils-2.21 => binutils}/libtool-2.4-update.patch (94%)
> >>> rename meta/recipes-devtools/binutils/{binutils-2.21 => binutils}/libtool-rpath-fix.patch (100%)
> >>> rename meta/recipes-devtools/binutils/{binutils_2.21.bb => binutils_2.21.1.bb} (87%)
> >>>
> >>
> >> How about changing the recipe to fetch from binutils-2_21-branch and
> >> call it binutils 2.21 as it is
> >
> > I don't really see the benefits in fetching this from the SCM?
>
> Not much yes however
>
> Releases happen not so frequently but bug fixes go into the branch and
> it makes it easier to upgrade may be same as adding patches to
> metadata but we don't need to keep them local in metadata
>
> It will match the process we do for other toolchain components
I have a dislike for depending on what are usually slow SCMs for
components of the system. I've been convinced we need to do it for gcc
but I think that is the exception to the rule and we don't have a
seriously large number of patches queued against binutils...
I've therefore taken the patch.
Cheers,
Richard
next prev parent reply other threads:[~2011-07-08 16:18 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-07 20:25 [PATCH 0/7] upgrades & misc fixes nitin.a.kamble
2011-07-07 20:25 ` [PATCH 1/7] binutils: upgrade from 2.21 to 2.21.1 nitin.a.kamble
2011-07-07 21:39 ` Khem Raj
2011-07-07 23:12 ` Richard Purdie
2011-07-08 0:42 ` Khem Raj
2011-07-08 15:24 ` Richard Purdie [this message]
2011-07-08 8:00 ` Phil Blundell
2011-07-07 20:25 ` [PATCH 2/7] gmp: upgrade from 5.0.1 to 5.0.2 nitin.a.kamble
2011-07-07 20:25 ` [PATCH 3/7] distro tracking: update devel.toolchain recipes's fields nitin.a.kamble
2011-07-07 20:25 ` [PATCH 4/7] binutils: package unpackaged files nitin.a.kamble
2011-07-07 21:32 ` Khem Raj
2011-07-08 15:26 ` Richard Purdie
2011-07-08 15:34 ` Phil Blundell
2011-07-08 21:15 ` Kamble, Nitin A
2011-07-08 21:29 ` Phil Blundell
2011-07-08 17:10 ` Kamble, Nitin A
2011-07-07 20:25 ` [PATCH 5/7] eglibc: fix installed but not packaged files nitin.a.kamble
2011-07-07 20:42 ` Phil Blundell
2011-07-07 21:41 ` Khem Raj
2011-07-07 23:11 ` Richard Purdie
2011-07-08 17:04 ` Kamble, Nitin A
2011-07-07 20:25 ` [PATCH 6/7] gcc-runtime: fix installed but unpackaged files nitin.a.kamble
2011-07-07 20:25 ` [PATCH 7/7] elfutils: fix compilations issue with the gcc 4.7 nitin.a.kamble
2011-07-08 15:23 ` [PATCH 0/7] upgrades & misc fixes Richard Purdie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1310138690.20015.878.camel@rex \
--to=richard.purdie@linuxfoundation.org \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.