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
next prev parent 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