Re: [yocto] How to maintain a global DL_DIR?

2016-08-16 Thread Gary Thomas 

On 2016-08-16 18:38, Robert P. J. Day wrote:

On Tue, 16 Aug 2016, Khem Raj wrote:


On Aug 16, 2016, at 8:37 AM, Robert P. J. Day  wrote:

On Tue, 16 Aug 2016, Patrick Doyle wrote:


As I am playing with several different Yocto/OE projects, I thought
it would be nice to set up a global downloads directory.

Also, being a somewhat forgetful sort, I thought it would be nice if
I could set DL_DIR in my .bashrc and not have to remember to edit
conf/local.conf each time I follow the directions from a third party
site to set up their Yocto based distribution.

Can I do this?  If so, how?


 if you're talking about creating a local source mirror for tarballs
to be shared across multiple projects, i taught an OE/YP course last
week based on a digi ConnectCore 6 dev kit, and i wrote some wiki
pages for it, including this one:

http://www.crashcourse.ca/wiki/index.php/CC6_local_source_mirror


a small nit, perhaps its better to use rsync instead of cp.


  good point, i will adjust that later. anything else i overlooked?


I use the attached script to manage my download mirror.  There are
two differences with the one Robert proposed:

* It copies all files, regardless of name.  This is important if you
  want your download mirror to be useful in a no-network environment
  (which seems to be very important to some of my larger customers)
  I normally run my builds with BB_NO_NETWORK="1" which lets me know
  immediately if my download mirror needs updating.  I disable BB_NO_NETWORK
  to download the new images, then update the mirror and turn it back
  on again.
* Once uploaded to the mirror, files are replaced by symbolic links
  just as if the file had been present in the first place.  This has
  two benefits - the downloads directory stays as small as possible
  and the next time the 'save_downloads' script runs, it won't have
  to bother with files already uploaded.  I use this process on a
  number of build machines, some with Poky/Yocto build trees that have
  been around for a long time (sometimes years) and keeping all those
  old files in 'downloads' can really add up.

However you manage it, using 'own-mirrors' with a local mirror really
improves the speed of builds - think about having to re-download the
git tree for the RaspberryPi firmware (>3.5GB) for every new build!

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

#! /bin/bash

MIRROR=/work/misc/Poky/sources

cd downloads
find . -maxdepth 1 -type f | sed -e 's;^\./;;' | grep -v '.lock$' | grep -v 
'.done$' >/tmp/files.$$
LEN=`ls -l /tmp/files.$$ | awk '{print $5}'`
if [ "${LEN}" == "0" ]; then
exit 0
fi
rsync -auv --files-from=/tmp/files.$$ . ${MIRROR}
if [ $? == 0 ]; then
read -p "Upload successful - purge files(y/n)? " PURGE
if [ "${PURGE}" == "y" ]; then
xargs -n1 -t rm -- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-raspberrypi][PATCH] sdcard_image-rpi.bbclass: exclude IMAGEDATESTAMP from signatures of do_image_rpi_sdimg

2016-08-16 Thread Khem Raj 
Fixes taskhash mismatch e.g.

ERROR: core-image-minimal-1.0-r0 do_image_rpi_sdimg: Taskhash mismatch 
78b2e0830a66052318e5e7eba193 versus 4b9bbe5dba1b48cf5cb5ad365d991de9 for 
/a/builder/home/kraj/work/oe/openembedded-core/meta/recipes-core/images/core-image-minimal.bb.do_image_rpi_sdimg
ERROR: Taskhash mismatch 78b2e0830a66052318e5e7eba193 versus 
4b9bbe5dba1b48cf5cb5ad365d991de9 for 
/a/builder/home/kraj/work/oe/openembedded-core/meta/recipes-core/images/core-image-minimal.bb.do_image_rpi_sdimg

Signed-off-by: Khem Raj 
---
 classes/sdcard_image-rpi.bbclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/classes/sdcard_image-rpi.bbclass b/classes/sdcard_image-rpi.bbclass
index a04204a..62df0b3 100644
--- a/classes/sdcard_image-rpi.bbclass
+++ b/classes/sdcard_image-rpi.bbclass
@@ -74,6 +74,7 @@ FATPAYLOAD ?= ""
 IMAGEDATESTAMP = "${@time.strftime('%Y.%m.%d',time.gmtime())}"
 IMAGE_CMD_rpi-sdimg[vardepsexclude] += "IMAGEDATESTAMP"
 IMAGE_CMD_rpi-sdimg[vardepsexclude] += "DATETIME"
+do_image_rpi_sdimg[vardepsexclude] += "DATETIME IMAGEDATESTAMP"
 
 RPI_KERNEL_VERSION := 
"${@get_kernelversion_file('${STAGING_KERNEL_BUILDDIR}')}"
 
-- 
2.9.3

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Access Control List (ACL) permissions attributes not getting preserved in rootfs

2016-08-16 Thread Kumar, Shrawan 
Hello Joshua,

We did not want bins like setfacl,setcap,chsmack  etc.. to be kept on target .

- wanted to understand "how does this postscript gets copied to target and at 
which path"?
-  I will have multiple recipe that will have this postscript to set respective 
packages bin's "acl" permissions and "smack" rules. Is it possible that after 
executing all the post script from   all the recipes , I shall be able to 
uninstall the acl and smack rpms ? Same applies for "setcap" rpms.

- Do you have near plan to fix these :) ?



Thanks and Regards
Shrawan

-Original Message-
From: Joshua G Lock [mailto:joshua.g.l...@linux.intel.com] 
Sent: Wednesday, August 17, 2016 1:22 AM
To: Kumar, Shrawan; yocto@yoctoproject.org
Subject: Re: [yocto] Access Control List (ACL) permissions attributes not 
getting preserved in rootfs

On Tue, 2016-08-16 at 11:55 +, Kumar, Shrawan wrote:
> Thanks Joshua,
> 
> "postinst"  works!!  I could see the attributes set under
> "poky/build_qemux86/tmp/work/qemux86-poky-linux/core-image-
> minimal/1.0-r0/rootfs/".
> 
>  However, I still could not see the attributes after booting qemu. It 
> seems during rootfs.ext4 (mkfs.ext4 command )creation when 
> "create_image_ext4.sh" is called , again this is getting   lost.
> 
> Any idea on this ?


I'm not sure why the attribute isn't preserved in the image, it could be a 
another missing piece for me to track in the quest to better support xattr.

There is a way to work around it, though — you can force the postinst to be run 
on the target at first boot, as documented in that same manual section. For 
example I have a test recipe with:

