* Re: [PATCH] base.bbclass: squash whitespace when printing BUILDCFG_VARS
From: Andre McCurdy @ 2016-11-29 0:32 UTC (permalink / raw)
To: Christopher Larson; +Cc: Patches and discussions about the oe-core layer
In-Reply-To: <CABcZAN=QjzMYd9my-xyOA-=12Mpv6bOvAS2a8shBSxyZFqZ5cQ@mail.gmail.com>
On Mon, Nov 28, 2016 at 3:53 PM, Christopher Larson <clarson@kergoth.com> wrote:
>
> On Mon, Nov 28, 2016 at 3:23 PM, Andre McCurdy <armccurdy@gmail.com> wrote:
>>
>> TUNE_FEATURES for ARM targets typically contains a lot of whitespace
>> due to refactoring in OE 2.1:
>>
>> http://git.openembedded.org/openembedded-core/commit/?id=f774b44fa007a2a756ada892ede832b1251d940c
>>
>> Squash whitespace when displaying BUILDCFG_VARS in buildcfg_vars().
>>
>> Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
>> ---
>> meta/classes/base.bbclass | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
>> index 024fe43..c36c5ed 100644
>> --- a/meta/classes/base.bbclass
>> +++ b/meta/classes/base.bbclass
>> @@ -191,7 +191,7 @@ def buildcfg_vars(d):
>> for var in statusvars:
>> value = d.getVar(var, True)
>> if value is not None:
>> - yield '%-17s = "%s"' % (var, value)
>> + yield '%-17s = "%s"' % (var, " ".join(value.split()))
>>
>> def buildcfg_neededvars(d):
>> needed_vars = oe.data.typed_value("BUILDCFG_NEEDEDVARS", d)
>
> This will result in inaccurate values displayed for non-list variables.
I didn't notice any changes in the other fields. Do you have an
example of a value which wouldn't display correctly?
> --
> Christopher Larson
> clarson at kergoth dot com
> Founder - BitBake, OpenEmbedded, OpenZaurus
> Maintainer - Tslib
> Senior Software Engineer, Mentor Graphics
^ permalink raw reply
* Re: [PATCH] base.bbclass: squash whitespace when printing BUILDCFG_VARS
From: Richard Purdie @ 2016-11-29 0:30 UTC (permalink / raw)
To: Christopher Larson, Andre McCurdy
Cc: Patches and discussions about the oe-core layer
In-Reply-To: <CABcZAN=QjzMYd9my-xyOA-=12Mpv6bOvAS2a8shBSxyZFqZ5cQ@mail.gmail.com>
On Mon, 2016-11-28 at 16:53 -0700, Christopher Larson wrote:
>
> On Mon, Nov 28, 2016 at 3:23 PM, Andre McCurdy <armccurdy@gmail.com>
> wrote:
> > TUNE_FEATURES for ARM targets typically contains a lot of
> > whitespace
> > due to refactoring in OE 2.1:
> >
> > http://git.openembedded.org/openembedded-core/commit/?id=f774b44f
> > a007a2a756ada892ede832b1251d940c
I'm wondering if we should take back some of the whitespace changes
that commit made...
Cheers,
Richard
^ permalink raw reply
* [PATCH 0/1] multilib.bbclass: update DEFAULTTUNE for image recipe
From: Robert Yang @ 2016-11-29 1:30 UTC (permalink / raw)
To: openembedded-core
The following changes since commit af280990bff4a484fd8a18e3442b56a0a39b7611:
Revert "classes/populate_sdk_ext: require uninative" (2016-11-28 14:49:37 +0000)
are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib rbt/img
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=rbt/img
Robert Yang (1):
multilib.bbclass: update DEFAULTTUNE for image recipe
meta/classes/multilib.bbclass | 16 +++++++++++-----
1 file changed, 11 insertions(+), 5 deletions(-)
--
2.9.0
^ permalink raw reply
* [PATCH 1/1] multilib.bbclass: update DEFAULTTUNE for image recipe
From: Robert Yang @ 2016-11-29 1:30 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <cover.1480383001.git.liezhi.yang@windriver.com>
Fixed:
MACHINE = "qemux86-64"
require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "x86"
$ bitbake -e lib32-core-image-minimal | grep ^TUNE_ARCH=
TUNE_ARCH="x86_64"
This is incorrect, it should be i686 (or other 32 bit tunes), this makes
we can't conditionlly install some packages, for example, the recipe-A
sets:
COMPATIBLE_HOST = "x86_64.*-linux"
Then it only can be installed when TARGET_ARCH is x86_64:
IMAGE_INSTALL_x86-64 += "package-A"
But it would be error when "bitbake lib32-core-image-minimal":
ERROR: lib32-recipe-A was skipped: incompatible with host i686-pokymllib32-linux (not in COMPATIBLE_HOST)
This is because TARGET_ARCH is not updated to "i686" when multilib, this
patch can fix the problem.
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
---
meta/classes/multilib.bbclass | 16 +++++++++++-----
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/meta/classes/multilib.bbclass b/meta/classes/multilib.bbclass
index d5a3128..5d2d048 100644
--- a/meta/classes/multilib.bbclass
+++ b/meta/classes/multilib.bbclass
@@ -23,6 +23,13 @@ python multilib_virtclass_handler () {
overrides = overrides.replace("pn-${PN}", "pn-${PN}:pn-" + pn)
e.data.setVar("OVERRIDES", overrides)
+ def multilib_set_default_tune():
+ # DEFAULTTUNE can change TARGET_ARCH override so expand this now before update_data
+ newtune = e.data.getVar("DEFAULTTUNE_" + "virtclass-multilib-" + variant, False)
+ if newtune:
+ e.data.setVar("DEFAULTTUNE", newtune)
+ e.data.setVar('DEFAULTTUNE_ML_%s' % variant, newtune)
+
if bb.data.inherits_class('image', e.data):
e.data.setVar("MLPREFIX", variant + "-")
e.data.setVar("PN", variant + "-" + e.data.getVar("PN", False))
@@ -30,6 +37,9 @@ python multilib_virtclass_handler () {
target_vendor = e.data.getVar("TARGET_VENDOR_" + "virtclass-multilib-" + variant, False)
if target_vendor:
e.data.setVar("TARGET_VENDOR", target_vendor)
+
+ multilib_set_default_tune()
+
return
if bb.data.inherits_class('cross-canadian', e.data):
@@ -65,11 +75,7 @@ python multilib_virtclass_handler () {
pkgs += " " + variant + "-" + pkg
e.data.setVar(whitelist, pkgs)
- # DEFAULTTUNE can change TARGET_ARCH override so expand this now before update_data
- newtune = e.data.getVar("DEFAULTTUNE_" + "virtclass-multilib-" + variant, False)
- if newtune:
- e.data.setVar("DEFAULTTUNE", newtune)
- e.data.setVar('DEFAULTTUNE_ML_%s' % variant, newtune)
+ multilib_set_default_tune()
}
addhandler multilib_virtclass_handler
--
2.9.0
^ permalink raw reply related
* Re: [PATCH 2/2] base-passwd: set root's default password to 'root'
From: Khem Raj @ 2016-11-29 1:57 UTC (permalink / raw)
To: Paul Eggleton; +Cc: openembedded-core
In-Reply-To: <5251131.puhPuqrAHf@peggleto-mobl.ger.corp.intel.com>
> On Nov 24, 2016, at 10:59 AM, Paul Eggleton <paul.eggleton@linux.intel.com> wrote:
>
> On Thu, 24 Nov 2016 08:46:29 Patrick Ohly wrote:
>> On Thu, 2016-11-24 at 11:38 +0800, Robert Yang wrote:
>>> Currently, debug-tweaks is in EXTRA_IMAGE_FEATURES by default for poky,
>>> and
>>> there is no passwd, so that user can login easily without a passwd, I
>>> think
>>> that current status is more unsafe ?
>>
>> Both well-known password and no password are unsafe. User "root" with
>> password "root" is not even "more" safe already now, because tools that
>> brute-force logins try that. Choosing something else would be a bit
>> safer for a short while until the tools add it to their dictionary.
>>
>> Poky is also targeting a different audience than OE-core. Poky can
>> assume to be used in a secure environment, OE-core can't (because it
>> might be used for all kinds of devices).
>
> I don't think that's part of the design goals on either side, it's simply
> about making development easier. The feature is clearly labelled "debug-
> tweaks" because it's for debugging not for production. It could be that we
> should make it do other things like append a notice to /etc/issue to avoid
> people leaving it on for production, if that is a concern.
>
Sometimes such goals can lead to problems. Making development easier by
all means if you can ensure a hard error on production e.g. debug-tweaks can
then never be part of production images. Otherwise someone will forget it
and it will be discovered on millions of devices in field along with the user
project will be red-faced.
^ permalink raw reply
* Re: Kernel: Builds use old version of defconfig
From: Khem Raj @ 2016-11-29 2:03 UTC (permalink / raw)
To: Bruce Ashfield
Cc: Mike Looijmans, Patches and discussions about the oe-core layer
In-Reply-To: <CADkTA4N-PEZZdDh7nrzaXBQb7jm0-SUkGbpcShXcQAJKe5bfEg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4958 bytes --]
> On Nov 24, 2016, at 5:55 AM, Bruce Ashfield <bruce.ashfield@gmail.com> wrote:
>
>
>
> On Thu, Nov 24, 2016 at 5:32 AM, Mike Looijmans <mike.looijmans@topic.nl <mailto:mike.looijmans@topic.nl>> wrote:
> On 24-11-16 11:10, Mike Looijmans wrote:
> I'm currently experiencing a problem with "defconfig" files and the kernel.
>
> In short, when I make a change to the "defconfig" file, the kernel is rebuilt
> (which is correct), but the resulting kernel has been built using the old
> defconfig from a previous build, instead of the new one.
>
> The kernel recipe just contains "file://defconfig" in its SRC_URI. The
> defconfig file is in the project's overlay.
>
> For example, I have a kernel with "CONFIG_DEVMEM" disabled:
>
> # gunzip < /proc/config.gz | grep DEVMEM
> # CONFIG_DEVMEM is not set
>
> Now, I change the defconfig to contain CONFIG_DEVMEM=y and build the image.
> The result:
>
> # gunzip < /proc/config.gz | grep DEVMEM
> # CONFIG_DEVMEM is not set
>
> So the change did not make it into the actual kernel, even though the kernel
> was rebuild as a result of the change.
>
> I run "bitbake -c cleansstate virtual/kernel" and build the image again:
>
> # gunzip < /proc/config.gz | grep DEVMEM
> CONFIG_DEVMEM=y
>
> After cleaning, the result is correct and the new defconfig is active.
>
> I'm trying to figure out how this can happen, any help is welcome...
>
> What seems to be the problem is this code in kernel.bbclass:
>
> # Copy defconfig to .config if .config does not exist. This allows
> # recipes to manage the .config themselves in do_configure_prepend().
> if [ -f "${WORKDIR}/defconfig" ] && [ ! -f "${B}/.config" ]; then
> cp "${WORKDIR}/defconfig" "${B}/.config"
> fi
>
> This keeps any existing ".config" file if it happens to still be in the $B path, which is the case if you're rebuilding a kernel.
>
> I see two possible ways to fix this.
>
> 1) During "cleanup" also remove the .config file in the build dir. However, the build dir is probably kept alive for a reason? I also can't figure out how that "cleanup" is being done.
>
>
> 2) Remove the second part of the "if" statement, so it becomes:
>
> # Copy defconfig to .config if "defconfig" exists. This allows
> # recipes to manage the .config themselves in do_configure_prepend().
> if [ -f "${WORKDIR}/defconfig" ]; then
> cp "${WORKDIR}/defconfig" "${B}/.config"
> fi
>
> I've tested that, and it solves my problem. However, it will probably break other people's config mangling?
>
>
> Yep, in particular all the fragment processing which has the capability of starting
> with a defconfig and then apply fragments from any number of other places. When
> that task completes, a full .config is in ${B}. If that statement comes along and
> clobbers the .config …
so you either assume that .config is valid once generated or you dont. When a configure task
is triggered it should recreate .config everytime.
>
> I'm actually working in the 2.3 release cycle to make the fragment processing
> be available to all kernels, which will likely solve this problem .. but we can't
> wait for that.
>
> So I'm hoping that there's a way to make the behaviour cover both use cases.
>
> Maybe someone with more bitbake knowledge can point out a way that can
> detect if the task is being run due to a change in the task signature.
>
> Since if you've modified the defconfig, the task is being re-run for that change
> and at that point we could safely remove the .config (versus forcing it on the
> clean step).
>
> Bruce
>
>
>
>
>
> Kind regards,
>
> Mike Looijmans
> System Expert
>
> TOPIC Products
> Materiaalweg 4, NL-5681 RJ Best
> Postbus 440, NL-5680 AK Best
> Telefoon: +31 (0) 499 33 69 79 <tel:%2B31%20%280%29%20499%2033%2069%2079>
> E-mail: mike.looijmans@topicproducts.com <mailto:mike.looijmans@topicproducts.com>
> Website: www.topicproducts.com <http://www.topicproducts.com/>
>
> Please consider the environment before printing this e-mail
>
>
>
>
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org <mailto:Openembedded-core@lists.openembedded.org>
> http://lists.openembedded.org/mailman/listinfo/openembedded-core <http://lists.openembedded.org/mailman/listinfo/openembedded-core>
>
>
>
> --
> "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org <mailto:Openembedded-core@lists.openembedded.org>
> http://lists.openembedded.org/mailman/listinfo/openembedded-core <http://lists.openembedded.org/mailman/listinfo/openembedded-core>
[-- Attachment #2: Type: text/html, Size: 13293 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] base-passwd: set root's default password to 'root'
From: Robert Yang @ 2016-11-29 2:45 UTC (permalink / raw)
To: Khem Raj, Paul Eggleton; +Cc: openembedded-core
In-Reply-To: <43EF9731-230A-4FEE-8D1F-D81BEB193D24@gmail.com>
On 11/29/2016 09:57 AM, Khem Raj wrote:
>
>> On Nov 24, 2016, at 10:59 AM, Paul Eggleton <paul.eggleton@linux.intel.com> wrote:
>>
>> On Thu, 24 Nov 2016 08:46:29 Patrick Ohly wrote:
>>> On Thu, 2016-11-24 at 11:38 +0800, Robert Yang wrote:
>>>> Currently, debug-tweaks is in EXTRA_IMAGE_FEATURES by default for poky,
>>>> and
>>>> there is no passwd, so that user can login easily without a passwd, I
>>>> think
>>>> that current status is more unsafe ?
>>>
>>> Both well-known password and no password are unsafe. User "root" with
>>> password "root" is not even "more" safe already now, because tools that
>>> brute-force logins try that. Choosing something else would be a bit
>>> safer for a short while until the tools add it to their dictionary.
>>>
>>> Poky is also targeting a different audience than OE-core. Poky can
>>> assume to be used in a secure environment, OE-core can't (because it
>>> might be used for all kinds of devices).
>>
>> I don't think that's part of the design goals on either side, it's simply
>> about making development easier. The feature is clearly labelled "debug-
>> tweaks" because it's for debugging not for production. It could be that we
>> should make it do other things like append a notice to /etc/issue to avoid
>> people leaving it on for production, if that is a concern.
>>
>
> Sometimes such goals can lead to problems. Making development easier by
> all means if you can ensure a hard error on production e.g. debug-tweaks can
> then never be part of production images. Otherwise someone will forget it
> and it will be discovered on millions of devices in field along with the user
> project will be red-faced.
Will something like IMAGE_FEATURES += "production" help here ? We may also
need something like IMAGE_FEATURES += "test" to make it can work with
-ctestimage.
// Robert
>
^ permalink raw reply
* [PATCH] devtool: execute associated functions while preparing the source tree
From: Jiajie Hu @ 2016-11-29 2:59 UTC (permalink / raw)
To: openembedded-core
Execute prefuncs and postfuncs associated with the task while preparing
the source tree. If any changes are made to the source tree by these
prefuncs or postfuncs, a separate commit will be created so that the
changes won't get incorporated with other patches.
Signed-off-by: Jiajie Hu <jiajie.hu@intel.com>
---
scripts/lib/devtool/standard.py | 23 ++++++++++++++++++++---
1 file changed, 20 insertions(+), 3 deletions(-)
diff --git a/scripts/lib/devtool/standard.py b/scripts/lib/devtool/standard.py
index e4d2a57..8302112 100644
--- a/scripts/lib/devtool/standard.py
+++ b/scripts/lib/devtool/standard.py
@@ -424,8 +424,7 @@ class BbTaskExecutor(object):
self.rdata = rdata
self.executed = []
- def exec_func(self, func, report):
- """Run bitbake task function"""
+ def _exec_func(self, func, report):
if not func in self.executed:
deps = self.rdata.getVarFlag(func, 'deps', False)
if deps:
@@ -435,12 +434,25 @@ class BbTaskExecutor(object):
logger.info('Executing %s...' % func)
fn = self.rdata.getVar('FILE', True)
localdata = bb.build._task_data(fn, func, self.rdata)
+ prefuncs = localdata.getVarFlag(func, 'prefuncs', True)
+ postfuncs = localdata.getVarFlag(func, 'postfuncs', True)
try:
+ for prefunc in (prefuncs or '').split():
+ bb.build.exec_func(prefunc, localdata)
+ yield prefunc
bb.build.exec_func(func, localdata)
+ for postfunc in (postfuncs or '').split():
+ bb.build.exec_func(postfunc, localdata)
+ yield postfunc
except bb.build.FuncFailed as e:
raise DevtoolError(str(e))
self.executed.append(func)
+ def exec_func(self, func, report):
+ """Run bitbake task function"""
+ for step in self._exec_func(func, report):
+ pass
+
class PatchTaskExecutor(BbTaskExecutor):
def __init__(self, rdata):
@@ -462,7 +474,12 @@ class PatchTaskExecutor(BbTaskExecutor):
else:
os.rmdir(patchdir)
- super(PatchTaskExecutor, self).exec_func(func, report)
+ for step in super(PatchTaskExecutor, self)._exec_func(func, report):
+ if self.check_git and os.path.exists(srcsubdir):
+ stdout, _ = bb.process.run('git status --porcelain', cwd=srcsubdir)
+ if stdout:
+ bb.process.run('git add .; git %s commit -a -m "Committing changes from %s\n\n%s"' % (' '.join(self.useroptions), step, GitApplyTree.ignore_commit_prefix + ' - from %s' % step), cwd=srcsubdir)
+
if self.check_git and os.path.exists(srcsubdir):
if func == 'do_patch':
if os.path.exists(patchdir):
--
1.9.1
^ permalink raw reply related
* Re: [PATCH 2/2] base-passwd: set root's default password to 'root'
From: Paul Eggleton @ 2016-11-29 3:45 UTC (permalink / raw)
To: Robert Yang, Khem Raj; +Cc: openembedded-core
In-Reply-To: <a63e3bae-0fe1-1f52-88b6-d9c53c38f306@windriver.com>
On Tue, 29 Nov 2016 10:45:51 Robert Yang wrote:
> On 11/29/2016 09:57 AM, Khem Raj wrote:
> >> On Nov 24, 2016, at 10:59 AM, Paul Eggleton
> >> <paul.eggleton@linux.intel.com> wrote:>>
> >> On Thu, 24 Nov 2016 08:46:29 Patrick Ohly wrote:
> >>> On Thu, 2016-11-24 at 11:38 +0800, Robert Yang wrote:
> >>>> Currently, debug-tweaks is in EXTRA_IMAGE_FEATURES by default for poky,
> >>>> and
> >>>> there is no passwd, so that user can login easily without a passwd, I
> >>>> think
> >>>> that current status is more unsafe ?
> >>>
> >>> Both well-known password and no password are unsafe. User "root" with
> >>> password "root" is not even "more" safe already now, because tools that
> >>> brute-force logins try that. Choosing something else would be a bit
> >>> safer for a short while until the tools add it to their dictionary.
> >>>
> >>> Poky is also targeting a different audience than OE-core. Poky can
> >>> assume to be used in a secure environment, OE-core can't (because it
> >>> might be used for all kinds of devices).
> >>
> >> I don't think that's part of the design goals on either side, it's simply
> >> about making development easier. The feature is clearly labelled "debug-
> >> tweaks" because it's for debugging not for production. It could be that
> >> we
> >> should make it do other things like append a notice to /etc/issue to
> >> avoid
> >> people leaving it on for production, if that is a concern.
> >
> > Sometimes such goals can lead to problems. Making development easier by
> > all means if you can ensure a hard error on production e.g. debug-tweaks
> > can then never be part of production images. Otherwise someone will
> > forget it and it will be discovered on millions of devices in field along
> > with the user project will be red-faced.
Right. FWIW in mitigation I did write the raw material for the following
section of the YP manuals, though I don't know how many people have ended
up reading it:
http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#making-images-more-secure
In there there is an explicit mention of disabling debug-tweaks. Looking
around the place it could be that we need more warnings about this being
on by default though.
> Will something like IMAGE_FEATURES += "production" help here ?
I'd like to see something like this - at least give the user some way of
saying "I really am in production now, so error out on anything that I
shouldn't be doing there". I wonder if it potentially goes further than
just conflicting with things like debug-tweaks and empty-root-password.
> We may also need something like IMAGE_FEATURES += "test" to make it can work
> with -ctestimage.
Not sure I follow your reasoning here - can you explain what this feature
would do?
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
^ permalink raw reply
* Re: [PATCH 2/2] base-passwd: set root's default password to 'root'
From: Robert Yang @ 2016-11-29 5:36 UTC (permalink / raw)
To: Paul Eggleton, Khem Raj; +Cc: openembedded-core
In-Reply-To: <1910837.9fFbRdU0ck@peggleto-mobl.ger.corp.intel.com>
On 11/29/2016 11:45 AM, Paul Eggleton wrote:
> On Tue, 29 Nov 2016 10:45:51 Robert Yang wrote:
>> On 11/29/2016 09:57 AM, Khem Raj wrote:
>>>> On Nov 24, 2016, at 10:59 AM, Paul Eggleton
>>>> <paul.eggleton@linux.intel.com> wrote:>>
>>>> On Thu, 24 Nov 2016 08:46:29 Patrick Ohly wrote:
>>>>> On Thu, 2016-11-24 at 11:38 +0800, Robert Yang wrote:
>>>>>> Currently, debug-tweaks is in EXTRA_IMAGE_FEATURES by default for poky,
>>>>>> and
>>>>>> there is no passwd, so that user can login easily without a passwd, I
>>>>>> think
>>>>>> that current status is more unsafe ?
>>>>>
>>>>> Both well-known password and no password are unsafe. User "root" with
>>>>> password "root" is not even "more" safe already now, because tools that
>>>>> brute-force logins try that. Choosing something else would be a bit
>>>>> safer for a short while until the tools add it to their dictionary.
>>>>>
>>>>> Poky is also targeting a different audience than OE-core. Poky can
>>>>> assume to be used in a secure environment, OE-core can't (because it
>>>>> might be used for all kinds of devices).
>>>>
>>>> I don't think that's part of the design goals on either side, it's simply
>>>> about making development easier. The feature is clearly labelled "debug-
>>>> tweaks" because it's for debugging not for production. It could be that
>>>> we
>>>> should make it do other things like append a notice to /etc/issue to
>>>> avoid
>>>> people leaving it on for production, if that is a concern.
>>>
>>> Sometimes such goals can lead to problems. Making development easier by
>>> all means if you can ensure a hard error on production e.g. debug-tweaks
>>> can then never be part of production images. Otherwise someone will
>>> forget it and it will be discovered on millions of devices in field along
>>> with the user project will be red-faced.
>
> Right. FWIW in mitigation I did write the raw material for the following
> section of the YP manuals, though I don't know how many people have ended
> up reading it:
>
> http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#making-images-more-secure
>
> In there there is an explicit mention of disabling debug-tweaks. Looking
> around the place it could be that we need more warnings about this being
> on by default though.
>
>> Will something like IMAGE_FEATURES += "production" help here ?
>
> I'd like to see something like this - at least give the user some way of
> saying "I really am in production now, so error out on anything that I
> shouldn't be doing there". I wonder if it potentially goes further than
> just conflicting with things like debug-tweaks and empty-root-password.
>
>> We may also need something like IMAGE_FEATURES += "test" to make it can work
>> with -ctestimage.
>
> Not sure I follow your reasoning here - can you explain what this feature
> would do?
For example, the "bitbake <image> -ctestimage" requires a few pkgs installed,
such as psplash-default, see the testcase in meta/lib/oeqa/runtime/smart.py:
def test_smart_install(self):
self.smart('remove -y psplash-default')
self.smart('install -y psplash-default')
The test would fail without psplash-default installed, and also it requires
sshd installed on the target. When IMAGE_FETURES += "test", we can install
these required packages, I'm not sure this is a good idea, or maybe we can
enhance testimge.bbclass to do it. Another way to fix the problem might be
not hardcode the package name.
// Robert
>
> Cheers,
> Paul
>
^ permalink raw reply
* Re: [PATCH] devtool: execute associated functions while preparing the source tree
From: Christopher Larson @ 2016-11-29 6:04 UTC (permalink / raw)
To: Jiajie Hu; +Cc: Patches and discussions about the oe-core layer
In-Reply-To: <1480388349-4206-1-git-send-email-jiajie.hu@intel.com>
[-- Attachment #1: Type: text/plain, Size: 3315 bytes --]
On Mon, Nov 28, 2016 at 7:59 PM, Jiajie Hu <jiajie.hu@intel.com> wrote:
> Execute prefuncs and postfuncs associated with the task while preparing
> the source tree. If any changes are made to the source tree by these
> prefuncs or postfuncs, a separate commit will be created so that the
> changes won't get incorporated with other patches.
>
> Signed-off-by: Jiajie Hu <jiajie.hu@intel.com>
> ---
> scripts/lib/devtool/standard.py | 23 ++++++++++++++++++++---
> 1 file changed, 20 insertions(+), 3 deletions(-)
>
> diff --git a/scripts/lib/devtool/standard.py b/scripts/lib/devtool/
> standard.py
> index e4d2a57..8302112 100644
> --- a/scripts/lib/devtool/standard.py
> +++ b/scripts/lib/devtool/standard.py
> @@ -424,8 +424,7 @@ class BbTaskExecutor(object):
> self.rdata = rdata
> self.executed = []
>
> - def exec_func(self, func, report):
> - """Run bitbake task function"""
> + def _exec_func(self, func, report):
> if not func in self.executed:
> deps = self.rdata.getVarFlag(func, 'deps', False)
> if deps:
> @@ -435,12 +434,25 @@ class BbTaskExecutor(object):
> logger.info('Executing %s...' % func)
> fn = self.rdata.getVar('FILE', True)
> localdata = bb.build._task_data(fn, func, self.rdata)
> + prefuncs = localdata.getVarFlag(func, 'prefuncs', True)
> + postfuncs = localdata.getVarFlag(func, 'postfuncs', True)
> try:
> + for prefunc in (prefuncs or '').split():
> + bb.build.exec_func(prefunc, localdata)
> + yield prefunc
> bb.build.exec_func(func, localdata)
> + for postfunc in (postfuncs or '').split():
> + bb.build.exec_func(postfunc, localdata)
> + yield postfunc
> except bb.build.FuncFailed as e:
> raise DevtoolError(str(e))
> self.executed.append(func)
>
> + def exec_func(self, func, report):
> + """Run bitbake task function"""
> + for step in self._exec_func(func, report):
> + pass
> +
>
> class PatchTaskExecutor(BbTaskExecutor):
> def __init__(self, rdata):
> @@ -462,7 +474,12 @@ class PatchTaskExecutor(BbTaskExecutor):
> else:
> os.rmdir(patchdir)
>
> - super(PatchTaskExecutor, self).exec_func(func, report)
> + for step in super(PatchTaskExecutor, self)._exec_func(func,
> report):
> + if self.check_git and os.path.exists(srcsubdir):
> + stdout, _ = bb.process.run('git status --porcelain',
> cwd=srcsubdir)
> + if stdout:
> + bb.process.run('git add .; git %s commit -a -m
> "Committing changes from %s\n\n%s"' % (' '.join(self.useroptions), step,
> GitApplyTree.ignore_commit_prefix + ' - from %s' % step), cwd=srcsubdir)
>
This will do the commit after the first postfunc is done, so won’t the
changes from the main func and the first postfunc both be included in that
commit?
--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
[-- Attachment #2: Type: text/html, Size: 4719 bytes --]
^ permalink raw reply
* Re: [PATCH] qemu*.conf: Add slirp support for all qemu machines
From: Robert Yang @ 2016-11-29 6:21 UTC (permalink / raw)
To: Randy Witt, openembedded-core
In-Reply-To: <1480363884-6789-1-git-send-email-randy.e.witt@linux.intel.com>
On 11/29/2016 04:11 AM, Randy Witt wrote:
> This patch also moves the "-net user" part out of the config and
> into runqemu. This is done because the "-net user" portion isn't
> machine specific, and it contains what ports to forward.
>
> [ YOCTO #7887 ]
>
> Signed-off-by: Randy Witt <randy.e.witt@linux.intel.com>
> ---
> meta/conf/machine/include/qemuboot-mips.inc | 1 +
> meta/conf/machine/include/qemuboot-x86.inc | 2 +-
> meta/conf/machine/qemuarm.conf | 1 +
> meta/conf/machine/qemuarm64.conf | 2 +-
> meta/conf/machine/qemuppc.conf | 1 +
> scripts/runqemu | 7 ++++++-
> 6 files changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/meta/conf/machine/include/qemuboot-mips.inc b/meta/conf/machine/include/qemuboot-mips.inc
> index 0c60cf2..c85dc86 100644
> --- a/meta/conf/machine/include/qemuboot-mips.inc
> +++ b/meta/conf/machine/include/qemuboot-mips.inc
> @@ -6,3 +6,4 @@ QB_KERNEL_CMDLINE_APPEND = "console=ttyS0 console=tty"
> # Add the 'virtio-rng-pci' device otherwise the guest may run out of entropy
> QB_OPT_APPEND = "-vga cirrus -show-cursor -usb -usbdevice tablet -device virtio-rng-pci"
> QB_SYSTEM_NAME = "qemu-system-${TUNE_ARCH}"
> +QB_SLIRP_OPT = "-device virtio-net-pci,netdev=net0"
> diff --git a/meta/conf/machine/include/qemuboot-x86.inc b/meta/conf/machine/include/qemuboot-x86.inc
> index 0870294..cc31dab 100644
> --- a/meta/conf/machine/include/qemuboot-x86.inc
> +++ b/meta/conf/machine/include/qemuboot-x86.inc
> @@ -13,4 +13,4 @@ QB_AUDIO_OPT = "-soundhw ac97,es1370"
> QB_KERNEL_CMDLINE_APPEND = "vga=0 uvesafb.mode_option=640x480-32 oprofile.timer=1 uvesafb.task_timeout=-1"
> # Add the 'virtio-rng-pci' device otherwise the guest may run out of entropy
> QB_OPT_APPEND = "-vga vmware -show-cursor -usb -usbdevice tablet -device virtio-rng-pci"
> -QB_SLIRP_OPT = "-net nic,model=e1000 -net user,hostfwd=tcp::2222-:22"
> +QB_SLIRP_OPT = "-device virtio-net-pci,netdev=net0"
> diff --git a/meta/conf/machine/qemuarm.conf b/meta/conf/machine/qemuarm.conf
> index 17402ef..974657b 100644
> --- a/meta/conf/machine/qemuarm.conf
> +++ b/meta/conf/machine/qemuarm.conf
> @@ -18,3 +18,4 @@ QB_KERNEL_CMDLINE_APPEND = "console=ttyAMA0,115200 console=tty"
> QB_OPT_APPEND = "-show-cursor -usb -usbdevice tablet -device virtio-rng-pci"
> PREFERRED_VERSION_linux-yocto ??= "4.8%"
> QB_DTB = "${@base_version_less_or_equal('PREFERRED_VERSION_linux-yocto', '4.7', '', 'zImage-versatile-pb.dtb', d)}"
> +QB_SLIRP_OPT = "-device virtio-net-pci,netdev=net0"
> diff --git a/meta/conf/machine/qemuarm64.conf b/meta/conf/machine/qemuarm64.conf
> index df2010c..ebd360e 100644
> --- a/meta/conf/machine/qemuarm64.conf
> +++ b/meta/conf/machine/qemuarm64.conf
> @@ -18,7 +18,7 @@ QB_KERNEL_CMDLINE_APPEND = "console=ttyAMA0,38400"
> # Add the 'virtio-rng-pci' device otherwise the guest may run out of entropy
> QB_OPT_APPEND = "-show-cursor -device virtio-rng-pci -monitor null"
> QB_TAP_OPT = "-netdev tap,id=net0,ifname=@TAP@,script=no,downscript=no -device virtio-net-device,netdev=net0,mac=@MAC@"
> -QB_SLIRP_OPT = "-netdev user,id=net0 -device virtio-net-device,netdev=net0"
> +QB_SLIRP_OPT = "-device virtio-net-device,netdev=net0"
> QB_ROOTFS_OPT = "-drive id=disk0,file=@ROOTFS@,if=none,format=raw -device virtio-blk-device,drive=disk0"
> QB_SERIAL_OPT = "-device virtio-serial-device -chardev null,id=virtcon -device virtconsole,chardev=virtcon"
> QB_TCPSERIAL_OPT = " -device virtio-serial-device -chardev socket,id=virtcon,port=@PORT@,host=127.0.0.1 -device virtconsole,chardev=virtcon"
> diff --git a/meta/conf/machine/qemuppc.conf b/meta/conf/machine/qemuppc.conf
> index 8703c20..4711751 100644
> --- a/meta/conf/machine/qemuppc.conf
> +++ b/meta/conf/machine/qemuppc.conf
> @@ -19,3 +19,4 @@ QB_KERNEL_CMDLINE_APPEND = "console=tty console=ttyS0"
> # Add the 'virtio-rng-pci' device otherwise the guest may run out of entropy
> QB_OPT_APPEND = "-show-cursor -usb -usbdevice tablet -device virtio-rng-pci"
> QB_TAP_OPT = "-netdev tap,id=net0,ifname=@TAP@,script=no,downscript=no -device virtio-net-pci,netdev=net0,mac=@MAC@"
> +QB_SLIRP_OPT = "-device virtio-net-pci,netdev=net0"
> diff --git a/scripts/runqemu b/scripts/runqemu
> index af25423..faab522 100755
> --- a/scripts/runqemu
> +++ b/scripts/runqemu
> @@ -730,7 +730,12 @@ class BaseConfig(object):
> if self.fstype == 'nfs':
> self.setup_nfs()
> self.kernel_cmdline_script += ' ip=dhcp'
> - self.set('NETWORK_CMD', self.get('QB_SLIRP_OPT'))
> + network_cmd = self.get('QB_SLIRP_OPT')
> +
> + # The network device created in qemuboot.conf is expected to be
> + # id=net0
> + network_cmd += ' -netdev user,id=net0,hostfwd=tcp::2222-:22'
Hi Randy,
This doesn't work when more than one qemu is running since the port
will be conflicted. And since all of the QB_SLIRP_OPT are the same,
so I'd like to set it as a default value in runqemu, just like
what we do for QB_TAP_OPT. And if we break them into two parts:
"-device virtio-net-device,netdev=net0" and
"-netdev user,id=net0,hostfwd=tcp::2222-:22"
Then there is no way for user to override the second part, and we can't
call the first part as a "QB_SLIRP_OPT" since it is only part of them,
so I won't break them into 2, and if the user defines QB_SLIRP_OPT
in there bsp conf file, then it will be replaced totally.
I will send a new patch for fixing this, and will add you in the CC list.
// Robert
> + self.set('NETWORK_CMD', network_cmd)
>
> def setup_tap(self):
> """Setup tap"""
>
^ permalink raw reply
* Re: [PATCH 2/2] base-passwd: set root's default password to 'root'
From: Paul Eggleton @ 2016-11-29 6:27 UTC (permalink / raw)
To: Robert Yang; +Cc: openembedded-core
In-Reply-To: <90784e81-531a-1da8-4660-e4946916ca69@windriver.com>
On Tue, 29 Nov 2016 13:36:58 Robert Yang wrote:
> On 11/29/2016 11:45 AM, Paul Eggleton wrote:
> > On Tue, 29 Nov 2016 10:45:51 Robert Yang wrote:
> >> We may also need something like IMAGE_FEATURES += "test" to make it can
> >> work with -ctestimage.
> >
> > Not sure I follow your reasoning here - can you explain what this feature
> > would do?
>
> For example, the "bitbake <image> -ctestimage" requires a few pkgs
> installed, such as psplash-default, see the testcase in
> meta/lib/oeqa/runtime/smart.py:
>
> def test_smart_install(self):
> self.smart('remove -y psplash-default')
> self.smart('install -y psplash-default')
>
> The test would fail without psplash-default installed, and also it requires
> sshd installed on the target. When IMAGE_FETURES += "test", we can install
> these required packages, I'm not sure this is a good idea, or maybe we can
> enhance testimge.bbclass to do it. Another way to fix the problem might be
> not hardcode the package name.
We have other means of dealing with that specifically - i.e. have the test
skip itself if a package required for the test is not in the image. I think we
already have examples of that.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
^ permalink raw reply
* [PATCH 1/5] runqemu: fix checking for <file>.cpio.gz
From: Robert Yang @ 2016-11-29 7:35 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <cover.1480404884.git.liezhi.yang@windriver.com>
When "runqemu /path/to/<file>.cpio.gz", it used the last suffix "gz" as
the fstype which was wrong. Check filename against self.fstypes firstly
can fix the problem.
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
---
scripts/runqemu | 22 ++++++++++++++++------
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/scripts/runqemu b/scripts/runqemu
index af25423..c737eb2 100755
--- a/scripts/runqemu
+++ b/scripts/runqemu
@@ -269,19 +269,29 @@ class BaseConfig(object):
self.kernel = p
elif os.path.exists(p) and (not os.path.isdir(p)) and re.search('-image-', os.path.basename(p)):
self.rootfs = p
- dirpath = os.path.dirname(p)
- m = re.search('(.*)\.(.*)$', p)
- if m:
- qb = '%s%s' % (re.sub('\.rootfs$', '', m.group(1)), '.qemuboot.conf')
+ # Check filename against self.fstypes can hanlde <file>.cpio.gz,
+ # otherwise, its type would be "gz", which is incorrect.
+ fst = ""
+ for t in self.fstypes:
+ if p.endswith(t):
+ fst = t
+ break
+ if not fst:
+ m = re.search('.*\.(.*)$', self.rootfs)
+ if m:
+ fst = m.group(1)
+ if fst:
+ self.check_arg_fstype(fst)
+ qb = re.sub('\.' + fst + "$", '', self.rootfs)
+ qb = '%s%s' % (re.sub('\.rootfs$', '', qb), '.qemuboot.conf')
if os.path.exists(qb):
self.qemuboot = qb
self.qbconfload = True
else:
logger.warn("%s doesn't exist" % qb)
- fst = m.group(2)
- self.check_arg_fstype(fst)
else:
raise Exception("Can't find FSTYPE from: %s" % p)
+
elif os.path.isdir(p) or re.search(':', arg) and re.search('/', arg):
if self.is_deploy_dir_image(p):
logger.info('DEPLOY_DIR_IMAGE: %s' % p)
--
2.9.0
^ permalink raw reply related
* [PATCH 0/5] runqemu: fixes for cpio.gz, nfs and slirp
From: Robert Yang @ 2016-11-29 7:35 UTC (permalink / raw)
To: openembedded-core
The following changes since commit af280990bff4a484fd8a18e3442b56a0a39b7611:
Revert "classes/populate_sdk_ext: require uninative" (2016-11-28 14:49:37 +0000)
are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib rbt/qemu
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=rbt/qemu
Robert Yang (5):
runqemu: fix checking for <file>.cpio.gz
qemuboot.bbclass: use IMGDEPLOYDIR
runqemu-export-rootfs: fix inconsistent var names
runqemu: support mutiple qemus running when nfs
runqemu: set default device and hostfwd for slirp
meta/classes/qemuboot.bbclass | 5 +-
meta/conf/machine/include/qemuboot-x86.inc | 1 -
meta/conf/machine/qemuarm64.conf | 1 -
scripts/runqemu | 111 ++++++++++++++++++++++-------
scripts/runqemu-export-rootfs | 21 +++---
5 files changed, 96 insertions(+), 43 deletions(-)
--
2.9.0
^ permalink raw reply
* [PATCH 3/5] runqemu-export-rootfs: fix inconsistent var names
From: Robert Yang @ 2016-11-29 7:35 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <cover.1480404884.git.liezhi.yang@windriver.com>
Fixed:
$ runqemu nfs qemux86-64
[snip]
On your target please remember to add the following options for NFS
nfsroot=IP_ADDRESS:/path/to/nfsroot,nfsvers=3,port=,mountprog=,nfsprog=,udp,mountport=
[snip]
Note that the values are null, this is because their var names are
inconsistent.
[YOCTO #10519]
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
---
scripts/runqemu-export-rootfs | 21 +++++++++------------
1 file changed, 9 insertions(+), 12 deletions(-)
diff --git a/scripts/runqemu-export-rootfs b/scripts/runqemu-export-rootfs
index 3dee131..0dd3eba 100755
--- a/scripts/runqemu-export-rootfs
+++ b/scripts/runqemu-export-rootfs
@@ -78,23 +78,17 @@ if [ ! -d "$PSEUDO_LOCALSTATEDIR" ]; then
fi
# rpc.mountd RPC port
-NFS_MOUNTPROG=$[ 21111 + $NFS_INSTANCE ]
+MOUNTD_RPCPORT=$[ 21111 + $NFS_INSTANCE ]
# rpc.nfsd RPC port
-NFS_NFSPROG=$[ 11111 + $NFS_INSTANCE ]
-# NFS port number
-NFS_PORT=$[ 3049 + 2 * $NFS_INSTANCE ]
+NFSD_RPCPORT=$[ 11111 + $NFS_INSTANCE ]
+# NFS server port number
+NFSD_PORT=$[ 3049 + 2 * $NFS_INSTANCE ]
# mountd port number
-MOUNT_PORT=$[ 3048 + 2 * $NFS_INSTANCE ]
+MOUNTD_PORT=$[ 3048 + 2 * $NFS_INSTANCE ]
## For debugging you would additionally add
## --debug all
-UNFSD_OPTS="-p -N -i $NFSPID -e $EXPORTS -x $NFS_NFSPROG -n $NFS_PORT -y $NFS_MOUNTPROG -m $MOUNT_PORT"
-
-# Setup the exports file
-if [ "$1" = "start" ]; then
- echo "Creating exports file..."
- echo "$NFS_EXPORT_DIR (rw,async,no_root_squash,no_all_squash,insecure)" > $EXPORTS
-fi
+UNFSD_OPTS="-p -N -i $NFSPID -e $EXPORTS -x $NFSD_RPCPORT -n $NFSD_PORT -y $MOUNTD_RPCPORT -m $MOUNTD_PORT"
# See how we were called.
case "$1" in
@@ -114,6 +108,9 @@ case "$1" in
exit 1
fi
+ echo "Creating exports file..."
+ echo "$NFS_EXPORT_DIR (rw,async,no_root_squash,no_all_squash,insecure)" > $EXPORTS
+
echo "Starting User Mode nfsd"
echo " $PSEUDO $PSEUDO_OPTS $OECORE_NATIVE_SYSROOT/usr/bin/unfsd $UNFSD_OPTS"
$PSEUDO $PSEUDO_OPTS $OECORE_NATIVE_SYSROOT/usr/bin/unfsd $UNFSD_OPTS
--
2.9.0
^ permalink raw reply related
* [PATCH 2/5] qemuboot.bbclass: use IMGDEPLOYDIR
From: Robert Yang @ 2016-11-29 7:35 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <cover.1480404884.git.liezhi.yang@windriver.com>
So that "bitbake <image> -ccleansstate" can remove qemuboot.conf
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
---
meta/classes/qemuboot.bbclass | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/meta/classes/qemuboot.bbclass b/meta/classes/qemuboot.bbclass
index 39df3ad..eb0ee57 100644
--- a/meta/classes/qemuboot.bbclass
+++ b/meta/classes/qemuboot.bbclass
@@ -43,6 +43,7 @@ QB_OPT_APPEND ?= "-show-cursor"
# Create qemuboot.conf
ROOTFS_POSTPROCESS_COMMAND += "write_qemuboot_conf; "
+IMGDEPLOYDIR ?= "${WORKDIR}/deploy-${PN}-image-complete"
def qemuboot_vars(d):
build_vars = ['MACHINE', 'TUNE_ARCH', 'DEPLOY_DIR_IMAGE',
@@ -55,8 +56,8 @@ write_qemuboot_conf[vardeps] += "${@' '.join(qemuboot_vars(d))}"
python write_qemuboot_conf() {
import configparser
- qemuboot = "%s/%s.qemuboot.conf" % (d.getVar('DEPLOY_DIR_IMAGE', True), d.getVar('IMAGE_NAME', True))
- qemuboot_link = "%s/%s.qemuboot.conf" % (d.getVar('DEPLOY_DIR_IMAGE', True), d.getVar('IMAGE_LINK_NAME', True))
+ qemuboot = "%s/%s.qemuboot.conf" % (d.getVar('IMGDEPLOYDIR', True), d.getVar('IMAGE_NAME', True))
+ qemuboot_link = "%s/%s.qemuboot.conf" % (d.getVar('IMGDEPLOYDIR', True), d.getVar('IMAGE_LINK_NAME', True))
cf = configparser.ConfigParser()
cf.add_section('config_bsp')
for k in qemuboot_vars(d):
--
2.9.0
^ permalink raw reply related
* [PATCH 5/5] runqemu: set default device and hostfwd for slirp
From: Robert Yang @ 2016-11-29 7:35 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <cover.1480404884.git.liezhi.yang@windriver.com>
There is no network rather than lo whitout set device, so set it by
default. And set hostfwd: 2222 -> 22, 2323 -> 23
[YOCTO #7887]
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
---
meta/conf/machine/include/qemuboot-x86.inc | 1 -
meta/conf/machine/qemuarm64.conf | 1 -
scripts/runqemu | 34 ++++++++++++++++++++++++++++--
3 files changed, 32 insertions(+), 4 deletions(-)
diff --git a/meta/conf/machine/include/qemuboot-x86.inc b/meta/conf/machine/include/qemuboot-x86.inc
index 0870294..06ac983 100644
--- a/meta/conf/machine/include/qemuboot-x86.inc
+++ b/meta/conf/machine/include/qemuboot-x86.inc
@@ -13,4 +13,3 @@ QB_AUDIO_OPT = "-soundhw ac97,es1370"
QB_KERNEL_CMDLINE_APPEND = "vga=0 uvesafb.mode_option=640x480-32 oprofile.timer=1 uvesafb.task_timeout=-1"
# Add the 'virtio-rng-pci' device otherwise the guest may run out of entropy
QB_OPT_APPEND = "-vga vmware -show-cursor -usb -usbdevice tablet -device virtio-rng-pci"
-QB_SLIRP_OPT = "-net nic,model=e1000 -net user,hostfwd=tcp::2222-:22"
diff --git a/meta/conf/machine/qemuarm64.conf b/meta/conf/machine/qemuarm64.conf
index df2010c..7a5570c 100644
--- a/meta/conf/machine/qemuarm64.conf
+++ b/meta/conf/machine/qemuarm64.conf
@@ -18,7 +18,6 @@ QB_KERNEL_CMDLINE_APPEND = "console=ttyAMA0,38400"
# Add the 'virtio-rng-pci' device otherwise the guest may run out of entropy
QB_OPT_APPEND = "-show-cursor -device virtio-rng-pci -monitor null"
QB_TAP_OPT = "-netdev tap,id=net0,ifname=@TAP@,script=no,downscript=no -device virtio-net-device,netdev=net0,mac=@MAC@"
-QB_SLIRP_OPT = "-netdev user,id=net0 -device virtio-net-device,netdev=net0"
QB_ROOTFS_OPT = "-drive id=disk0,file=@ROOTFS@,if=none,format=raw -device virtio-blk-device,drive=disk0"
QB_SERIAL_OPT = "-device virtio-serial-device -chardev null,id=virtcon -device virtconsole,chardev=virtcon"
QB_TCPSERIAL_OPT = " -device virtio-serial-device -chardev socket,id=virtcon,port=@PORT@,host=127.0.0.1 -device virtconsole,chardev=virtcon"
diff --git a/scripts/runqemu b/scripts/runqemu
index a10270c..7123b8f 100755
--- a/scripts/runqemu
+++ b/scripts/runqemu
@@ -147,6 +147,19 @@ def get_first_file(cmds):
return f
return ''
+def check_free_port(host, port):
+ """ Check whether the port is free or not """
+ import socket
+ from contextlib import closing
+
+ with closing(socket.socket(socket.AF_INET, socket.SOCK_STREAM)) as sock:
+ if sock.connect_ex((host, port)) == 0:
+ # Port is open, so not free
+ return False
+ else:
+ # Port is not open, so free
+ return True
+
class BaseConfig(object):
def __init__(self):
# Vars can be merged with .qemuboot.conf, use a dict to manage them.
@@ -751,14 +764,31 @@ class BaseConfig(object):
self.nfs_running = True
-
def setup_slirp(self):
"""Setup user networking"""
if self.fstype == 'nfs':
self.setup_nfs()
self.kernel_cmdline_script += ' ip=dhcp'
- self.set('NETWORK_CMD', self.get('QB_SLIRP_OPT'))
+ # Port mapping
+ hostfwd = ",hostfwd=tcp::2222-:22,hostfwd=tcp::2323-:23"
+ qb_slirp_opt_default = "-netdev user,id=net0%s -device virtio-net-pci,netdev=net0" % hostfwd
+ qb_slirp_opt = self.get('QB_SLIRP_OPT') or qb_slirp_opt_default
+ # Figure out the port
+ ports = re.findall('hostfwd=[^-]*:([0-9]+)-[^,-]*', qb_slirp_opt)
+ ports = [int(i) for i in ports]
+ # Find a free port to avoid conflicts
+ for p in ports[:]:
+ p_new = p
+ while not check_free_port('127.0.0.1', p_new):
+ p_new += 1
+ while p_new in ports:
+ p_new += 1
+ if p != p_new:
+ ports.append(p_new)
+ qb_slirp_opt = re.sub(':%s-' % p, ':%s-' % p_new, qb_slirp_opt)
+ logger.info("Port forward changed: %s -> %s" % (p, p_new))
+ self.set('NETWORK_CMD', qb_slirp_opt)
def setup_tap(self):
"""Setup tap"""
--
2.9.0
^ permalink raw reply related
* [PATCH 4/5] runqemu: support mutiple qemus running when nfs
From: Robert Yang @ 2016-11-29 7:35 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <cover.1480404884.git.liezhi.yang@windriver.com>
Fixed:
* In build1:
$ runqemu nfs qemux86-64
In build2:
$ runqemu nfs qemux86-64
It would fail before since the port numerbs and conf files are
conflicted, now make runqemu-export-rootfs work together with runqemu to
fix the problem.
* And we don't need export PSEUDO_LOCALSTATEDIR in runqemu, the
runqemu-export-rootfs can handle it well based on NFS_EXPORT_DIR.
* Remove "async" option from unfsd to fix warning in syslog:
Warning: unknown exports option `async' ignored
* Fixed typos
Both slirp and tap can work.
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
---
scripts/runqemu | 55 ++++++++++++++++++++++++++++---------------
scripts/runqemu-export-rootfs | 10 ++++----
2 files changed, 41 insertions(+), 24 deletions(-)
diff --git a/scripts/runqemu b/scripts/runqemu
index c737eb2..a10270c 100755
--- a/scripts/runqemu
+++ b/scripts/runqemu
@@ -690,17 +690,33 @@ class BaseConfig(object):
else:
self.nfs_server = '192.168.7.1'
- nfs_instance = int(self.nfs_instance)
-
- mountd_rpcport = 21111 + nfs_instance
- nfsd_rpcport = 11111 + nfs_instance
- nfsd_port = 3049 + 2 * nfs_instance
- mountd_port = 3048 + 2 * nfs_instance
- unfs_opts="nfsvers=3,port=%s,mountprog=%s,nfsprog=%s,udp,mountport=%s" % (nfsd_port, mountd_rpcport, nfsd_rpcport, mountd_port)
- self.unfs_opts = unfs_opts
+ # Figure out a new nfs_instance to allow multiple qemus running.
+ cmd = "ps aux"
+ ps = subprocess.Popen(cmd, shell=True, stdout=subprocess.PIPE).stdout.read().decode('utf-8')
+ pattern = '/bin/unfsd .* -i .*\.pid -e .*/exports([0-9]+) '
+ all_instances = re.findall(pattern, ps, re.M)
+ if all_instances:
+ all_instances.sort(key=int)
+ self.nfs_instance = int(all_instances.pop()) + 1
+
+ mountd_rpcport = 21111 + self.nfs_instance
+ nfsd_rpcport = 11111 + self.nfs_instance
+ nfsd_port = 3049 + 2 * self.nfs_instance
+ mountd_port = 3048 + 2 * self.nfs_instance
+
+ # Export vars for runqemu-export-rootfs
+ export_dict = {
+ 'NFS_INSTANCE': self.nfs_instance,
+ 'MOUNTD_RPCPORT': mountd_rpcport,
+ 'NFSD_RPCPORT': nfsd_rpcport,
+ 'NFSD_PORT': nfsd_port,
+ 'MOUNTD_PORT': mountd_port,
+ }
+ for k, v in export_dict.items():
+ # Use '%s' since they are integers
+ os.putenv(k, '%s' % v)
- p = '%s/.runqemu-sdk/pseudo' % os.getenv('HOME')
- os.putenv('PSEUDO_LOCALSTATEDIR', p)
+ self.unfs_opts="nfsvers=3,port=%s,mountprog=%s,nfsprog=%s,udp,mountport=%s" % (nfsd_port, mountd_rpcport, nfsd_rpcport, mountd_port)
# Extract .tar.bz2 or .tar.bz if no self.nfs_dir
if not self.nfs_dir:
@@ -728,7 +744,7 @@ class BaseConfig(object):
self.nfs_dir = dest
# Start the userspace NFS server
- cmd = 'runqemu-export-rootfs restart %s' % self.nfs_dir
+ cmd = 'runqemu-export-rootfs start %s' % self.nfs_dir
logger.info('Running %s...' % cmd)
if subprocess.call(cmd, shell=True) != 0:
raise Exception('Failed to run %s' % cmd)
@@ -737,6 +753,8 @@ class BaseConfig(object):
def setup_slirp(self):
+ """Setup user networking"""
+
if self.fstype == 'nfs':
self.setup_nfs()
self.kernel_cmdline_script += ' ip=dhcp'
@@ -804,14 +822,13 @@ class BaseConfig(object):
logger.error("Failed to setup tap device. Run runqemu-gen-tapdevs to manually create.")
return 1
self.tap = tap
- n0 = tap[3:]
- n1 = int(n0) * 2 + 1
- n2 = n1 + 1
- self.nfs_instance = n0
+ tapnum = int(tap[3:])
+ gateway = tapnum * 2 + 1
+ client = gateway + 1
if self.fstype == 'nfs':
self.setup_nfs()
- self.kernel_cmdline_script += " ip=192.168.7.%s::192.168.7.%s:255.255.255.0" % (n2, n1)
- mac = "52:54:00:12:34:%02x" % n2
+ self.kernel_cmdline_script += " ip=192.168.7.%s::192.168.7.%s:255.255.255.0" % (client, gateway)
+ mac = "52:54:00:12:34:%02x" % client
qb_tap_opt = self.get('QB_TAP_OPT')
if qb_tap_opt:
qemu_tap_opt = qb_tap_opt.replace('@TAP@', tap).replace('@MAC@', mac)
@@ -854,11 +871,11 @@ class BaseConfig(object):
vm_drive = '-drive if=none,id=hd,file=%s,format=%s -device virtio-scsi-pci,id=scsi -device scsi-hd,drive=hd' \
% (self.rootfs, rootfs_format)
elif subprocess.call(cmd2, shell=True) == 0:
- logger.info('Using scsi drive')
+ logger.info('Using ide drive')
vm_drive = "%s,format=%s" % (self.rootfs, rootfs_format)
else:
logger.warn("Can't detect drive type %s" % self.rootfs)
- logger.warn('Tring to use virtio block drive')
+ logger.warn('Trying to use virtio block drive')
vm_drive = '-drive if=virtio,file=%s,format=%s' % (self.rootfs, rootfs_format)
self.rootfs_options = '%s -no-reboot' % vm_drive
self.kernel_cmdline = 'root=%s rw highres=off' % (self.get('QB_KERNEL_ROOT'))
diff --git a/scripts/runqemu-export-rootfs b/scripts/runqemu-export-rootfs
index 0dd3eba..7ebc071 100755
--- a/scripts/runqemu-export-rootfs
+++ b/scripts/runqemu-export-rootfs
@@ -78,13 +78,13 @@ if [ ! -d "$PSEUDO_LOCALSTATEDIR" ]; then
fi
# rpc.mountd RPC port
-MOUNTD_RPCPORT=$[ 21111 + $NFS_INSTANCE ]
+MOUNTD_RPCPORT=${MOUNTD_RPCPORT:=$[ 21111 + $NFS_INSTANCE ]}
# rpc.nfsd RPC port
-NFSD_RPCPORT=$[ 11111 + $NFS_INSTANCE ]
+NFSD_RPCPORT=${NFSD_RPCPORT:=$[ 11111 + $NFS_INSTANCE ]}
# NFS server port number
-NFSD_PORT=$[ 3049 + 2 * $NFS_INSTANCE ]
+NFSD_PORT=${NFSD_PORT:=$[ 3049 + 2 * $NFS_INSTANCE ]}
# mountd port number
-MOUNTD_PORT=$[ 3048 + 2 * $NFS_INSTANCE ]
+MOUNTD_PORT=${MOUNTD_PORT:=$[ 3048 + 2 * $NFS_INSTANCE ]}
## For debugging you would additionally add
## --debug all
@@ -109,7 +109,7 @@ case "$1" in
fi
echo "Creating exports file..."
- echo "$NFS_EXPORT_DIR (rw,async,no_root_squash,no_all_squash,insecure)" > $EXPORTS
+ echo "$NFS_EXPORT_DIR (rw,no_root_squash,no_all_squash,insecure)" > $EXPORTS
echo "Starting User Mode nfsd"
echo " $PSEUDO $PSEUDO_OPTS $OECORE_NATIVE_SYSROOT/usr/bin/unfsd $UNFSD_OPTS"
--
2.9.0
^ permalink raw reply related
* Re: [PATCH] devtool: execute associated functions while preparing the source tree
From: Jiajie Hu @ 2016-11-29 7:37 UTC (permalink / raw)
To: Christopher Larson; +Cc: Patches and discussions about the oe-core layer
In-Reply-To: <CABcZANmmXvVNTiozc_y-i+efy7JZGphPezgbBRS8fZKfdtYnVA@mail.gmail.com>
On Monday, November 28, 2016 11:04:40 PM Christopher Larson wrote:
> This will do the commit after the first postfunc is done, so won’t the
> changes from the main func and the first postfunc both be included in that
> commit?
I suppose all changes from the main func have already been committed in
exec_func. As an example, `devtool modify x11vnc`, where x11vnc comes from
meta-oe, seems to work as expected.
^ permalink raw reply
* Re: ✗ patchtest: failure for Fixes for eSDK and testsdkext
From: Robert Yang @ 2016-11-29 7:38 UTC (permalink / raw)
To: Burton, Ross, OE-core; +Cc: Lock, Joshua G, Paul Eggleton
In-Reply-To: <CAJTo0LYTbP3h5T+YEMiESUCwq0YM6QXtj5+_nr0ZWMH1Z3mhNQ@mail.gmail.com>
On 11/17/2016 05:02 PM, Burton, Ross wrote:
>
> On 17 November 2016 at 06:55, Patchwork <patchwork@patchwork.openembedded.org
> <mailto:patchwork@patchwork.openembedded.org>> wrote:
>
> * Patch [7/8] oeqa/sdkext/devtool.py: skip
> test_extend_autotools_recipe_creation when no libxml2
> Issue Commit shortlog is too long [test_shortlog_length]
> Suggested fix Edit shortlog so that it is 80 characters or less
> (currently 82 characters)
>
>
> I'm not sure we've ever been super-strict on this, so I'm wondering if warning
> over 90 is sensible so that we allow an extra two characters when function names
> are long but still detect when someone has put an essay in the first line (which
> does happen if the submitter isn't aware of the git convention).
Ping, do I have to make the subject line shorter and resend the patches, please ?
// Robert
>
> Ross
>
>
^ permalink raw reply
* Re: Kernel: Builds use old version of defconfig
From: Mike Looijmans @ 2016-11-29 7:58 UTC (permalink / raw)
To: Khem Raj, Bruce Ashfield; +Cc: Patches and discussions about the oe-core layer
In-Reply-To: <B3A9B210-3501-47BB-8B16-CC31C7A4BCC5@gmail.com>
On 29-11-16 03:03, Khem Raj wrote:
>
>> On Nov 24, 2016, at 5:55 AM, Bruce Ashfield <bruce.ashfield@gmail.com
>> <mailto:bruce.ashfield@gmail.com>> wrote:
>>
>>
>>
>> On Thu, Nov 24, 2016 at 5:32 AM, Mike Looijmans <mike.looijmans@topic.nl
>> <mailto:mike.looijmans@topic.nl>> wrote:
>>
>> On 24-11-16 11:10, Mike Looijmans wrote:
>>
>> I'm currently experiencing a problem with "defconfig" files and the
>> kernel.
>>
>> In short, when I make a change to the "defconfig" file, the kernel
>> is rebuilt
>> (which is correct), but the resulting kernel has been built using
>> the old
>> defconfig from a previous build, instead of the new one.
>>
>> The kernel recipe just contains "file://defconfig" in its SRC_URI. The
>> defconfig file is in the project's overlay.
>>
>> For example, I have a kernel with "CONFIG_DEVMEM" disabled:
>>
>> # gunzip < /proc/config.gz | grep DEVMEM
>> # CONFIG_DEVMEM is not set
>>
>> Now, I change the defconfig to contain CONFIG_DEVMEM=y and build the
>> image.
>> The result:
>>
>> # gunzip < /proc/config.gz | grep DEVMEM
>> # CONFIG_DEVMEM is not set
>>
>> So the change did not make it into the actual kernel, even though
>> the kernel
>> was rebuild as a result of the change.
>>
>> I run "bitbake -c cleansstate virtual/kernel" and build the image again:
>>
>> # gunzip < /proc/config.gz | grep DEVMEM
>> CONFIG_DEVMEM=y
>>
>> After cleaning, the result is correct and the new defconfig is active.
>>
>> I'm trying to figure out how this can happen, any help is welcome...
>>
>>
>> What seems to be the problem is this code in kernel.bbclass:
>>
>> # Copy defconfig to .config if .config does not exist. This allows
>> # recipes to manage the .config themselves in
>> do_configure_prepend().
>> if [ -f "${WORKDIR}/defconfig" ] && [ ! -f "${B}/.config" ]; then
>> cp "${WORKDIR}/defconfig" "${B}/.config"
>> fi
>>
>> This keeps any existing ".config" file if it happens to still be in the
>> $B path, which is the case if you're rebuilding a kernel.
>>
>> I see two possible ways to fix this.
>>
>> 1) During "cleanup" also remove the .config file in the build dir.
>> However, the build dir is probably kept alive for a reason? I also can't
>> figure out how that "cleanup" is being done.
>>
>>
>> 2) Remove the second part of the "if" statement, so it becomes:
>>
>> # Copy defconfig to .config if "defconfig" exists. This allows
>> # recipes to manage the .config themselves in
>> do_configure_prepend().
>> if [ -f "${WORKDIR}/defconfig" ]; then
>> cp "${WORKDIR}/defconfig" "${B}/.config"
>> fi
>>
>> I've tested that, and it solves my problem. However, it will probably
>> break other people's config mangling?
>>
>>
>> Yep, in particular all the fragment processing which has the capability of
>> starting
>> with a defconfig and then apply fragments from any number of other places. When
>> that task completes, a full .config is in ${B}. If that statement comes
>> along and
>> clobbers the .config …
>
> so you either assume that .config is valid once generated or you dont. When a
> configure task
> is triggered it should recreate .config everytime.
The problem seems to be that the class "do_configure" does things that should
happen before and after things that the recipe would want to change.
Copying defconfig or whatever means to create a .config should be first.
Next, the specific kernel recipe would want to mangle that configuration to
suit its needs, like applying fragments and such.
Then the makeoldconfig (or whatever) task should run.
The current system assumes that the kernel recipe creates a
do_configure_prepend to do the mangling, which is rather counterintuitive, one
would expect to "append" extra actions.
A structured approach would be to split the do_configure into two parts that
should run in sequence, and then kernel recipes can inject their actions by
appending to them as they see fit. The first task would create the .config
file by (forcibly) copying any defconfig or starting point. The second task
would call the kernel's make script to futher process it.
But this too would break existing recipes.
>>
>> I'm actually working in the 2.3 release cycle to make the fragment processing
>> be available to all kernels, which will likely solve this problem .. but we
>> can't
>> wait for that.
>>
>> So I'm hoping that there's a way to make the behaviour cover both use cases.
>>
>> Maybe someone with more bitbake knowledge can point out a way that can
>> detect if the task is being run due to a change in the task signature.
>>
>> Since if you've modified the defconfig, the task is being re-run for that change
>> and at that point we could safely remove the .config (versus forcing it on the
>> clean step).
Kind regards,
Mike Looijmans
System Expert
TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijmans@topicproducts.com
Website: www.topicproducts.com
Please consider the environment before printing this e-mail
^ permalink raw reply
* Re: [PATCH V2] scripts.send-pull-request: Avoid multiple chain headers
From: Patrick Ohly @ 2016-11-29 8:51 UTC (permalink / raw)
To: Jose Lamego; +Cc: openembedded-core
In-Reply-To: <e4228247-306f-2fd6-6ba8-1c4e01e11a28@linux.intel.com>
On Mon, 2016-11-28 at 16:35 -0600, Jose Lamego wrote:
>
> On 11/28/2016 03:34 PM, Patrick Ohly wrote:
> > On Mon, 2016-11-28 at 14:28 -0600, Jose Lamego wrote:
> >> Agree. Please provide feedback about below comments and I will submit a
> >> v3 patch.
> >>
> >> On 11/28/2016 01:47 PM, Patrick Ohly wrote:
> >>> On Mon, 2016-11-28 at 10:23 -0600, Jose Lamego wrote:
> >> More than 1 "In-Reply-To" and "References" message headers are in
> >> violation of rfc2822 [1] and may cause that some email-related
> >> applications do not point to the appropriate root message in a
> >> conversation/series.
> >
> > Fixing that makes sense. Just add it as reason and the "why" part is
> > covered.
> >
> >>> And I don't understand why this proposed change has the described
> >>> effect. Does changing the threading parameters change the output of "git
> >>> send-email" and thus indirectly the mail headers of the following
> >>> patches?
> >
> > The "how" part still isn't clear to me. Perhaps I'm just dumb, but would
> > you bear with me and explain a bit more how changing the sending of the
> > cover letter affects sending of the patches?
I've tried out your proposed change with
bash -x ../poky/scripts/send-pull-request --to=patrick.ohly@gmx.de -p pull-11827
where pull-11827 is my recent bitbake submission.
The resulting emails are still broken because that one line that you
modify isn't event used. It's under "if [ $AUTO_CL -eq 1 ]" and I am not
using the -a option that enables that behavior.
Even when I use -a, the result is still broken.
The root cause of the problem is that both create-pull-request and
send-pull-request allow git to insert In-Reply-To headers.
"git send-email --help" explicitly warns about that:
It is up to the user to ensure that no In-Reply-To header already exists when git send-email is asked
to add it (especially note that git format-patch can be configured to do the threading itself). Failure
to do so may not produce the expected result in the recipient’s MUA.
> What I'm doing
> here is to include no reference to any root message at the first call,
> then including a reference at the second call to the very first message
> in the chain, which is either the cover letter or the patch #1.
No, that doesn't work. Whether the first call uses --no-thread or
--no-chain-reply-to has no effect whatsoever, because when "git
send-email" only sends a single email, it doesn't add headers, and the
second call was left unmodified in your patch.
The right fix (tested successfully here) is to use --no-thread in the
second call which sends the sequence of patches. I'll send my change
for review separately.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
^ permalink raw reply
* [PATCH V3] scripts/send-pull-request: Avoid multiple chain headers
From: Patrick Ohly @ 2016-11-29 8:55 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <1480409468.6873.232.camel@intel.com>
When creating a patch set with cover letter using the
send-pull-request script, both the "In-Reply-To" and "References"
headers are appended twice in patch 2 and subsequent.
That's because git-format-patch already inserted them and then
git-send-email repeats that. Suppressing mail threading in
git-send-email with --no-thread avoids the problem and is the
right solution because it works regardless whether git-send-email is
called once or twicee.
Repeating these headers is a violation of RFC 2822 and can confuse
mail programs. For example, Patchwork does not detect a patch series
problem when there are these extra headers.
[YOCTO #10718]
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
---
scripts/send-pull-request | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/scripts/send-pull-request b/scripts/send-pull-request
index 575549d..883deac 100755
--- a/scripts/send-pull-request
+++ b/scripts/send-pull-request
@@ -158,11 +158,16 @@ GIT_EXTRA_CC=$(for R in $EXTRA_CC; do echo -n "--cc='$R' "; done)
unset IFS
# Handoff to git-send-email. It will perform the send confirmation.
+# Mail threading was already handled by git-format-patch in
+# create-pull-request, so we must not allow git-send-email to
+# add In-Reply-To and References headers again.
PATCHES=$(echo $PDIR/*.patch)
if [ $AUTO_CL -eq 1 ]; then
# Send the cover letter to every recipient, both specified as well as
# harvested. Then remove it from the patches list.
- eval "git send-email $GIT_TO $GIT_CC $GIT_EXTRA_CC --confirm=always --no-chain-reply-to --suppress-cc=all $CL"
+ # --no-thread is redundant here (only sending a single message) and
+ # merely added for the sake of consistency.
+ eval "git send-email $GIT_TO $GIT_CC $GIT_EXTRA_CC --confirm=always --no-thread --suppress-cc=all $CL"
if [ $? -eq 1 ]; then
echo "ERROR: failed to send cover-letter with automatic recipients."
exit 1
@@ -172,7 +177,7 @@ fi
# Send the patch to the specified recipients and, if -c was specified, those git
# finds in this specific patch.
-eval "git send-email $GIT_TO $GIT_EXTRA_CC --confirm=always --no-chain-reply-to $GITSOBCC $PATCHES"
+eval "git send-email $GIT_TO $GIT_EXTRA_CC --confirm=always --no-thread $GITSOBCC $PATCHES"
if [ $? -eq 1 ]; then
echo "ERROR: failed to send patches."
exit 1
--
2.1.4
^ permalink raw reply related
* Re: ✗ patchtest: failure for Fixes for eSDK and testsdkext
From: Paul Eggleton @ 2016-11-29 9:10 UTC (permalink / raw)
To: Robert Yang; +Cc: Lock, Joshua G, OE-core
In-Reply-To: <bdecee11-e5f5-d34d-fb09-f247dfb460d6@windriver.com>
On Tue, 29 Nov 2016 15:38:50 Robert Yang wrote:
> On 11/17/2016 05:02 PM, Burton, Ross wrote:
> > On 17 November 2016 at 06:55, Patchwork
> > <patchwork@patchwork.openembedded.org>
> > <mailto:patchwork@patchwork.openembedded.org>> wrote:
> > * Patch [7/8] oeqa/sdkext/devtool.py: skip
> > test_extend_autotools_recipe_creation when no libxml2
> >
> > Issue Commit shortlog is too long [test_shortlog_length]
> > Suggested fix Edit shortlog so that it is 80 characters or less
> >
> > (currently 82 characters)
> >
> > I'm not sure we've ever been super-strict on this, so I'm wondering if
> > warning over 90 is sensible so that we allow an extra two characters when
> > function names are long but still detect when someone has put an essay in
> > the first line (which does happen if the submitter isn't aware of the git
> > convention).
>
> Ping, do I have to make the subject line shorter and resend the patches,
> please ?
No, no need to do that.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox