Re: [OE-core] Kernel: Builds use old version of defconfig

2016-11-29 Thread Mike Looijmans

On 29-11-16 03:03, Khem Raj wrote:



On Nov 24, 2016, at 5:55 AM, Bruce Ashfield mailto:bruce.ashfi...@gmail.com>> wrote:



On Thu, Nov 24, 2016 at 5:32 AM, Mike Looijmans mailto:mike.looijm...@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.looijm...@topicproducts.com
Website: www.topi

Re: [OE-core] [PATCH V2] scripts.send-pull-request: Avoid multiple chain headers

2016-11-29 Thread Patrick Ohly
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.o...@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.



-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH V3] scripts/send-pull-request: Avoid multiple chain headers

2016-11-29 Thread Patrick Ohly
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 
---
 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

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] ✗ patchtest: failure for Fixes for eSDK and testsdkext

2016-11-29 Thread Paul Eggleton
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
> >  
> > > wrote:
> > * Patch[7/8] oeqa/sdkext/devtool.py: skip
> > test_extend_autotools_recipe_creation when no libxml2
> > 
> >   IssueCommit shortlog is too long [test_shortlog_length]
> >   Suggested fixEdit 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
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH 0/1] kernel-devsrc: remove symlink source

2016-11-29 Thread Robert Yang
The following changes since commit af280990bff4a484fd8a18e3442b56a0a39b7611:

  Revert "classes/populate_sdk_ext: require uninative" (2016-11-28 14:49:37 
+)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib rbt/kernel
  
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=rbt/kernel

Robert Yang (1):
  kernel-devsrc: remove symlink source

 meta/recipes-kernel/linux/kernel-devsrc.bb | 7 +++
 1 file changed, 7 insertions(+)

-- 
2.9.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH 1/1] kernel-devsrc: remove symlink source

2016-11-29 Thread Robert Yang
Fixed:
$ rpm -qplv tmp/deploy/rpm/qemuppc/kernel-devsrc-1.0-r0.qemuppc.rpm | grep 
kernel/source
/usr/src/kernel/source -> 
/buildarea/lyang1/test_yocto/tmp/work/qemuppc-poky-linux/kernel-devsrc/1.0-r0/image/usr/src/kernel

It is generated by kernel's "make clean _mrproper_scripts", the
kernel-devsrc includeds full sources, this symlink is not needed, and
the path is invalid on target, so remove it.

Signed-off-by: Robert Yang 
---
 meta/recipes-kernel/linux/kernel-devsrc.bb | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/meta/recipes-kernel/linux/kernel-devsrc.bb 
b/meta/recipes-kernel/linux/kernel-devsrc.bb
index 9fd2e08..b182936 100644
--- a/meta/recipes-kernel/linux/kernel-devsrc.bb
+++ b/meta/recipes-kernel/linux/kernel-devsrc.bb
@@ -53,6 +53,13 @@ do_install() {
 # architecture (since scripts and helpers are native format).
 KBUILD_OUTPUT="$kerneldir"
 oe_runmake -C $kerneldir CC="${KERNEL_CC}" LD="${KERNEL_LD}" clean 
_mrproper_scripts
+# make clean generates an absolute path symlink called "source"
+# in $kerneldir points to $kerneldir, which doesn't make any
+# sense, so remove it.
+if [ -L $kerneldir/source ]; then
+bbnote "Removing $kerneldir/source"
+rm -f $kerneldir/source
+fi
 
 # As of Linux kernel version 3.0.1, the clean target removes
 # arch/powerpc/lib/crtsavres.o which is present in
-- 
2.9.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH][krogoth] bs4: fix bitbake build error with latest html5lib version

2016-11-29 Thread Enrico Jorns
Since the 0.9 release of python-html5lib, the module
`treewalkers._base` was changed to `treewalkers.base` (without
underscore). This breaks bitbake is it uses the old module name.

|   [...]
|   File "[...]/bitbake/lib/bs4/builder/_html5lib.py", line 57, in 
|   class TreeBuilderForHtml5lib(html5lib.treebuilders._base.TreeBuilder):
| AttributeError: 'module' object has no attribute '_base'
| [...]/bitbake/lib/bb/event.py:119: RuntimeWarning: Parent module 'bb' not 
found while handling absolute import

This patch renames all occurrences of the `_base` module to `base`.

Note that this patch will break builds with older versions of
python-html5lib.

Signed-off-by: Enrico Jorns 
---
 bitbake/lib/bs4/builder/_html5lib.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/bitbake/lib/bs4/builder/_html5lib.py 
b/bitbake/lib/bs4/builder/_html5lib.py
index 7de36ae..529ce5a 100644
--- a/bitbake/lib/bs4/builder/_html5lib.py
+++ b/bitbake/lib/bs4/builder/_html5lib.py
@@ -54,7 +54,7 @@ class HTML5TreeBuilder(HTMLTreeBuilder):
 return u'%s' % fragment
 
 
-class TreeBuilderForHtml5lib(html5lib.treebuilders._base.TreeBuilder):
+class TreeBuilderForHtml5lib(html5lib.treebuilders.base.TreeBuilder):
 
 def __init__(self, soup, namespaceHTMLElements):
 self.soup = soup
@@ -115,7 +115,7 @@ class AttrList(object):
 return name in list(self.attrs.keys())
 
 
-class Element(html5lib.treebuilders._base.Node):
+class Element(html5lib.treebuilders.base.Node):
 def __init__(self, element, soup, namespace):
 html5lib.treebuilders._base.Node.__init__(self, element.name)
 self.element = element
-- 
2.10.2

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH 5/5] runqemu: set default device and hostfwd for slirp

2016-11-29 Thread Nathan Rossi
On 29 November 2016 at 17:35, Robert Yang  wrote:
> There is no network rather than lo whitout set device, so set it by
> default. And set hostfwd:  -> 22, 2323 -> 23
>
> [YOCTO #7887]
>
> Signed-off-by: Robert Yang 
> ---
>  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::-: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::-: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]

Should runqemu not just always supply "-netdev user,id=net0..." itself
for slirp. And qemuboot should supply only the devices, e.g. the "-dev
virtio-net-pci,netdev=net0" or "-net nic,netdev=net0". This could even
allow for consolidation of the "QB_SLIRP_OPT" and "QB_TAP_OPT" into
"QB_NETWORK".

This way runqemu would not need to do any searching/substitution and
could just build the user netdev arg itself. This would allow for easy
extension of custom forwards (e.g gdbserver, etc), and also even
setting up the in qemu user/slirp 'tftp=' server.

> +# 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):

Should this be 'localhost', since 127.0.0.1 will only check for ipv4 listeners.

Regards,
Nathan

> +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
>
>

Re: [OE-core] [PATCH 5/5] runqemu: set default device and hostfwd for slirp

2016-11-29 Thread Nathan Rossi
On 29 November 2016 at 19:38, Nathan Rossi  wrote:
> On 29 November 2016 at 17:35, Robert Yang  wrote:
>> There is no network rather than lo whitout set device, so set it by
>> default. And set hostfwd:  -> 22, 2323 -> 23
>>
>> [YOCTO #7887]
>>
>> Signed-off-by: Robert Yang 
>> ---
>>  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::-: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::-: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]
>
> Should runqemu not just always supply "-netdev user,id=net0..." itself
> for slirp. And qemuboot should supply only the devices, e.g. the "-dev
> virtio-net-pci,netdev=net0" or "-net nic,netdev=net0". This could even
> allow for consolidation of the "QB_SLIRP_OPT" and "QB_TAP_OPT" into
> "QB_NETWORK".

Just saw this patch was an updated version of
https://patchwork.openembedded.org/patch/134399/ which was doing
similar to what I suggested above. (I read this patch before the other
one linked)

Maybe QB_SLIRP_OPT and QB_TAP_OPT should provide overrides for the
-netdev user/tap, and if a BSP/etc needs to overwrite them it can. But
the "-net"/"-device" is provided as a separate QB_NETWORK variable.
This would allow for BSPs to take advantage of the default netdev
user/tap args that runqemu provides without needing to specify any of
the forwards/etc. And would also allow for backwards compatibility
with current BSP QB_* setups.

Regards,
Nathan

>
> This way runqemu would not need to do any searching/substitution and
> could just build the user netdev arg itself. This would allow for easy
> extension of custom forwards (e.g 

[OE-core] [PATCH] qemu: Fix pci-assign

2016-11-29 Thread zhe.he
From: He Zhe 

Fix iommu pci device assignment failure.

"qemu-system-x86_64: -device pci-assign,host=02:00.0: No IOMMU found.
Unable to assign device "(null)""

Signed-off-by: He Zhe 
---
 ...sync-MSI-MSI-X-cap-and-table-with-PCIDevi.patch | 71 ++
 meta/recipes-devtools/qemu/qemu_2.7.0.bb   |  1 +
 2 files changed, 72 insertions(+)
 create mode 100644 
meta/recipes-devtools/qemu/qemu/0001-pci-assign-sync-MSI-MSI-X-cap-and-table-with-PCIDevi.patch

diff --git 
a/meta/recipes-devtools/qemu/qemu/0001-pci-assign-sync-MSI-MSI-X-cap-and-table-with-PCIDevi.patch
 
b/meta/recipes-devtools/qemu/qemu/0001-pci-assign-sync-MSI-MSI-X-cap-and-table-with-PCIDevi.patch
new file mode 100644
index 000..03472dd
--- /dev/null
+++ 
b/meta/recipes-devtools/qemu/qemu/0001-pci-assign-sync-MSI-MSI-X-cap-and-table-with-PCIDevi.patch
@@ -0,0 +1,71 @@
+From 6baa545df93253fced4fc0d52b14b98447e00473 Mon Sep 17 00:00:00 2001
+From: Peter Xu 
+Date: Mon, 28 Nov 2016 15:02:44 +0800
+Subject: [PATCH] pci-assign: sync MSI/MSI-X cap and table with PCIDevice
+
+Since commit e1d4fb2d ("kvm-irqchip: x86: add msi route notify fn"),
+kvm_irqchip_add_msi_route() starts to use pci_get_msi_message() to fetch
+MSI info. This requires that we setup MSI related fields in PCIDevice.
+For most devices, that won't be a problem, as long as we are using
+general interfaces like msi_init()/msix_init().
+
+However, for pci-assign devices, MSI/MSI-X is treated differently - PCI
+assign devices are maintaining its own MSI table and cap information in
+AssignedDevice struct. however that's not synced up with PCIDevice's
+fields. That will leads to pci_get_msi_message() failed to find correct
+MSI capability, even with an NULL msix_table.
+
+A quick fix is to sync up the two places: both the capability bits and
+table address for MSI/MSI-X.
+
+Upstream-Status: Backport 
[https://lists.gnu.org/archive/html/qemu-devel/2016-11/msg04649.html]
+
+Reported-by: Changlimin 
+Tested-by: Changlimin 
+Cc: address@hidden
+Fixes: e1d4fb2d ("kvm-irqchip: x86: add msi route notify fn")
+Signed-off-by: Peter Xu 
+Signed-off-by: He Zhe 
+---
+ hw/i386/kvm/pci-assign.c | 4 
+ 1 file changed, 4 insertions(+)
+
+diff --git a/hw/i386/kvm/pci-assign.c b/hw/i386/kvm/pci-assign.c
+index 8238fbc..87dcbdd 100644
+--- a/hw/i386/kvm/pci-assign.c
 b/hw/i386/kvm/pci-assign.c
+@@ -1251,6 +1251,7 @@ static int assigned_device_pci_cap_init(PCIDevice 
*pci_dev, Error **errp)
+ error_propagate(errp, local_err);
+ return -ENOTSUP;
+ }
++dev->dev.cap_present |= QEMU_PCI_CAP_MSI;
+ dev->cap.available |= ASSIGNED_DEVICE_CAP_MSI;
+ /* Only 32-bit/no-mask currently supported */
+ ret = pci_add_capability2(pci_dev, PCI_CAP_ID_MSI, pos, 10,
+@@ -1285,6 +1286,7 @@ static int assigned_device_pci_cap_init(PCIDevice 
*pci_dev, Error **errp)
+ error_propagate(errp, local_err);
+ return -ENOTSUP;
+ }
++dev->dev.cap_present |= QEMU_PCI_CAP_MSIX;
+ dev->cap.available |= ASSIGNED_DEVICE_CAP_MSIX;
+ ret = pci_add_capability2(pci_dev, PCI_CAP_ID_MSIX, pos, 12,
+   &local_err);
+@@ -1648,6 +1650,7 @@ static void 
assigned_dev_register_msix_mmio(AssignedDevice *dev, Error **errp)
+ dev->msix_table = NULL;
+ return;
+ }
++dev->dev.msix_table = (uint8_t *)dev->msix_table;
+ 
+ assigned_dev_msix_reset(dev);
+ 
+@@ -1665,6 +1668,7 @@ static void 
assigned_dev_unregister_msix_mmio(AssignedDevice *dev)
+ error_report("error unmapping msix_table! %s", strerror(errno));
+ }
+ dev->msix_table = NULL;
++dev->dev.msix_table = NULL;
+ }
+ 
+ static const VMStateDescription vmstate_assigned_device = {
+-- 
+2.8.3
+
diff --git a/meta/recipes-devtools/qemu/qemu_2.7.0.bb 
b/meta/recipes-devtools/qemu/qemu_2.7.0.bb
index cef181d..9da5134 100644
--- a/meta/recipes-devtools/qemu/qemu_2.7.0.bb
+++ b/meta/recipes-devtools/qemu/qemu_2.7.0.bb
@@ -13,6 +13,7 @@ SRC_URI += 
"file://configure-fix-Darwin-target-detection.patch \
 file://0002-fix-CVE-2016-7423.patch \
 file://0003-fix-CVE-2016-7908.patch \
 file://0004-fix-CVE-2016-7909.patch \
+
file://0001-pci-assign-sync-MSI-MSI-X-cap-and-table-with-PCIDevi.patch \
 "
 
 SRC_URI_prepend = "http://wiki.qemu-project.org/download/${BP}.tar.bz2";
-- 
2.8.3

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH 5/5] runqemu: set default device and hostfwd for slirp

2016-11-29 Thread Robert Yang



On 11/29/2016 05:38 PM, Nathan Rossi wrote:

On 29 November 2016 at 17:35, Robert Yang  wrote:

There is no network rather than lo whitout set device, so set it by
default. And set hostfwd:  -> 22, 2323 -> 23

[YOCTO #7887]

Signed-off-by: Robert Yang 
---
 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::-: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::-: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]


Should runqemu not just always supply "-netdev user,id=net0..." itself
for slirp. And qemuboot should supply only the devices, e.g. the "-dev
virtio-net-pci,netdev=net0" or "-net nic,netdev=net0". This could even


The problem is if runqemu only uses the part "-dev virtio-net-pci,netdev=net0",
and QB_SLIRP_OPT doesn't replace it, then the bsp,conf can't custom freely,
for example, its bsp may not support "-dev virtio-net-pci", then it would
cause troubles. So if bsp.conf wants to redfine the options, manage
the full options is better than part of them.



allow for consolidation of the "QB_SLIRP_OPT" and "QB_TAP_OPT" into
"QB_NETWORK".

This way runqemu would not need to do any searching/substitution and


The searching/substitution is still needed, suppose you defined something
like: hostfwd=tcp::-:22 in bsp.conf, then they will go into qemuboot.conf,
and it would fail when you run more than one qemu targets since the port
is used by the first running qemu.


could just build the user netdev arg itself. This would allow for easy
extension of custom forwards (e.g gdbserver, etc), and also even
setting up the in qemu user/slirp 'tftp=' server.


+# 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):


Should this be 'localhost', since 127.0.0.1 will only check for ipv4 liste