8 
> Regards
> Shrawan
> 
> 
> 
> 
> 
> -Original Message-
> From: Joshua G Lock [mailto:joshua.g.l...@linux.intel.com]
> Sent: Friday, August 12, 2016 7:22 PM
> To: Kumar, Shrawan; yocto@yoctoproject.org
> Subject: Re: [yocto] Access Control List (ACL) permissions attributes 
> not getting preserved in rootfs
> 
> On Fri, 2016-08-12 at 12:33 +, Kumar, Shrawan wrote:
> > 
> > Hello All,
> >  
> > I am  using  poky “ jethro”  , and  though  one of my recipe, I have 
> > created user1 & user2 and then trying to set ACL rules  on 
> > “helloworld” bin as below :
> >  
> >  
> > do_install() {
> >     install -d ${D}${bindir}
> >     install -m 0700 helloworld ${D}${bindir}
> >     install -d ${D}/lib/systemd/system
> >     install -m 0700 hello.service 
> > ${D}/lib/systemd/system/
> >     chown    user1:group1 ${D}${bindir}/helloworld
> >        setfacl -m u:user2:r-- ${D}${bindir}/helloworld }
> >  
> >  
> > è When I see   on the devshell ( bitbake HelloWorld –c devshell)  :
> > poky/build_qemux86/tmp/work/qemux86-poky-linux/core-image-
> > minimal/1.0-r0/rootfs/usr/bin# getfacl helloworld    , I could see 
> > that ACL permissions are set correctly as below :
> > -    # file: helloworld
> > -    # owner: user1
> > -    # group: group1
> > -    user::rwx
> > -    user:user2:r--
> > -    group::---
> > -    mask::r--
> > -    other::---
> >  
> > However, It does not seems to be getting preserved in rootfs. :
> > /poky/build_qemux86/tmp/work/qemux86-poky-linux/core-image-
> > minimal/1.0-r0/rootfs/usr/bin# getfacl helloworld # file:
> > helloworld #
> > owner: user1 # group: group1 user::rwx
> > group::---
> > other::---
> >  
> > quick help  here would be highly appreciated
> 
> This is due to the fact that we don't currently have a mechanism to 
> preserve xattr through to image construction[1].
> 
> The largest barrier for doig so is that the package managers 
> (certainly dpkg and rpm) don't have any support for xattrs in packages 
> (an image is populated via the package manager).
> 
> To the best of my knowledge the only option for adding some xattr/ACL 
> is to use a postinst[2] to set the attributes after the package has 
> been installed.
> 
> Regards,
> 
> Joshua
> 
> 1. https://bugzilla.yoctoproject.org/show_bug.cgi?id=9858
> 2. http://www.yoctoproject.org/docs/2.1/dev-manual/dev-manual.html#ne
> w-
> recipe-post-installation-scripts
> 
--

[yocto] Yocto Extensible SDK question

2016-08-16 Thread Manjukumar Harthikote Matha 

Hi,

Is there a way to disable recipes to be excluded in eSDK?

I am facing issues while extracting an SDK, which complains about kernel 
fragments are left over in setscene


Thanks
Manju
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH] rmc: fix allocating buffer issue in read_file() (32 bit)

2016-08-16 Thread Khem Raj 

> On Aug 16, 2016, at 4:12 PM, Jianxun Zhang  
> wrote:
> 
> Runtime test script failed on T100TA (32 bit) machine because
> read_file() function in rmc.c gets a wrong value of st_size from
> the buffer returned by stat(). We include rmc header files prior
> to the rest of standard header files in rmc.c, so standard data
> subsequently defined could be affected by "#pragma pack(1)" in rmc
> header files.


perhaps resetting the pragma would make it independent of positioning sequence ?

> 
> Runtime test passes on T100TA and other two boards with this change.
> 
> Signed-off-by: Jianxun Zhang 
> ---
> src/rmc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/src/rmc.c b/src/rmc.c
> index 714ae3a..6cf584e 100644
> --- a/src/rmc.c
> +++ b/src/rmc.c
> @@ -10,8 +10,6 @@
> #include 
> #include 
> #include 
> -#include 
> -#include 
> #include 
> #include 
> #include 
> @@ -20,6 +18,8 @@
> #include 
> #include 
> 
> +#include 
> +#include 
> 
> #define USAGE "RMC (Runtime Machine configuration) Tool\n" \
> "NOTE: Most of usages require root permission (sudo)\n" \
> --
> 2.7.4
> 
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [yocto-autobuilder][PATCH] cleanup and restart crashed vnc server

2016-08-16 Thread Bill Randle 
Use a common script to check for a running vnc server, and if not running
cleanup dangling lock files and restart the server.

[YOCTO #8210]

Signed-off-by: Bill Randle 
---
 bin/checkvnc   | 10 ++
 .../site-packages/autobuilder/buildsteps/RunESDKSanityTests.py |  3 +--
 .../site-packages/autobuilder/buildsteps/RunOeSelftest.py  |  3 +--
 .../site-packages/autobuilder/buildsteps/RunSDKSanityTests.py  |  3 +--
 .../site-packages/autobuilder/buildsteps/RunSanityTests.py |  3 +--
 5 files changed, 14 insertions(+), 8 deletions(-)
 create mode 100755 bin/checkvnc

diff --git a/bin/checkvnc b/bin/checkvnc
new file mode 100755
index 000..574ba48
--- /dev/null
+++ b/bin/checkvnc
@@ -0,0 +1,10 @@
+#!/bin/sh
+#
+# check if vnc server is running, and if not, cleanup and restart
+#
+pid=$(pidof Xvnc)
+if [[ $? != 0 ]]; then
+echo "Xvnc not running, attempting restart"
+vncserver -kill :1
+vncserver
+fi
diff --git 
a/lib/python2.7/site-packages/autobuilder/buildsteps/RunESDKSanityTests.py 
b/lib/python2.7/site-packages/autobuilder/buildsteps/RunESDKSanityTests.py
index 7471d3d..c16c8c2 100644
--- a/lib/python2.7/site-packages/autobuilder/buildsteps/RunESDKSanityTests.py
+++ b/lib/python2.7/site-packages/autobuilder/buildsteps/RunESDKSanityTests.py
@@ -47,8 +47,7 @@ class RunESDKSanityTests(BitbakeShellCommand):
 layerversion = self.getProperty("layerversion_core")
 command = ""
 command = command + ". ./oe-init-build-env; "
-command = command + "netstat -an | grep -q 5901 ;"
-command = command + 'if [ $? -ne 0 ]; then echo "Starting a VNC server 
on :1"; vncserver :1; else echo "Will use a VNC server already running on :1"; 
fi;'
+command = command + "checkvnc; "
 if layerversion and int(layerversion) >= 7:
 command = command + "echo 'INHERIT += \"testsdk\"' >> 
./conf/auto.conf;"
 command = command + "echo 'TEST_QEMUBOOT_TIMEOUT = \"1500\"' >> 
./conf/auto.conf;"
diff --git 
a/lib/python2.7/site-packages/autobuilder/buildsteps/RunOeSelftest.py 
b/lib/python2.7/site-packages/autobuilder/buildsteps/RunOeSelftest.py
index 809bcc3..84d32fe 100644
--- a/lib/python2.7/site-packages/autobuilder/buildsteps/RunOeSelftest.py
+++ b/lib/python2.7/site-packages/autobuilder/buildsteps/RunOeSelftest.py
@@ -31,8 +31,7 @@ class RunOeSelftest(ShellCommand):
 def start(self):
 self.command = ""
 self.command += ". ./oe-init-build-env; "
-self.command += "netstat -an | grep -q 5901 ;"
-self.command += "if [ $? -ne 0 ]; then echo 'Starting a VNC server on 
:1'; vncserver :1; else echo 'Will use a VNC server already running on :1'; fi;"
+self.command += "checkvnc; "
 if self.tests == None:
 self.command += "if [ -d ../meta-selftest ]; then export 
DISPLAY=:1; oe-selftest --run-all-tests; else echo 'Skipping step - no 
meta-selftest layer here'; fi"
 else:
diff --git 
a/lib/python2.7/site-packages/autobuilder/buildsteps/RunSDKSanityTests.py 
b/lib/python2.7/site-packages/autobuilder/buildsteps/RunSDKSanityTests.py
index 9b6eb5b..6fb3127 100644
--- a/lib/python2.7/site-packages/autobuilder/buildsteps/RunSDKSanityTests.py
+++ b/lib/python2.7/site-packages/autobuilder/buildsteps/RunSDKSanityTests.py
@@ -47,8 +47,7 @@ class RunSDKSanityTests(BitbakeShellCommand):
 layerversion = self.getProperty("layerversion_core")
 command = ""
 command = command + ". ./oe-init-build-env; "
-command = command + "netstat -an | grep -q 5901 ;"
-command = command + 'if [ $? -ne 0 ]; then echo "Starting a VNC server 
on :1"; vncserver :1; else echo "Will use a VNC server already running on :1"; 
fi;'
+command = command + "checkvnc; "
 if layerversion and int(layerversion) >= 6:
 command = command + "echo 'INHERIT += \"testimage\"' >> 
./conf/auto.conf;"
 command = command + "echo 'TEST_QEMUBOOT_TIMEOUT = \"1500\"' >> 
./conf/auto.conf;"
diff --git 
a/lib/python2.7/site-packages/autobuilder/buildsteps/RunSanityTests.py 
b/lib/python2.7/site-packages/autobuilder/buildsteps/RunSanityTests.py
index 4fa6dac..81e20cd 100644
--- a/lib/python2.7/site-packages/autobuilder/buildsteps/RunSanityTests.py
+++ b/lib/python2.7/site-packages/autobuilder/buildsteps/RunSanityTests.py
@@ -48,8 +48,7 @@ class RunSanityTests(BitbakeShellCommand):
 distro = self.getProperty("DISTRO")
 command = ""
 command = command + ". ./oe-init-build-env; "
-command = command + "netstat -an | grep -q 5901 ;"
-command = command + 'if [ $? -ne 0 ]; then echo "Starting a VNC server 
on :1"; vncserver :1; else echo "Will use a VNC server already running on :1"; 
fi;'
+command = command + "checkvnc; "
 if distro == "poky-lsb" and layerversion and int(layerversion) < 6:
 command = "echo 'Skipping

[yocto] [yocto-autobuilder][PATCH] enable use of kvm with qemux86*

2016-08-16 Thread Bill Randle 
When used with corresponding oe-core patch, this will enable the use
of kvm when running qemux86* images on a x86* host that supports kvm.
On the same build machine, for an x86_64 testimage run, the with and
without times are:
  without kvm:
core-image-sato-1.0-r0 do_testimage: Ran 43 tests in 728.726s
core-image-sato-sdk-1.0-r0 do_testimage: Ran 52 tests in 1090.838s
  with kvm:
core-image-sato-1.0-r0 do_testimage: Ran 43 tests in 60.255s
core-image-sato-sdk-1.0-r0 do_testimage: Ran 52 tests in 71.719s

[YOCTO #9298]

Signed-off-by: Bill Randle 
---
 config/autobuilder.conf.example | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/config/autobuilder.conf.example b/config/autobuilder.conf.example
index 9179d14..96bc4c6 100644
--- a/config/autobuilder.conf.example
+++ b/config/autobuilder.conf.example
@@ -60,6 +60,9 @@ RESOLVE_TRIGGERED_HEAD = True
 DEVKERNEL_MUT_REPO = 
"{'git://git.yoctoproject.org/poky-contrib':['stage/master_under_test', 
'sgw/mut']}"
 DEVKERNEL = "linux-yocto-dev"
 
+[TestSettings]
+QEMU_USE_KVM = "True"
+
 [ADTREPO Settings]
 ADTREPO_POPULATE = False
 ADTREPO_DEV_POPULATE = True
-- 
2.5.5

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH] rmc: fix wrong error message

2016-08-16 Thread Jianxun Zhang 
Signed-off-by: Jianxun Zhang 
---
 src/rmc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/rmc.c b/src/rmc.c
