I automatically sync about 12 layers every day. This is a show stopper because it breaks that workflow and forces a deviation from just building on “master”. I am now about two months behind “master” for various reasons, but this is the one remaining blocker. I have zero interest in carrying local patches for this. Just frustrated. I wish I had a suggestion for a better way.
In particular, this points out the frailty of bbclasses not having a mechanism like bbapends. It is invasive to fix this locally. Or I am just being dumb. And frustrated. And should be sleeping now. On Thu, Feb 22, 2018 at 12:48 AM Martin Jansa <martin.ja...@gmail.com> wrote: > +Joe who will merge it to meta-networking > > maybe you meant show stopper as libtalloc failure not the whole OE world > failing to parse because of waf-samba.bbclass (even if you don't build any > recipes using it). > > FWIW: I've also sent simple fix for that to oe-core a while ago: > > http://git.openembedded.org/openembedded-core-contrib/commit/?h=jansa/master&id=71debaa06cb6f0d8996527e6d3bd6634508bd4a5 > that's why it isn't failing for me, but it wasn't merged to oe-core and not > sure if it ever will be. > > Regards, > > > On Thu, Feb 22, 2018 at 9:30 AM, Martin Jansa <martin.ja...@gmail.com> > wrote: > > > I've merged the fix for parsing issues immediately after sending it (6 > > days ago): > > http://git.openembedded.org/meta-openembedded/commit/?id=2f7 > > de931885c1b9e63c4e4238f0f7ad1388e8b6d > > > > So it shouldn't fail to parse for you if you use new enough oe-core (it > > doesn't fail for me). > > > > waf.bbclass is still broken in rocko and master, but that's different > > issue and not as fatal as missing get_waf_parallel_make function. > > > > On Thu, Feb 22, 2018 at 3:48 AM, Tim Orling > <timothy.t.orling@linux.intel. > > com> wrote: > > > >> Still failing for me, which is a show stopper. :( > >> > >> > On Feb 21, 2018, at 5:36 PM, Denys Dmytriyenko <de...@denix.org> > wrote: > >> > > >> > Any updates on this one yet? Thanks. > >> > > >> > On Fri, Feb 16, 2018 at 02:18:32PM -0800, Tim Orling wrote: > >> >> Expediting the fix is greatly appreciated. > >> >> > >> >> Thank you! > >> >> > >> >> --Tim > >> >> > >> >> On Fri, Feb 16, 2018 at 1:00 PM, Joshua Watt <jpewhac...@gmail.com> > >> wrote: > >> >> > >> >>> On Fri, 2018-02-16 at 21:55 +0100, Martin Jansa wrote: > >> >>>> Don't you want to update that one to use the new function from > utils > >> >>>> instead of re-introducing get_waf_parallel_make? > >> >>> > >> >>> .... yes. I guess I can do that now. It didn't exist when I wrote > the > >> >>> first version of this patch > >> >>>> On Fri, Feb 16, 2018 at 9:18 PM, Joshua Watt <jpewhac...@gmail.com > > > >> >>>> wrote: > >> >>>>> On Fri, 2018-02-16 at 21:08 +0100, Martin Jansa wrote: > >> >>>>>> And now it will fail to parse as well: > >> >>>>>> > http://git.openembedded.org/openembedded-core/commit/?id=ccd1142d > >> >>>>>> 22b31ed85d8823b1bc9e11ccfd72b61f > >> >>>>>> > >> >>>>>> removed get_waf_parallel_make from waf.bbclass, so now all waf- > >> >>>>>> samba.bbclass users will fail to parse with: > >> >>>>> > >> >>>>> > http://lists.openembedded.org/pipermail/openembedded-devel/2018-Feb > >> >>>>> ruary/116701.html will fix that as well.... We probably need to > >> >>>>> speed along that getting merged. > >> >>>>> Armin can you help with that? > >> >>>>> > >> >>>>> This patch should resolve all of the waf issues that have been > >> >>>>> discussed here, with exception of the one improvement proposed by > >> >>>>> Denys. While it should probably be improved, I don't beleive it > >> >>>>> actually affects any recipes (some please give me an example if I > >> >>>>> am wrong). > >> >>>>> > >> >>>>> Sorry for the churn. Hopefull this will be better in the future > >> >>>>> since waf and samba-waf are no longer tied together. > >> >>>>> > >> >>>>> Joshua Watt > >> >>>>>> bb.data_smart.ExpansionError: Failure expanding variable > >> >>>>>> do_compile, expression was > >> >>>>>> python ./buildtools/bin/waf ${@get_waf_parallel_make(d)} > >> >>>>>> which triggered exception NameError: name > >> >>>>>> 'get_waf_parallel_make' is not defined > >> >>>>>> On Fri, Feb 16, 2018 at 9:45 AM, Martin Jansa <martin.jansa@gmail > >> >>>>>> .com> wrote: > >> >>>>>>> Check this thread: > >> >>>>>>> http://lists.openembedded.org/pipermail/openembedded-commits/20 > >> >>>>>>> 18-January/218460.html > >> >>>>>>> > >> >>>>>>> but my patch wasn't merged: > >> >>>>>>> http://lists.openembedded.org/pipermail/openembedded-core/2018- > >> >>>>>>> January/146974.html > >> >>>>>>> only the one from Joshua. > >> >>>>>>> > >> >>>>>>> > >> >>>>>>> The original issue is still in rocko as well, the backported > >> >>>>>>> waf change doesn't work and causes useless warning. > >> >>>>>>> > >> >>>>>>> Either the "waf.bbclass: explicitly pass bindir and libdir if > >> >>>>>>> supported" should be reverted in rocko or all fixes for this > >> >>>>>>> should be backported to rocko once they are all in oe-core and > >> >>>>>>> meta-oe master. > >> >>>>>>> > >> >>>>>>> Regards, > >> >>>>>>> > >> >>>>>>> On Fri, Feb 16, 2018 at 2:03 AM, Denys Dmytriyenko <denis@denix > >> >>>>>>> .org> wrote: > >> >>>>>>>> On Thu, Feb 15, 2018 at 06:37:11PM -0600, Joshua Watt wrote: > >> >>>>>>>> > >> >>>>>>>>> On Feb 15, 2018 17:42, "Denys Dmytriyenko" <de...@denix.org > >> >>>>>>>>> wrote: > >> >>>>>>>> > >> >>>>>>>>> > >> >>>>>>>> > >> >>>>>>>>> On Thu, Feb 15, 2018 at 03:30:06PM -0800, Khem Raj wrote: > >> >>>>>>>> > >> >>>>>>>>>> On Thu, Feb 15, 2018 at 3:24 PM, Denys Dmytriyenko <denis > >> >>>>>>>> @denix.org> > >> >>>>>>>> > >> >>>>>>>>> wrote: > >> >>>>>>>> > >> >>>>>>>>>>> On Thu, Feb 15, 2018 at 11:20:49PM +0000, Tim Orling > >> >>>>>>>> wrote: > >> >>>>>>>> > >> >>>>>>>>>>>> Then why did ‘sudo dnf install waf’ get me past the > >> >>>>>>>> error above? And > >> >>>>>>>> > >> >>>>>>>>> why > >> >>>>>>>> > >> >>>>>>>>>>>> does Fedora have a package for it? > >> >>>>>>>> > >> >>>>>>>>>>>> > >> >>>>>>>> > >> >>>>>>>>>>>> https://src.fedoraproject.org/rpms/waf > >> >>>>>>>> > >> >>>>>>>>>>>> > >> >>>>>>>> > >> >>>>>>>>>>>> Regardless, something broke. > >> >>>>>>>> > >> >>>>>>>>>>> > >> >>>>>>>> > >> >>>>>>>>>>> I thought so too. As waf.bbclass from oe-core looks for > >> >>>>>>>> waf binary in > >> >>>>>>>> > >> >>>>>>>>> the root > >> >>>>>>>> > >> >>>>>>>>>>> of the source package, I looked inside libtalloc 2.1.9 > >> >>>>>>>> and 2.1.10 and > >> >>>>>>>> > >> >>>>>>>>> neither > >> >>>>>>>> > >> >>>>>>>>>>> of them have any "waf" files at the root. How was it > >> >>>>>>>> working before? > >> >>>>>>>> > >> >>>>>>>>> What > >> >>>>>>>> > >> >>>>>>>>>>> broke? > >> >>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>> > >> >>>>>>>>>> its using waf-samba.bbclass, there is a patch floating > >> >>>>>>>> for that > >> >>>>>>>> > >> >>>>>>>>>> https://patchwork.openembedded.org/patch/148046/ > >> >>>>>>>> > >> >>>>>>>>> > >> >>>>>>>> > >> >>>>>>>>> So, it will fix libtalloc, but some other packages that > >> >>>>>>>> still use > >> >>>>>>>> > >> >>>>>>>>> waf.bbclass > >> >>>>>>>> > >> >>>>>>>>> will keep on failing with an exception? > >> >>>>>>>> > >> >>>>>>>>> > >> >>>>>>>> > >> >>>>>>>>> > >> >>>>>>>> > >> >>>>>>>>> They shouldn't. I tested all the ones I could find. The way > >> >>>>>>>> waf-samba uses > >> >>>>>>>> > >> >>>>>>>>> waf is more of the exception than the rule.... Most > >> >>>>>>>> projects will follow > >> >>>>>>>> > >> >>>>>>>>> the waf.bbclass pattern of a wscript and waf in $S, but we > >> >>>>>>>> can probably > >> >>>>>>>> > >> >>>>>>>>> parameterize it if necessary. > >> >>>>>>>> > >> >>>>>>>>> > >> >>>>>>>> > >> >>>>>>>>> Do you know of a specific recipe that fails? > >> >>>>>>>> > >> >>>>>>>> > >> >>>>>>>> > >> >>>>>>>> > >> >>>>>>>> No, but as Andre said here earlier, it should be more > >> >>>>>>>> forgiving when ${S}/waf > >> >>>>>>>> > >> >>>>>>>> is not available or at least give a proper error message > >> >>>>>>>> instead of dumping a > >> >>>>>>>> > >> >>>>>>>> cryptic exception stack... > >> >>>>>>>> > >> >>>>>>>> > >> >>>>>>>> > >> >>>>>>>> In other words, before this waf.bbclass change in oe-core it > >> >>>>>>>> was handling such > >> >>>>>>>> > >> >>>>>>>> situation just fine and there was a warning "Unable to > >> >>>>>>>> execute waf --version, > >> >>>>>>>> > >> >>>>>>>> exit code 127". Now it never reaches that code and just > >> >>>>>>>> throws an exception. > >> >>>>>>>> > >> >>>>>>>> > >> >>>>>>>> > >> >>>>>>>> > >> >>>>>>>> > >> >>>>>>>>>>>> On Thu, Feb 15, 2018 at 3:16 PM Joshua Watt <jpewhacke > >> >>>>>>>> r...@gmail.com> > >> >>>>>>>> > >> >>>>>>>>> wrote: > >> >>>>>>>> > >> >>>>>>>>>>>> > >> >>>>>>>> > >> >>>>>>>>>>>>> On Thu, 2018-02-15 at 23:10 +0000, Tim Orling wrote: > >> >>>>>>>> > >> >>>>>>>>>>>>>> Seeing the same and trying to figure it out. Also, > >> >>>>>>>> seems there is > >> >>>>>>>> > >> >>>>>>>>> no > >> >>>>>>>> > >> >>>>>>>>>>>>>> recipe > >> >>>>>>>> > >> >>>>>>>>>>>>>> for waf-native, so it becomes a new required host > >> >>>>>>>> tool. > >> >>>>>>>> > >> >>>>>>>>>>>>> > >> >>>>>>>> > >> >>>>>>>>>>>>> There is no "waf" tool, so a "waf-native" tool > >> >>>>>>>> doesn't make sense... > >> >>>>>>>> > >> >>>>>>>>>>>>> it's not how waf works. Each project has their own > >> >>>>>>>> copy of the waf > >> >>>>>>>> > >> >>>>>>>>>>>>> program, it's not something the host has to provide. > >> >>>>>>>> > >> >>>>>>>>>>>>> > >> >>>>>>>> > >> >>>>>>>>>>>>>> On Thu, Feb 15, 2018 at 2:57 PM Denys Dmytriyenko > >> >>>>>>>> <de...@denix.org> > >> >>>>>>>> > >> >>>>>>>>>>>>>> wrote: > >> >>>>>>>> > >> >>>>>>>>>>>>>> > >> >>>>>>>> > >> >>>>>>>>>>>>>>> Hi, > >> >>>>>>>> > >> >>>>>>>>>>>>>>> > >> >>>>>>>> > >> >>>>>>>>>>>>>>> I'm getting below stack dump building libtalloc > >> >>>>>>>> 2.1.10 in master. > >> >>>>>>>> > >> >>>>>>>>>>>>>>> Works > >> >>>>>>>> > >> >>>>>>>>>>>>>>> fine in > >> >>>>>>>> > >> >>>>>>>>>>>>>>> rocko with libtalloc 2.1.9. I need it for cifs- > >> >>>>>>>> utils. I'm not > >> >>>>>>>> > >> >>>>>>>>>>>>>>> familiar with > >> >>>>>>>> > >> >>>>>>>>>>>>>>> waf, any help? Thanks. > >> >>>>>>>> > >> >>>>>>>>>>>>>>> > >> >>>>>>>> > >> >>>>>>>>>>>>>>> > >> >>>>>>>> > >> >>>>>>>>>>>>>>> ERROR: libtalloc-2.1.10-r0 do_configure: Error > >> >>>>>>>> executing a python > >> >>>>>>>> > >> >>>>>>>>>>>>>>> function > >> >>>>>>>> > >> >>>>>>>>>>>>>>> in exec_python_func() autogenerated: > >> >>>>>>>> > >> >>>>>>>>>>>>>>> > >> >>>>>>>> > >> >>>>>>>>>>>>>>> The stack trace of python calls that resulted in > >> >>>>>>>> this > >> >>>>>>>> > >> >>>>>>>>>>>>>>> exception/failure > >> >>>>>>>> > >> >>>>>>>>>>>>>>> was: > >> >>>>>>>> > >> >>>>>>>>>>>>>>> File: 'exec_python_func() autogenerated', > >> >>>>>>>> lineno: 2, function: > >> >>>>>>>> > >> >>>>>>>>>>>>>>> <module> > >> >>>>>>>> > >> >>>>>>>>>>>>>>> 0001: > >> >>>>>>>> > >> >>>>>>>>>>>>>>> *** 0002:waf_preconfigure(d) > >> >>>>>>>> > >> >>>>>>>>>>>>>>> 0003: > >> >>>>>>>> > >> >>>>>>>>>>>>>>> File: '/OE/master/sources/oe- > >> >>>>>>>> core/meta/classes/waf.bbclass', > >> >>>>>>>> > >> >>>>>>>>>>>>>>> lineno: 34, > >> >>>>>>>> > >> >>>>>>>>>>>>>>> function: waf_preconfigure > >> >>>>>>>> > >> >>>>>>>>>>>>>>> 0030: from distutils.version import > >> >>>>>>>> StrictVersion > >> >>>>>>>> > >> >>>>>>>>>>>>>>> 0031: subsrcdir = d.getVar('S') > >> >>>>>>>> > >> >>>>>>>>>>>>>>> 0032: wafbin = os.path.join(subsrcdir, > >> >>>>>>>> 'waf') > >> >>>>>>>> > >> >>>>>>>>>>>>>>> 0033: try: > >> >>>>>>>> > >> >>>>>>>>>>>>>>> *** 0034: result = > >> >>>>>>>> subprocess.check_output([wafbin, ' > >> >>>>>>>> > >> >>>>>>>>>>>>>>> --version'], > >> >>>>>>>> > >> >>>>>>>>>>>>>>> cwd=subsrcdir, stderr=subprocess.STDOUT) > >> >>>>>>>> > >> >>>>>>>>>>>>>>> 0035: version = result.decode('utf- > >> >>>>>>>> 8').split()[1] > >> >>>>>>>> > >> >>>>>>>>>>>>>>> 0036: if StrictVersion(version) >= > >> >>>>>>>> > >> >>>>>>>>>>>>>>> StrictVersion("1.8.7"): > >> >>>>>>>> > >> >>>>>>>>>>>>>>> 0037: d.setVar("WAF_EXTRA_CONF", > >> >>>>>>>> " > >> >>>>>>>> > >> >>>>>>>>>>>>>>> --bindir=${bindir} > >> >>>>>>>> > >> >>>>>>>>>>>>>>> --libdir=${libdir}") > >> >>>>>>>> > >> >>>>>>>>>>>>>>> 0038: except > >> >>>>>>>> subprocess.CalledProcessError as e: > >> >>>>>>>> > >> >>>>>>>>>>>>>>> File: '/usr/lib/python3.5/subprocess.py', > >> >>>>>>>> lineno: 626, function: > >> >>>>>>>> > >> >>>>>>>>>>>>>>> check_output > >> >>>>>>>> > >> >>>>>>>>>>>>>>> 0622: # empty string. That is > >> >>>>>>>> maintained here for > >> >>>>>>>> > >> >>>>>>>>>>>>>>> backwards > >> >>>>>>>> > >> >>>>>>>>>>>>>>> compatibility. > >> >>>>>>>> > >> >>>>>>>>>>>>>>> 0623: kwargs['input'] = '' if > >> >>>>>>>> > >> >>>>>>>>>>>>>>> kwargs.get('universal_newlines', > >> >>>>>>>> > >> >>>>>>>>>>>>>>> False) else b'' > >> >>>>>>>> > >> >>>>>>>>>>>>>>> 0624: > >> >>>>>>>> > >> >>>>>>>>>>>>>>> 0625: return run(*popenargs, > >> >>>>>>>> stdout=PIPE, > >> >>>>>>>> > >> >>>>>>>>> timeout=timeout, > >> >>>>>>>> > >> >>>>>>>>>>>>>>> check=True, > >> >>>>>>>> > >> >>>>>>>>>>>>>>> *** 0626: **kwargs).stdout > >> >>>>>>>> > >> >>>>>>>>>>>>>>> 0627: > >> >>>>>>>> > >> >>>>>>>>>>>>>>> 0628: > >> >>>>>>>> > >> >>>>>>>>>>>>>>> 0629:class CompletedProcess(object): > >> >>>>>>>> > >> >>>>>>>>>>>>>>> 0630: """A process that has finished > >> >>>>>>>> running. > >> >>>>>>>> > >> >>>>>>>>>>>>>>> File: '/usr/lib/python3.5/subprocess.py', > >> >>>>>>>> lineno: 693, function: > >> >>>>>>>> > >> >>>>>>>>>>>>>>> run > >> >>>>>>>> > >> >>>>>>>>>>>>>>> 0689: if 'stdin' in kwargs: > >> >>>>>>>> > >> >>>>>>>>>>>>>>> 0690: raise ValueError('stdin > >> >>>>>>>> and input arguments > >> >>>>>>>> > >> >>>>>>>>>>>>>>> may not > >> >>>>>>>> > >> >>>>>>>>>>>>>>> both be used.') > >> >>>>>>>> > >> >>>>>>>>>>>>>>> 0691: kwargs['stdin'] = PIPE > >> >>>>>>>> > >> >>>>>>>>>>>>>>> 0692: > >> >>>>>>>> > >> >>>>>>>>>>>>>>> *** 0693: with Popen(*popenargs, **kwargs) > >> >>>>>>>> as process: > >> >>>>>>>> > >> >>>>>>>>>>>>>>> 0694: try: > >> >>>>>>>> > >> >>>>>>>>>>>>>>> 0695: stdout, stderr = > >> >>>>>>>> process.communicate(input, > >> >>>>>>>> > >> >>>>>>>>>>>>>>> timeout=timeout) > >> >>>>>>>> > >> >>>>>>>>>>>>>>> 0696: except TimeoutExpired: > >> >>>>>>>> > >> >>>>>>>>>>>>>>> 0697: process.kill() > >> >>>>>>>> > >> >>>>>>>>>>>>>>> File: '/usr/lib/python3.5/subprocess.py', > >> >>>>>>>> lineno: 947, function: > >> >>>>>>>> > >> >>>>>>>>>>>>>>> __init__ > >> >>>>>>>> > >> >>>>>>>>>>>>>>> 0943: > >> >>>>>>>> startupinfo, > >> >>>>>>>> > >> >>>>>>>>>>>>>>> creationflags, > >> >>>>>>>> > >> >>>>>>>>>>>>>>> shell, > >> >>>>>>>> > >> >>>>>>>>>>>>>>> 0944: > >> >>>>>>>> p2cread, p2cwrite, > >> >>>>>>>> > >> >>>>>>>>>>>>>>> 0945: > >> >>>>>>>> c2pread, c2pwrite, > >> >>>>>>>> > >> >>>>>>>>>>>>>>> 0946: > >> >>>>>>>> errread, errwrite, > >> >>>>>>>> > >> >>>>>>>>>>>>>>> *** 0947: > >> >>>>>>>> restore_signals, > >> >>>>>>>> > >> >>>>>>>>>>>>>>> start_new_session) > >> >>>>>>>> > >> >>>>>>>>>>>>>>> 0948: except: > >> >>>>>>>> > >> >>>>>>>>>>>>>>> 0949: # Cleanup if the child > >> >>>>>>>> failed starting. > >> >>>>>>>> > >> >>>>>>>>>>>>>>> 0950: for f in filter(None, > >> >>>>>>>> (self.stdin, > >> >>>>>>>> > >> >>>>>>>>>>>>>>> self.stdout, > >> >>>>>>>> > >> >>>>>>>>>>>>>>> self.stderr)): > >> >>>>>>>> > >> >>>>>>>>>>>>>>> 0951: try: > >> >>>>>>>> > >> >>>>>>>>>>>>>>> File: '/usr/lib/python3.5/subprocess.py', > >> >>>>>>>> lineno: 1551, function: > >> >>>>>>>> > >> >>>>>>>>>>>>>>> _execute_child > >> >>>>>>>> > >> >>>>>>>>>>>>>>> 1547: # The > >> >>>>>>>> error must be > >> >>>>>>>> > >> >>>>>>>>> from > >> >>>>>>>> > >> >>>>>>>>>>>>>>> chdir(cwd). > >> >>>>>>>> > >> >>>>>>>>>>>>>>> 1548: > >> >>>>>>>> err_msg += ': ' + > >> >>>>>>>> > >> >>>>>>>>>>>>>>> repr(cwd) > >> >>>>>>>> > >> >>>>>>>>>>>>>>> 1549: else: > >> >>>>>>>> > >> >>>>>>>>>>>>>>> 1550: > >> >>>>>>>> err_msg += ': ' + > >> >>>>>>>> > >> >>>>>>>>>>>>>>> repr(orig_executable) > >> >>>>>>>> > >> >>>>>>>>>>>>>>> *** 1551: raise > >> >>>>>>>> child_exception_type(errno_ > >> >>>>>>>> > >> >>>>>>>>> num, > >> >>>>>>>> > >> >>>>>>>>>>>>>>> err_msg) > >> >>>>>>>> > >> >>>>>>>>>>>>>>> 1552: raise > >> >>>>>>>> child_exception_type(err_msg) > >> >>>>>>>> > >> >>>>>>>>>>>>>>> 1553: > >> >>>>>>>> > >> >>>>>>>>>>>>>>> 1554: > >> >>>>>>>> > >> >>>>>>>>>>>>>>> 1555: def _handle_exitstatus(self, > >> >>>>>>>> sts, > >> >>>>>>>> > >> >>>>>>>>>>>>>>> _WIFSIGNALED=os.WIFSIGNALED, > >> >>>>>>>> > >> >>>>>>>>>>>>>>> Exception: FileNotFoundError: [Errno 2] No such > >> >>>>>>>> file or > >> >>>>>>>> > >> >>>>>>>>> directory: > >> >>>>>>>> > >> >>>>>>>>>>>>>>> '/OE/master/build/tmp-glibc/work/armv7ahf-neon- > >> >>>>>>>> oe-linux- > >> >>>>>>>> > >> >>>>>>>>>>>>>>> gnueabi/libtalloc/2.1.10-r0/talloc-2.1.10/waf' > >> >>>>>>>> > >> >>>>>>>>>>>>>>> > >> >>>>>>>> > >> >>>>>>>>>>>>>>> ERROR: libtalloc-2.1.10-r0 do_configure: > >> >>>>>>>> Function failed: > >> >>>>>>>> > >> >>>>>>>>>>>>>>> waf_preconfigure > >> >>>>>>>> > >> >>>>>>>>>>>>>>> ERROR: Logfile of failure stored in: > >> >>>>>>>> > >> >>>>>>>>>>>>>>> /OE/master/build/tmp-glibc/work/armv7ahf-neon- > >> >>>>>>>> oe-linux- > >> >>>>>>>> > >> >>>>>>>>>>>>>>> gnueabi/libtalloc/2.1.10- > >> >>>>>>>> r0/temp/log.do_configure.52699 > >> >>>>>>>> > >> >>>>>>>>>>>>>>> ERROR: Task > >> >>>>>>>> > >> >>>>>>>>>>>>>>> (/OE/master/sources/meta-openembedded/meta- > >> >>>>>>>> networking/recipes- > >> >>>>>>>> > >> >>>>>>>>>>>>>>> > >> >>>>>>>> support/libtalloc/libtalloc_2.1.10.bb:do_configure) > >> >>>>>>>> > >> >>>>>>>>>>>>>>> failed with exit code '1' > >> >>>>>>>> > >> >>>>>>>>>>>>>>> -- > >> >>>>>>>> > >> >>>>>>>>>>>>>>> _______________________________________________ > >> >>>>>>>> > >> >>>>>>>>>>>>>>> Openembedded-devel mailing list > >> >>>>>>>> > >> >>>>>>>>>>>>>>> Openembedded-devel@lists.openembedded.org > >> >>>>>>>> > >> >>>>>>>>>>>>>>> http://lists.openembedded.org/mailman/listinfo/o > >> >>>>>>>> penembedded-devel > >> >>>>>>>> > >> >>>>>>>>>>>>>>> > >> >>>>>>>> > >> >>>>>>>>>>>>> > >> >>>>>>>> > >> >>>>>>>>>>> -- > >> >>>>>>>> > >> >>>>>>>>>>> _______________________________________________ > >> >>>>>>>> > >> >>>>>>>>>>> Openembedded-devel mailing list > >> >>>>>>>> > >> >>>>>>>>>>> Openembedded-devel@lists.openembedded.org > >> >>>>>>>> > >> >>>>>>>>>>> http://lists.openembedded.org/mailman/listinfo/openembe > >> >>>>>>>> dded-devel > >> >>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>> > >> >>>>>>>>> -- > >> >>>>>>>> > >> >>>>>>>>> _______________________________________________ > >> >>>>>>>> > >> >>>>>>>>> Openembedded-devel mailing list > >> >>>>>>>> > >> >>>>>>>>> Openembedded-devel@lists.openembedded.org > >> >>>>>>>> > >> >>>>>>>>> http://lists.openembedded.org/mailman/listinfo/openembedded > >> >>>>>>>> -devel > >> >>>>>>>> > >> >>>>>>>> -- > >> >>>>>>>> > >> >>>>>>>> _______________________________________________ > >> >>>>>>>> > >> >>>>>>>> Openembedded-devel mailing list > >> >>>>>>>> > >> >>>>>>>> Openembedded-devel@lists.openembedded.org > >> >>>>>>>> > >> >>>>>>>> http://lists.openembedded.org/mailman/listinfo/openembedded-d > >> >>>>>>>> evel > >> >>>>>>>> > >> >>> -- > >> >>> _______________________________________________ > >> >>> Openembedded-devel mailing list > >> >>> Openembedded-devel@lists.openembedded.org > >> >>> http://lists.openembedded.org/mailman/listinfo/openembedded-devel > >> >>> > >> >> -- > >> >> _______________________________________________ > >> >> Openembedded-devel mailing list > >> >> Openembedded-devel@lists.openembedded.org > >> >> http://lists.openembedded.org/mailman/listinfo/openembedded-devel > >> > -- > >> > _______________________________________________ > >> > Openembedded-devel mailing list > >> > Openembedded-devel@lists.openembedded.org > >> > http://lists.openembedded.org/mailman/listinfo/openembedded-devel > >> > >> -- > >> _______________________________________________ > >> Openembedded-devel mailing list > >> Openembedded-devel@lists.openembedded.org > >> http://lists.openembedded.org/mailman/listinfo/openembedded-devel > >> > > > > > -- > _______________________________________________ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-devel > -- _______________________________________________ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