Re: [OE-core] [PATCH 5/5] runqemu: set default device and hostfwd for slirp

2016-11-29 Thread Robert Yang



On 11/29/2016 05:54 PM, Nathan Rossi wrote:

On 29 November 2016 at 19:38, Nathan Rossi  wrote:

On 29 November 2016 at 17:35, Robert Yang  wrote:

There is no network rather than lo whitout set device, so set it by
default. And set hostfwd:  -> 22, 2323 -> 23

[YOCTO #7887]

Signed-off-by: Robert Yang 
---
 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::-: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::-: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]


Should runqemu not just always supply "-netdev user,id=net0..." itself
for slirp. And qemuboot should supply only the devices, e.g. the "-dev
virtio-net-pci,netdev=net0" or "-net nic,netdev=net0". This could even
allow for consolidation of the "QB_SLIRP_OPT" and "QB_TAP_OPT" into
"QB_NETWORK".


Just saw this patch was an updated version of
https://patchwork.openembedded.org/patch/134399/ which was doing
similar to what I suggested above. (I read this patch before the other
one linked)

Maybe QB_SLIRP_OPT and QB_TAP_OPT should provide overrides for the
-netdev user/tap, and if a BSP/etc needs to overwrite them it can. But
the "-net"/"-device" is provided as a separate QB_NETWORK variable.
This would allow for BSPs to take advantage of the default netdev
user/tap args that runqemu provides without needing to specify any of
the forwards/etc. And would also allow for backwards compatibility
with current BSP QB_* setups.


Hi Nathan,

I have to go now, will reply later after more thinking.

// Robert



Regards,
Nathan



This way runqemu would not need to do any searching/substitution and
could just build the user netdev arg itself. This would allow for easy
extension of custom forwards (e.g gdbserver, etc), and also even
setting up the in qemu user/slirp 'tftp=' server.


+# Find a free port to avoid conflicts
+fo

Re: [OE-core] [PATCH 0/4] Persistent /var/log support

2016-11-29 Thread Jack Mitchell



On 22/11/16 10:10, Chen Qi wrote:

The following changes since commit a675b2c89e477af088faee9b3be96eae19a85f0b:

  sanity.bbclass: fix logging of an error (2016-11-15 15:18:50 +)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib ChenQi/persistent-var-log
  
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=ChenQi/persistent-var-log

Chen Qi (4):
  bitbake.conf: add VOLATILE_LOG_DIR variable
  base-files: respect VOLATILE_LOG_DIR
  initscripts: support persistent /var/log
  package.bbclass: support persistent /var/log

 meta/classes/package.bbclass   |  2 +-
 meta/conf/bitbake.conf |  3 +
 meta/files/fs-perms-persistent-log.txt | 69 ++
 meta/recipes-core/base-files/base-files_3.0.14.bb  |  4 +-
 .../initscripts/initscripts-1.0/volatiles  |  1 -
 meta/recipes-core/initscripts/initscripts_1.0.bb   |  3 +
 6 files changed, 78 insertions(+), 4 deletions(-)
 create mode 100644 meta/files/fs-perms-persistent-log.txt



Ack from me, I don't know if this is the best way to do it, but it is 
way way way too hard to get persistent logging in OE. I've had to 
implement it in numerous ways, multiple times over the past few years 
and it shouldn't be that hard.

--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] ASSUME_PROVIDED versus SANITY_REQUIRED_UTILITIES versus "The Build Host Packages"

2016-11-29 Thread Robert P. J. Day
On Mon, 28 Nov 2016, Richard Purdie wrote:

> On Mon, 2016-11-28 at 06:20 -0500, Robert P. J. Day wrote:
> >   a bit confused by what i'm seeing in a recent
> > qemuppc/core-image-minimal build on my fedora system regarding which
> > native packages are built, despite what's in bitbake.conf (using
> > current poky layer checkout).
> >
> >   first, here's a snippet from bitbake.conf:
> >
> >   ASSUME_PROVIDED = "\
> > bzip2-native \  <---
> > chrpath-native \
> > file-native \   <---
> > findutils-native \
> > git-native \
> > grep-native \
> > diffstat-native \
> > ... snip ...
> >
> > suggesting that (among other things) bzip2-native and file-native
> > shouldn't be built -- it's the developer's responsibility to install
> > them, yes? but if i peek under tmp/work/x86_64-linux, i can see:
>
> There are two ways "file-native" can be used in a build. It can be
> used as the host provided "file" command and it is also needed by
> the file recipe to build file for the target. We need to build
> file-native in order for the build for the target file command to
> build/work. This is why it gets built.
>
> With bzip2, we need libbz2 (native) during the build process and we
> don't ASSUME_PROVIDED libbz2-devel, hence it builds bzip2-native
> only for that piece. Confusing perhaps but necessary unfortunately.

  ah, gotcha ... so in cases like that, even if a recipe needs to be
*partially* built for libraries, that in no way affects the
ASSUME_PROVIDED setting, correct? as in, once I ASSUME_PROVIDED
"bzip2-native", then that *better* exist on my build host, correct?

rday

P.S. there is still some lack of sync amongst:

  * ASSUME_PROVIDED
  * sanity.bbclass
  * YP quick start guide

one example i mentioned is that the YP guide does not list "sed" as a
build host requirement, but "sed-native" is in ASSUME_PROVIDED;
however, it's not listed in SANITY_REQUIRED_UTILITIES. that seems
inconsistent.

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH 1/1] kernel-devsrc: remove symlink source

2016-11-29 Thread Bruce Ashfield
On Tue, Nov 29, 2016 at 4:16 AM, Robert Yang 
wrote:

> Fixed:
> $ rpm -qplv tmp/deploy/rpm/qemuppc/kernel-devsrc-1.0-r0.qemuppc.rpm |
> grep kernel/source
> /usr/src/kernel/source -> /buildarea/lyang1/test_yocto/
> tmp/work/qemuppc-poky-linux/kernel-devsrc/1.0-r0/image/usr/src/kernel
>
> It is generated by kernel's "make clean _mrproper_scripts", the
> kernel-devsrc includeds full sources, this symlink is not needed, and
> the path is invalid on target, so remove it.
>
> Signed-off-by: Robert Yang 
> ---
>  meta/recipes-kernel/linux/kernel-devsrc.bb | 7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/meta/recipes-kernel/linux/kernel-devsrc.bb
> b/meta/recipes-kernel/linux/kernel-devsrc.bb
> index 9fd2e08..b182936 100644
> --- a/meta/recipes-kernel/linux/kernel-devsrc.bb
> +++ b/meta/recipes-kernel/linux/kernel-devsrc.bb
> @@ -53,6 +53,13 @@ do_install() {
>  # architecture (since scripts and helpers are native format).
>  KBUILD_OUTPUT="$kerneldir"
>  oe_runmake -C $kerneldir CC="${KERNEL_CC}" LD="${KERNEL_LD}"
> clean _mrproper_scripts
> +# make clean generates an absolute path symlink called "source"
> +# in $kerneldir points to $kerneldir, which doesn't make any
> +# sense, so remove it.
> +if [ -L $kerneldir/source ]; then
> +bbnote "Removing $kerneldir/source"
>

This message needs to be clarified. When that comes out, I'd read it and
think
"it is removing my kernel source".

Maybe:

 bbnote "Removing $kerneldir/source symlink"

is better.

Bruce


> +rm -f $kerneldir/source
> +fi
>
>  # As of Linux kernel version 3.0.1, the clean target removes
>  # arch/powerpc/lib/crtsavres.o which is present in
> --
> 2.9.0
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> 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
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] ASSUME_PROVIDED versus SANITY_REQUIRED_UTILITIES versus "The Build Host Packages"

2016-11-29 Thread Burton, Ross
On 29 November 2016 at 10:47, Robert P. J. Day 
wrote:

> one example i mentioned is that the YP guide does not list "sed" as a
> build host requirement, but "sed-native" is in ASSUME_PROVIDED;
> however, it's not listed in SANITY_REQUIRED_UTILITIES. that seems
> inconsistent.
>

It would be somewhat useful if there where a way to annotate in recipes
what binary to check for on the host, so just doing
ASSUME_PROVIDED=sed-native would look up in the sed recipe to check that
"sed" exists on the host, so that SANITY_REQUIRED_UTILITIES doesn't need to
be maintained separately.

Very low hanging fruit though.  Patches welcome!

Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH] buildhistory-diff: report directory renames

2016-11-29 Thread Alexander Kanavin

On 11/28/2016 07:28 PM, Ed Bartosh wrote:

The script detects directory renaming if two different
directories with the same set of files are added and removed.


What happens if the sets of files are slightly different? (e.g. a couple 
of files are added or removed). Can we get some wiggle space here?


Alex

--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH 06/18] cmake: update to 3.7.0

2016-11-29 Thread Alexander Kanavin

On 11/29/2016 01:24 AM, Khem Raj wrote:



On Nov 28, 2016, at 5:34 AM, Alexander Kanavin 
 wrote:

License is still 3-clause BSD.


OK. what triggered the checksum change then ?


They added a contributor list to Copyright.txt (I'll trim the lines that 
are checksummed if that list will be constantly changing), and changed 
the header in cmake.h from


/*
  CMake - Cross Platform Makefile Generator
  Copyright 2000-2009 Kitware, Inc., Insight Software Consortium

  Distributed under the OSI-approved BSD License (the "License");
  see accompanying file Copyright.txt for details.

  This software is distributed WITHOUT ANY WARRANTY; without even the
  implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
  See the License for more information.
*/

to

/* Distributed under the OSI-approved BSD 3-Clause License.  See 
accompanying

   file Copyright.txt or https://cmake.org/licensing for details.  */

Alex

--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH 0/2] Add communication mechanism for sending test results

2016-11-29 Thread mariano . lopez
From: Mariano Lopez 


These changes add a mechanism for sending test result to a remote
repository for later consumption of the data from other clients.

These patches were tested in our local autobuilders.

The following changes since commit 12a0ee049e453b6d0d2ce2f3fa981d1b6e02bd78:

  dev-manual: Added note about RPM not dealing with post-install (2016-11-23 
11:10:35 +)

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib mariano/bug9954
  http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=mariano/bug9954

Mariano Lopez (2):
  oeqa/utils/metadata.py: Add metadata library
  oe-selftest: Add option to submit test result to a git repository.

 meta/lib/oeqa/utils/metadata.py | 77 
 scripts/oe-selftest | 98 +
 2 files changed, 175 insertions(+)
 create mode 100644 meta/lib/oeqa/utils/metadata.py

-- 
2.7.3

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH 1/2] oeqa/utils/metadata.py: Add metadata library

2016-11-29 Thread mariano . lopez
From: Mariano Lopez 

Adds functions to get metadata from the host running the tests.

[YOCTO #9954]

Signed-off-by: Mariano Lopez 
---
 meta/lib/oeqa/utils/metadata.py | 77 +
 1 file changed, 77 insertions(+)
 create mode 100644 meta/lib/oeqa/utils/metadata.py

diff --git a/meta/lib/oeqa/utils/metadata.py b/meta/lib/oeqa/utils/metadata.py
new file mode 100644
index 000..3be805c
--- /dev/null
+++ b/meta/lib/oeqa/utils/metadata.py
@@ -0,0 +1,77 @@
+# Copyright (C) 2016 Intel Corporation
+#
+# Released under the MIT license (see COPYING.MIT)
+#
+# Functions to get metadata from the testing host used
+# for analytics of test results.
+
+from git import Repo
+from collections import OrderedDict
+from collections.abc import MutableMapping
+from xml.dom.minidom import parseString
+from xml.etree.ElementTree import Element, tostring
+
+from oe.lsb import distro_identifier
+from oeqa.utils.commands import runCmd, get_bb_var
+
+def metadata_from_bb():
+""" Returns test's metadata as OrderedDict.
+
+Data will be gathered using bitbake -e thanks to get_bb_var.
+"""
+
+info_dict = OrderedDict()
+hostname = runCmd('hostname')
+info_dict['hostname'] = hostname.output
+info_dict['machine'] = get_bb_var('MACHINE')
+info_dict['distro'] = get_bb_var('DISTRO')
+info_dict['distro_version'] = get_bb_var('DISTRO_VERSION')
+host_distro= distro_identifier()
+host_distro, _, host_distro_release = host_distro.partition('-')
+info_dict['host_distro'] = host_distro
+info_dict['host_distro_release'] = host_distro_release
+info_dict['layers'] = get_layers(get_bb_var('BBLAYERS'))
+return info_dict
+
+def metadata_from_data_store(d):
+""" Returns test's metadata as OrderedDict.
+
+Data will be collected from the provided data store.
+"""
+# TODO: Getting metadata from the data store would
+# be useful when running within bitbake.
+pass
+
+def get_layers(layers):
+""" Returns layer name, branch, and revision as OrderedDict. """
+
+layer_dict = OrderedDict()
+for layer in layers.split():
+layer_name = os.path.basename(layer)
+layer_dict[layer_name] = OrderedDict()
+repo = Repo(layer, search_parent_directories=True)
+revision, branch = repo.head.object.name_rev.split()
+layer_dict[layer_name]['branch'] = branch
+layer_dict[layer_name]['revision'] = revision
+return layer_dict
+
+def write_metadata_file(file_path, metadata):
+""" Writes metadata to a XML file in directory. """
+
+xml = dict_to_XML('metadata', metadata)
+xml_doc = parseString(tostring(xml).decode('UTF-8'))
+with open(file_path, 'w') as f:
+f.write(xml_doc.toprettyxml())
+
+def dict_to_XML(tag, dictionary):
+""" Return XML element converting dicts recursively. """
+
+elem = Element(tag)
+for key, val in dictionary.items():
+if isinstance(val, MutableMapping):
+child = (dict_to_XML(key, val))
+else:
+child = Element(key)
+child.text = str(val)
+elem.append(child)
+return elem
-- 
2.7.3

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH 2/2] oe-selftest: Add option to submit test result to a git repository.

2016-11-29 Thread mariano . lopez
From: Mariano Lopez 

This new option allows to commit the result to a git repository,
along with the results it will add a metadata file for information
of the current selftest run, such as: hostname, machine, distro,
distro version, host version, and layers.

This implementation will have a branch per different hostname,
testing branch, and machine.

To use this feature use:

oe-selftest  --repository 

[YOCTO #9954]

Signed-off-by: Mariano Lopez 
---
 scripts/oe-selftest | 98 +
 1 file changed, 98 insertions(+)

diff --git a/scripts/oe-selftest b/scripts/oe-selftest
index deaa432..81dfa3d 100755
--- a/scripts/oe-selftest
+++ b/scripts/oe-selftest
@@ -36,6 +36,7 @@ import re
 import fnmatch
 import collections
 import imp
+import git
 
 sys.path.insert(0, os.path.dirname(os.path.realpath(__file__)) + '/lib')
 import scriptpath
@@ -46,6 +47,7 @@ import argparse_oe
 import oeqa.selftest
 import oeqa.utils.ftools as ftools
 from oeqa.utils.commands import runCmd, get_bb_var, get_test_layer
+from oeqa.utils.metadata import metadata_from_bb, write_metadata_file
 from oeqa.selftest.base import oeSelfTest, get_available_machines
 
 try:
@@ -106,6 +108,8 @@ def get_args_parser():
help='List all tags that have been set to test cases.')
 parser.add_argument('--machine', required=False, dest='machine', 
choices=['random', 'all'], default=None,
 help='Run tests on different machines (random/all).')
+parser.add_argument('--repository', required=False, dest='repository', 
default='', action='store',
+help='Submit test results to a repository')
 return parser
 
 
@@ -572,6 +576,71 @@ def main():
 
 log.info("Finished")
 
+if args.repository:
+# Commit tests results to repository
+metadata = metadata_from_bb()
+git_dir = os.path.join(os.getcwd(), 'selftest')
+if not os.path.isdir(git_dir):
+os.mkdir(git_dir)
+
+log.debug('Checking for git repository in %s' % git_dir)
+try:
+repo = git.Repo(git_dir)
+except git.exc.InvalidGitRepositoryError:
+log.debug("Couldn't find git repository %s; "
+ "cloning from %s" % (git_dir, args.repository))
+repo = git.Repo.clone_from(args.repository, git_dir)
+
+r_branches = repo.git.branch(r=True)
+r_branches = set(r_branches.replace('origin/', '').split())
+l_branches = {str(branch) for branch in repo.branches}
+branch = '%s/%s/%s' % (metadata['hostname'],
+   metadata['layers']['meta']['branch'],
+   metadata['machine'])
+
+if branch in r_branches:
+log.debug('Found branch in remote repository, checking'
+  ' out and pulling')
+repo.git.checkout(branch)
+repo.git.pull()
+elif branch in l_branches:
+log.debug('Found branch in local repository, checking out')
+repo.git.checkout(branch)
+else:
+log.debug('New branch %s' % branch)
+repo.git.checkout('master')
+repo.git.checkout(b=branch)
+
+cleanResultsDir(repo)
+xml_dir = os.path.join(os.getcwd(), log_prefix)
+copyResultFiles(xml_dir, git_dir, repo)
+metadata_file = os.path.join(git_dir, 'metadata.xml')
+write_metadata_file(metadata_file, metadata)
+repo.index.add([metadata_file])
+repo.index.write()
+
+# Get information for commit message
+layer_info = ''
+for layer, values in metadata['layers'].items():
+layer_info = '%s%-17s = %s:%s\n' % (layer_info, layer,
+  values['branch'], values['revision'])
+msg = 'Selftest for build %s of %s %s for machine %s on %s\n\n%s' 
% (
+   log_prefix[12:], metadata['distro'], 
metadata['distro_version'],
+   metadata['machine'], metadata['hostname'], layer_info)
+
+log.debug('Commiting results to local repository')
+repo.index.commit(msg)
+if not repo.is_dirty():
+if branch in r_branches:
+log.debug('Pushing changes to remote repository')
+repo.git.push()
+else:
+log.debug('Pushing changes to remote repository '
+  'creating new branch')
+repo.git.push('-u', 'origin', branch)
+else:
+log.error('Local repository is dirty, not pushing commits')
+
 if result.wasSuccessful():
 return 0
 else:
@@ -655,6 +724,35 @@ def buildResultClass(args):
 
 return StampedResu

Re: [OE-core] [PATCH V2] scripts.send-pull-request: Avoid multiple chain headers

2016-11-29 Thread Jose Lamego


On 11/29/2016 02:51 AM, Patrick Ohly wrote:
> 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.o...@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.
> 
You are right, I wrongly tested using patches created with
git-format-patch command, and then send-pull-request which produced a
correctly created chain with only the first change, but didn't tested
creating a pull request in the first place, which is the appropriate.

> 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.
> 

-- 
Jose Lamego | OTC Embedded Platforms & Tools | GDC



signature.asc
Description: OpenPGP digital signature
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH 06/18] cmake: update to 3.7.0

2016-11-29 Thread Khem Raj

> On Nov 29, 2016, at 6:01 AM, Alexander Kanavin 
>  wrote:
> 
> On 11/29/2016 01:24 AM, Khem Raj wrote:
>> 
>>> On Nov 28, 2016, at 5:34 AM, Alexander Kanavin 
>>>  wrote:
>>> 
>>> License is still 3-clause BSD.
>> 
>> OK. what triggered the checksum change then ?
> 
> They added a contributor list to Copyright.txt (I'll trim the lines that are 
> checksummed if that list will be constantly changing), and changed the header 
> in cmake.h from
> 
> /*
>  CMake - Cross Platform Makefile Generator
>  Copyright 2000-2009 Kitware, Inc., Insight Software Consortium
> 
>  Distributed under the OSI-approved BSD License (the "License");
>  see accompanying file Copyright.txt for details.
> 
>  This software is distributed WITHOUT ANY WARRANTY; without even the
>  implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>  See the License for more information.
> */
> 
> to
> 
> /* Distributed under the OSI-approved BSD 3-Clause License.  See accompanying
>   file Copyright.txt or https://cmake.org/licensing for details.  */
> 

Thanks for sharing this. I think it will be good to make a note of it, maybe in 
commit msg itself.

> Alex
> 

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] ASSUME_PROVIDED versus SANITY_REQUIRED_UTILITIES versus "The Build Host Packages"

2016-11-29 Thread Paul Eggleton
On Tue, 29 Nov 2016 11:31:44 Burton, Ross wrote:
> On 29 November 2016 at 10:47, Robert P. J. Day 
> wrote:
> > one example i mentioned is that the YP guide does not list "sed" as a
> > build host requirement, but "sed-native" is in ASSUME_PROVIDED;
> > however, it's not listed in SANITY_REQUIRED_UTILITIES. that seems
> > inconsistent.
> 
> It would be somewhat useful if there where a way to annotate in recipes
> what binary to check for on the host, so just doing
> ASSUME_PROVIDED=sed-native would look up in the sed recipe to check that
> "sed" exists on the host, so that SANITY_REQUIRED_UTILITIES doesn't need to
> be maintained separately.
> 
> Very low hanging fruit though.  Patches welcome!

How would you get access to that recipe-space information within 
sanity.bbclass though?

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] Kernel: Builds use old version of defconfig

2016-11-29 Thread Khem Raj

> On Nov 28, 2016, at 11:58 PM, Mike Looijmans  wrote:
> 
> On 29-11-16 03:03, Khem Raj wrote:
>> 
>>> On Nov 24, 2016, at 5:55 AM, Bruce Ashfield >> > wrote:
>>> 
>>> 
>>> 
>>> On Thu, Nov 24, 2016 at 5:32 AM, Mike Looijmans >> > 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.
> 

it might just be enough to expect kernel.bbclass to error out if a given task 
is not implemented by inheriting recipes much like pure virtual functions in C++
and get rid of _append/_prepend sequencing expectations.


> 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, 

Re: [OE-core] ASSUME_PROVIDED versus SANITY_REQUIRED_UTILITIES versus "The Build Host Packages"

2016-11-29 Thread Burton, Ross
On 29 November 2016 at 17:24, Paul Eggleton 
wrote:

> How would you get access to that recipe-space information within
> sanity.bbclass though?
>

Yeah good point, that might be "a bit" tricky.

Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH] systemd.bbclass: don't block on service restart

2016-11-29 Thread Khem Raj

> On Nov 24, 2016, at 8:17 PM, Mark Asselstine  
> wrote:
> 
> The current class works fine when a recipe uses SYSTEMD_AUTO_ENABLE
> 'enable' and has no on device pkg_postinst(), ie when the postinst is
> run as part of rootfs creation.  However, when there is a component of
> pkg_postinst() that is run on device the 'systemctl restart' is run as
> part of the run_postinsts.service at boot. This results in the boot
> spinning indefinitely with:
> 
> [ *** ] A start job is running for Run pending postinsts (7s / no limit)

yeah usually it would be nice if there was some sort of timeout on failed
restarts

> 
> The issue could potentially be that the packages service has an
> 'After' clause which comes later in the boot, beyond
> run_postinsts.service, creating a chicken before the egg
> scenario. Even service files without an 'After' clause cause this
> situation however. Despite this not being the cause of the issue this
> fix will prevent this scenario from happenning.
> 
> Using strace we are able to find that during boot, when
> run_postinsts.service is running attempting to start or restart any
> service will result in the call get stuck on poll(). Since the
> run_postinsts.service does not monitor the outcome of the call to
> restart we can work around this by using '--no-block'.
> 
> Signed-off-by: Mark Asselstine 
> ---
> meta/classes/systemd.bbclass | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/classes/systemd.bbclass b/meta/classes/systemd.bbclass
> index 7e51ed6..99a08a0 100644
> --- a/meta/classes/systemd.bbclass
> +++ b/meta/classes/systemd.bbclass
> @@ -36,7 +36,7 @@ if type systemctl >/dev/null 2>/dev/null; then
>   systemctl $OPTS ${SYSTEMD_AUTO_ENABLE} ${SYSTEMD_SERVICE}
> 
>   if [ -z "$D" -a "${SYSTEMD_AUTO_ENABLE}" = "enable" ]; then
> - systemctl restart ${SYSTEMD_SERVICE}
> + systemctl --no-block restart ${SYSTEMD_SERVICE}
>   fi
> fi
> }
> -- 
> 2.7.4
> 
> -- 
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] Kernel: Builds use old version of defconfig

2016-11-29 Thread Andre McCurdy
On Mon, Nov 28, 2016 at 11:58 PM, Mike Looijmans
 wrote:
>
> 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.

For reference, I've implemented support for merging of config
fragments in kernel.bbclass based kernel recipes just by over-riding
KERNEL_CONFIG_COMMAND. No do_configure_prepend required.

The basic version is:

