From: ChenQi <Qi.Chen@windriver.com>
To: "Aníbal Limón" <anibal.limon@linux.intel.com>,
"Paul Eggleton" <paul.eggleton@linux.intel.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH 1/5] rootfs.py: two changes regarding log checking
Date: Thu, 19 Mar 2015 10:16:02 +0800 [thread overview]
Message-ID: <550A3162.6050701@windriver.com> (raw)
In-Reply-To: <55099DF2.70809@linux.intel.com>
On 03/18/2015 11:46 PM, Aníbal Limón wrote:
> Hi Paul, Chen,
>
> Days ago i sent a patchset for handle INCOMPATIBLE_LICENSE in manifest
> creation [1] that contains
> a rewrite of license_manifest_creation from shell to python, i mean
> now these warnings appears.
>
> Also i sent a similar patches like Chen's ones to avoid warnings
> [2][3], You said (Paul) that packagegroups
> should not have files, how we can address these case to avoid license
> warnings in packagegroups?
>
Hi Alimon,
Paul suggested to skip checking if the package contains no file, because
in such case the license is not relevant as long as the final image is
concerned.
I will send out a new patchset using the above approach.
Best Regards,
Chen Qi
> Cheers,
> alimon
>
> [1]
> http://lists.openembedded.org/pipermail/openembedded-core/2015-March/102684.html
> [2]
> http://lists.openembedded.org/pipermail/openembedded-core/2015-March/102683.html
> [3]
> http://lists.openembedded.org/pipermail/openembedded-core/2015-March/102682.html
>
> On 18/03/15 03:48, Paul Eggleton wrote:
>> On Wednesday 18 March 2015 17:16:10 Chen Qi wrote:
>>> 1. Extend the regular expression to also catch '^WRARNING:' in
>>> _log_check_warn. Warnings from bb.note or bbnote begin with
>>> 'WARNING:'. So
>>> if we decide to catch warnings at rootfs time, we should not ignore
>>> those
>>> produced by the build system itself.
>> FYI, I still have an unfinished patchset to ensure bbwarn calls from
>> shell
>> functions get piped through to BitBake's event system, with the
>> result that
>> such warnings actually get logged and displayed by the BitBake UI. (That
>> doesn't mean this patch shouldn't go in in the mean time, though.)
>>
>> Cheers,
>> Paul
>>
>
>
>
next prev parent reply other threads:[~2015-03-19 2:16 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-18 9:16 [PATCH 0/5] Changes regarding log checking and license checksums Chen Qi
2015-03-18 9:16 ` [PATCH 1/5] rootfs.py: two changes regarding log checking Chen Qi
2015-03-18 9:48 ` Paul Eggleton
2015-03-18 15:46 ` Aníbal Limón
2015-03-19 2:16 ` ChenQi [this message]
2015-03-18 12:03 ` Martin Jansa
2015-03-18 9:16 ` [PATCH 2/5] rootfs.py: add log checking ability for deb and ipk Chen Qi
2015-03-18 9:16 ` [PATCH 3/5] packagegroup: add LIC_FILES_CHKSUM Chen Qi
2015-03-18 9:37 ` Paul Eggleton
2015-03-18 9:16 ` [PATCH 4/5] os-release: " Chen Qi
2015-03-18 9:16 ` [PATCH 5/5] glibc-collateral.inc: " Chen Qi
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=550A3162.6050701@windriver.com \
--to=qi.chen@windriver.com \
--cc=anibal.limon@linux.intel.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=paul.eggleton@linux.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.