All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Martin Jansa <martin.jansa@gmail.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [RFC][PATCHv2] cmake.bbclass, perf: don't re-create ${B}
Date: Tue, 22 Sep 2015 09:10:34 +0100	[thread overview]
Message-ID: <1442909434.12435.242.camel@linuxfoundation.org> (raw)
In-Reply-To: <1442867607-8913-1-git-send-email-Martin.Jansa@gmail.com>

On Mon, 2015-09-21 at 22:33 +0200, Martin Jansa wrote:
> * otherwise there is race-condition between do_configure rm+mkdir and
>   bitbake trying to use it as CWD for do_populate_lic task, which
>   results in errors like this:
> 
> NOTE: recipe perf-1.0-r9: task do_configure: Started
> NOTE: recipe perf-1.0-r9: task do_populate_lic: Started
> ERROR: Build of do_populate_lic failed
> ERROR: Traceback (most recent call last):
>   File "/OE/build/oe-core/bitbake/lib/bb/build.py", line 553, in exec_task
>     return _exec_task(fn, task, d, quieterr)
>   File "/OE/build/oe-core/bitbake/lib/bb/build.py", line 493, in _exec_task
>     exec_func(func, localdata)
>   File "/OE/build/oe-core/bitbake/lib/bb/build.py", line 227, in exec_func
>     exec_func_python(func, d, runfile, cwd=adir)
>   File "/OE/build/oe-core/bitbake/lib/bb/build.py", line 252, in exec_func_python
>     os.chdir(cwd)
> OSError: [Errno 2] No such file or directory: '/OE/build/oe-core/tmp-glibc/work/qemux86-oe-linux/perf/1.0-r9/perf-1.0'
> NOTE: recipe perf-1.0-r9: task do_populate_lic: Failed
> ERROR: Task 7 (/OE/build/oe-core/openembedded-core/meta/recipes-kernel/perf/perf.bb, do_populate_lic) failed with exit code '1'
> NOTE: recipe perf-1.0-r9: task do_configure: Succeeded
> 
> or even longer exception:
> 
> NOTE: recipe perf-1.0-r9: task do_populate_lic: Started
> NOTE: recipe perf-1.0-r9: task do_configure: Started
> ERROR: Error executing a python function in /OE/build/oe-core/openembedded-core/meta/recipes-kernel/perf/perf.bb:
> 
> The stack trace of python calls that resulted in this exception/failure was:
> File: 'sstate_task_postfunc', lineno: 14, function: <module>
>      0010:    sstate_package(shared_state, d)
>      0011:    os.umask(omask)
>      0012:
>      0013:
>  *** 0014:sstate_task_postfunc(d)
>      0015:
> File: 'sstate_task_postfunc', lineno: 4, function: sstate_task_postfunc
>      0001:
>      0002:def sstate_task_postfunc(d):
>      0003:    shared_state = sstate_state_fromvars(d)
>  *** 0004:    sstate_install(shared_state, d)
>      0005:    for intercept in shared_state['interceptfuncs']:
>      0006:        bb.build.exec_func(intercept, d)
>      0007:    omask = os.umask(002)
>      0008:    if omask != 002:
> File: 'sstate.bbclass', lineno: 113, function: sstate_install
>      0109:        if os.path.exists(state[1]):
>      0110:            oe.path.copyhardlinktree(state[1], state[2])
>      0111:
>      0112:    for postinst in (d.getVar('SSTATEPOSTINSTFUNCS', True) or '').split():
>  *** 0113:        bb.build.exec_func(postinst, d)
>      0114:
>      0115:    for lock in locks:
>      0116:        bb.utils.unlockfile(lock)
>      0117:

The longer stack trace is actually really helpful. I believe the code
here should inherit the working directory of the current task rather
than rely on the default of ${B} which bitbake assigns if there is
nothing else.

The trouble is that if the function does specify a dirs flag, it should
really use that instead of a supplied parameter and if we use the
parameter to exec_func(), it won't do that.

There aren't that many uses of SSTATEPOSTINSTFUNCS in our metadata so
the easiest way to fix this short term is probably to go through them
and add specific [dirs] options to the functions.

Cheers,

Richard



  parent reply	other threads:[~2015-09-22  8:10 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-02 16:00 Robert Yang : perf: fix for rebuilding Martin Jansa
2015-09-10 16:05 ` Martin Jansa
2015-09-15  5:29   ` [PATCH][master][fido][dizzy] Revert "perf: fix for rebuilding" Martin Jansa
2015-09-15  5:53     ` Robert Yang
2015-09-16  7:48       ` Robert Yang
2015-09-16  8:57         ` Burton, Ross
2015-09-16  9:07           ` Robert Yang
2015-09-21 19:04         ` Martin Jansa
2015-09-21 19:36           ` [RFC][PATCH] perf: don't re-create ${B} Martin Jansa
2015-09-21 20:33           ` [RFC][PATCHv2] cmake.bbclass, " Martin Jansa
2015-09-21 20:55             ` Burton, Ross
2015-09-22  5:44               ` Martin Jansa
2015-09-22  8:10             ` Richard Purdie [this message]
2015-09-22  9:36               ` Burton, Ross
2015-09-22  5:48           ` [RFC][PATCHv3] autotools.bbclass, " Martin Jansa

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=1442909434.12435.242.camel@linuxfoundation.org \
    --to=richard.purdie@linuxfoundation.org \
    --cc=martin.jansa@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.