KERNEL_CONFIG_COMMAND = " \
cd ${S} ; \
${WORKDIR}/merge_config.sh -r -O ${B} ${B}/.config `ls
${WORKDIR}/*.cfg 2>/dev/null` ; \
cd ${B} \
"

The debug version, with lots of error checking etc to verify that
calling merge_config.sh with no config fragments is equivalent to the
default KERNEL_CONFIG_COMMAND (which calls "make oldnoconfig" with a
fallback to "yes '' | make oldconfig" for _very_ old kernels) is:

KERNEL_CONFIG_COMMAND = " \
set -x ; \
cp .config .config_original ; \
cd ${S} ; \
oe_runmake_call O=${B} oldnoconfig ; \
mv ${B}/.config ${B}/.config_oldnoconfig ; \
cp ${B}/.config_original ${B}/.config ; \
${WORKDIR}/merge_config.sh -r -O ${B} ${B}/.config ; \
mv ${B}/.config ${B}/.config_merged_no_fragments ; \
cp ${B}/.config_original ${B}/.config ; \
${WORKDIR}/merge_config.sh -r -O ${B} ${B}/.config `ls
${WORKDIR}/*.cfg 2>/dev/null` ; \
cp ${B}/.config ${B}/.config_merged_with_fragments ; \
cd ${B} ; \
diff -u .config_oldnoconfig .config_merged_no_fragments ; \
diff -u .config_oldnoconfig .config_merged_with_fragments || true \
"


> 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.
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH] devtool: execute associated functions while preparing the source tree

2016-11-29 Thread Paul Eggleton
Hi Jiajie,

On Tue, 29 Nov 2016 10:59:09 Jiajie Hu 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.

So this in itself looks reasonable in theory, but I have to warn you that when 
we switch to tinfoil2 [1] these commits are going to be done via the metadata 
instead, and beyond a possible hack that I'd really rather not think about 
it's going to be a bit difficult to intercept the prefuncs/postfuncs there. At 
least they will be executed though since with tinfoil2 we'll be going through 
a much more standard path to run the tasks.

Cheers,
Paul

[1] https://wiki.yoctoproject.org/wiki/Tinfoil2

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH] qemu*.conf: Add slirp support for all qemu machines

2016-11-29 Thread Randy Witt




"-device virtio-net-device,netdev=net0" and
"-netdev user,id=net0,hostfwd=tcp::-: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'm aware that this will only work for one instance, but currently it doesn't 
work at all and it blocks a high priority bug. The only way to make it 100% 
work, would be to have qemu do the binding of the port to a dynamic one and then 
the user queries it after. Otherwise there is always a window where another 
process could bind to the port.


I don't think the bsp should be in the business of choosing which ports to 
forward. And if it is, then it should be a separate option in the qemuboot.conf, 
with just the "-netdev user" part because otherwise the user will always have to 
modify qemuboot.conf just to forward different ports.


It makes more sense to let the user do something like "runqemu slirp=22,65,..." 
and then return back the actual port used in the forwarding.


--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH] sysvinit-inittab: fix getty device removal

2016-11-29 Thread leonardo . sandoval . gonzalez
From: Leonardo Sandoval 

getty devices were not being removed in some cases because device name
was not at the end of the line, for example a ttyS1 device:

S1:12345:respawn:/bin/start_getty 115200 ttyS1 vt102

Removing this limitation allows sed to remove any line containing
the device.

Signed-off-by: Leonardo Sandoval 
---
 meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb 
b/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb
index c219cbf..dd30f43 100644
--- a/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb
+++ b/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb
@@ -62,7 +62,7 @@ if [ "x$D" = "x" ] && [ -e /proc/consoles ]; then
k=`echo ${i} | sed s/^.*\://g`
if [ -z "`grep ${j} /proc/consoles`" ]; then
if [ -z "${k}" ] || [ -z "`grep ${k} /proc/consoles`" ] 
|| [ ! -e /dev/${j} ]; then
-   sed -i /^.*${j}$/d /etc/inittab
+   sed -i /^.*${j}/d /etc/inittab
fi
fi
done
-- 
2.1.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH] tune-cortexa*.inc: squash whitespace within TUNE_FEATURES strings

2016-11-29 Thread Andre McCurdy
TUNE_FEATURES is include in BUILDCFG_VARS, so any whitespace is
visible to the user during the build process. Remove the extra
whitespace added during the 2.1 development cycle:

  
http://git.openembedded.org/openembedded-core/commit/?id=f774b44fa007a2a756ada892ede832b1251d940c

For consistency, squash whitespace within PACKAGE_EXTRA_ARCHS strings
too.

Signed-off-by: Andre McCurdy 
---
 meta/conf/machine/include/tune-cortexa15.inc | 32 -
 meta/conf/machine/include/tune-cortexa17.inc | 32 -
 meta/conf/machine/include/tune-cortexa5.inc  | 24 +--
 meta/conf/machine/include/tune-cortexa7.inc  | 32 -
 meta/conf/machine/include/tune-cortexa8.inc  | 24 +--
 meta/conf/machine/include/tune-cortexa9.inc  | 36 ++--
 6 files changed, 90 insertions(+), 90 deletions(-)

diff --git a/meta/conf/machine/include/tune-cortexa15.inc 
b/meta/conf/machine/include/tune-cortexa15.inc
index a33b27f..03de602 100644
--- a/meta/conf/machine/include/tune-cortexa15.inc
+++ b/meta/conf/machine/include/tune-cortexa15.inc
@@ -13,17 +13,17 @@ ARMPKGARCH_tune-cortexa15-neon= "cortexa15"
 ARMPKGARCH_tune-cortexa15t-neon   = "cortexa15"
 ARMPKGARCH_tune-cortexa15-neon-vfpv4  = "cortexa15"
 ARMPKGARCH_tune-cortexa15t-neon-vfpv4 = "cortexa15"
-TUNE_FEATURES_tune-cortexa15 = "${TUNE_FEATURES_tune-armv7ve}  
   cortexa15"
-TUNE_FEATURES_tune-cortexa15t= "${TUNE_FEATURES_tune-armv7vet} 
   cortexa15"
-TUNE_FEATURES_tune-cortexa15-neon= "${TUNE_FEATURES_tune-armv7ve-neon} 
   cortexa15"
-TUNE_FEATURES_tune-cortexa15t-neon   = 
"${TUNE_FEATURES_tune-armv7vet-neon}   cortexa15"
-TUNE_FEATURES_tune-cortexa15-neon-vfpv4  = 
"${TUNE_FEATURES_tune-armv7ve-neon-vfpv4}  cortexa15"
+TUNE_FEATURES_tune-cortexa15 = "${TUNE_FEATURES_tune-armv7ve} 
cortexa15"
+TUNE_FEATURES_tune-cortexa15t= "${TUNE_FEATURES_tune-armv7vet} 
cortexa15"
+TUNE_FEATURES_tune-cortexa15-neon= "${TUNE_FEATURES_tune-armv7ve-neon} 
cortexa15"
+TUNE_FEATURES_tune-cortexa15t-neon   = 
"${TUNE_FEATURES_tune-armv7vet-neon} cortexa15"
+TUNE_FEATURES_tune-cortexa15-neon-vfpv4  = 
"${TUNE_FEATURES_tune-armv7ve-neon-vfpv4} cortexa15"
 TUNE_FEATURES_tune-cortexa15t-neon-vfpv4 = 
"${TUNE_FEATURES_tune-armv7vet-neon-vfpv4} cortexa15"
-PACKAGE_EXTRA_ARCHS_tune-cortexa15 = 
"${PACKAGE_EXTRA_ARCHS_tune-armv7ve}  cortexa15-vfp"
+PACKAGE_EXTRA_ARCHS_tune-cortexa15 = 
"${PACKAGE_EXTRA_ARCHS_tune-armv7ve} cortexa15-vfp"
 PACKAGE_EXTRA_ARCHS_tune-cortexa15t= 
"${PACKAGE_EXTRA_ARCHS_tune-armv7vet} cortexa15-vfp cortexa15t2-vfp"
-PACKAGE_EXTRA_ARCHS_tune-cortexa15-neon= 
"${PACKAGE_EXTRA_ARCHS_tune-armv7ve-neon}  cortexa15-vfp cortexa15-neon"
+PACKAGE_EXTRA_ARCHS_tune-cortexa15-neon= 
"${PACKAGE_EXTRA_ARCHS_tune-armv7ve-neon} cortexa15-vfp cortexa15-neon"
 PACKAGE_EXTRA_ARCHS_tune-cortexa15t-neon   = 
"${PACKAGE_EXTRA_ARCHS_tune-armv7vet-neon} cortexa15-vfp cortexa15-neon 
cortexa15t2-vfp cortexa15t2-neon"
-PACKAGE_EXTRA_ARCHS_tune-cortexa15-neon-vfpv4  = 
"${PACKAGE_EXTRA_ARCHS_tune-armv7ve-neon-vfpv4}  cortexa15-vfp cortexa15-neon 
cortexa15-neon-vfpv4"
+PACKAGE_EXTRA_ARCHS_tune-cortexa15-neon-vfpv4  = 
"${PACKAGE_EXTRA_ARCHS_tune-armv7ve-neon-vfpv4} cortexa15-vfp cortexa15-neon 
cortexa15-neon-vfpv4"
 PACKAGE_EXTRA_ARCHS_tune-cortexa15t-neon-vfpv4 = 
"${PACKAGE_EXTRA_ARCHS_tune-armv7vet-neon-vfpv4} cortexa15-vfp cortexa15-neon 
cortexa15-neon-vfpv4 cortexa15t2-vfp cortexa15t2-neon cortexa15t2-neon-vfpv4"
 
 # HF Tunes
@@ -34,15 +34,15 @@ ARMPKGARCH_tune-cortexa15hf-neon= "cortexa15"
 ARMPKGARCH_tune-cortexa15thf-neon   = "cortexa15"
 ARMPKGARCH_tune-cortexa15hf-neon-vfpv4  = "cortexa15"
 ARMPKGARCH_tune-cortexa15thf-neon-vfpv4 = "cortexa15"
-TUNE_FEATURES_tune-cortexa15hf = "${TUNE_FEATURES_tune-armv7vehf}  
   cortexa15"
-TUNE_FEATURES_tune-cortexa15thf= "${TUNE_FEATURES_tune-armv7vethf} 
   cortexa15"
-TUNE_FEATURES_tune-cortexa15hf-neon= 
"${TUNE_FEATURES_tune-armv7vehf-neon}cortexa15"
-TUNE_FEATURES_tune-cortexa15thf-neon   = 
"${TUNE_FEATURES_tune-armv7vethf-neon}   cortexa15"
-TUNE_FEATURES_tune-cortexa15hf-neon-vfpv4  = 
"${TUNE_FEATURES_tune-armv7vehf-neon-vfpv4}  cortexa15"
+TUNE_FEATURES_tune-cortexa15hf = "${TUNE_FEATURES_tune-armv7vehf} 
cortexa15"
+TUNE_FEATURES_tune-cortexa15thf= "${TUNE_FEATURES_tune-armv7vethf} 
cortexa15"
+TUNE_FEATURES_tune-cortexa15hf-neon= 
"${TUNE_FEATURES_tune-armv7vehf-neon} cortexa15"
+TUNE_FEATURES_tune-cortexa15thf-neon   = 
"${TUNE_FEATURES_tune-armv7vethf-neon} cortexa15"
+TUNE_FEATURES_tune-cortexa15hf-neon-vfpv4  = 
"${TUNE_FEATURES_tune-armv7vehf-neon-vfpv4} cortexa15"
 TUNE_FEATURES_tune-cortexa15thf-neon-vfpv4 = 
"${TUNE_FEATURES_tune-armv7vethf-neon-vfpv4} 

Re: [OE-core] [PATCH] sysvinit-inittab: fix getty device removal

2016-11-29 Thread Christopher Larson
On Tue, Nov 29, 2016 at 11:29 AM, <
leonardo.sandoval.gonza...@linux.intel.com> wrote:

> From: Leonardo Sandoval 
>
> getty devices were not being removed in some cases because device name
> was not at the end of the line, for example a ttyS1 device:
>
> S1:12345:respawn:/bin/start_getty 115200 ttyS1 vt102
>
> Removing this limitation allows sed to remove any line containing
> the device.
>
> Signed-off-by: Leonardo Sandoval  linux.intel.com>
> ---
>  meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb
> b/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb
> index c219cbf..dd30f43 100644
> --- a/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb
> +++ b/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb
> @@ -62,7 +62,7 @@ if [ "x$D" = "x" ] && [ -e /proc/consoles ]; then
> k=`echo ${i} | sed s/^.*\://g`
> if [ -z "`grep ${j} /proc/consoles`" ]; then
> if [ -z "${k}" ] || [ -z "`grep ${k}
> /proc/consoles`" ] || [ ! -e /dev/${j} ]; then
> -   sed -i /^.*${j}$/d /etc/inittab
> +   sed -i /^.*${j}/d /etc/inittab
>

This doesn’t check for the end of a word, so it’d match a partial as well.
Would that be a problem? i.e. ttyS1 vs ttyS10.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH 1/1] parselogs.py: Whitelist iwlwifi firmware load error messages

2016-11-29 Thread California Sullivan
The iwlwifi module of any given kernel has a minimum and maximum
supported firmware version. The kernel begins by attempting to load the
maximum version, and decrements until it is successful. The 4.8 kernel's
maximum supported firmware version is 24, but thus far only 22 has been
released, meaning we get errors for 24 and 23.

Filter out iwlwifi firmware load error messages, as they are not
necessarily indicative of real problems.

Signed-off-by: California Sullivan 
---
 meta/lib/oeqa/runtime/parselogs.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/lib/oeqa/runtime/parselogs.py 
b/meta/lib/oeqa/runtime/parselogs.py
index 58f62da..8610863 100644
--- a/meta/lib/oeqa/runtime/parselogs.py
+++ b/meta/lib/oeqa/runtime/parselogs.py
@@ -58,6 +58,7 @@ x86_common = [
 'failed to setup card detect gpio',
 'amd_nb: Cannot enumerate AMD northbridges',
 'failed to retrieve link info, disabling eDP',
+'Direct firmware load for iwlwifi',
 ] + common_errors
 
 qemux86_common = [
-- 
2.5.5

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH] sysvinit-inittab: fix getty device removal

2016-11-29 Thread Leonardo Sandoval



On 11/29/2016 02:15 PM, Christopher Larson wrote:


On Tue, Nov 29, 2016 at 11:29 AM, 
> wrote:


From: Leonardo Sandoval
mailto:leonardo.sandoval.gonza...@linux.intel.com>>

getty devices were not being removed in some cases because device name
was not at the end of the line, for example a ttyS1 device:

S1:12345:respawn:/bin/start_getty 115200 ttyS1 vt102

Removing this limitation allows sed to remove any line containing
the device.

Signed-off-by: Leonardo Sandoval
mailto:leonardo.sandoval.gonza...@linux.intel.com>>
---
 meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb
 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git
a/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb

b/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb

index c219cbf..dd30f43 100644
--- a/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb

+++ b/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb

@@ -62,7 +62,7 @@ if [ "x$D" = "x" ] && [ -e /proc/consoles ]; then
k=`echo ${i} | sed s/^.*\://g`
if [ -z "`grep ${j} /proc/consoles`" ]; then
if [ -z "${k}" ] || [ -z "`grep ${k}
/proc/consoles`" ] || [ ! -e /dev/${j} ]; then
-   sed -i /^.*${j}$/d /etc/inittab
+   sed -i /^.*${j}/d /etc/inittab


This doesn’t check for the end of a word, so it’d match a partial as 
well. Would that be a problem? i.e. ttyS1 vs ttyS10.


That is the intention, that line removal is not tied to finding the 
device at the end of the line. With proposed patch, it removes the 
device, no matter where is located.




--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics


-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH] sysvinit-inittab: fix getty device removal

2016-11-29 Thread Cal Sullivan



On 11/29/2016 12:52 PM, Leonardo Sandoval wrote:




On 11/29/2016 02:15 PM, Christopher Larson wrote:


On Tue, Nov 29, 2016 at 11:29 AM, 
> wrote:


From: Leonardo Sandoval
mailto:leonardo.sandoval.gonza...@linux.intel.com>>

getty devices were not being removed in some cases because device
name
was not at the end of the line, for example a ttyS1 device:

S1:12345:respawn:/bin/start_getty 115200 ttyS1 vt102

Removing this limitation allows sed to remove any line containing
the device.

Signed-off-by: Leonardo Sandoval
mailto:leonardo.sandoval.gonza...@linux.intel.com>>
---
 meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb
 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git
a/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb

b/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb

index c219cbf..dd30f43 100644
--- a/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb

+++ b/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb

@@ -62,7 +62,7 @@ if [ "x$D" = "x" ] && [ -e /proc/consoles ]; then
k=`echo ${i} | sed s/^.*\://g`
if [ -z "`grep ${j} /proc/consoles`" ]; then
if [ -z "${k}" ] || [ -z "`grep ${k}
/proc/consoles`" ] || [ ! -e /dev/${j} ]; then
-   sed -i /^.*${j}$/d /etc/inittab
+   sed -i /^.*${j}/d /etc/inittab


This doesn’t check for the end of a word, so it’d match a partial as 
well. Would that be a problem? i.e. ttyS1 vs ttyS10.


That is the intention, that line removal is not tied to finding the 
device at the end of the line. With proposed patch, it removes the 
device, no matter where is located.



Right, but look at this hypothetical example:

S1:12345:respawn:/bin/start_getty 115200 ttyS1 vt102
S10:12345:respawn:/bin/start_getty 115200 ttyS10

Both would match, when you only want the top to match. This is untested 
but likely more what we want:


sed -i /^.*${j}[\ $]/d /etc/inittab

That way we either match up to a space (end of word) or end of line.

---
Cal




--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics






-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH] sysvinit-inittab: fix getty device removal

2016-11-29 Thread Cal Sullivan

Oops, accidentally dropped CCs. See my reply below.

On 11/29/2016 01:05 PM, Cal Sullivan wrote:



On 11/29/2016 12:52 PM, Leonardo Sandoval wrote:




On 11/29/2016 02:15 PM, Christopher Larson wrote:


On Tue, Nov 29, 2016 at 11:29 AM, 
> wrote:


From: Leonardo Sandoval
mailto:leonardo.sandoval.gonza...@linux.intel.com>>

getty devices were not being removed in some cases because
device name
was not at the end of the line, for example a ttyS1 device:

S1:12345:respawn:/bin/start_getty 115200 ttyS1 vt102

Removing this limitation allows sed to remove any line containing
the device.

Signed-off-by: Leonardo Sandoval
mailto:leonardo.sandoval.gonza...@linux.intel.com>>
---
 meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb
 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git
a/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb

b/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb

index c219cbf..dd30f43 100644
--- a/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb

+++ b/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb

@@ -62,7 +62,7 @@ if [ "x$D" = "x" ] && [ -e /proc/consoles ]; then
k=`echo ${i} | sed s/^.*\://g`
if [ -z "`grep ${j} /proc/consoles`" ]; then
if [ -z "${k}" ] || [ -z "`grep ${k}
/proc/consoles`" ] || [ ! -e /dev/${j} ]; then
-   sed -i /^.*${j}$/d /etc/inittab
+   sed -i /^.*${j}/d /etc/inittab


This doesn’t check for the end of a word, so it’d match a partial as 
well. Would that be a problem? i.e. ttyS1 vs ttyS10.


That is the intention, that line removal is not tied to finding the 
device at the end of the line. With proposed patch, it removes the 
device, no matter where is located.



Right, but look at this hypothetical example:

S1:12345:respawn:/bin/start_getty 115200 ttyS1 vt102
S10:12345:respawn:/bin/start_getty 115200 ttyS10

Both would match, when you only want the top to match. This is 
untested but likely more what we want:


sed -i /^.*${j}[\ $]/d /etc/inittab

That way we either match up to a space (end of word) or end of line.

---
Cal




--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics








-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH] texinfo upgrade to 6.3

2016-11-29 Thread Edwin Plauchu
Signed-off-by: Edwin Plauchu 

---
 .../texinfo/texinfo/dont-depend-on-help2man.patch  | 19 ---
 .../texinfo/texinfo/texinfo-4.12-zlib.patch| 65 +++---
 .../texinfo/{texinfo_6.0.bb => texinfo_6.3.bb} |  5 +-
 3 files changed, 56 insertions(+), 33 deletions(-)
 rename meta/recipes-extended/texinfo/{texinfo_6.0.bb => texinfo_6.3.bb} (93%)

diff --git 
a/meta/recipes-extended/texinfo/texinfo/dont-depend-on-help2man.patch 
b/meta/recipes-extended/texinfo/texinfo/dont-depend-on-help2man.patch
index 0ce47ec..f418439 100644
--- a/meta/recipes-extended/texinfo/texinfo/dont-depend-on-help2man.patch
+++ b/meta/recipes-extended/texinfo/texinfo/dont-depend-on-help2man.patch
@@ -1,31 +1,32 @@
-From 6f1f3912fcb900b3a3e6cbe3360306fade333497 Mon Sep 17 00:00:00 2001
-From: Jussi Kukkonen 
-Date: Thu, 6 Aug 2015 14:55:08 +0300
+From e89b1c57d76f5cf5acbb0d0187374f7a77bce1e2 Mon Sep 17 00:00:00 2001
+From: Edwin Plauchu 
+Date: Tue, 29 Nov 2016 13:43:24 -0600
 Subject: [PATCH] dont-depend-on-help2man
 
 Upstream-Status: Inappropriate
 
 Signed-off-by: Marko Lindqvist 
+Signed-off-by: Edwin Plauchu 
 ---
  doc/Makefile.am |  2 +-
  man/Makefile.am | 12 ++--
  2 files changed, 7 insertions(+), 7 deletions(-)
 
 diff --git a/doc/Makefile.am b/doc/Makefile.am
-index 7198a6b..4bba550 100644
+index 39db834..1bb2a4f
 --- a/doc/Makefile.am
 +++ b/doc/Makefile.am
-@@ -40,7 +40,7 @@ refcard_files = refcard/Makefile refcard/txicmdcheck \
+@@ -38,7 +38,7 @@ refcard_files = refcard/Makefile refcard/txicmdcheck \
  # Include our texinfo.tex, not Automake's.
  EXTRA_DIST = epsf.tex texinfo.tex \
   fdl.texi \
 -   $(man_MANS) $(TXI_XLATE) \
 +   $(TXI_XLATE) \
-$(refcard_files)
+  $(refcard_files) texinfo-tex-test.texi \
+  texinfo-ja.tex short-sample-ja.texi
  
- if INSTALL_WARNINGS
 diff --git a/man/Makefile.am b/man/Makefile.am
-index a08d603..bdfc9a4 100644
+index 6bfcb3d..a820c96
 --- a/man/Makefile.am
 +++ b/man/Makefile.am
 @@ -13,24 +13,24 @@
@@ -60,5 +61,5 @@ index a08d603..bdfc9a4 100644
  # Maintainers should be able to regenerate.
  MAINTAINERCLEANFILES = $(man_MANS)
 -- 
-2.1.4
+2.9.3
 
diff --git a/meta/recipes-extended/texinfo/texinfo/texinfo-4.12-zlib.patch 
b/meta/recipes-extended/texinfo/texinfo/texinfo-4.12-zlib.patch
index 41bd220..f25352c 100644
--- a/meta/recipes-extended/texinfo/texinfo/texinfo-4.12-zlib.patch
+++ b/meta/recipes-extended/texinfo/texinfo/texinfo-4.12-zlib.patch
@@ -1,19 +1,22 @@
-From 20e1d8a9481dc13dd1d4d168b90e0ed2ff097b98 Mon Sep 17 00:00:00 2001
-From: Jussi Kukkonen 
-Date: Thu, 6 Aug 2015 14:29:57 +0300
+From fe4f00459601efe0cfa75d92749a32237800a530 Mon Sep 17 00:00:00 2001
+From: Edwin Plauchu 
+Date: Tue, 29 Nov 2016 12:27:17 -0600
 Subject: [PATCH] texinfo-4.12-zlib
 
 Upstream-Status: Pending
+
+Signed-off-by: Jussi Kukkonen 
+Signed-off-by: Edwin Plauchu 
 ---
- install-info/Makefile.in|  2 +-
- install-info/install-info.c | 67 +++--
- 2 files changed, 42 insertions(+), 27 deletions(-)
+ install-info/Makefile.in| 12 ++-
+ install-info/install-info.c | 79 +++--
+ 2 files changed, 49 insertions(+), 42 deletions(-)
 
 diff --git a/install-info/Makefile.in b/install-info/Makefile.in
-index ad73abb..eaa2153 100644
+index 837d020..ba96579 100644
 --- a/install-info/Makefile.in
 +++ b/install-info/Makefile.in
-@@ -241,7 +241,7 @@ am__installdirs = "$(DESTDIR)$(bindir)" 
"$(DESTDIR)$(bindir)"
+@@ -216,7 +208,7 @@ am__installdirs = "$(DESTDIR)$(bindir)" 
"$(DESTDIR)$(bindir)"
  PROGRAMS = $(bin_PROGRAMS)
  am_ginstall_info_OBJECTS = install-info.$(OBJEXT)
  ginstall_info_OBJECTS = $(am_ginstall_info_OBJECTS)
@@ -23,7 +26,7 @@ index ad73abb..eaa2153 100644
  ginstall_info_DEPENDENCIES = $(top_builddir)/gnulib/lib/libgnu.a \
$(am__DEPENDENCIES_1)
 diff --git a/install-info/install-info.c b/install-info/install-info.c
-index b454c15..4e39122 100644
+index e58189c..8617787 100644
 --- a/install-info/install-info.c
 +++ b/install-info/install-info.c
 @@ -22,6 +22,7 @@
@@ -43,7 +46,7 @@ index b454c15..4e39122 100644
  open_possibly_compressed_file (char *filename,
  void (*create_callback) (char *),
 -char **opened_filename, char **compression_program) 
-+char **opened_filename, char **compression_program, int *is_pipe) 
++char **opened_filename, char **compression_program, int *is_pipe)
  {
char *local_opened_filename, *local_compression_program;
int nread;
@@ -119,7 +122,7 @@ index b454c15..4e39122 100644
if (!f)
  return 0;
  }
-@@ -767,12 +768,12 @@ open_possibly_compressed_file (char *filename,
+@@ -767,26 +768,26 @@ open_possibly_compressed_file (char *filename,
  
/* Read first few bytes of file rather than relying on the filename.
   If the file is shorter than this it can't be usable anyway.  */
