[oe] [meta-oe][PATCH] gphoto2: fix gettext build error

[Andreas Müller]

On Fri, Nov 30, 2012 at 7:22 PM, Peter Bigot <bigotp at acm.org> wrote:
> On Fri, Nov 30, 2012 at 11:50 AM, Andreas Müller
> <schnitzeltony at googlemail.com> wrote:
>>
>> On Fri, Nov 30, 2012 at 6:45 PM, Andreas Müller
>> <schnitzeltony at googlemail.com> wrote:
>> > On Fri, Nov 30, 2012 at 6:17 PM, Andreas Müller
>> > <schnitzeltony at googlemail.com> wrote:
>> >>> gettext 0.18.1 is installed both on the build machine, and as a native
>> >>> package used when building under bitbake.  If it's at all relevant, I
>> >>> have
>> >>> LANG=en_US.UTF-8 in the environment in which bitbake is executed.
>> >>>
>> >>> Did you try a full reversion of 5febf70?  Can you tell why, in your
>> >>> environment, autotools.bbclass replaces the Makefile.in.in for
>> >>> libgphoto2?
>> >>> It does not do this for me (otherwise I think Koen's patch that only
>> >>> reverts
>> >>> part of 5febf70 would not work).
>> >>>
>> >>> Peter
>> >>>
>> >> It should copy see autotools.bbclass line 195
>> >>
>> >> Andreas
>> > Peter
>> >
>> > One stupid question: Are you working with oe-core master - because
>> >
>> > commit 841ea3c1c18e50e77fccbd5f44d6a79a50913b67
>> > Author: Richard Purdie <richard.purdie at linuxfoundation.org>
>> > Date:   Thu Oct 11 08:43:01 2012 +0000
>> >
>> > which started my gphoto2 trouble is not found in danny
>
>
> Yes, seems to be a danny/master inconsistency, resulting from oe-core
> branching danny six weeks before meta-openembedded did, with my checkouts
> happening between the two points.
>
>> So from what I can see now is that meta-oe's
>>
>> commit 92e3f684d14fd287194e78bc5e65f80504758b7d
>> Author: Koen Kooi <koen at dominion.thruhere.net>
>> Date:   Wed Nov 21 14:42:02 2012 +0000
>>
>>     gphoto2: fix gettext build error
>>
>>     Signed-off-by: Koen Kooi <koen at dominion.thruhere.net>
>>
>> should be merged to danny and reverted (with PRbump) in master.
>
>
> I think 5febf70 should be reverted (with PR bump) in danny, which is where
> I'd started before I noticed 92e3f68 in patchwork.
agreed

> In any case 92e3f68 should be discarded since it leaves the removal of AM_PO_SUBDIRS() from
> configure.ac in place with no motivation once the Makefile.in.in is no
> longer overwritten.
Isn't that exactly what the patch I sent does?
>
> If that seems plausible I'll prepare a patch.
Appreciated - because if would do it would most likely cause further
confusion :)

Andreas