From: Robert Yang <liezhi.yang@windriver.com>
To: Richard Purdie <richard.purdie@linuxfoundation.org>,
Nicolas Dechesne <nicolas.dechesne@linaro.org>,
"Burton, Ross" <ross.burton@intel.com>
Cc: bitbake-devel <bitbake-devel@lists.openembedded.org>
Subject: Re: [PATCH 2/2] bitbake: build.py: check dependendent task for addtask
Date: Sun, 5 May 2019 18:30:46 +0800 [thread overview]
Message-ID: <90381831-a25e-921f-40eb-1fe96c633a78@windriver.com> (raw)
In-Reply-To: <0c43bc44-1cf4-af21-e4e4-ed7ef2cf0365@windriver.com>
Hi RP,
After more investigations, these warnings are caused by recrdeptask,
the rm_work calls:
addtask after 'deps + recrdeptask' before do_build
Then we will get the warnings, and we can divide these warnings into 3 kinds:
1) deltask only removes task from 'deps', but doesn't remove it from
'recrdeptask', so there are warnings for native recipes like dependent
task do_package_write_rpm, although native.bbclass has called
"deltask do_package_write_rpm', such a recrdeptask doesn't make any sense
for native recipes. But we can't make deltask remove recrdeptask since we may
need keep recrdeptask sometimes, for example, the image recipes don't need
do_package_write_rpm, but their do_rootfs tasks require all the dependent
rpms are done. I think that we need a command such as delrecrdeptask to fix
it, but I'm not sure whether it is worth or not.
2) base.bbclass has set 'do_build[recrdeptask] += "do_deploy"', but do_deploy
doesn't exist for most of the recipes, so we get the warnings of not
do_deploy task, I don't know why do_deploy should be a recrdeptask, and
maybe we need set it in rootfs_xxx.bbclass or image.bbclass, or set it
conditionally in a func.
3) gcc-source doesn't have do_populate_sysroot or do_populate_lic, but
do_build_without_rm_work always depends on them:
bb.build.addtask('do_build_without_rm_work', '', ' '.join(deps), d)
so we get warnings that gcc-source has no dependent task do_populate_sysroot
or do_populate_lic. I think that we can make do_build_without_rm_work
depend on them conditionally to fix the problem.
Any comments are appreciated.
// Robert
On 5/5/19 1:56 PM, Robert Yang wrote:
>
>
> On 5/2/19 3:42 AM, Richard Purdie wrote:
>> On Wed, 2019-05-01 at 18:48 +0200, Nicolas Dechesne wrote:
>>> On Wed, May 1, 2019 at 5:30 PM Burton, Ross <ross.burton@intel.com>
>>> wrote:
>>>> On Wed, 1 May 2019 at 11:51, Jacob Kroon <jacob.kroon@gmail.com>
>>>> wrote:
>>>>> I'm getting a lot of these warnings after removing tmp/ and
>>>>> rebuilding
>>>>> my image from sstate cache.
>>>>> FWIW I use rm_work.bbclass, and regularly use the
>>>>> sstate-cache-management,sh script to prune old cache.
>>>>
>>>> There's a patch I hacked up in master-next that shows where these
>>>> warnings are coming from. Yes, this patch produces two warnings
>>>> per
>>>> recipe with rm_work enabled.
>>>
>>> argh... i hit the same issue and came up with the exact same
>>> conclusion.. i should have checked the mailing list earlier today ;)
>>>
>>> I am getting thousands of warnings like that with rm_work. I had
>>> modified bitbake so that it shows the 'task' name like Ross, in ().
>>
>> I suspect we're going to need to rethink that patch, and/or perhaps
>> rm_work...
>
>
> Sorry for the warnings, I just came back from the International Labour Day
> Holiday. Something is wrong with rm_work, I will send a patch to fix it.
>
>>
>> I did have concerns about it but was assured it was widely tested. We
>> also probably need an rm_work test case on the autobuilder (need a bug
>> for that so we don't forget?).
>
> Rather than add a testcae on autobuilder, how about add a testcase to
> oe-selftest, please ?
>
> // Robert
>
>>
>> Cheers,
>>
>> Richard
>>
>>
>>
prev parent reply other threads:[~2019-05-05 10:31 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-25 10:00 [PATCH 0/2] Fixes for addtask and deltask Robert Yang
2019-04-25 10:00 ` [PATCH 1/2] bitbake: BBHandler: Fix " Robert Yang
2019-04-25 10:48 ` Richard Purdie
2019-04-26 3:17 ` Robert Yang
2019-04-25 10:01 ` [PATCH 2/2] bitbake: build.py: check dependendent task for addtask Robert Yang
2019-04-25 10:50 ` Richard Purdie
2019-04-26 2:49 ` Robert Yang
2019-04-30 12:13 ` Martin Jansa
2019-05-01 10:50 ` Jacob Kroon
2019-05-01 15:30 ` Burton, Ross
2019-05-01 16:48 ` Nicolas Dechesne
2019-05-01 19:42 ` Richard Purdie
2019-05-05 5:56 ` Robert Yang
2019-05-05 10:30 ` Robert Yang [this message]
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=90381831-a25e-921f-40eb-1fe96c633a78@windriver.com \
--to=liezhi.yang@windriver.com \
--cc=bitbake-devel@lists.openembedded.org \
--cc=nicolas.dechesne@linaro.org \
--cc=richard.purdie@linuxfoundation.org \
--cc=ross.burton@intel.com \
/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.