@@ -128,14 +131,34 @@ index b454c15..4

Re: [OE-core] [PATCH] texinfo upgrade to 6.3

2016-11-29 Thread Burton, Ross
On 29 November 2016 at 21:17, Edwin Plauchu <
edwin.plauchu.cama...@linux.intel.com> wrote:

> -   file://disable-native-tools.patch \
>

Should this patch be deleted?

Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH] sysvinit-inittab: fix getty device removal

2016-11-29 Thread Leonardo Sandoval



On 11/29/2016 03:08 PM, Cal Sullivan wrote:

Oops, accidentally dropped CCs. See my reply below.

On 11/29/2016 01:05 PM, Cal Sullivan wrote:



On 11/29/2016 12:52 PM, Leonardo Sandoval wrote:




On 11/29/2016 02:15 PM, Christopher Larson wrote:


On Tue, Nov 29, 2016 at 11:29 AM, 
> wrote:


From: Leonardo Sandoval
mailto:leonardo.sandoval.gonza...@linux.intel.com>>

getty devices were not being removed in some cases because
device name
was not at the end of the line, for example a ttyS1 device:

S1:12345:respawn:/bin/start_getty 115200 ttyS1 vt102

Removing this limitation allows sed to remove any line containing
the device.

Signed-off-by: Leonardo Sandoval
mailto:leonardo.sandoval.gonza...@linux.intel.com>>
---
 meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb
 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git
a/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb

b/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb

index c219cbf..dd30f43 100644
--- a/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb

+++ b/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb

@@ -62,7 +62,7 @@ if [ "x$D" = "x" ] && [ -e /proc/consoles ]; then
k=`echo ${i} | sed s/^.*\://g`
if [ -z "`grep ${j} /proc/consoles`" ]; then
if [ -z "${k}" ] || [ -z "`grep ${k}
/proc/consoles`" ] || [ ! -e /dev/${j} ]; then
-   sed -i /^.*${j}$/d /etc/inittab
+   sed -i /^.*${j}/d /etc/inittab


This doesn’t check for the end of a word, so it’d match a partial 
as well. Would that be a problem? i.e. ttyS1 vs ttyS10.


That is the intention, that line removal is not tied to finding the 
device at the end of the line. With proposed patch, it removes the 
device, no matter where is located.



Right, but look at this hypothetical example:

S1:12345:respawn:/bin/start_getty 115200 ttyS1 vt102
S10:12345:respawn:/bin/start_getty 115200 ttyS10

Both would match, when you only want the top to match. This is 
untested but likely more what we want:


sed -i /^.*${j}[\ $]/d /etc/inittab

That way we either match up to a space (end of word) or end of line.


Got it, that can be possible. Sending a v2



---
Cal




--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics










-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH V2] texinfo upgrade to 6.3

2016-11-29 Thread Edwin Plauchu
From: Edwin Plauchu 

Signed-off-by: Edwin Plauchu 
---
 .../texinfo/texinfo/disable-native-tools.patch | 43 --
 .../texinfo/texinfo/dont-depend-on-help2man.patch  | 19 ---
 .../texinfo/texinfo/texinfo-4.12-zlib.patch| 65 +++---
 .../texinfo/{texinfo_6.0.bb => texinfo_6.3.bb} |  5 +-
 4 files changed, 56 insertions(+), 76 deletions(-)
 delete mode 100644 
meta/recipes-extended/texinfo/texinfo/disable-native-tools.patch
 rename meta/recipes-extended/texinfo/{texinfo_6.0.bb => texinfo_6.3.bb} (93%)

diff --git a/meta/recipes-extended/texinfo/texinfo/disable-native-tools.patch 
b/meta/recipes-extended/texinfo/texinfo/disable-native-tools.patch
deleted file mode 100644
index ab6f165..000
--- a/meta/recipes-extended/texinfo/texinfo/disable-native-tools.patch
+++ /dev/null
@@ -1,43 +0,0 @@
-We already DEPEND on the native texinfo being present before building so
-there isn't any need to try and build the required native texinfo binaries
-before cross-compiling. This simplifies the recipe somewhat!
-
-Upstream-Status: Inappropriate oe specific
-
-Signed-off-by: Joshua Lock 
-
-Index: texinfo-4.13/configure.ac
-===
 texinfo-4.13.orig/configure.ac
-+++ texinfo-4.13/configure.ac
-@@ -100,29 +100,7 @@ AC_CANONICAL_BUILD
- # $native_tools is also added to SUBDIRS in the main Makefile.am,
- # so that make compiles the native tools first.
- #
--if test "$cross_compiling" = no; then
--  native_tools=
--else
--  native_tools=tools
--  test -d "$native_tools" || mkdir "$native_tools"
--  confdir=`(cd "$srcdir";pwd)`
--  # Make sure the secondary configure won't fail with
--  # "error: source directory already configured".
--  rm -f config.status
--  AC_MSG_NOTICE([[Doing configure of native tools (${build}).]])
--  cd "$native_tools" || exit 1
--  # Run secondary configure in alternate environment or
--  # it gets the wrong CC etc.
--  # env -i gives this build host configure a clean environment;
--  # consequently, we have to re-initialize $PATH.
--  env -i CC="$BUILD_CC" AR="$BUILD_AR" RANLIB="$BUILD_RANLIB" \
--  PATH="$PATH" \
--  tools_only=1 \
--${confdir}/configure --build=${build} --host=${build} \
-- --disable-rpath --disable-nls
--  cd .. || exit 1
--  AC_MSG_NOTICE([[Continuing with main configure (${host}).]])
--fi
-+native_tools=
- AC_SUBST(native_tools)
- AM_CONDITIONAL(TOOLS_ONLY, [[test "x$tools_only" = x1]])
- 
diff --git 
a/meta/recipes-extended/texinfo/texinfo/dont-depend-on-help2man.patch 
b/meta/recipes-extended/texinfo/texinfo/dont-depend-on-help2man.patch
index 0ce47ec..f418439 100644
--- a/meta/recipes-extended/texinfo/texinfo/dont-depend-on-help2man.patch
+++ b/meta/recipes-extended/texinfo/texinfo/dont-depend-on-help2man.patch
@@ -1,31 +1,32 @@
-From 6f1f3912fcb900b3a3e6cbe3360306fade333497 Mon Sep 17 00:00:00 2001
-From: Jussi Kukkonen 
-Date: Thu, 6 Aug 2015 14:55:08 +0300
+From e89b1c57d76f5cf5acbb0d0187374f7a77bce1e2 Mon Sep 17 00:00:00 2001
+From: Edwin Plauchu 
+Date: Tue, 29 Nov 2016 13:43:24 -0600
 Subject: [PATCH] dont-depend-on-help2man
 
 Upstream-Status: Inappropriate
 
 Signed-off-by: Marko Lindqvist 
+Signed-off-by: Edwin Plauchu 
 ---
  doc/Makefile.am |  2 +-
  man/Makefile.am | 12 ++--
  2 files changed, 7 insertions(+), 7 deletions(-)
 
 diff --git a/doc/Makefile.am b/doc/Makefile.am
-index 7198a6b..4bba550 100644
+index 39db834..1bb2a4f
 --- a/doc/Makefile.am
 +++ b/doc/Makefile.am
-@@ -40,7 +40,7 @@ refcard_files = refcard/Makefile refcard/txicmdcheck \
+@@ -38,7 +38,7 @@ refcard_files = refcard/Makefile refcard/txicmdcheck \
  # Include our texinfo.tex, not Automake's.
  EXTRA_DIST = epsf.tex texinfo.tex \
   fdl.texi \
 -   $(man_MANS) $(TXI_XLATE) \
 +   $(TXI_XLATE) \
-$(refcard_files)
+  $(refcard_files) texinfo-tex-test.texi \
+  texinfo-ja.tex short-sample-ja.texi
  
- if INSTALL_WARNINGS
 diff --git a/man/Makefile.am b/man/Makefile.am
-index a08d603..bdfc9a4 100644
+index 6bfcb3d..a820c96
 --- a/man/Makefile.am
 +++ b/man/Makefile.am
 @@ -13,24 +13,24 @@
@@ -60,5 +61,5 @@ index a08d603..bdfc9a4 100644
  # Maintainers should be able to regenerate.
  MAINTAINERCLEANFILES = $(man_MANS)
 -- 
-2.1.4
+2.9.3
 
diff --git a/meta/recipes-extended/texinfo/texinfo/texinfo-4.12-zlib.patch 
b/meta/recipes-extended/texinfo/texinfo/texinfo-4.12-zlib.patch
index 41bd220..f25352c 100644
--- a/meta/recipes-extended/texinfo/texinfo/texinfo-4.12-zlib.patch
+++ b/meta/recipes-extended/texinfo/texinfo/texinfo-4.12-zlib.patch
@@ -1,19 +1,22 @@
-From 20e1d8a9481dc13dd1d4d168b90e0ed2ff097b98 Mon Sep 17 00:00:00 2001
-From: Jussi Kukkonen 
-Date: Thu, 6 Aug 2015 14:29:57 +0300
+From fe4f00459601efe0cfa75d92749a32237800a530 Mon Sep 17 00:00:00 2001
+From: Edwin Plauchu 
+Date: Tue, 29 Nov 2016 12:27:17 -0600
 Subject: [PATCH] texinfo-4.12-zlib
 
 Upstream-Status: Pending
+

[OE-core] [PATCH v2] sysvinit-inittab: fix getty device removal

2016-11-29 Thread leonardo . sandoval . gonzalez
From: Leonardo Sandoval 

getty devices were not being removed in some cases because device name
was not at the end of the line, for example a ttyS1 device:

S1:12345:respawn:/bin/start_getty 115200 ttyS1 vt102

Removing this limitation allows sed to remove any line containing
the device.

Signed-off-by: Leonardo Sandoval 
---
 meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb 
b/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb
index c219cbf..5b9c422 100644
--- a/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb
+++ b/meta/recipes-core/sysvinit/sysvinit-inittab_2.88dsf.bb
@@ -62,7 +62,7 @@ if [ "x$D" = "x" ] && [ -e /proc/consoles ]; then
k=`echo ${i} | sed s/^.*\://g`
if [ -z "`grep ${j} /proc/consoles`" ]; then
if [ -z "${k}" ] || [ -z "`grep ${k} /proc/consoles`" ] 
|| [ ! -e /dev/${j} ]; then
-   sed -i /^.*${j}$/d /etc/inittab
+   sed -i -e /^.*${j}\ /d -e /^.*${j}$/d 
/etc/inittab
fi
fi
done
-- 
2.1.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH 1/2] oeqa/utils/metadata.py: Add metadata library