index 6cf584e..7f63c59 100644
--- a/src/rmc.c
+++ b/src/rmc.c
@@ -112,7 +112,7 @@ static int read_file(const char *pathname, char **data, 
size_t* len) {
 
 while (byte < total) {
 if ((tmp = read(fd, buf + byte, total - byte)) < 0) {
-perror("rmc: failed to alloc read buf");
+perror("rmc: failed to read file");
 free(buf);
 close(fd);
 return 1;
-- 
2.7.4

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH] rmc: fix allocating buffer issue in read_file() (32 bit)

2016-08-16 Thread Jianxun Zhang 
Runtime test script failed on T100TA (32 bit) machine because
read_file() function in rmc.c gets a wrong value of st_size from
the buffer returned by stat(). We include rmc header files prior
to the rest of standard header files in rmc.c, so standard data
subsequently defined could be affected by "#pragma pack(1)" in rmc
header files.

Runtime test passes on T100TA and other two boards with this change.

Signed-off-by: Jianxun Zhang 
---
 src/rmc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/rmc.c b/src/rmc.c
index 714ae3a..6cf584e 100644
--- a/src/rmc.c
+++ b/src/rmc.c
@@ -10,8 +10,6 @@
 #include 
 #include 
 #include 
-#include 
-#include 
 #include 
 #include 
 #include 
@@ -20,6 +18,8 @@
 #include 
 #include 
 
+#include 
+#include 
 
 #define USAGE "RMC (Runtime Machine configuration) Tool\n" \
 "NOTE: Most of usages require root permission (sudo)\n" \
-- 
2.7.4

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH] test: Provide test scripts and sample data

2016-08-16 Thread Jianxun Zhang 
Two test scripts cover basic functionality in both build and
runtime with some sample data of three boards.

Signed-off-by: Jianxun Zhang 
---
This is the first patch to rmc project since it was published in YP.
After consulting some people, we choose yocto mailing list for rmc
patch review.

Thanks

 test/README   |  63 +++
 test/boards/NUC4.D54250WYK.fp | Bin 0 -> 149 bytes
 test/boards/NUC4.file.1   |   1 +
 test/boards/NUC4.file.2   |   1 +
 test/boards/NUC6.file.1   |   1 +
 test/boards/NUC6.file.2   |   1 +
 test/boards/NUC6.file.3   |  11 
 test/boards/NUC6i5SYB_H.fp| Bin 0 -> 149 bytes
 test/boards/T100.32.file.1|   2 +
 test/boards/T100.32.file.2|   1 +
 test/boards/T100TA-32bit.fp   | Bin 0 -> 116 bytes
 test/db.build.sh  |  89 
 test/rmctool.runtime.sh   | 117 ++
 13 files changed, 287 insertions(+)
 create mode 100644 test/README
 create mode 100644 test/boards/NUC4.D54250WYK.fp
 create mode 100644 test/boards/NUC4.file.1
 create mode 100644 test/boards/NUC4.file.2
 create mode 100644 test/boards/NUC6.file.1
 create mode 100644 test/boards/NUC6.file.2
 create mode 100644 test/boards/NUC6.file.3
 create mode 100644 test/boards/NUC6i5SYB_H.fp
 create mode 100644 test/boards/T100.32.file.1
 create mode 100644 test/boards/T100.32.file.2
 create mode 100644 test/boards/T100TA-32bit.fp
 create mode 100755 test/db.build.sh
 create mode 100755 test/rmctool.runtime.sh

diff --git a/test/README b/test/README
new file mode 100644
index 000..1ef380d
--- /dev/null
+++ b/test/README
@@ -0,0 +1,63 @@
+Test Suite of RMC project
+
+
+To test RMC functionality, we provide scripts and some launched commercial
+boards with sample data.
+
+*.runtime.*: Test to run on a type of board
+
+*.build.*:   Test to run at build time
+
+=
+db.build.sh - Test database generation with built-in samples
+
+What it does:
+() Compile rmc tool
+() Generate a RMC database file with data in ./boards and check if it is
+identical to a known fully-tested database based on same data.
+
+Usage:
+# To run test in test directory:
+./db.build.sh
+
+# To run test against another database checksum:
+RMC_TEST_DB_MD5=your_md5_digist_string ./db.build.sh
+
+# To obtain a copy of the current golden sample database, make sure no change
+# in ./boards, then run:
+RMC_TEST_DB_MD5="" ./db.build.sh
+
+=
+rmctool.runtime.sh - Test querying data and fingerprint at runtime on target
+
+What it does:
+() Test obtaining fingerprint on a supported board
+() Test querying data on a supported board
+() Test querying data for other boards (negative case)
+
+Usage:
+Copy rmctool.runtime.sh, a database file and rmc tool onto target.
+Change permissions so that the test script and rmc tool for test are 
executable.
+
+# To run test with a provided rmc database file:
+./rmctool.runtime.sh database_file
+
+# To run test with a specified rmc tool:
+RMC_BIN=pathname_of_rmc ./rmctool.runtime.sh database_file
+
+# To run test and specify another directory for data generated in test:
+./rmctool.runtime.sh database_file test_dir
+
+=
+Update sample data for test
+() Modify data in ./boards
+
+() Run this command to generate a new database file:
+RMC_TEST_DB_MD5="" ./db.build.sh
+
+() Run *.runtime.* scripts and pass ALL test cases on ALL boards with the new
+database file.
+
+() Update database checksum in ./db.build.sh
+
+() Run *.build.* scripts and pass all tests in build time.
diff --git a/test/boards/NUC4.D54250WYK.fp b/test/boards/NUC4.D54250WYK.fp
new file mode 100644
index 
..6c6c2a8ac1ffef5a4dc675193bfd7174c0bb6693
GIT binary patch
literal 149
zcmZQ%Ehx%QDNQbk$gl7?@BsxR{z4nHq#gdNZ%*CGXXfWIc;=O)=4b?I
wDmdpCrD}xuYAR%!>VlMoDmVv(DmW+@>KPljdsH#hGZdv3rxul^rZAwe0cXf1-v9sr

literal 0
HcmV?d1

diff --git a/test/boards/NUC4.file.1 b/test/boards/NUC4.file.1
new file mode 100644
index 000..7f80ab1
--- /dev/null
+++ b/test/boards/NUC4.file.1
@@ -0,0 +1 @@
+Sample data #1 for NUC Gen 4
diff --git a/test/boards/NUC4.file.2 b/test/boards/NUC4.file.2
new file mode 100644
index 000..83d8d47
--- /dev/null
+++ b/test/boards/NUC4.file.2
@@ -0,0 +1 @@
+Sample data #2 for NUC Gen 4
diff --git a/test/boards/NUC6.file.1 b/test/boards/NUC6.file.1
new file mode 100644
index 000..a573b9e
--- /dev/null
+++ b/test/boards/NUC6.file.1
@@ -0,0 +1 @@
+This is #1 sample data file of NUC Gen 6
diff --git a/test/boards/NUC6.file.2 b/test/boards/NUC6.file.2
new file mode 100644
index 000..3080b66
--- /dev/null
+++ b/test/boards/NUC6.file.2
@@ -0,0 +1 @@
+This is #2 sample data file of NUC Gen 6
diff --git a/test/boards/NUC6.file.3 b/test/boards/NUC6.file.3
new file mode 100644
index 000..bade7ef
--- /dev/null
+++ b/test/boards/NUC6.file.3
@@ -0,0 +1,11

Re: [yocto] How to maintain a global DL_DIR?

2016-08-16 Thread Patrick Doyle 
On Tue, Aug 16, 2016 at 4:24 PM, Peter Kjellerstedt
 wrote:
> You seem to be using an old version of Poky.
I am using the version of poky distributed with the board.  In this
case, the board is the Edison board, and the manufacturer is Intel.  I
guess I was assuming that the Edison would have been distributed with
the latest version of Yocto/OE.  Oh well.

For other boards with other distributions, who knows what I will find?


> If you do not have the option of using Krogoth or newer, you could
> use this trick in your .bashrc:
>
> alias bitbake="BB_ENV_EXTRAWHITE=\"$BB_ENV_EXTRAWHITE DL_DIR\" bitbake"
>
> It may not be kosher, but it works. ;)

I like that solution a whole lot more than the solution I proposed.

Learning that the Yocto shipped with the Edison is old, and that there
is a newer/better way to address this problem is.. priceless.

Thanks for the tip.

--wpd
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How to maintain a global DL_DIR?

2016-08-16 Thread Peter Kjellerstedt 
> -Original Message-
> From: yocto-boun...@yoctoproject.org [mailto:yocto-
> boun...@yoctoproject.org] On Behalf Of Patrick Doyle
> Sent: den 16 augusti 2016 17:13
> To: yocto@yoctoproject.org
> Subject: Re: [yocto] How to maintain a global DL_DIR?
> 
> Oh this is ugly...
> I tried setting BB_ENV_EXTRAWHITE to DL_DIR in my .bashrc, but found
> that BB_ENV_EXTRAWHITE gets overwritten by oe-buildenv-internal as I
> mentioned previously.

You seem to be using an old version of Poky. The code in 
oe-buildenv-internal was changed in Krogoth to add the variables 
that OE requires to BB_ENV_EXTRAWHITE. So if you are using Krogoth 
or later it should be possible to do 
export BB_ENV_EXTRAWHITE="DL_DIR"
in your .bashrc and get it to work as expected...

If you do not have the option of using Krogoth or newer, you could 
use this trick in your .bashrc:

alias bitbake="BB_ENV_EXTRAWHITE=\"$BB_ENV_EXTRAWHITE DL_DIR\" bitbake"

It may not be kosher, but it works. ;)

