All of lore.kernel.org
 help / color / mirror / Atom feed
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
>>
>>
>>


      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.