2016-11-29 Thread Benjamin Esquivel
On Tue, 2016-11-29 at 08:42 -0600, mariano.lo...@linux.intel.com wrote:
> From: Mariano Lopez 
> 
> Adds functions to get metadata from the host running the tests.
> 
> [YOCTO #9954]
> 
> Signed-off-by: Mariano Lopez 
> ---
>  meta/lib/oeqa/utils/metadata.py | 77
> +
>  1 file changed, 77 insertions(+)
>  create mode 100644 meta/lib/oeqa/utils/metadata.py
> 
> diff --git a/meta/lib/oeqa/utils/metadata.py
> b/meta/lib/oeqa/utils/metadata.py
> new file mode 100644
> index 000..3be805c
> --- /dev/null
> +++ b/meta/lib/oeqa/utils/metadata.py
> @@ -0,0 +1,77 @@
> +# Copyright (C) 2016 Intel Corporation
> +#
> +# Released under the MIT license (see COPYING.MIT)
> +#
> +# Functions to get metadata from the testing host used
> +# for analytics of test results.
> +
> +from git import Repo
> +from collections import OrderedDict
> +from collections.abc import MutableMapping
> +from xml.dom.minidom import parseString
> +from xml.etree.ElementTree import Element, tostring
> +
> +from oe.lsb import distro_identifier
> +from oeqa.utils.commands import runCmd, get_bb_var
> +
> +def metadata_from_bb():
> +""" Returns test's metadata as OrderedDict.
> +
> +Data will be gathered using bitbake -e thanks to get_bb_var.
> +"""
> +
> +info_dict = OrderedDict()
> +hostname = runCmd('hostname')
> +info_dict['hostname'] = hostname.output
> +info_dict['machine'] = get_bb_var('MACHINE')
> +info_dict['distro'] = get_bb_var('DISTRO')
> +info_dict['distro_version'] = get_bb_var('DISTRO_VERSION')
> +host_distro= distro_identifier()
> +host_distro, _, host_distro_release = host_distro.partition('-')
> +info_dict['host_distro'] = host_distro
> +info_dict['host_distro_release'] = host_distro_release
> +info_dict['layers'] = get_layers(get_bb_var('BBLAYERS'))
is none of the upper statements going to throw exceptions? otherwise
try/except as appropriate.
> +return info_dict
> +
> +def metadata_from_data_store(d):
> +""" Returns test's metadata as OrderedDict.
> +
> +Data will be collected from the provided data store.
> +"""
> +# TODO: Getting metadata from the data store would
> +# be useful when running within bitbake.
> +pass
> +
> +def get_layers(layers):
> +""" Returns layer name, branch, and revision as OrderedDict. """
> +
> +layer_dict = OrderedDict()
> +for layer in layers.split():
> +layer_name = os.path.basename(layer)
> +layer_dict[layer_name] = OrderedDict()
> +repo = Repo(layer, search_parent_directories=True)
> +revision, branch = repo.head.object.name_rev.split()
> +layer_dict[layer_name]['branch'] = branch
> +layer_dict[layer_name]['revision'] = revision
same here for the try/except, did you test with usual cases of zero
input and unexisting path's, etc?
> +return layer_dict
> +
> +def write_metadata_file(file_path, metadata):
> +""" Writes metadata to a XML file in directory. """
> +
> +xml = dict_to_XML('metadata', metadata)
> +xml_doc = parseString(tostring(xml).decode('UTF-8'))
> +with open(file_path, 'w') as f:
> +f.write(xml_doc.toprettyxml())
> +
> +def dict_to_XML(tag, dictionary):
> +""" Return XML element converting dicts recursively. """
> +
> +elem = Element(tag)
> +for key, val in dictionary.items():
> +if isinstance(val, MutableMapping):
> +child = (dict_to_XML(key, val))
> +else:
> +child = Element(key)
> +child.text = str(val)
> +elem.append(child)
> +return elem
> -- 
> 2.7.3
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH 2/2] oe-selftest: Add option to submit test result to a git repository.

2016-11-29 Thread Benjamin Esquivel
On Tue, 2016-11-29 at 08:42 -0600, mariano.lo...@linux.intel.com wrote:
> From: Mariano Lopez 
> 
> This new option allows to commit the result to a git repository,
> along with the results it will add a metadata file for information
> of the current selftest run, such as: hostname, machine, distro,
> distro version, host version, and layers.
> 
> This implementation will have a branch per different hostname,
> testing branch, and machine.
> 
> To use this feature use:
> 
> oe-selftest  --repository 
> 
> [YOCTO #9954]
> 
> Signed-off-by: Mariano Lopez 
> ---
>  scripts/oe-selftest | 98
> +
>  1 file changed, 98 insertions(+)
> 
> diff --git a/scripts/oe-selftest b/scripts/oe-selftest
> index deaa432..81dfa3d 100755
> --- a/scripts/oe-selftest
> +++ b/scripts/oe-selftest
> @@ -36,6 +36,7 @@ import re
>  import fnmatch
>  import collections
>  import imp
> +import git
>  
>  sys.path.insert(0, os.path.dirname(os.path.realpath(__file__)) +
> '/lib')
>  import scriptpath
> @@ -46,6 +47,7 @@ import argparse_oe
>  import oeqa.selftest
>  import oeqa.utils.ftools as ftools
>  from oeqa.utils.commands import runCmd, get_bb_var, get_test_layer
> +from oeqa.utils.metadata import metadata_from_bb,
> write_metadata_file
>  from oeqa.selftest.base import oeSelfTest, get_available_machines
>  
>  try:
> @@ -106,6 +108,8 @@ def get_args_parser():
> help='List all tags that have been set to
> test cases.')
>  parser.add_argument('--machine', required=False, dest='machine',
> choices=['random', 'all'], default=None,
>  help='Run tests on different machines
> (random/all).')
> +parser.add_argument('--repository', required=False,
> dest='repository', default='', action='store',
> +help='Submit test results to a repository')
>  return parser
>  
>  
> @@ -572,6 +576,71 @@ def main():
>  
>  log.info("Finished")
>  
> +if args.repository:
oe-selftest is already long and not so modular, is there a chance to
send these actions to methods outside oe-selftest and import them? it
would also make them accessible to other data flows that wish to do the
same.
> +# Commit tests results to repository
> +metadata = metadata_from_bb()
> +git_dir = os.path.join(os.getcwd(), 'selftest')
> +if not os.path.isdir(git_dir):
> +os.mkdir(git_dir)
> +
> +log.debug('Checking for git repository in %s' % git_dir)
> +try:
> +repo = git.Repo(git_dir)
> +except git.exc.InvalidGitRepositoryError:
> +log.debug("Couldn't find git repository %s; "
> + "cloning from %s" % (git_dir,
> args.repository))
> +repo = git.Repo.clone_from(args.repository, git_dir)
> +
> +r_branches = repo.git.branch(r=True)
> +r_branches = set(r_branches.replace('origin/',
> '').split())
> +l_branches = {str(branch) for branch in repo.branches}
> +branch = '%s/%s/%s' % (metadata['hostname'],
> +   metadata['layers']['meta']['branc
> h'],
> +   metadata['machine'])
> +
> +if branch in r_branches:
> +log.debug('Found branch in remote repository,
> checking'
> +  ' out and pulling')
> +repo.git.checkout(branch)
> +repo.git.pull()
> +elif branch in l_branches:
> +log.debug('Found branch in local repository,
> checking out')
> +repo.git.checkout(branch)
can you explain why the remote branches have precedence over the local
branches here?
> +else:
> +log.debug('New branch %s' % branch)
> +repo.git.checkout('master')
> +repo.git.checkout(b=branch)
> +
> +cleanResultsDir(repo)
> +xml_dir = os.path.join(os.getcwd(), log_prefix)
> +copyResultFiles(xml_dir, git_dir, repo)
> +metadata_file = os.path.join(git_dir, 'metadata.xml')
> +write_metadata_file(metadata_file, metadata)
> +repo.index.add([metadata_file])
> +repo.index.write()
> +
> +# Get information for commit message
> +layer_info = ''
> +for layer, values in metadata['layers'].items():
> +layer_info = '%s%-17s = %s:%s\n' % (layer_info,
> layer,
> +  values['branch'], values['revision'])
> +msg = 'Selftest for build %s of %s %s for machine %s on
> %s\n\n%s' % (
> +   log_prefix[12:], metadata['distro'],
> metadata['distro_version'],
> +   metadata['machine'], metadata['hostname'],
> layer_info)
> +
> +log.debug('Commiting results to local repository')
> +repo.index.commit(msg)
> +if n

Re: [OE-core] [PATCH 1/2] oeqa/utils/metadata.py: Add metadata library

2016-11-29 Thread Mariano Lopez
On Tuesday, November 29, 2016 04:17:25 PM Benjamin Esquivel wrote:
> On Tue, 2016-11-29 at 08:42 -0600, mariano.lo...@linux.intel.com wrote:
> > From: Mariano Lopez 
> > 
> > Adds functions to get metadata from the host running the tests.
> > 
> > [YOCTO #9954]
> > 
> > Signed-off-by: Mariano Lopez 
> > ---
> >  meta/lib/oeqa/utils/metadata.py | 77
> > +
> >  1 file changed, 77 insertions(+)
> >  create mode 100644 meta/lib/oeqa/utils/metadata.py
> > 
> > diff --git a/meta/lib/oeqa/utils/metadata.py
> > b/meta/lib/oeqa/utils/metadata.py
> > new file mode 100644
> > index 000..3be805c
> > --- /dev/null
> > +++ b/meta/lib/oeqa/utils/metadata.py
> > @@ -0,0 +1,77 @@
> > +# Copyright (C) 2016 Intel Corporation
> > +#
> > +# Released under the MIT license (see COPYING.MIT)
> > +#
> > +# Functions to get metadata from the testing host used
> > +# for analytics of test results.
> > +
> > +from git import Repo
> > +from collections import OrderedDict
> > +from collections.abc import MutableMapping
> > +from xml.dom.minidom import parseString
> > +from xml.etree.ElementTree import Element, tostring
> > +
> > +from oe.lsb import distro_identifier
> > +from oeqa.utils.commands import runCmd, get_bb_var
> > +
> > +def metadata_from_bb():
> > +""" Returns test's metadata as OrderedDict.
> > +
> > +Data will be gathered using bitbake -e thanks to get_bb_var.
> > +"""
> > +
> > +info_dict = OrderedDict()
> > +hostname = runCmd('hostname')
> > +info_dict['hostname'] = hostname.output
> > +info_dict['machine'] = get_bb_var('MACHINE')
> > +info_dict['distro'] = get_bb_var('DISTRO')
> > +info_dict['distro_version'] = get_bb_var('DISTRO_VERSION')
> > +host_distro= distro_identifier()
> > +host_distro, _, host_distro_release = host_distro.partition('-')
> > +info_dict['host_distro'] = host_distro
> > +info_dict['host_distro_release'] = host_distro_release
> > +info_dict['layers'] = get_layers(get_bb_var('BBLAYERS'))
> is none of the upper statements going to throw exceptions? otherwise
> try/except as appropriate.

I really don't expect this code to throw an exception, these are bitbake
commands running in the host.

> > +return info_dict
> > +
> > +def metadata_from_data_store(d):
> > +""" Returns test's metadata as OrderedDict.
> > +
> > +Data will be collected from the provided data store.
> > +"""
> > +# TODO: Getting metadata from the data store would
> > +# be useful when running within bitbake.
> > +pass
> > +
> > +def get_layers(layers):
> > +""" Returns layer name, branch, and revision as OrderedDict. """
> > +
> > +layer_dict = OrderedDict()
> > +for layer in layers.split():
> > +layer_name = os.path.basename(layer)
> > +layer_dict[layer_name] = OrderedDict()
> > +repo = Repo(layer, search_parent_directories=True)
> > +revision, branch = repo.head.object.name_rev.split()
> > +layer_dict[layer_name]['branch'] = branch
> > +layer_dict[layer_name]['revision'] = revision
> same here for the try/except, did you test with usual cases of zero
> input and unexisting path's, etc?

If the function doesn't receive input, it won't enter in the loop, in case the
directory doesn't exists bitbake would complain long before reaching this
code. If the user gets creative enough to not pass a valid BBLAYER value
I think s/he deserve to be bitten by the exception.

> > +return layer_dict
> > +
> > +def write_metadata_file(file_path, metadata):
> > +""" Writes metadata to a XML file in directory. """
> > +
> > +xml = dict_to_XML('metadata', metadata)
> > +xml_doc = parseString(tostring(xml).decode('UTF-8'))
> > +with open(file_path, 'w') as f:
> > +f.write(xml_doc.toprettyxml())
> > +
> > +def dict_to_XML(tag, dictionary):
> > +""" Return XML element converting dicts recursively. """
> > +
> > +elem = Element(tag)
> > +for key, val in dictionary.items():
> > +if isinstance(val, MutableMapping):
> > +child = (dict_to_XML(key, val))
> > +else:
> > +child = Element(key)
> > +child.text = str(val)
> > +elem.append(child)
> > +return elem
> > -- 
> > 2.7.3
> > 

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH 2/2] oe-selftest: Add option to submit test result to a git repository.

2016-11-29 Thread Mariano Lopez
On Tuesday, November 29, 2016 04:26:45 PM Benjamin Esquivel wrote:
> On Tue, 2016-11-29 at 08:42 -0600, mariano.lo...@linux.intel.com wrote:
> > From: Mariano Lopez 
> > 
> > This new option allows to commit the result to a git repository,
> > along with the results it will add a metadata file for information
> > of the current selftest run, such as: hostname, machine, distro,
> > distro version, host version, and layers.
> > 
> > This implementation will have a branch per different hostname,
> > testing branch, and machine.
> > 
> > To use this feature use:
> > 
> > oe-selftest  --repository 
> > 
> > [YOCTO #9954]
> > 
> > Signed-off-by: Mariano Lopez 
> > ---
> >  scripts/oe-selftest | 98
> > +
> >  1 file changed, 98 insertions(+)
> > 
> > diff --git a/scripts/oe-selftest b/scripts/oe-selftest
> > index deaa432..81dfa3d 100755
> > --- a/scripts/oe-selftest
> > +++ b/scripts/oe-selftest
> > @@ -36,6 +36,7 @@ import re
> >  import fnmatch
> >  import collections
> >  import imp
> > +import git
> >  
> >  sys.path.insert(0, os.path.dirname(os.path.realpath(__file__)) +
> > '/lib')
> >  import scriptpath
> > @@ -46,6 +47,7 @@ import argparse_oe
> >  import oeqa.selftest
> >  import oeqa.utils.ftools as ftools
> >  from oeqa.utils.commands import runCmd, get_bb_var, get_test_layer
> > +from oeqa.utils.metadata import metadata_from_bb,
> > write_metadata_file
> >  from oeqa.selftest.base import oeSelfTest, get_available_machines
> >  
> >  try:
> > @@ -106,6 +108,8 @@ def get_args_parser():
> > help='List all tags that have been set to
> > test cases.')
> >  parser.add_argument('--machine', required=False, dest='machine',
> > choices=['random', 'all'], default=None,
> >  help='Run tests on different machines
> > (random/all).')
> > +parser.add_argument('--repository', required=False,
> > dest='repository', default='', action='store',
> > +help='Submit test results to a repository')
> >  return parser
> >  
> >  
> > @@ -572,6 +576,71 @@ def main():
> >  
> >  log.info("Finished")
> >  
> > +if args.repository:
> oe-selftest is already long and not so modular, is there a chance to
> send these actions to methods outside oe-selftest and import them? it
> would also make them accessible to other data flows that wish to do the
> same.

It would be possible to move this code to a module, although the specific
needs of every test would be different, for example the clean and add
functions must be different for everyone. I would leave it here and check
the needs of other test to check if this can be reused. I would do that
work, because I'm already familiar with this.

> > +# Commit tests results to repository
> > +metadata = metadata_from_bb()
> > +git_dir = os.path.join(os.getcwd(), 'selftest')
> > +if not os.path.isdir(git_dir):
> > +os.mkdir(git_dir)
> > +
> > +log.debug('Checking for git repository in %s' % git_dir)
> > +try:
> > +repo = git.Repo(git_dir)
> > +except git.exc.InvalidGitRepositoryError:
> > +log.debug("Couldn't find git repository %s; "
> > + "cloning from %s" % (git_dir,
> > args.repository))
> > +repo = git.Repo.clone_from(args.repository, git_dir)
> > +
> > +r_branches = repo.git.branch(r=True)
> > +r_branches = set(r_branches.replace('origin/',
> > '').split())
> > +l_branches = {str(branch) for branch in repo.branches}
> > +branch = '%s/%s/%s' % (metadata['hostname'],
> > +   metadata['layers']['meta']['branc
> > h'],
> > +   metadata['machine'])
> > +
> > +if branch in r_branches:
> > +log.debug('Found branch in remote repository,
> > checking'
> > +  ' out and pulling')
> > +repo.git.checkout(branch)
> > +repo.git.pull()
> > +elif branch in l_branches:
> > +log.debug('Found branch in local repository,
> > checking out')
> > +repo.git.checkout(branch)
> can you explain why the remote branches have precedence over the local
> branches here?

Because some other system could have pushed before and our branch is
not up date.

> > +else:
> > +log.debug('New branch %s' % branch)
> > +repo.git.checkout('master')
> > +repo.git.checkout(b=branch)
> > +
> > +cleanResultsDir(repo)
> > +xml_dir = os.path.join(os.getcwd(), log_prefix)
> > +copyResultFiles(xml_dir, git_dir, repo)
> > +metadata_file = os.path.join(git_dir, 'metadata.xml')
> > +write_metadata_file(metadata_file, metadata)
> > +repo.index.add([metadata_file

[OE-core] [PATCH] sqlite3: 3.14.1 -> 3.15.1

2016-11-29 Thread huangqy
From: Huang Qiyu 

Upgrade sqlite3 from 3.14.1 to 3.15.1.

Signed-off-by: Huang Qiyu 
---
 meta/recipes-support/sqlite/{sqlite3_3.14.1.bb => sqlite3_3.15.1.bb} | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-support/sqlite/{sqlite3_3.14.1.bb => sqlite3_3.15.1.bb} 
(66%)

diff --git a/meta/recipes-support/sqlite/sqlite3_3.14.1.bb 
b/meta/recipes-support/sqlite/sqlite3_3.15.1.bb
similarity index 66%
rename from meta/recipes-support/sqlite/sqlite3_3.14.1.bb
rename to meta/recipes-support/sqlite/sqlite3_3.15.1.bb
index 7c8fa40..c315a53 100644
--- a/meta/recipes-support/sqlite/sqlite3_3.14.1.bb
+++ b/meta/recipes-support/sqlite/sqlite3_3.15.1.bb
@@ -8,5 +8,5 @@ SRC_URI = "\
   file://0001-revert-ad601c7962-that-brings-2-increase-of-build-ti.patch \
   "
 
-SRC_URI[md5sum] = "3634a90a3f49541462bcaed3474b2684"
-SRC_URI[sha256sum] = 
"bc7182476900017becb81565ecea7775d46ab747a97281aa610f4f45881c47a6"
+SRC_URI[md5sum] = "0259d52be88f085d104c6d2aaa8349ac"
+SRC_URI[sha256sum] = 
"5dfa89b7697ee3c2ac7b44e8e157e7f204bf999c866afcaa8bb1c7ff656ae2c5"
-- 
2.7.4



-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH] devtool: execute associated functions while preparing the source tree

2016-11-29 Thread Jiajie Hu
Hi, Paul

On Wednesday, November 30, 2016 07:01:30 AM Paul Eggleton wrote:
> So this in itself looks reasonable in theory, but I have to warn you that
> when we switch to tinfoil2 [1] these commits are going to be done via the
> metadata instead, and beyond a possible hack that I'd really rather not
> think about it's going to be a bit difficult to intercept the
> prefuncs/postfuncs there. At least they will be executed though since with
> tinfoil2 we'll be going through a much more standard path to run the tasks.
> 
> Cheers,
> Paul
> 
> [1] https://wiki.yoctoproject.org/wiki/Tinfoil2

Glad to know that my fix can be superseded by tinfoil2 APIs. Do you have any 
estimation when the switch will happen?

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH] devtool: execute associated functions while preparing the source tree

2016-11-29 Thread Paul Eggleton
On Wed, 30 Nov 2016 09:33:22 Jiajie Hu wrote:
> On Wednesday, November 30, 2016 07:01:30 AM Paul Eggleton wrote:
> > So this in itself looks reasonable in theory, but I have to warn you that
> > when we switch to tinfoil2 [1] these commits are going to be done via the
> > metadata instead, and beyond a possible hack that I'd really rather not
> > think about it's going to be a bit difficult to intercept the
> > prefuncs/postfuncs there. At least they will be executed though since with
> > tinfoil2 we'll be going through a much more standard path to run the
> > tasks.
> >
> > [1] https://wiki.yoctoproject.org/wiki/Tinfoil2
> 
> Glad to know that my fix can be superseded by tinfoil2 APIs. Do you have any
> estimation when the switch will happen?

The target is 2.3 milestone 1, which is in December. However there are still a 
lot of things to be fixed as I've noted on the wiki page I linked.

Thinking about it though it's possible I could split out this particular 
change and get it sent earlier - in fact that may be a good idea anyway. I'll 
look into that.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH] qemu*.conf: Add slirp support for all qemu machines

2016-11-29 Thread Robert Yang



On 11/30/2016 02:24 AM, Randy Witt wrote:




"-device virtio-net-device,netdev=net0" and
"-netdev user,id=net0,hostfwd=tcp::-: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'm aware that this will only work for one instance, but currently it doesn't
work at all and it blocks a high priority bug. The only way to make it 100%
work, would be to have qemu do the binding of the port to a dynamic one and then
the user queries it after. Otherwise there is always a window where another
process could bind to the port.


We can check whether the port is free and use another one if not, we've
already done similar things in runqemu-export-rootfs for nfs, please see:

http://lists.openembedded.org/pipermail/openembedded-core/2016-November/129376.html

// Robert



I don't think the bsp should be in the business of choosing which ports to
forward. And if it is, then it should be a separate option in the qemuboot.conf,
with just the "-netdev user" part because otherwise the user will always have to
modify qemuboot.conf just to forward different ports.

It makes more sense to let the user do something like "runqemu slirp=22,65,..."
and then return back the actual port used in the forwarding.







--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH 1/1] kernel-devsrc: remove symlink source

2016-11-29 Thread Robert Yang



On 11/29/2016 06:57 PM, Bruce Ashfield wrote:



On Tue, Nov 29, 2016 at 4:16 AM, Robert Yang mailto:liezhi.y...@windriver.com>> wrote:

Fixed:
$ rpm -qplv tmp/deploy/rpm/qemuppc/kernel-devsrc-1.0-r0.qemuppc.rpm | grep
kernel/source
/usr/src/kernel/source ->

/buildarea/lyang1/test_yocto/tmp/work/qemuppc-poky-linux/kernel-devsrc/1.0-r0/image/usr/src/kernel

It is generated by kernel's "make clean _mrproper_scripts", the
kernel-devsrc includeds full sources, this symlink is not needed, and
the path is invalid on target, so remove it.

Signed-off-by: Robert Yang mailto:liezhi.y...@windriver.com>>
---
 meta/recipes-kernel/linux/kernel-devsrc.bb  | 7
+++
 1 file changed, 7 insertions(+)

diff --git a/meta/recipes-kernel/linux/kernel-devsrc.bb
 b/meta/recipes-kernel/linux/kernel-devsrc.bb

index 9fd2e08..b182936 100644
--- a/meta/recipes-kernel/linux/kernel-devsrc.bb 
+++ b/meta/recipes-kernel/linux/kernel-devsrc.bb 
@@ -53,6 +53,13 @@ do_install() {
 # architecture (since scripts and helpers are native format).
 KBUILD_OUTPUT="$kerneldir"
 oe_runmake -C $kerneldir CC="${KERNEL_CC}" LD="${KERNEL_LD}" clean
_mrproper_scripts
+# make clean generates an absolute path symlink called "source"
+# in $kerneldir points to $kerneldir, which doesn't make any
+# sense, so remove it.
+if [ -L $kerneldir/source ]; then
+bbnote "Removing $kerneldir/source"


This message needs to be clarified. When that comes out, I'd read it and think
"it is removing my kernel source".

Maybe:

 bbnote "Removing $kerneldir/source symlink"

is better.


Thanks, updated in the repo:

diff --git a/meta/recipes-kernel/linux/kernel-devsrc.bb 
b/meta/recipes-kernel/linux/kernel-devsrc.bb

index 9fd2e08..7004261 100644
--- a/meta/recipes-kernel/linux/kernel-devsrc.bb
+++ b/meta/recipes-kernel/linux/kernel-devsrc.bb
@@ -53,6 +53,13 @@ do_install() {
 # architecture (since scripts and helpers are native format).
 KBUILD_OUTPUT="$kerneldir"
 oe_runmake -C $kerneldir CC="${KERNEL_CC}" LD="${KERNEL_LD}" clean 
_mrproper_scripts

+# make clean generates an absolute path symlink called "source"
+# in $kerneldir points to $kerneldir, which doesn't make any
+# sense, so remove it.
+if [ -L $kerneldir/source ]; then
+bbnote "Removing $kerneldir/source symlink"
+rm -f $kerneldir/source
+fi

 # As of Linux kernel version 3.0.1, the clean target removes
 # arch/powerpc/lib/crtsavres.o which is present in


// Robert



Bruce


+rm -f $kerneldir/source
+fi

 # As of Linux kernel version 3.0.1, the clean target removes
 # arch/powerpc/lib/crtsavres.o which is present in
--
2.9.0

--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org

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
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH] devtool: execute associated functions while preparing the source tree

2016-11-29 Thread Paul Eggleton
On Wed, 30 Nov 2016 14:39:12 Paul Eggleton wrote:
> On Wed, 30 Nov 2016 09:33:22 Jiajie Hu wrote:
> > On Wednesday, November 30, 2016 07:01:30 AM Paul Eggleton wrote:
> > > So this in itself looks reasonable in theory, but I have to warn you
> > > that when we switch to tinfoil2 [1] these commits are going to be done
> > > via the metadata instead, and beyond a possible hack that I'd really
> > > rather not think about it's going to be a bit difficult to intercept the
> > > prefuncs/postfuncs there. At least they will be executed though since
> > > with tinfoil2 we'll be going through a much more standard path to run
> > > the tasks.
> > > 
> > > [1] https://wiki.yoctoproject.org/wiki/Tinfoil2
> > 
> > Glad to know that my fix can be superseded by tinfoil2 APIs. Do you have
> > any estimation when the switch will happen?
> 
> The target is 2.3 milestone 1, which is in December. However there are still
> a lot of things to be fixed as I've noted on the wiki page I linked.
> 
> Thinking about it though it's possible I could split out this particular
> change and get it sent earlier - in fact that may be a good idea anyway.
> I'll look into that.

Actually, I spoke too soon. Whilst moving the creation of commits out to the 
metadata can be done separately (and is already implemented in a separate 
patch), it won't actually help on its own because it doesn't change how the 
tasks are executed. The bit we need is executing the tasks as they would be 
executed normally, and unfortunately that's not possible without the full 
tinfoil2 changeset.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH 0/2] fix can't login when debug-tweaks is not in IMAGE_FEATURES

2016-11-29 Thread Robert Yang

Hello,

According to the discussions, here are things that we may do,
please feel free to give your comments.
1) Add an image feature like "production", which will conflict with
   debug-tweaks, and check for some common security issues ?

2) Add a way like ROOT_PASSWD to let user can set root passwd easily ?

3) Do nothing, leave it as the current status.

// Robert

On 11/23/2016 03:49 PM, Robert Yang wrote:

Fixed 2 bugs:
- Can't login as root when debug-tweaks/empty-root-password is not in
  IMAGE_FEATURES since no passwd.
- When set root passwd and debug-tweaks/empty-root-password is in
  IMAGE_FEATURES, passwd is *required* to login.

Filed https://bugzilla.yoctoproject.org/show_bug.cgi?id=10710, and
marked doc changes required as yes.

// Robert

The following changes since commit a675b2c89e477af088faee9b3be96eae19a85f0b:

  sanity.bbclass: fix logging of an error (2016-11-15 15:18:50 +)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib rbt/root
  
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=rbt/root

Robert Yang (2):
  rootfs-postcommands.bbclass: fix zap_empty_root_password
  base-passwd: set root's default password to 'root'

 meta/classes/rootfs-postcommands.bbclass |  8 
 .../base-passwd/base-passwd/passwd_master.patch  | 16 
 meta/recipes-core/base-passwd/base-passwd_3.5.29.bb  |  1 +
 3 files changed, 21 insertions(+), 4 deletions(-)
 create mode 100644 
meta/recipes-core/base-passwd/base-passwd/passwd_master.patch


--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH] strace: 4.13 -> 4.14

2016-11-29 Thread huangqy
From: Huang Qiyu 

Upgrade strace from 4.13 to 4.14.

Signed-off-by: Huang Qiyu 
---
 meta/recipes-devtools/strace/{strace_4.13.bb => strace_4.14.bb} | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-devtools/strace/{strace_4.13.bb => strace_4.14.bb} (91%)

diff --git a/meta/recipes-devtools/strace/strace_4.13.bb 
b/meta/recipes-devtools/strace/strace_4.14.bb
similarity index 91%
rename from meta/recipes-devtools/strace/strace_4.13.bb
rename to meta/recipes-devtools/strace/strace_4.14.bb
index cae7f21..452925c 100644
--- a/meta/recipes-devtools/strace/strace_4.13.bb
+++ b/meta/recipes-devtools/strace/strace_4.14.bb
@@ -15,8 +15,8 @@ SRC_URI = "${SOURCEFORGE_MIRROR}/strace/strace-${PV}.tar.xz \
file://mips-SIGEMT.patch \
"
 
-SRC_URI[md5sum] = "4b78c7febdd24c79d5147824d1a080a3"
-SRC_URI[sha256sum] = 
"d48f732576c91ece36a5843d63f9be054c40ef59f1e4773986042636861625d7"
+SRC_URI[md5sum] = "1e39b5f7583256d7dc21170b9da529ae"
+SRC_URI[sha256sum] = 
"5bed5110b243dce6864bedba269446c18c8c63f553cdd7fd4f808d89a764712f"
 
 inherit autotools ptest bluetooth
 
-- 
2.7.4



-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH V5] subprocess cleanup

2016-11-29 Thread Stephano Cetola
changed since V4:
Removed single quotes from the --show-format option on smart query.
The quote was causing the arch search to fail in the following for
loop.

Stephano Cetola (1):
  package_manager: remove strings and migrate to direct arrays

 meta/lib/oe/package.py |  13 +--
 meta/lib/oe/package_manager.py | 229 -
 2 files changed, 118 insertions(+), 124 deletions(-)

-- 
2.10.2

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH V5] package_manager: remove strings and migrate to direct arrays

2016-11-29 Thread Stephano Cetola
When using subprocess call and check_output, it is better to use arrays
rather than strings when possible to avoid whitespace and quoting
problems.

[ YOCTO #9342 ]

Signed-off-by: Stephano Cetola 
---
 meta/lib/oe/package.py |  13 +--
 meta/lib/oe/package_manager.py | 229 -
 2 files changed, 118 insertions(+), 124 deletions(-)

diff --git a/meta/lib/oe/package.py b/meta/lib/oe/package.py
index 02642f2..ae60a58 100644
--- a/meta/lib/oe/package.py
+++ b/meta/lib/oe/package.py
@@ -18,23 +18,24 @@ def runstrip(arg):
 newmode = origmode | stat.S_IWRITE | stat.S_IREAD
 os.chmod(file, newmode)
 
-extraflags = ""
+stripcmd = [strip]
 
 # kernel module
 if elftype & 16:
-extraflags = "--strip-debug --remove-section=.comment 
--remove-section=.note --preserve-dates"
+stripcmd.extend(["--strip-debug", "--remove-section=.comment",
+"--remove-section=.note", "--preserve-dates"])
 # .so and shared library
 elif ".so" in file and elftype & 8:
-extraflags = "--remove-section=.comment --remove-section=.note 
--strip-unneeded"
+stripcmd.extend(["--remove-section=.comment", 
"--remove-section=.note", "--strip-unneeded"])
 # shared or executable:
 elif elftype & 8 or elftype & 4:
-extraflags = "--remove-section=.comment --remove-section=.note"
+stripcmd.extend(["--remove-section=.comment", 
"--remove-section=.note"])
 
-stripcmd = "'%s' %s '%s'" % (strip, extraflags, file)
+stripcmd.append(file)
 bb.debug(1, "runstrip: %s" % stripcmd)
 
 try:
-output = subprocess.check_output(stripcmd, stderr=subprocess.STDOUT, 
shell=True)
+output = subprocess.check_output(stripcmd, stderr=subprocess.STDOUT)
 except subprocess.CalledProcessError as e:
 bb.error("runstrip: '%s' strip command failed with %s (%s)" % 
(stripcmd, e.returncode, e.output))
 
diff --git a/meta/lib/oe/package_manager.py b/meta/lib/oe/package_manager.py
index 7ba2e4d..d4a5185 100644
--- a/meta/lib/oe/package_manager.py
+++ b/meta/lib/oe/package_manager.py
@@ -358,12 +358,11 @@ class RpmPkgsList(PkgsList):
 RpmIndexer(d, rootfs_dir).get_ml_prefix_and_os_list(arch_var, 
os_var)
 
 # Determine rpm version
-cmd = "%s --version" % self.rpm_cmd
 try:
-output = subprocess.check_output(cmd, stderr=subprocess.STDOUT, 
shell=True).decode("utf-8")
+output = subprocess.check_output([self.rpm_cmd, "--version"], 
stderr=subprocess.STDOUT).decode("utf-8")
 except subprocess.CalledProcessError as e:
 bb.fatal("Getting rpm version failed. Command '%s' "
- "returned %d:\n%s" % (cmd, e.returncode, 
e.output.decode("utf-8")))
+ "returned %d:\n%s" % (self.rpm_cmd, e.returncode, 
e.output.decode("utf-8")))
 
 '''
 Translate the RPM/Smart format names to the OE multilib format names
@@ -412,16 +411,15 @@ class RpmPkgsList(PkgsList):
 return output
 
 def list_pkgs(self):
-cmd = self.rpm_cmd + ' --root ' + self.rootfs_dir
-cmd += ' -D "_dbpath /var/lib/rpm" -qa'
-cmd += " --qf '[%{NAME} %{ARCH} %{VERSION} %{PACKAGEORIGIN}\n]'"
+cmd = [self.rpm_cmd, '--root', self.rootfs_dir]
+cmd.extend(['-D', '_dbpath /var/lib/rpm'])
+cmd.extend(['-qa', '--qf', '[%{NAME} %{ARCH} %{VERSION} 
%{PACKAGEORIGIN}\n]'])
 
 try:
-# bb.note(cmd)
-tmp_output = subprocess.check_output(cmd, 
stderr=subprocess.STDOUT, shell=True).strip().decode("utf-8")
+tmp_output = subprocess.check_output(cmd, 
stderr=subprocess.STDOUT).strip().decode("utf-8")
 except subprocess.CalledProcessError as e:
 bb.fatal("Cannot get the installed packages list. Command '%s' "
- "returned %d:\n%s" % (cmd, e.returncode, 
e.output.decode("utf-8")))
+ "returned %d:\n%s" % (' '.join(cmd), e.returncode, 
e.output.decode("utf-8")))
 
 output = dict()
 deps = dict()
@@ -672,11 +670,11 @@ class RpmPM(PackageManager):
 # 2 = --log-level=debug
 # 3 = --log-level=debug plus dumps of scriplet content and command 
invocation
 self.debug_level = int(d.getVar('ROOTFS_RPM_DEBUG', True) or "0")
-self.smart_opt = "--log-level=%s --data-dir=%s" % \
+self.smart_opt = ["--log-level=%s" %
  ("warning" if self.debug_level == 0 else
   "info" if self.debug_level == 1 else
-  "debug",
-  os.path.join(target_rootfs, 'var/lib/smart'))
+  "debug"), "--data-dir=%s" %
+  os.path.join(target_rootfs, 'var/lib/smart')]
 self.scriptlet_wrapper = self.d.expand('${WORKDIR}/scriptlet_wrapper')
 self.solution_manifest = self.d.expand('${T}/saved/%s_solution' %
 

[OE-core] [PATCH] bluez5: 5.42 -> 5.43

2016-11-29 Thread huangqy
From: Huang Qiyu 

Upgrade bluez5 from 5.42 to 5.43.

Signed-off-by: Huang Qiyu 
---
 meta/recipes-connectivity/bluez5/{bluez5_5.42.bb => bluez5_5.43.bb} | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-connectivity/bluez5/{bluez5_5.42.bb => bluez5_5.43.bb} 
(89%)

diff --git a/meta/recipes-connectivity/bluez5/bluez5_5.42.bb 
b/meta/recipes-connectivity/bluez5/bluez5_5.43.bb
similarity index 89%
rename from meta/recipes-connectivity/bluez5/bluez5_5.42.bb
rename to meta/recipes-connectivity/bluez5/bluez5_5.43.bb
index e6ab9b6..e10b82d 100644
--- a/meta/recipes-connectivity/bluez5/bluez5_5.42.bb
+++ b/meta/recipes-connectivity/bluez5/bluez5_5.43.bb
@@ -2,8 +2,8 @@ require bluez5.inc
 
 REQUIRED_DISTRO_FEATURES = "bluez5"
 
-SRC_URI[md5sum] = "cc8c53133d5be0d6c126e00cf2529028"
-SRC_URI[sha256sum] = 
"4f166fed80fc017396d6f2b3cae5185520875ab456d1c74d6b4eaa4da0e16109"
+SRC_URI[md5sum] = "698def88df96840dfbb0858bb6d73350"
+SRC_URI[sha256sum] = 
"16c9c05d2a1da644ce3570d975ada3643d2e60c007a955bac09c0a0efeb58d15"
 
 # noinst programs in Makefile.tools that are conditional on READLINE
 # support
-- 
2.7.4



-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH] iw: 4.7 -> 4.9

2016-11-29 Thread huangqy
From: Huang Qiyu 

Upgrade iw from 4.7 to 4.9.

Signed-off-by: Huang Qiyu 
---
 meta/recipes-connectivity/iw/{iw_4.7.bb => iw_4.9.bb} | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-connectivity/iw/{iw_4.7.bb => iw_4.9.bb} (86%)

diff --git a/meta/recipes-connectivity/iw/iw_4.7.bb 
b/meta/recipes-connectivity/iw/iw_4.9.bb
similarity index 86%
rename from meta/recipes-connectivity/iw/iw_4.7.bb
rename to meta/recipes-connectivity/iw/iw_4.9.bb
index e9f4141..6daeb07 100644
--- a/meta/recipes-connectivity/iw/iw_4.7.bb
+++ b/meta/recipes-connectivity/iw/iw_4.9.bb
@@ -14,8 +14,8 @@ SRC_URI = 
"http://www.kernel.org/pub/software/network/iw/${BP}.tar.gz \
file://separate-objdir.patch \
 "
 
-SRC_URI[md5sum] = "19d1edd276b2ac0c6cccfc7ae8d2b732"
-SRC_URI[sha256sum] = 
"758092229f13d691968060a0ad41364ba8eb8da4503626c20233a5b1eb33b4d9"
+SRC_URI[md5sum] = "06e96ab7a5c652f8eaed6f71533a9e0f"
+SRC_URI[sha256sum] = 
"12f921f3dbe0f33c309f5f2891cccf5325c94bd48dceeb102de183f5f048a9e2"
 
 inherit pkgconfig
 
-- 
2.7.4



-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH] man-pages: 4.07 -> 4.08

2016-11-29 Thread huangqy
From: Huang Qiyu 

Upgrade man-pages from 4.07 to 4.08.

Signed-off-by: Huang Qiyu 
---
 .../man-pages/{man-pages_4.07.bb => man-pages_4.08.bb}| 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-extended/man-pages/{man-pages_4.07.bb => 
man-pages_4.08.bb} (86%)

diff --git a/meta/recipes-extended/man-pages/man-pages_4.07.bb 
b/meta/recipes-extended/man-pages/man-pages_4.08.bb
similarity index 86%
rename from meta/recipes-extended/man-pages/man-pages_4.07.bb
rename to meta/recipes-extended/man-pages/man-pages_4.08.bb
index 76a3fd8..8fc6cb0 100644
--- a/meta/recipes-extended/man-pages/man-pages_4.07.bb
+++ b/meta/recipes-extended/man-pages/man-pages_4.08.bb
@@ -7,8 +7,8 @@ LICENSE = "GPLv2+"
 LIC_FILES_CHKSUM = "file://README;md5=8f2a3d43057d458e5066714980567a60"
 SRC_URI = "${KERNELORG_MIRROR}/linux/docs/${BPN}/Archive/${BP}.tar.gz"
 
-SRC_URI[md5sum] = "05ba1cb21e99d02bd7bc1a59378965d2"
-SRC_URI[sha256sum] = 
"c973351131931f7700f5e9fbf4ef366c43ea7c1515d282e8d5db9c77590c4c93"
+SRC_URI[md5sum] = "88760ffa6cf92495327758b828850015"
+SRC_URI[sha256sum] = 
"1fa6529ab2784e7db2a498feb2c5307f4afb87dff0e3321e5964265e2e8433fd"
 
 RDEPENDS_${PN} = "man"
 
-- 
2.7.4



-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH] gstreamer1.0: Upgrade to 1.10.1

2016-11-29 Thread Khem Raj
Remove backported patches and upstreamed ones
Drop --disable-trace its no more in 1.10.x

Add packageconfig option for kms, keep it disabled by default
in bad plugins recipe

Signed-off-by: Khem Raj 
---
 ...libav_1.8.3.bb => gstreamer1.0-libav_1.10.1.bb} |   5 +-
 .../gstreamer/gstreamer1.0-plugins-bad.inc |   1 +
 ...-don-t-hardcode-libtool-name-when-running.patch |  35 +-
 ...gl.pc.in-don-t-append-GL_CFLAGS-to-CFLAGS.patch |  15 +-
 ...lplugin-enable-gldeinterlace-on-OpenGL-ES.patch | 634 -
 ...ert-implement-multiple-render-targets-for.patch | 244 
 ...ert-don-t-use-the-predefined-variable-nam.patch |  32 --
 .../0005-glshader-add-glBindFragDataLocation.patch |  77 ---
 ...ert-GLES3-deprecates-texture2D-and-it-doe.patch |  51 --
 .../0008-gl-implement-GstGLMemoryEGL.patch | 495 
 ...valid-sentinels-for-gst_structure_get-etc.patch |  59 +-
 ...1.8.3.bb => gstreamer1.0-plugins-bad_1.10.1.bb} |  10 +-
 8.3.bb => gstreamer1.0-plugins-base_1.10.1.bb} |   5 +-
 8.3.bb => gstreamer1.0-plugins-good_1.10.1.bb} |   5 +-
 8.3.bb => gstreamer1.0-plugins-ugly_1.10.1.bb} |   5 +-
 .../gstreamer/gstreamer1.0-rtsp-server_1.10.1.bb   |   6 +
 .../gstreamer/gstreamer1.0-rtsp-server_1.8.3.bb|   6 -
 meta/recipes-multimedia/gstreamer/gstreamer1.0.inc |   1 -
 ...streamer1.0_1.8.3.bb => gstreamer1.0_1.10.1.bb} |   5 +-
 19 files changed, 69 insertions(+), 1622 deletions(-)
 rename meta/recipes-multimedia/gstreamer/{gstreamer1.0-libav_1.8.3.bb => 
gstreamer1.0-libav_1.10.1.bb} (86%)
 delete mode 100755 
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad/0002-glplugin-enable-gldeinterlace-on-OpenGL-ES.patch
 delete mode 100755 
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad/0003-glcolorconvert-implement-multiple-render-targets-for.patch
 delete mode 100755 
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad/0004-glcolorconvert-don-t-use-the-predefined-variable-nam.patch
 delete mode 100755 
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad/0005-glshader-add-glBindFragDataLocation.patch
 delete mode 100755 
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad/0006-glcolorconvert-GLES3-deprecates-texture2D-and-it-doe.patch
 delete mode 100644 
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad/0008-gl-implement-GstGLMemoryEGL.patch
 rename meta/recipes-multimedia/gstreamer/{gstreamer1.0-plugins-bad_1.8.3.bb => 
gstreamer1.0-plugins-bad_1.10.1.bb} (64%)
 rename meta/recipes-multimedia/gstreamer/{gstreamer1.0-plugins-base_1.8.3.bb 
=> gstreamer1.0-plugins-base_1.10.1.bb} (85%)
 rename meta/recipes-multimedia/gstreamer/{gstreamer1.0-plugins-good_1.8.3.bb 
=> gstreamer1.0-plugins-good_1.10.1.bb} (84%)
 rename meta/recipes-multimedia/gstreamer/{gstreamer1.0-plugins-ugly_1.8.3.bb 
=> gstreamer1.0-plugins-ugly_1.10.1.bb} (76%)
 create mode 100644 
meta/recipes-multimedia/gstreamer/gstreamer1.0-rtsp-server_1.10.1.bb
 delete mode 100644 
meta/recipes-multimedia/gstreamer/gstreamer1.0-rtsp-server_1.8.3.bb
 rename meta/recipes-multimedia/gstreamer/{gstreamer1.0_1.8.3.bb => 
gstreamer1.0_1.10.1.bb} (69%)

diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_1.8.3.bb 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_1.10.1.bb
similarity index 86%
rename from meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_1.8.3.bb
rename to meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_1.10.1.bb
index 3d86221..98f5a50 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_1.8.3.bb
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_1.10.1.bb
@@ -13,8 +13,7 @@ SRC_URI = " \
 file://0001-Disable-yasm-for-libav-when-disable-yasm.patch \
 file://workaround-to-build-gst-libav-for-i586-with-gcc.patch \
 "
-
-SRC_URI[md5sum] = "b51a736147bacb40f85827a4e0ae0d2c"
-SRC_URI[sha256sum] = 
"9006a05990089f7155ee0e848042f6bb24e52ab1d0a59ff8d1b5d7e33001a495"
+SRC_URI[md5sum] = "9dc8fb8dd01818c27230a1ed6ba9f4de"
+SRC_URI[sha256sum] = 
"27b28b8de0e6dff1e3952428e8ed8ba4a12f452f789ac0ae9bbe50f00a5c72c7"
 
 S = "${WORKDIR}/gst-libav-${PV}"
diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc
index 0fe5564..d26a6a9 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc
@@ -42,6 +42,7 @@ PACKAGECONFIG[gtk] = 
"--enable-gtk3,--disable-gtk3,gtk+3"
 # ensure OpenSSL is used for HLS AES description instead of nettle
 # (OpenSSL is a shared dependency with dtls)
 PACKAGECONFIG[hls] = "--enable-hls 
--with-hls-crypto=openssl,--disable-hls,openssl"
+PACKAGECONFIG[kms] = "--enable-kms,--disable-kms,libdrm"
 PACKAGECONFIG[libmms]  = "--enable-libmms,--disable-libmms,libmms"
 PACKAGECONFIG[libssh2] = "--enable-libssh2,--disable-libssh2,libssh2"
 PACKAGECONFIG[modplug] = 
"--