> I tried setting BB_ENV_WHITELIST to DL_DIR in my .bashrc and found
> that bitbake just stopped working.
> 
> After rereading the manual
> (https://www.yoctoproject.org/docs/1.6/bitbake-user-manual/bitbake-
> user-manual.html#var-BB_ENV_WHITELIST)
> I tried setting BB_ENV_WHITELIST to "BBPATH BB_RESERVE_ENV
> BB_ENV_WHITELIST BB_ENV_EXTRAWHITE DL_DIR", and bitbake still didn't
> work.
> 
> So I looked in poky/bitbake/lib/bb/utils.py and found the following:
> 
> def preserved_envvars_exported():
> """Variables which are taken from the environment and placed in and
> exported
> from the metadata"""
> return [
> 'BB_TASKHASH',
> 'HOME',
> 'LOGNAME',
> 'PATH',
> 'PWD',
> 'SHELL',
> 'TERM',
> 'USER',
> ]
> 
> def preserved_envvars():
> """Variables which are taken from the environment and placed in
> the metadata"""
> v = [
> 'BBPATH',
> 'BB_PRESERVE_ENV',
> 'BB_ENV_WHITELIST',
> 'BB_ENV_EXTRAWHITE',
> ]
> return v + preserved_envvars_exported()
> 
> ...
> if 'BB_ENV_WHITELIST' in os.environ:
> approved = os.environ['BB_ENV_WHITELIST'].split()
> approved.extend(['BB_ENV_WHITELIST'])
> else:
> approved = preserved_envvars()
> 
> This looks like, if BB_ENV_WHITELIST is defined in the environment,
> bitbake will use it (arbitrarily appending BB_ENV_WHITELIST to the end
> of whatever was defined in the environment variable).  If it is not
> defined, then BB_ENV_WHITELIST is initialized to be:
> 
> ['BBPATH', 'BB_PRESERVE_ENV', 'BB_ENV_WHITELIST', 'BB_ENV_EXTRAWHITE',
> 'BB_TASKHASH', 'HOME', ...]
> 
> So I finally tried setting BB_ENV_WHITELIST in .bashrc to be "BBPATH
> BB_PRESERVE_ENV BB_ENV_EXTRAWHITE BB_TASKHASH HOME LOGNAME PATH PWD
> SHELL TERM USER DL_DIR"
> 
> But it is very sadly ugly... not terribly maintainable... and makes me
> think I'm missing something important.
> 
> Please tell me I'm missing something important.
> 
> --wpd

//Peter

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Access Control List (ACL) permissions attributes not getting preserved in rootfs

2016-08-16 Thread Joshua G Lock 
On Tue, 2016-08-16 at 11:55 +, Kumar, Shrawan wrote:
> Thanks Joshua,
> 
> "postinst"  works!!  I could see the attributes set under
> "poky/build_qemux86/tmp/work/qemux86-poky-linux/core-image-
> minimal/1.0-r0/rootfs/".
> 
>  However, I still could not see the attributes after booting qemu. It
> seems during rootfs.ext4 (mkfs.ext4 command )creation when
> "create_image_ext4.sh" is called , again this is getting   lost.
> 
> Any idea on this ?


I'm not sure why the attribute isn't preserved in the image, it could
be a another missing piece for me to track in the quest to better
support xattr.

There is a way to work around it, though — you can force the postinst
to be run on the target at first boot, as documented in that same
manual section. For example I have a test recipe with:

8 
> Regards
> Shrawan
> 
> 
> 
> 
> 
> -Original Message-
> From: Joshua G Lock [mailto:joshua.g.l...@linux.intel.com] 
> Sent: Friday, August 12, 2016 7:22 PM
> To: Kumar, Shrawan; yocto@yoctoproject.org
> Subject: Re: [yocto] Access Control List (ACL) permissions attributes
> not getting preserved in rootfs
> 
> On Fri, 2016-08-12 at 12:33 +, Kumar, Shrawan wrote:
> > 
> > Hello All,
> >  
> > I am  using  poky “ jethro”  , and  though  one of my recipe, I
> > have 
> > created user1 & user2 and then trying to set ACL rules  on 
> > “helloworld” bin as below :
> >  
> >  
> > do_install() {
> >     install -d ${D}${bindir}
> >     install -m 0700 helloworld ${D}${bindir}
> >     install -d ${D}/lib/systemd/system
> >     install -m 0700 hello.service 
> > ${D}/lib/systemd/system/
> >     chown    user1:group1 ${D}${bindir}/helloworld
> >        setfacl -m u:user2:r-- ${D}${bindir}/helloworld
> > }
> >  
> >  
> > è When I see   on the devshell ( bitbake HelloWorld –c devshell)  :
> > poky/build_qemux86/tmp/work/qemux86-poky-linux/core-image-
> > minimal/1.0-r0/rootfs/usr/bin# getfacl helloworld    , I could see 
> > that ACL permissions are set correctly as below :
> > -    # file: helloworld
> > -    # owner: user1
> > -    # group: group1
> > -    user::rwx
> > -    user:user2:r--
> > -    group::---
> > -    mask::r--
> > -    other::---
> >  
> > However, It does not seems to be getting preserved in rootfs. :
> > /poky/build_qemux86/tmp/work/qemux86-poky-linux/core-image-
> > minimal/1.0-r0/rootfs/usr/bin# getfacl helloworld # file:
> > helloworld # 
> > owner: user1 # group: group1 user::rwx
> > group::---
> > other::---
> >  
> > quick help  here would be highly appreciated
> 
> This is due to the fact that we don't currently have a mechanism to
> preserve xattr through to image construction[1].
> 
> The largest barrier for doig so is that the package managers
> (certainly dpkg and rpm) don't have any support for xattrs in
> packages (an image is populated via the package manager).
> 
> To the best of my knowledge the only option for adding some xattr/ACL
> is to use a postinst[2] to set the attributes after the package has
> been installed.
> 
> Regards,
> 
> Joshua
> 
> 1. https://bugzilla.yoctoproject.org/show_bug.cgi?id=9858
> 2. http://www.yoctoproject.org/docs/2.1/dev-manual/dev-manual.html#ne
> w-
> recipe-post-installation-scripts
> 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [RFT] gcc 6.2 RC1 update

2016-08-16 Thread Khem Raj 
Hi All

I have put together recipe upgrade for upcoming gcc 6.2 release now that it 
entered RC phase. With gcc 6.2 the recipes are using tarballs instead of git 
fetcher as promised :)
Please help testing it out in your setups and report any issues you see.

The commit you need to cherry-pick for OE-core is this one

https://github.com/kraj/openembedded-core/commit/0319b603761a16e65d704336112c3709a8bf771c

Thank you for your help

-Khem


signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [eclipse-poky][neon][PATCH] scripts/setup.sh: fix download URIs

2016-08-16 Thread Tim Orling 
The non-upstream URIs were accidentally still pointing to Mars data.

Signed-off-by: Tim Orling 
---
 scripts/setup.sh | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/setup.sh b/scripts/setup.sh
index 30f4463..75310ab 100755
--- a/scripts/setup.sh
+++ b/scripts/setup.sh
@@ -227,8 +227,8 @@ then
 TM_SITE="http://download.eclipse.org/tm/updates/4.0/GA;
 TM_TERMINAL_SITE="http://download.eclipse.org/tm/terminal/marketplace;
 else
-MAIN_SITE="http://downloads.yoctoproject.org/eclipse/mars/;
-
DEPRECATED_SITE="http://downloads.yoctoproject.org/eclipse/luna/ftp.osuosl.org/pub/eclipse/releases/luna;
+MAIN_SITE="http://downloads.yoctoproject.org/eclipse/neon/;
+DEPRECATED_SITE="http://downloads.yoctoproject.org/eclipse/mars;
 TM_SITE="http://downloads.yoctoproject.org/eclipse/tm/updates/4.0/;
 
TM_TERMINAL_SITE="http://downloads.yoctoproject.org/eclipse/tm/terminal/marketplace;
 fi
-- 
2.7.4

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Computing transaction...error: Can't install azure-test-1.0-r0@armv5e: no package provides libumock.so

2016-08-16 Thread Peters, Johnnie 
I have created a recipe for to add the Azure libraries to a Yocto image.  I see 
the libraries are included in the the Azure rpm file and the .so’s and include 
files in the dev rpm.  I second recipe to test being able to link to the 
libraries also builds and links correctly.  However, in the do_rootfs stage I 
get the above error message.

I have also looked in the azure log.do_package file and find these lines:

In the build/tmp/work/…/azure/1.0-r0/package/usr/lib directory I see:

lrwxrwxrwx. 1 jpeters jpeters 15  Aug 16 09:24 libuamqp.so -> 
libuamqp.so.1.1
lrwxrwxrwx. 1 jpeters jpeters 15  Aug 16 09:24 libuamqp.so.1 -> 
libuamqp.so.1.1
-rwxr-xr-x. 2 jpeters jpeters 699588 Aug 16 09:24 libuamqp.so.1.1
lrwxrwxrwx. 1 jpeters jpeters 15  Aug 16 09:24 libumock.so -> 
libumock.so.1.1
lrwxrwxrwx. 1 jpeters jpeters 15  Aug 16 09:24 libumock.so.1 -> 
libumock.so.1.1
-rwxr-xr-x. 2 jpeters jpeters 390736 Aug 16 09:24 libumock.so.1.1
lrwxrwxrwx. 1 jpeters jpeters 15  Aug 16 09:24 libumqtt.so -> 
libumqtt.so.1.1
lrwxrwxrwx. 1 jpeters jpeters 15  Aug 16 09:24 libumqtt.so.1 -> 
libumqtt.so.1.1
-rwxr-xr-x. 2 jpeters jpeters  77704 Aug 16 09:24 libumqtt.so.1.1

Which would seem to be correct but in log.do_package I see some lines I do not 
find correct:

DEBUG: azure-dev contains dangling link /usr/lib/libumqtt.so.1.1
DEBUG: target found in azure
DEBUG: azure-dev contains dangling link /usr/lib/libuamqp.so.1.1
DEBUG: target found in azure
DEBUG: azure-dev contains dangling link /usr/lib/libumock.so.1.1
DEBUG: target found in azure

DEBUG: LIBNAMES: pkg azure-staticdev libs 0 bins 0 sonames []
DEBUG: LIBNAMES: pkg azure-locale libs 0 bins 0 sonames []
DEBUG: LIBNAMES: pkg azure-doc libs 0 bins 0 sonames []
DEBUG: LIBNAMES: pkg azure-dev libs 1 bins 0 sonames []
DEBUG: LIBNAMES: pkg azure-dbg libs 0 bins 0 sonames []
DEBUG: LIBNAMES: pkg azure libs 1 bins 0 sonames []

And finally here is my azure.bb file:

SUMMARY = "Miscrosoft Azure"

LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://LICENSE;md5=4283671594edec4c13aeb073c219237a"

SRCREV_base = "bef3995f64da33f3aeb5b98d359cf8feebeee903"

SRC_URI = " \
git://github.com/Azure/azure-iot-sdks.git;destsuffix=${S};name=base \
file://Makefile \
file://Makefile.umqtt \
file://Makefile.uamqp \
file://Makefile.umock \
"

inherit autotools pkgconfig

B = "${S}"

do_compile_prepend () {
cd ${B}; git submodule update --init --recursive
cp ${WORKDIR}/Makefile ${S}/Makefile
cp ${WORKDIR}/Makefile.umqtt ${S}/c/azure-umqtt-c/src/Makefile
cp ${WORKDIR}/Makefile.uamqp ${S}/c/azure-uamqp-c/src/Makefile
cp ${WORKDIR}/Makefile.umock 
${S}/c/azure-uamqp-c/azure-c-shared-utility/src/Makefile
}

INHIBIT_PACKAGE_STRIP = “1"

#FILES_${PN} = "${libdir}/lib*${SOLIBS}"
#FILES_${PN}-dev = "${libdir}/lib*${SOLIBSDEV} ${includedir}/azure/*/*”

One additional note, I added the INHIBIT_PACKAGE_STRIP because I found the 
libraries had been stripped.

What doi I need to do to correct this situation?

Johnnie


-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How to maintain a global DL_DIR?

2016-08-16 Thread Robert P. J. Day 
On Tue, 16 Aug 2016, Khem Raj wrote:

> > On Aug 16, 2016, at 8:37 AM, Robert P. J. Day  wrote:
> >
> > On Tue, 16 Aug 2016, Patrick Doyle wrote:
> >
> >> As I am playing with several different Yocto/OE projects, I thought
> >> it would be nice to set up a global downloads directory.
> >>
> >> Also, being a somewhat forgetful sort, I thought it would be nice if
> >> I could set DL_DIR in my .bashrc and not have to remember to edit
> >> conf/local.conf each time I follow the directions from a third party
> >> site to set up their Yocto based distribution.
> >>
> >> Can I do this?  If so, how?
> >
> >  if you're talking about creating a local source mirror for tarballs
> > to be shared across multiple projects, i taught an OE/YP course last
> > week based on a digi ConnectCore 6 dev kit, and i wrote some wiki
> > pages for it, including this one:
> >
> > http://www.crashcourse.ca/wiki/index.php/CC6_local_source_mirror
>
> a small nit, perhaps its better to use rsync instead of cp.

  good point, i will adjust that later. anything else i overlooked?

rday

-- 


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

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How to maintain a global DL_DIR?

2016-08-16 Thread Khem Raj 

> On Aug 16, 2016, at 8:37 AM, Robert P. J. Day  wrote:
> 
> On Tue, 16 Aug 2016, Patrick Doyle wrote:
> 
>> As I am playing with several different Yocto/OE projects, I thought
>> it would be nice to set up a global downloads directory.
>> 
>> Also, being a somewhat forgetful sort, I thought it would be nice if
>> I could set DL_DIR in my .bashrc and not have to remember to edit
>> conf/local.conf each time I follow the directions from a third party
>> site to set up their Yocto based distribution.
>> 
>> Can I do this?  If so, how?
> 
>  if you're talking about creating a local source mirror for tarballs
> to be shared across multiple projects, i taught an OE/YP course last
> week based on a digi ConnectCore 6 dev kit, and i wrote some wiki
> pages for it, including this one:
> 
> http://www.crashcourse.ca/wiki/index.php/CC6_local_source_mirror
> 

a small nit, perhaps its better to use rsync instead of cp.

> that explains how to create a globally accessible directory full of
> tarballs, how to configure each new project to look there first, and
> there's even a script so that, if a new project *does* have to
> download a bit of stuff that's not in your local source mirror, you
> can run that script from the downloads/ directory, and it will copy
> all the newly-downloaded stuff into your local source mirror.
> 
>  let me know if anything on that page is unclear.
> 
> rday
> 
> --
> 
> 
> Robert P. J. Day Ottawa, Ontario, CANADA
>http://crashcourse.ca
> 
> Twitter:   http://twitter.com/rpjday
> LinkedIn:   http://ca.linkedin.com/in/rpjday
> 
> 
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How to maintain a global DL_DIR?

2016-08-16 Thread Robert P. J. Day 
On Tue, 16 Aug 2016, Patrick Doyle wrote:

> As I am playing with several different Yocto/OE projects, I thought
> it would be nice to set up a global downloads directory.
>
> Also, being a somewhat forgetful sort, I thought it would be nice if
> I could set DL_DIR in my .bashrc and not have to remember to edit
> conf/local.conf each time I follow the directions from a third party
> site to set up their Yocto based distribution.
>
> Can I do this?  If so, how?

  if you're talking about creating a local source mirror for tarballs
to be shared across multiple projects, i taught an OE/YP course last
week based on a digi ConnectCore 6 dev kit, and i wrote some wiki
pages for it, including this one:

http://www.crashcourse.ca/wiki/index.php/CC6_local_source_mirror

that explains how to create a globally accessible directory full of
tarballs, how to configure each new project to look there first, and
there's even a script so that, if a new project *does* have to
download a bit of stuff that's not in your local source mirror, you
can run that script from the downloads/ directory, and it will copy
all the newly-downloaded stuff into your local source mirror.

  let me know if anything on that page is unclear.

rday

-- 


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

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-virtualization][PATCH] libvirt: fix CVE-2016-5008

2016-08-16 Thread Bruce Ashfield 

Still going to the wrong list use: meta-virtualizat...@yoctoproject.org.

On 2016-08-15 11:21 PM, kai.k...@windriver.com wrote:

From: Kai Kang 

Backport patch to fix CVE-2016-5008 from:

https://libvirt.org/git/?p=libvirt.git;a=commit;h=f32441c


I typically prefer uprevs to backports for these sorts of things, but
since it is a CVE, I've taken the change an pushed it.

Bruce



Signed-off-by: Kai Kang 
---
 ...pty-default-VNC-password-work-as-document.patch | 81 ++
 recipes-extended/libvirt/libvirt_1.3.5.bb  |  1 +
 2 files changed, 82 insertions(+)
 create mode 100644 
recipes-extended/libvirt/libvirt-1.3.5/0001-qemu-Let-empty-default-VNC-password-work-as-document.patch

diff --git 
a/recipes-extended/libvirt/libvirt-1.3.5/0001-qemu-Let-empty-default-VNC-password-work-as-document.patch
 
b/recipes-extended/libvirt/libvirt-1.3.5/0001-qemu-Let-empty-default-VNC-password-work-as-document.patch
new file mode 100644
index 000..1d13dd3
--- /dev/null
+++ 
b/recipes-extended/libvirt/libvirt-1.3.5/0001-qemu-Let-empty-default-VNC-password-work-as-document.patch
@@ -0,0 +1,81 @@
+Upstream-Status: Backport
+
+Backport patch to fix CVE-2016-5008 from:
+
+https://libvirt.org/git/?p=libvirt.git;a=commit;h=f32441c69bf450d6ac593c3acd621c37e120cdaf
+
+Signed-off-by: Kai Kang 
+---
+From f32441c69bf450d6ac593c3acd621c37e120cdaf Mon Sep 17 00:00:00 2001
+From: Jiri Denemark 
+Date: Tue, 28 Jun 2016 14:39:58 +0200
+Subject: [PATCH] qemu: Let empty default VNC password work as documented
+
+CVE-2016-5008
+
+Setting an empty graphics password is documented as a way to disable
+VNC/SPICE access, but QEMU does not always behaves like that. VNC would
+happily accept the empty password. Let's enforce the behavior by setting
+password expiration to "now".
+
+https://bugzilla.redhat.com/show_bug.cgi?id=1180092
+
+Signed-off-by: Jiri Denemark 
+(cherry picked from commit bb848feec0f3f10e92dd8e5231ae7aa89b5598f3)
+---
+ src/qemu/qemu_hotplug.c | 14 +++---
+ 1 file changed, 7 insertions(+), 7 deletions(-)
+
+diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c
+index 5f12d77..fda28b0 100644
+--- a/src/qemu/qemu_hotplug.c
 b/src/qemu/qemu_hotplug.c
+@@ -3547,6 +3547,7 @@ qemuDomainChangeGraphicsPasswords(virQEMUDriverPtr 
driver,
+ time_t now = time(NULL);
+ char expire_time [64];
+ const char *connected = NULL;
++const char *password;
+ int ret = -1;
+ virQEMUDriverConfigPtr cfg = virQEMUDriverGetConfig(driver);
+
+@@ -3554,16 +3555,14 @@ qemuDomainChangeGraphicsPasswords(virQEMUDriverPtr 
driver,
+ ret = 0;
+ goto cleanup;
+ }
++password = auth->passwd ? auth->passwd : defaultPasswd;
+
+ if (auth->connected)
+ connected = 
virDomainGraphicsAuthConnectedTypeToString(auth->connected);
+
+ if (qemuDomainObjEnterMonitorAsync(driver, vm, asyncJob) < 0)
+ goto cleanup;
+-ret = qemuMonitorSetPassword(priv->mon,
+- type,
+- auth->passwd ? auth->passwd : defaultPasswd,
+- connected);
++ret = qemuMonitorSetPassword(priv->mon, type, password, connected);
+
+ if (ret == -2) {
+ if (type != VIR_DOMAIN_GRAPHICS_TYPE_VNC) {
+@@ -3571,14 +3570,15 @@ qemuDomainChangeGraphicsPasswords(virQEMUDriverPtr 
driver,
+_("Graphics password only supported for VNC"));
+ ret = -1;
+ } else {
+-ret = qemuMonitorSetVNCPassword(priv->mon,
+-auth->passwd ? auth->passwd : 
defaultPasswd);
++ret = qemuMonitorSetVNCPassword(priv->mon, password);
+ }
+ }
+ if (ret != 0)
+ goto end_job;
+
+-if (auth->expires) {
++if (password[0] == '\0') {
++snprintf(expire_time, sizeof(expire_time), "now");
++} else if (auth->expires) {
+ time_t lifetime = auth->validTo - now;
+ if (lifetime <= 0)
+ snprintf(expire_time, sizeof(expire_time), "now");
+--
+2.9.0
+
diff --git a/recipes-extended/libvirt/libvirt_1.3.5.bb 
b/recipes-extended/libvirt/libvirt_1.3.5.bb
index 7ff2c5f..6222b69 100644
--- a/recipes-extended/libvirt/libvirt_1.3.5.bb
+++ b/recipes-extended/libvirt/libvirt_1.3.5.bb
@@ -34,6 +34,7 @@ SRC_URI = 
"http://libvirt.org/sources/libvirt-${PV}.tar.gz;name=libvirt \
file://Revert-build-add-prefix-to-SYSTEMD_UNIT_DIR.patch \
file://install-missing-file.patch \
file://0001-nsslinktest-also-build-virAtomic.h.patch \
+   
file://0001-qemu-Let-empty-default-VNC-password-work-as-document.patch \
   "

 SRC_URI[libvirt.md5sum] = "f9dc1e63d559eca50ae0ee798a4c6c6d"



--
___
yocto mailing list
yocto@yoctoproject.org

Re: [yocto] How to maintain a global DL_DIR?

2016-08-16 Thread Patrick Doyle 
Oh this is ugly...
I tried setting BB_ENV_EXTRAWHITE to DL_DIR in my .bashrc, but found
that BB_ENV_EXTRAWHITE gets overwritten by oe-buildenv-internal as I
mentioned previously.

I tried setting BB_ENV_WHITELIST to DL_DIR in my .bashrc and found
that bitbake just stopped working.

After rereading the manual
(https://www.yoctoproject.org/docs/1.6/bitbake-user-manual/bitbake-user-manual.html#var-BB_ENV_WHITELIST)
I tried setting BB_ENV_WHITELIST to "BBPATH BB_RESERVE_ENV
BB_ENV_WHITELIST BB_ENV_EXTRAWHITE DL_DIR", and bitbake still didn't
work.

So I looked in poky/bitbake/lib/bb/utils.py and found the following:

def preserved_envvars_exported():
"""Variables which are taken from the environment and placed in and exported
from the metadata"""
return [
'BB_TASKHASH',
'HOME',
'LOGNAME',
'PATH',
'PWD',
'SHELL',
'TERM',
'USER',
]

def preserved_envvars():
"""Variables which are taken from the environment and placed in
the metadata"""
v = [
'BBPATH',
'BB_PRESERVE_ENV',
'BB_ENV_WHITELIST',
'BB_ENV_EXTRAWHITE',
]
return v + preserved_envvars_exported()

...
if 'BB_ENV_WHITELIST' in os.environ:
approved = os.environ['BB_ENV_WHITELIST'].split()
approved.extend(['BB_ENV_WHITELIST'])
else:
approved = preserved_envvars()

This looks like, if BB_ENV_WHITELIST is defined in the environment,
bitbake will use it (arbitrarily appending BB_ENV_WHITELIST to the end
of whatever was defined in the environment variable).  If it is not
defined, then BB_ENV_WHITELIST is initialized to be:

['BBPATH', 'BB_PRESERVE_ENV', 'BB_ENV_WHITELIST', 'BB_ENV_EXTRAWHITE',
'BB_TASKHASH', 'HOME', ...]

So I finally tried setting BB_ENV_WHITELIST in .bashrc to be "BBPATH
BB_PRESERVE_ENV BB_ENV_EXTRAWHITE BB_TASKHASH HOME LOGNAME PATH PWD
SHELL TERM USER DL_DIR"

But it is very sadly ugly... not terribly maintainable... and makes me
think I'm missing something important.

Please tell me I'm missing something important.

--wpd
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] How to maintain a global DL_DIR?

2016-08-16 Thread Patrick Doyle 
As I am playing with several different Yocto/OE projects, I thought it
would be nice to set up a global downloads directory.

Also, being a somewhat forgetful sort, I thought it would be nice if I
could set DL_DIR in my .bashrc and not have to remember to edit
conf/local.conf each time I follow the directions from a third party
site to set up their Yocto based distribution.

Can I do this?  If so, how?

Do I add DL_DIR to BB_ENV_WHITELIST?  Do I add it to
BB_ENV_EXTRAWHITE?  But I note that poky/scripts/oe-buildenv-internal
arbitrarily blasts its own values into BB_ENV_EXTRAWHITE, so setting
BB_ENV_EXTRAWHITE in my .bashrc won't work.

Perhaps I am misunderstanding the concept of the whitelist.  Perhaps I
should just ask for some help.

Help.

Can I maintain a single global download directory specified solely
through environment variables?  If so, how?

Thanks.

--wpd
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Access Control List (ACL) permissions attributes not getting preserved in rootfs

2016-08-16 Thread Kumar, Shrawan 
Thanks Joshua,

"postinst"  works!!  I could see the attributes set under 
"poky/build_qemux86/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/rootfs/".

 However, I still could not see the attributes after booting qemu. It seems 
during rootfs.ext4 (mkfs.ext4 command )creation when "create_image_ext4.sh" is 
called , again this is getting   lost.

Any idea on this ?


Regards
Shrawan





-Original Message-
From: Joshua G Lock [mailto:joshua.g.l...@linux.intel.com] 
Sent: Friday, August 12, 2016 7:22 PM
To: Kumar, Shrawan; yocto@yoctoproject.org
Subject: Re: [yocto] Access Control List (ACL) permissions attributes not 
getting preserved in rootfs

On Fri, 2016-08-12 at 12:33 +, Kumar, Shrawan wrote:
> Hello All,
>  
> I am  using  poky “ jethro”  , and  though  one of my recipe, I have 
> created user1 & user2 and then trying to set ACL rules  on 
> “helloworld” bin as below :
>  
>  
> do_install() {
>     install -d ${D}${bindir}
>     install -m 0700 helloworld ${D}${bindir}
>     install -d ${D}/lib/systemd/system
>     install -m 0700 hello.service 
> ${D}/lib/systemd/system/
>     chown    user1:group1 ${D}${bindir}/helloworld
>        setfacl -m u:user2:r-- ${D}${bindir}/helloworld }
>  
>  
> è When I see   on the devshell ( bitbake HelloWorld –c devshell)  :
> poky/build_qemux86/tmp/work/qemux86-poky-linux/core-image-
> minimal/1.0-r0/rootfs/usr/bin# getfacl helloworld    , I could see 
> that ACL permissions are set correctly as below :
> -    # file: helloworld
> -    # owner: user1
> -    # group: group1
> -    user::rwx
> -    user:user2:r--
> -    group::---
> -    mask::r--
> -    other::---
>  
> However, It does not seems to be getting preserved in rootfs. :
> /poky/build_qemux86/tmp/work/qemux86-poky-linux/core-image-
> minimal/1.0-r0/rootfs/usr/bin# getfacl helloworld # file: helloworld # 
> owner: user1 # group: group1 user::rwx
> group::---
> other::---
>  
> quick help  here would be highly appreciated

This is due to the fact that we don't currently have a mechanism to preserve 
xattr through to image construction[1].

The largest barrier for doig so is that the package managers (certainly dpkg 
and rpm) don't have any support for xattrs in packages (an image is populated 
via the package manager).

To the best of my knowledge the only option for adding some xattr/ACL is to use 
a postinst[2] to set the attributes after the package has been installed.

Regards,

Joshua

1. https://bugzilla.yoctoproject.org/show_bug.cgi?id=9858
2. http://www.yoctoproject.org/docs/2.1/dev-manual/dev-manual.html#new-
recipe-post-installation-scripts

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-virtualization][PATCH] libvirt: remove qemu from PACKAGECONFIG

2016-08-16 Thread kai.kang 
From: Kai Kang 

qemu is not compatible with mips64, so remove 'qemu' which causes
libvirt depends on package qemu from PACKAGECONFIG for mips64.

Signed-off-by: Kai Kang 
---
 recipes-extended/libvirt/libvirt_1.3.5.bb | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/recipes-extended/libvirt/libvirt_1.3.5.bb 
b/recipes-extended/libvirt/libvirt_1.3.5.bb
index 6222b69..68e0885 100644
--- a/recipes-extended/libvirt/libvirt_1.3.5.bb
+++ b/recipes-extended/libvirt/libvirt_1.3.5.bb
@@ -173,6 +173,9 @@ PACKAGECONFIG ??= "qemu yajl uml openvz vmware vbox esx 
iproute2 lxc test \
${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'polkit', 
'', d)} \
   "
 
+# qemu is NOT compatible with mips64
+PACKAGECONFIG_remove_class-target_mips64 = "qemu"
+
 # enable,disable,depends,rdepends
 #
 PACKAGECONFIG[qemu] = "--with-qemu,--without-qemu,qemu,"
-- 
2.9.3

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto