On Fri, Nov 30, 2012 at 7:22 PM, Peter Bigot <[email protected]> wrote: > On Fri, Nov 30, 2012 at 11:50 AM, Andreas Müller > <[email protected]> wrote: >> >> On Fri, Nov 30, 2012 at 6:45 PM, Andreas Müller >> <[email protected]> wrote: >> > On Fri, Nov 30, 2012 at 6:17 PM, Andreas Müller >> > <[email protected]> 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 <[email protected]> >> > 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 <[email protected]> >> Date: Wed Nov 21 14:42:02 2012 +0000 >> >> gphoto2: fix gettext build error >> >> Signed-off-by: Koen Kooi <[email protected]> >> >> 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 _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
