Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Tom Rini <tom_rini@mentor.com>
To: <openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH] automake: Fix issue with tar configure	failing with large UID/GIDs
Date: Tue, 2 Aug 2011 09:04:42 -0700	[thread overview]
Message-ID: <4E38201A.8080006@mentor.com> (raw)
In-Reply-To: <12877E24-5764-42AA-B48C-6F90914DC709@kernel.crashing.org>

On 08/02/2011 09:01 AM, Kumar Gala wrote:
> 
> On Aug 2, 2011, at 10:34 AM, Tom Rini wrote:
> 
>> On 08/02/2011 08:19 AM, Phil Blundell wrote:
>>> On Tue, 2011-08-02 at 03:14 -0500, Kumar Gala wrote:
>>>> +-_am_tools='gnutar m4_if([$1], [ustar], [plaintar]) pax cpio none'
>>>> ++_am_tools='gnutar m4_if([$1], [ustar], [plaintar]) cpio pax none'
>>>
>>> Have you discussed that with upstream?  If not, are you confident that
>>> preferring cpio will not simply mean that we are swapping one deficiency
>>> for another?
>>
>> A bug was filed with upstream automake.  At issue is that pax does not
>> fail gracefully when it cannot create ustar archives while cpio does.
>>
>>>> +Index: automake-1.11.1/Makefile.in
>>>> +===================================================================
>>>> +--- automake-1.11.1.orig/Makefile.in
>>>> ++++ automake-1.11.1/Makefile.in
>>>> +@@ -44,7 +44,7 @@ am__aclocal_m4_deps = $(top_srcdir)/m4/a
>>>> + 	$(top_srcdir)/m4/missing.m4 $(top_srcdir)/m4/mkdirp.m4 \
>>>> + 	$(top_srcdir)/m4/options.m4 $(top_srcdir)/m4/runlog.m4 \
>>>> + 	$(top_srcdir)/m4/sanity.m4 $(top_srcdir)/m4/strip.m4 \
>>>> +-	$(top_srcdir)/m4/substnot.m4 $(top_srcdir)/m4/tar.m4 \
>>>> ++	$(top_srcdir)/m4/substnot.m4 \
>>>> + 	$(top_srcdir)/configure.ac
>>>> + am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
>>>> + 	$(ACLOCAL_M4)
>>>
>>> Can you explain why this hunk is necessary?
>>
>> That I don't recall.  Possibly some sort of re-gen hell I was trying /
>> needing to avoid.
>>
>>>
>>>> +do_configure () {
>>>> +	touch ${S}/Makefile.in
>>>> +	autotools_do_configure
>>>> +}
>>>
>>> ... and this one?
>>
>> Didn't do that one.  Kumar? :)
> 
> I think I pulled that from the SB3 change you made.

Gah, you're right.  I think it was more "avoid re-gen" bits.

-- 
Tom Rini
Mentor Graphics Corporation



  reply	other threads:[~2011-08-02 16:09 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-02  8:14 [PATCH] automake: Fix issue with tar configure failing with large UID/GIDs Kumar Gala
2011-08-02 10:09 ` Richard Purdie
2011-08-02 15:09 ` Khem Raj
2011-08-02 15:19 ` Phil Blundell
2011-08-02 15:34   ` Tom Rini
2011-08-02 15:35     ` Tom Rini
2011-08-02 16:01     ` Kumar Gala
2011-08-02 16:04       ` Tom Rini [this message]
2011-08-02 16:08         ` Kumar Gala

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=4E38201A.8080006@mentor.com \
    --to=tom_rini@mentor.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox