[OE-core] [PATCH] dtc: 1.4.2 -> 1.4.4

2017-05-11 Thread zhengrq 
Upgrade dtc from 1.4.2 to 1.4.4.

Signed-off-by: Zheng Ruoqin 
---
 meta/recipes-kernel/dtc/{dtc_1.4.2.bb => dtc_1.4.4.bb} | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 rename meta/recipes-kernel/dtc/{dtc_1.4.2.bb => dtc_1.4.4.bb} (81%)

diff --git a/meta/recipes-kernel/dtc/dtc_1.4.2.bb 
b/meta/recipes-kernel/dtc/dtc_1.4.4.bb
similarity index 81%
rename from meta/recipes-kernel/dtc/dtc_1.4.2.bb
rename to meta/recipes-kernel/dtc/dtc_1.4.4.bb
index cc72adc..eadb7ba 100644
--- a/meta/recipes-kernel/dtc/dtc_1.4.2.bb
+++ b/meta/recipes-kernel/dtc/dtc_1.4.4.bb
@@ -3,7 +3,7 @@ require dtc.inc
 LIC_FILES_CHKSUM = "file://GPL;md5=94d55d512a9ba36caa9b7df079bae19f \

file://libfdt/libfdt.h;beginline=3;endline=52;md5=fb360963151f8ec2d6c06b055bcbb68c"
 
-SRCREV = "ec02b34c05be04f249ffaaca4b666f5246877dea"
+SRCREV = "558cd81bdd432769b59bff01240c44f82cfb1a9d"
 
 S = "${WORKDIR}/git"
 
-- 
2.7.4



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

Re: [OE-core] [PATCH] recipes-support: Add recipe for libgpiod

2017-05-11 Thread Denys Dmytriyenko 
On Thu, May 11, 2017 at 08:50:09PM +0200, Belisko Marek wrote:
> On Thu, May 11, 2017 at 8:19 PM, Denys Dmytriyenko  wrote:
> > Not to derail your enthusiasm, but since this is being proposed for OE-Core,
> > how is it better than libsoc by Jack Mitchell?
> libsoc is fine but libgpiod will implement correctly gpio handling in
> userspace as gpio sysfs is deprecated.
> What is the problem to have libgpiod available for other potential
> users? Thanks.

As far as I know, libsoc is still being actively supported and if there's an 
API change, it should be fixed in no time. That's why I'm copying Jack here, 
who is an active OE developer here.

As of having an alternative for other potential users - there's nothing wrong 
with it. But, acceptance criteria into OE-Core is quite high, especially when 
there are alternative solutions already available. That's why I'm asking if 
it's any better than the other solution. In other words, why libgpiod should 
be accepted to OE-Core, but not libsoc? Maybe it should be submitted to 
meta-openembedded layer instead?


> More here: 
> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1392949.html
> >
> >
> > On Thu, May 11, 2017 at 07:43:00PM +0200, Marek Belisko wrote:
> >> libgpiod - C library and tools for interacting with the linux GPIO
> >> character device
> >>
> >> Since linux 4.8 the GPIO sysfs interface is deprecated.
> >> User space should use the character device instead.
> >> This library encapsulates the ioctl calls and data structures behind a
> >> straightforward API.
> >>
> >> Signed-off-by: Marek Belisko 
> >> ---
> >>  meta/recipes-support/libgpiod/libgpiod_0.2.bb | 25 
> >> +
> >>  1 file changed, 25 insertions(+)
> >>  create mode 100644 meta/recipes-support/libgpiod/libgpiod_0.2.bb
> >>
> >> diff --git a/meta/recipes-support/libgpiod/libgpiod_0.2.bb 
> >> b/meta/recipes-support/libgpiod/libgpiod_0.2.bb
> >> new file mode 100644
> >> index 000..fe2cd80
> >> --- /dev/null
> >> +++ b/meta/recipes-support/libgpiod/libgpiod_0.2.bb
> >> @@ -0,0 +1,25 @@
> >> +SUMMARY = "C library and tools for interacting with the linux GPIO 
> >> character device"
> >> +HOMEPAGE = "https://github.com/brgl/libgpiod;
> >> +
> >> +LICENSE = "LGPLv2.1+"
> >> +LIC_FILES_CHKSUM = "file://COPYING;md5=2caced0b25dfefd4c601d92bd15116de"
> >> +
> >> +UPSTREAM_CHECK_URI = "https://github.com/brgl/libgpiod/releases;
> >> +
> >> +SRC_URI = "https://github.com/brgl/libgpiod/archive/v${PV}.tar.gz;
> >> +
> >> +SRC_URI[md5sum] = "e3430f35b6efa842693d659c0bfb7ad5"
> >> +SRC_URI[sha256sum] = 
> >> "de1947f3cb2cc4174364af430309fe6238976658575655bdbd76c60cffa7df92"
> >> +
> >> +inherit autotools pkgconfig
> >> +
> >> +# enable tools
> >> +PACKAGECONFIG ?= "tools"
> >> +
> >> +PACKAGECONFIG[tests] = "--enable-tests,--disable-tests,kmod udev"
> >> +PACKAGECONFIG[tools] = "--enable-tools,--disable-tools,"
> >> +
> >> +PACKAGES += " ${PN}-tools"
> >> +
> >> +FILES_${PN} = "${libdir}/*"
> >> +FILES_${PN}-tools = "${bindir}/*"
> >> --
> >> 2.7.4
> >>
> >> --
> >> ___
> >> Openembedded-core mailing list
> >> Openembedded-core@lists.openembedded.org
> >> http://lists.openembedded.org/mailman/listinfo/openembedded-core
> 
> BR,
> 
> marek
> 
> -- 
> as simple and primitive as possible
> -
> Marek Belisko - OPEN-NANDRA
> Freelance Developer
> 
> Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
> Tel: +421 915 052 184
> skype: marekwhite
> twitter: #opennandra
> web: http://open-nandra.com
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] devtool/standard: Fix lock in _prep_extract_operation

2017-05-11 Thread Aníbal Limón 
If for any reason the parse_recipe fail in extract command
the process gets locked because Cooker is expecting the
finish event by tinfoil.

For example:

$ devtool extract remake /tmp/remake

ERROR: remake is unavailable:
  remake was skipped: PREFERRED_PROVIDER_virtual/make set to make, not remake

Signed-off-by: Aníbal Limón 
---
 scripts/lib/devtool/standard.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/scripts/lib/devtool/standard.py b/scripts/lib/devtool/standard.py
index 5ff1e23..5fa1317 100644
--- a/scripts/lib/devtool/standard.py
+++ b/scripts/lib/devtool/standard.py
@@ -436,6 +436,7 @@ def _prep_extract_operation(config, basepath, recipename, 
tinfoil=None):
 
 rd = parse_recipe(config, tinfoil, recipename, True)
 if not rd:
+tinfoil.shutdown()
 return None
 
 if bb.data.inherits_class('kernel-yocto', rd):
-- 
2.1.4

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

Re: [OE-core] [PATCH v2] runtime/dnf: Add new dnf test cases

2017-05-11 Thread Jose Perez Carranza 



On 05/11/2017 01:56 PM, Alexander Kanavin wrote:

On 05/11/2017 08:33 PM, jose.perez.carra...@linux.intel.com wrote:

+def test_dnf_exclude(self):
+excludepkg = 'curl-dev'
+self.dnf('list %s' % excludepkg, 0)
+self.dnf_with_repo('remove -y curl')
+self.dnf_with_repo('install -y --exclude=%s curl' % excludepkg)
+self.dnf('list %s' % excludepkg, 1)


1) Why is curl-dev already installed when the test starts? Will that 
be always the case?
Will add logic to validate if curl is not installed then not try to 
remove it and go directly to test --exclude option


2) I still don't understand how the test works. You are asking for 
curl to be installed and curl-dev to be excluded, but curl-dev would 
not be installed regardless of --exclude option, because curl does not 
depend on it. You need to test a situation where --exclude makes a 
difference, and check that there is indeed a difference.
curl-dev is always installed with curl as a weak dependency, so every 
time you install or remove curl also curl-dev is affected, hence this 
test validate that --exclude option is working correctly by checking 
that curl-dev (weak dependency) is not installed,


Alex



--
Saludos
José

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

Re: [OE-core] [PATCH v2] runtime/dnf: Add new dnf test cases

2017-05-11 Thread Alexander Kanavin 

On 05/11/2017 08:33 PM, jose.perez.carra...@linux.intel.com wrote:

+def test_dnf_exclude(self):
+excludepkg = 'curl-dev'
+self.dnf('list %s' % excludepkg, 0)
+self.dnf_with_repo('remove -y curl')
+self.dnf_with_repo('install -y --exclude=%s curl' % excludepkg)
+self.dnf('list %s' % excludepkg, 1)


1) Why is curl-dev already installed when the test starts? Will that be 
always the case?


2) I still don't understand how the test works. You are asking for curl 
to be installed and curl-dev to be excluded, but curl-dev would not be 
installed regardless of --exclude option, because curl does not depend 
on it. You need to test a situation where --exclude makes a difference, 
and check that there is indeed a difference.


Alex

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

Re: [OE-core] [PATCH] recipes-support: Add recipe for libgpiod

2017-05-11 Thread Belisko Marek 
On Thu, May 11, 2017 at 8:19 PM, Denys Dmytriyenko  wrote:
> Not to derail your enthusiasm, but since this is being proposed for OE-Core,
> how is it better than libsoc by Jack Mitchell?
libsoc is fine but libgpiod will implement correctly gpio handling in
userspace as gpio sysfs is deprecated.
What is the problem to have libgpiod available for other potential
users? Thanks.
More here: 
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1392949.html
>
>
> On Thu, May 11, 2017 at 07:43:00PM +0200, Marek Belisko wrote:
>> libgpiod - C library and tools for interacting with the linux GPIO
>> character device
>>
>> Since linux 4.8 the GPIO sysfs interface is deprecated.
>> User space should use the character device instead.
>> This library encapsulates the ioctl calls and data structures behind a
>> straightforward API.
>>
>> Signed-off-by: Marek Belisko 
>> ---
>>  meta/recipes-support/libgpiod/libgpiod_0.2.bb | 25 +
>>  1 file changed, 25 insertions(+)
>>  create mode 100644 meta/recipes-support/libgpiod/libgpiod_0.2.bb
>>
>> diff --git a/meta/recipes-support/libgpiod/libgpiod_0.2.bb 
>> b/meta/recipes-support/libgpiod/libgpiod_0.2.bb
>> new file mode 100644
>> index 000..fe2cd80
>> --- /dev/null
>> +++ b/meta/recipes-support/libgpiod/libgpiod_0.2.bb
>> @@ -0,0 +1,25 @@
>> +SUMMARY = "C library and tools for interacting with the linux GPIO 
>> character device"
>> +HOMEPAGE = "https://github.com/brgl/libgpiod;
>> +
>> +LICENSE = "LGPLv2.1+"
>> +LIC_FILES_CHKSUM = "file://COPYING;md5=2caced0b25dfefd4c601d92bd15116de"
>> +
>> +UPSTREAM_CHECK_URI = "https://github.com/brgl/libgpiod/releases;
>> +
>> +SRC_URI = "https://github.com/brgl/libgpiod/archive/v${PV}.tar.gz;
>> +
>> +SRC_URI[md5sum] = "e3430f35b6efa842693d659c0bfb7ad5"
>> +SRC_URI[sha256sum] = 
>> "de1947f3cb2cc4174364af430309fe6238976658575655bdbd76c60cffa7df92"
>> +
>> +inherit autotools pkgconfig
>> +
>> +# enable tools
>> +PACKAGECONFIG ?= "tools"
>> +
>> +PACKAGECONFIG[tests] = "--enable-tests,--disable-tests,kmod udev"
>> +PACKAGECONFIG[tools] = "--enable-tools,--disable-tools,"
>> +
>> +PACKAGES += " ${PN}-tools"
>> +
>> +FILES_${PN} = "${libdir}/*"
>> +FILES_${PN}-tools = "${bindir}/*"
>> --
>> 2.7.4
>>
>> --
>> ___
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core

BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] recipes-support: Add recipe for libgpiod

2017-05-11 Thread Denys Dmytriyenko 
Not to derail your enthusiasm, but since this is being proposed for OE-Core, 
how is it better than libsoc by Jack Mitchell?


On Thu, May 11, 2017 at 07:43:00PM +0200, Marek Belisko wrote:
> libgpiod - C library and tools for interacting with the linux GPIO
> character device
> 
> Since linux 4.8 the GPIO sysfs interface is deprecated.
> User space should use the character device instead.
> This library encapsulates the ioctl calls and data structures behind a
> straightforward API.
> 
> Signed-off-by: Marek Belisko 
> ---
>  meta/recipes-support/libgpiod/libgpiod_0.2.bb | 25 +
>  1 file changed, 25 insertions(+)
>  create mode 100644 meta/recipes-support/libgpiod/libgpiod_0.2.bb
> 
> diff --git a/meta/recipes-support/libgpiod/libgpiod_0.2.bb 
> b/meta/recipes-support/libgpiod/libgpiod_0.2.bb
> new file mode 100644
> index 000..fe2cd80
> --- /dev/null
> +++ b/meta/recipes-support/libgpiod/libgpiod_0.2.bb
> @@ -0,0 +1,25 @@
> +SUMMARY = "C library and tools for interacting with the linux GPIO character 
> device"
> +HOMEPAGE = "https://github.com/brgl/libgpiod;
> +
> +LICENSE = "LGPLv2.1+"
> +LIC_FILES_CHKSUM = "file://COPYING;md5=2caced0b25dfefd4c601d92bd15116de"
> +
> +UPSTREAM_CHECK_URI = "https://github.com/brgl/libgpiod/releases;
> +
> +SRC_URI = "https://github.com/brgl/libgpiod/archive/v${PV}.tar.gz;
> +
> +SRC_URI[md5sum] = "e3430f35b6efa842693d659c0bfb7ad5"
> +SRC_URI[sha256sum] = 
> "de1947f3cb2cc4174364af430309fe6238976658575655bdbd76c60cffa7df92"
> +
> +inherit autotools pkgconfig
> +
> +# enable tools
> +PACKAGECONFIG ?= "tools"
> +
> +PACKAGECONFIG[tests] = "--enable-tests,--disable-tests,kmod udev"
> +PACKAGECONFIG[tools] = "--enable-tools,--disable-tools,"
> +
> +PACKAGES += " ${PN}-tools"
> +
> +FILES_${PN} = "${libdir}/*"
> +FILES_${PN}-tools = "${bindir}/*"
> -- 
> 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

[OE-core] [PATCH] recipes-support: Add recipe for libgpiod

2017-05-11 Thread Marek Belisko 
libgpiod - C library and tools for interacting with the linux GPIO
character device

Since linux 4.8 the GPIO sysfs interface is deprecated.
User space should use the character device instead.
This library encapsulates the ioctl calls and data structures behind a
straightforward API.

Signed-off-by: Marek Belisko 
---
 meta/recipes-support/libgpiod/libgpiod_0.2.bb | 25 +
 1 file changed, 25 insertions(+)
 create mode 100644 meta/recipes-support/libgpiod/libgpiod_0.2.bb

diff --git a/meta/recipes-support/libgpiod/libgpiod_0.2.bb 
b/meta/recipes-support/libgpiod/libgpiod_0.2.bb
new file mode 100644
index 000..fe2cd80
--- /dev/null
+++ b/meta/recipes-support/libgpiod/libgpiod_0.2.bb
@@ -0,0 +1,25 @@
+SUMMARY = "C library and tools for interacting with the linux GPIO character 
device"
+HOMEPAGE = "https://github.com/brgl/libgpiod;
+
+LICENSE = "LGPLv2.1+"
+LIC_FILES_CHKSUM = "file://COPYING;md5=2caced0b25dfefd4c601d92bd15116de"
+
+UPSTREAM_CHECK_URI = "https://github.com/brgl/libgpiod/releases;
+
+SRC_URI = "https://github.com/brgl/libgpiod/archive/v${PV}.tar.gz;
+
+SRC_URI[md5sum] = "e3430f35b6efa842693d659c0bfb7ad5"
+SRC_URI[sha256sum] = 
"de1947f3cb2cc4174364af430309fe6238976658575655bdbd76c60cffa7df92"
+
+inherit autotools pkgconfig
+
+# enable tools
+PACKAGECONFIG ?= "tools"
+
+PACKAGECONFIG[tests] = "--enable-tests,--disable-tests,kmod udev"
+PACKAGECONFIG[tools] = "--enable-tools,--disable-tools,"
+
+PACKAGES += " ${PN}-tools"
+
+FILES_${PN} = "${libdir}/*"
+FILES_${PN}-tools = "${bindir}/*"
-- 
2.7.4

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

[OE-core] [PATCH v2] runtime/dnf: Add new dnf test cases

2017-05-11 Thread jose . perez . carranza 
From: Jose Perez Carranza 

Add test cases to test “exclude” and “installroot“ options, also modify
the logic of filtering packages on the feed to have all the packages
needed by the tests.

[YOCTO #10744]

Signed-off-by: Jose Perez Carranza 
---
 meta/classes/testimage.bbclass | 11 ---
 meta/lib/oeqa/runtime/cases/dnf.py | 19 ++-
 2 files changed, 26 insertions(+), 4 deletions(-)

diff --git a/meta/classes/testimage.bbclass b/meta/classes/testimage.bbclass
index fb214604a97..a0d07c9f003 100644
--- a/meta/classes/testimage.bbclass
+++ b/meta/classes/testimage.bbclass
@@ -329,6 +329,7 @@ def create_index(arg):
 return None
 
 def create_rpm_index(d):
+import glob
 # Index RPMs
 rpm_createrepo = bb.utils.which(os.getenv('PATH'), "createrepo_c")
 index_cmds = []
@@ -345,9 +346,13 @@ def create_rpm_index(d):
 lf = bb.utils.lockfile(lockfilename, False)
 oe.path.copyhardlinktree(rpm_dir, idx_path)
 # Full indexes overload a 256MB image so reduce the number of rpms
-# in the feed. Filter to r* since we use the run-postinst packages and
-# this leaves some allarch and machine arch packages too.
-bb.utils.remove(idx_path + "*/[a-qs-z]*.rpm")
+# in the feed by filtering to specific packages needed by the tests.
+package_list = glob.glob(idx_path + "*/*.rpm")
+
+for pkg in package_list:
+if not os.path.basename(pkg).startswith(("rpm", "run-postinsts", 
"busybox", "bash", "update-alternatives", "libc6", "curl")):
+bb.utils.remove(pkg)
+
 bb.utils.unlockfile(lf)
 cmd = '%s --update -q %s' % (rpm_createrepo, idx_path)
 
diff --git a/meta/lib/oeqa/runtime/cases/dnf.py 
b/meta/lib/oeqa/runtime/cases/dnf.py
index 2f87296b4e0..0baf796278b 100644
--- a/meta/lib/oeqa/runtime/cases/dnf.py
+++ b/meta/lib/oeqa/runtime/cases/dnf.py
@@ -120,4 +120,21 @@ class DnfRepoTest(DnfTest):
 def test_dnf_reinstall(self):
 self.dnf_with_repo('reinstall -y run-postinsts-dev')
 
-
+@OETestDepends(['dnf.DnfRepoTest.test_dnf_makecache'])
+@OETestID(1771)
+def test_dnf_installroot(self):
+rootpath = '/home/root/chroot/test'
+self.dnf_with_repo('install --installroot=%s --allowerasing -v -y 
busybox run-postinsts' % rootpath)
+status, output = self.target.run('test -e %s/var/cache/dnf' % 
rootpath, 1500)
+self.assertEqual(0, status, output)
+status, output = self.target.run('test -e %s/bin/busybox' % rootpath, 
1500)
+self.assertEqual(0, status, output)
+
+@OETestDepends(['dnf.DnfRepoTest.test_dnf_reinstall'])
+@OETestID(1772)
+def test_dnf_exclude(self):
+excludepkg = 'curl-dev'
+self.dnf('list %s' % excludepkg, 0)
+self.dnf_with_repo('remove -y curl')
+self.dnf_with_repo('install -y --exclude=%s curl' % excludepkg)
+self.dnf('list %s' % excludepkg, 1)
-- 
2.11.0

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

Re: [OE-core] [OT?] where to start building for qualcomm snapdragon APQ8016E dragonboard 410C?

2017-05-11 Thread Khem Raj 
On Thu, May 11, 2017 at 9:48 AM, Nicolas Dechesne
 wrote:
> On Thu, May 11, 2017 at 6:43 PM, Khem Raj  wrote:
>> user meta-96boards and meta-qcom and you are set usually do builds
>> for MACHINE = "dragonboard-410c"
>
> meta-96boards is not required.  the main recipe from meta-96boards
> which is 'useful' is 96boards-tools since it would auto resize the
> rootfs partition at first boot. but it's clearly non essential
> content.

right on. Thats what I use it from that layer but its quite handy

>
>>
>> you also need
>>
>> ACCEPT_EULA_dragonboard-410c = "1"
>>
>> otherwise the build errors out with strange access errors.
>
> hmm. that's not quite expected.. I will check this one. on the other
> hand I will soon remove that anyways..

will be good. but it doesnt bother me I also deal with fsl layers :(
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [OT?] where to start building for qualcomm snapdragon APQ8016E dragonboard 410C?

2017-05-11 Thread Nicolas Dechesne 
On Thu, May 11, 2017 at 6:43 PM, Khem Raj  wrote:
> user meta-96boards and meta-qcom and you are set usually do builds
> for MACHINE = "dragonboard-410c"

meta-96boards is not required.  the main recipe from meta-96boards
which is 'useful' is 96boards-tools since it would auto resize the
rootfs partition at first boot. but it's clearly non essential
content.

>
> you also need
>
> ACCEPT_EULA_dragonboard-410c = "1"
>
> otherwise the build errors out with strange access errors.

hmm. that's not quite expected.. I will check this one. on the other
hand I will soon remove that anyways..
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 3/3] package_ipk/deb: Tweak functions for better cleanup and layout

2017-05-11 Thread Richard Purdie 
This uses more modern formatting to handle the lockfiles and control
file cleanup with try/finally, taking advantage of the previous
extra indentation.

Signed-off-by: Richard Purdie 
---
 meta/classes/package_deb.bbclass | 33 +
 meta/classes/package_ipk.bbclass | 32 
 2 files changed, 33 insertions(+), 32 deletions(-)

diff --git a/meta/classes/package_deb.bbclass b/meta/classes/package_deb.bbclass
index 636647d..04b9197 100644
--- a/meta/classes/package_deb.bbclass
+++ b/meta/classes/package_deb.bbclass
@@ -69,25 +69,26 @@ python do_package_deb () {
 }
 
 def deb_write_pkg(pkg, d):
-import re, copy
-import textwrap
-import subprocess
-import collections
-import codecs
+import re, copy
+import textwrap
+import subprocess
+import collections
+import codecs
 
-outdir = d.getVar('PKGWRITEDIRDEB')
-pkgdest = d.getVar('PKGDEST')
+outdir = d.getVar('PKGWRITEDIRDEB')
+pkgdest = d.getVar('PKGDEST')
 
-def cleanupcontrol(root):
-for p in ['CONTROL', 'DEBIAN']:
-p = os.path.join(root, p)
-if os.path.exists(p):
-bb.utils.prunedir(p)
+def cleanupcontrol(root):
+for p in ['CONTROL', 'DEBIAN']:
+p = os.path.join(root, p)
+if os.path.exists(p):
+bb.utils.prunedir(p)
 
-localdata = bb.data.createCopy(d)
-root = "%s/%s" % (pkgdest, pkg)
+localdata = bb.data.createCopy(d)
+root = "%s/%s" % (pkgdest, pkg)
 
-lf = bb.utils.lockfile(root + ".lock")
+lf = bb.utils.lockfile(root + ".lock")
+try:
 
 localdata.setVar('ROOT', '')
 localdata.setVar('ROOT_%s' % pkg, root)
@@ -109,7 +110,6 @@ def deb_write_pkg(pkg, d):
 g = glob('*')
 if not g and localdata.getVar('ALLOW_EMPTY', False) != "1":
 bb.note("Not creating empty archive for %s-%s-%s" % (pkg, 
localdata.getVar('PKGV'), localdata.getVar('PKGR')))
-bb.utils.unlockfile(lf)
 return
 
 controldir = os.path.join(root, 'DEBIAN')
@@ -283,6 +283,7 @@ def deb_write_pkg(pkg, d):
 os.chdir(basedir)
 subprocess.check_output("PATH=\"%s\" dpkg-deb -b %s %s" % 
(localdata.getVar("PATH"), root, pkgoutdir), shell=True)
 
+finally:
 cleanupcontrol(root)
 bb.utils.unlockfile(lf)
 
diff --git a/meta/classes/package_ipk.bbclass b/meta/classes/package_ipk.bbclass
index 16ee761..5cc7e0a 100644
--- a/meta/classes/package_ipk.bbclass
+++ b/meta/classes/package_ipk.bbclass
@@ -44,25 +44,25 @@ python do_package_ipk () {
 }
 
 def ipk_write_pkg(pkg, d):
-import re, copy
-import subprocess
-import textwrap
-import collections
+import re, copy
+import subprocess
+import textwrap
+import collections
 
-def cleanupcontrol(root):
-for p in ['CONTROL', 'DEBIAN']:
-p = os.path.join(root, p)
-if os.path.exists(p):
-bb.utils.prunedir(p)
+def cleanupcontrol(root):
+for p in ['CONTROL', 'DEBIAN']:
+p = os.path.join(root, p)
+if os.path.exists(p):
+bb.utils.prunedir(p)
 
-outdir = d.getVar('PKGWRITEDIRIPK')
-pkgdest = d.getVar('PKGDEST')
-
-localdata = bb.data.createCopy(d)
-root = "%s/%s" % (pkgdest, pkg)
+outdir = d.getVar('PKGWRITEDIRIPK')
+pkgdest = d.getVar('PKGDEST')
 
-lf = bb.utils.lockfile(root + ".lock")
+localdata = bb.data.createCopy(d)
+root = "%s/%s" % (pkgdest, pkg)
 
+lf = bb.utils.lockfile(root + ".lock")
+try:
 localdata.setVar('ROOT', '')
 localdata.setVar('ROOT_%s' % pkg, root)
 pkgname = localdata.getVar('PKG_%s' % pkg)
@@ -107,7 +107,6 @@ def ipk_write_pkg(pkg, d):
 g = glob('*')
 if not g and localdata.getVar('ALLOW_EMPTY', False) != "1":
 bb.note("Not creating empty archive for %s-%s-%s" % (pkg, 
localdata.getVar('PKGV'), localdata.getVar('PKGR')))
-bb.utils.unlockfile(lf)
 return
 
 controldir = os.path.join(root, 'CONTROL')
@@ -245,6 +244,7 @@ def ipk_write_pkg(pkg, d):
 ipk_to_sign = "%s/%s_%s_%s.ipk" % (pkgoutdir, pkgname, ipkver, 
d.getVar('PACKAGE_ARCH'))
 sign_ipk(d, ipk_to_sign)
 
+finally:
 cleanupcontrol(root)
 bb.utils.unlockfile(lf)
 
-- 
2.7.4

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

[OE-core] [PATCH 1/3] package_ipk: Split into two functions

2017-05-11 Thread Richard Purdie 
This prepares the way to parallelise ipk generation and splits the iteration
over packages and the package generation into separate functions. Whitespace
indentation is unchanged deliberately and is fixed in a followup patch. There
should be no functional change.

Signed-off-by: Richard Purdie 
---
 meta/classes/package_ipk.bbclass | 38 +++---
 1 file changed, 23 insertions(+), 15 deletions(-)

diff --git a/meta/classes/package_ipk.bbclass b/meta/classes/package_ipk.bbclass
index c7cec9d..16ee761 100644
--- a/meta/classes/package_ipk.bbclass
+++ b/meta/classes/package_ipk.bbclass
@@ -17,11 +17,6 @@ OPKG_ARGS += "${@['', '--add-exclude ' + ' --add-exclude 
'.join((d.getVar('PACKA
 OPKGLIBDIR = "${localstatedir}/lib"
 
 python do_package_ipk () {
-import re, copy
-import textwrap
-import subprocess
-import collections
-
 oldcwd = os.getcwd()
 
 workdir = d.getVar('WORKDIR')
@@ -42,13 +37,27 @@ python do_package_ipk () {
 if os.access(os.path.join(tmpdir, "stamps", "IPK_PACKAGE_INDEX_CLEAN"), 
os.R_OK):
 os.unlink(os.path.join(tmpdir, "stamps", "IPK_PACKAGE_INDEX_CLEAN"))
 
-def cleanupcontrol(root):
-for p in ['CONTROL', 'DEBIAN']:
-p = os.path.join(root, p)
-if os.path.exists(p):
-bb.utils.prunedir(p)
-
 for pkg in packages.split():
+ipk_write_pkg(pkg, d)
+
+os.chdir(oldcwd)
+}
+
+def ipk_write_pkg(pkg, d):
+import re, copy
+import subprocess
+import textwrap
+import collections
+
+def cleanupcontrol(root):
+for p in ['CONTROL', 'DEBIAN']:
+p = os.path.join(root, p)
+if os.path.exists(p):
+bb.utils.prunedir(p)
+
+outdir = d.getVar('PKGWRITEDIRIPK')
+pkgdest = d.getVar('PKGDEST')
+
 localdata = bb.data.createCopy(d)
 root = "%s/%s" % (pkgdest, pkg)
 
@@ -99,7 +108,7 @@ python do_package_ipk () {
 if not g and localdata.getVar('ALLOW_EMPTY', False) != "1":
 bb.note("Not creating empty archive for %s-%s-%s" % (pkg, 
localdata.getVar('PKGV'), localdata.getVar('PKGR')))
 bb.utils.unlockfile(lf)
-continue
+return
 
 controldir = os.path.join(root, 'CONTROL')
 bb.utils.mkdirhier(controldir)
@@ -239,10 +248,9 @@ python do_package_ipk () {
 cleanupcontrol(root)
 bb.utils.unlockfile(lf)
 
-os.chdir(oldcwd)
-}
 # Otherwise allarch packages may change depending on override configuration
-do_package_ipk[vardepsexclude] = "OVERRIDES"
+ipk_write_pkg[vardepsexclude] = "OVERRIDES"
+
 
 SSTATETASKS += "do_package_write_ipk"
 do_package_write_ipk[sstate-inputdirs] = "${PKGWRITEDIRIPK}"
-- 
2.7.4

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

[OE-core] [PATCH 2/3] package_deb: Split do_package_write_deb into two functions

2017-05-11 Thread Richard Purdie 
This prepares the way to parallelise deb generation and splits the iteration
over packages and the package generation into separate functions. Whitespace
indentation is unchanged deliberately and is fixed in a followup patch. There
should be no functional change.

Some checks on variables are removed as they were pointless when you looked
at the code.

Signed-off-by: Richard Purdie 
---
 meta/classes/package_deb.bbclass | 57 +---
 1 file changed, 24 insertions(+), 33 deletions(-)

diff --git a/meta/classes/package_deb.bbclass b/meta/classes/package_deb.bbclass
index eacabcd..636647d 100644
--- a/meta/classes/package_deb.bbclass
+++ b/meta/classes/package_deb.bbclass
@@ -51,47 +51,39 @@ def debian_arch_map(arch, tune):
 # INSTALL_TASK_DEB - task name
 
 python do_package_deb () {
-import re, copy
-import textwrap
-import subprocess
-import collections
-import codecs
-
 oldcwd = os.getcwd()
 
-workdir = d.getVar('WORKDIR')
-if not workdir:
-bb.error("WORKDIR not defined, unable to package")
-return
-
-outdir = d.getVar('PKGWRITEDIRDEB')
-if not outdir:
-bb.error("PKGWRITEDIRDEB not defined, unable to package")
-return
-
 packages = d.getVar('PACKAGES')
 if not packages:
 bb.debug(1, "PACKAGES not defined, nothing to package")
 return
 
 tmpdir = d.getVar('TMPDIR')
-
 if os.access(os.path.join(tmpdir, "stamps", 
"DEB_PACKAGE_INDEX_CLEAN"),os.R_OK):
 os.unlink(os.path.join(tmpdir, "stamps", "DEB_PACKAGE_INDEX_CLEAN"))
 
-if packages == []:
-bb.debug(1, "No packages; nothing to do")
-return
+for pkg in packages.split():
+deb_write_pkg(pkg, d)
+
+os.chdir(oldcwd)
+}
 
-pkgdest = d.getVar('PKGDEST')
+def deb_write_pkg(pkg, d):
+import re, copy
+import textwrap
+import subprocess
+import collections
+import codecs
 
-def cleanupcontrol(root):
-for p in ['CONTROL', 'DEBIAN']:
-p = os.path.join(root, p)
-if os.path.exists(p):
-bb.utils.prunedir(p)
+outdir = d.getVar('PKGWRITEDIRDEB')
+pkgdest = d.getVar('PKGDEST')
+
+def cleanupcontrol(root):
+for p in ['CONTROL', 'DEBIAN']:
+p = os.path.join(root, p)
+if os.path.exists(p):
+bb.utils.prunedir(p)
 
-for pkg in packages.split():
 localdata = bb.data.createCopy(d)
 root = "%s/%s" % (pkgdest, pkg)
 
@@ -118,7 +110,7 @@ python do_package_deb () {
 if not g and localdata.getVar('ALLOW_EMPTY', False) != "1":
 bb.note("Not creating empty archive for %s-%s-%s" % (pkg, 
localdata.getVar('PKGV'), localdata.getVar('PKGR')))
 bb.utils.unlockfile(lf)
-continue
+return
 
 controldir = os.path.join(root, 'DEBIAN')
 bb.utils.mkdirhier(controldir)
@@ -293,13 +285,12 @@ python do_package_deb () {
 
 cleanupcontrol(root)
 bb.utils.unlockfile(lf)
-os.chdir(oldcwd)
-}
-# Indirect references to these vars
-do_package_write_deb[vardeps] += "PKGV PKGR PKGV DESCRIPTION SECTION PRIORITY 
MAINTAINER DPKG_ARCH PN HOMEPAGE"
+
 # Otherwise allarch packages may change depending on override configuration
-do_package_deb[vardepsexclude] = "OVERRIDES"
+deb_write_pkg[vardepsexclude] = "OVERRIDES"
 
+# Indirect references to these vars
+do_package_write_deb[vardeps] += "PKGV PKGR PKGV DESCRIPTION SECTION PRIORITY 
MAINTAINER DPKG_ARCH PN HOMEPAGE"
 
 SSTATETASKS += "do_package_write_deb"
 do_package_write_deb[sstate-inputdirs] = "${PKGWRITEDIRDEB}"
-- 
2.7.4

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

Re: [OE-core] [OT?] where to start building for qualcomm snapdragon APQ8016E dragonboard 410C?

2017-05-11 Thread Khem Raj 
user meta-96boards and meta-qcom and you are set usually do builds
for MACHINE = "dragonboard-410c"

you also need

ACCEPT_EULA_dragonboard-410c = "1"

otherwise the build errors out with strange access errors.

On Thu, May 11, 2017 at 5:22 AM, Nicolas Dechesne
 wrote:
> hi Robert,
>
> On Thu, May 11, 2017 at 12:48 PM, Robert P. J. Day
>  wrote:
>>
>>   (i'm sure there's a more appropriate forum to ask this, but i'm just
>> going to throw myself on the mercy of the general OE list.)
>>
>>   i've been asked to help out with lashing together an OE build for a
>> target board that will be based on qualcomm's snapdragon 410 APQ8016E,
>> so the obvious choice for an initial reference system would be the
>> 96boards.org-approved dragonboard 410c from arrow (i'm open to other
>> suggestions for more fully-featured boards supported by OE):
>>
>>  http://www.96boards.org/product/dragonboard410c/
>>
>> but, wow, are there a bunch of places to start pulling content from.
>>
>>   i picked out the meta-qcom layer immediately:
>>
>>  http://git.yoctoproject.org/cgit/cgit.cgi/meta-qcom
>
> As a disclaimer... I am the maintainer for the above layer (and also
> very much involved with what Linaro/96boards does with dragonboard in
> general).
>
> Note that the layer is more generally maintained on github, and
> mirror'd on YP git. So if you want to contribute you should use github
> instead:
>
> https://github.com/ndechesne/meta-qcom
>
>>
>> which has a machine definition for that very board, and i built a
>> core-image-minimal image for that target with no trouble (have not
>> loaded and tested yet, board supposedly arrives tomorrow). so far, so
>> good. but when i perused further, i found all sorts of URLs with more
>> info/content/layers, depending on what you were after:
>>
>>  git://git.linaro.org/landing-teams/working/qualcomm/kernel.git
>
> This is the kernel tree maintained by Linaro. Everything that we do is
> intended to end up in mainline kernel at some point, and in the mean
> time we have development and release branches that we maintained for
> our own builds.
>
> At Linaro we are doing/supporting "linux" builds (based on Debian or
> OE) and we  also have experimental Android builds based on AOSP.
>
> Canonical has been using this tree as a starting point for their
> Ubuntu Core port for the board as well. Several other distros are
> doing similar things..
>
> The kernel is *very* different from what you would find in shipping
> Qualcomm products. Qualcomm has their own kernel tree for each SoC
> that they support, and they *never* upgrade kernel. For MSM8916
> chipset they shipped with a 3.10 based kernel. For the Linaro/96boards
> builds, our kernel is being upgraded once a year, we track LTS
> releases, so we currently support 4.9.
>
> For reference the Qualcomm 'product/vendor' tree can be found here:
>
> https://source.codeaurora.org/quic/la/kernel/msm-3.10/
>
>>  
>> https://www.codeaurora.org/openembedded-mass-market-and-ioe-qualcomm-snapdragon
>
> This is a build from Qualcomm, which is derived from the Linaro Open
> Embedded builds for Dragonboard. There aren't many differences between
> what you can get from this build, vs what you can get from Linaro OE
> builds for this board. In fact, you can consider this product as a
> 'downstream' of ours.
>
>>  https://developer.qualcomm.com/hardware/dragonboard-410c
>
> This is Qualcomm official developer page for the board. With chipset
> documentation (h/w) and s/w documentation. The s/w documentation is
> mostly about Qualcomm Android builds and the vendor kernel. You can
> also find there the proprietary bootloader and firmware blob, which we
> use even in our Linux builds.
>
>>  https://github.com/96boards/
>
> This is the home for some of the 96boards related projects, it's
> mostly irrelevant in your situtation, most of what you expect/want can
> be found in meta-qcom.
>
>>  https://createpoint.qti.qualcomm.com/
>
> this is a documentation data base from QCOM. You need to be authorized
> for access , here. And based on your level of authorization, you will
> have access to more or less documentation..
>
>>
>> and i'm not sure that's even the entire list i've seen.
>
> in fact I believe there is also a Linux/OE based 'setup' that exists
> somewhere, from Qualcomm, but using their very own vendor (e.g. 3.10)
> kernel. I am not sure what this is about, and I don't have any detail
> about this one.
>
>>
>>   specifically, i'm wondering where the canonical code base is for
>> what i'm doing, and i was told that it's at that qualcomm location,
>> for which one needs an account. a colleague has an account and let me
>> peruse the qualcomm createpoint repo, but it seems that whatever i see
>> there is available publicly, particularly at codeaurora.org.
>>
>>   can someone clarify how all these sites hang together, and where one
>> starts? as i said, right now, the meta-qcom layer works right out of
>> the

[OE-core] [PATCH 3/4] sstate: Ensure native/cross recipes have relocation of HOSTTOOLS_DIR

2017-05-11 Thread Richard Purdie 
The previous change to relocate HOSTTOOLS wasn't complete as some files,
particularly in gcc stashed build directories were not being correctly
relocated. This patch addresses the issue.

Signed-off-by: Richard Purdie 
---
 meta/classes/sstate.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
index ddc442c..0a12935 100644
--- a/meta/classes/sstate.bbclass
+++ b/meta/classes/sstate.bbclass
@@ -33,7 +33,7 @@ SSTATE_DUPWHITELIST += "${DEPLOY_DIR_SRC}"
 
 SSTATE_SCAN_FILES ?= "*.la *-config *_config postinst-*"
 SSTATE_SCAN_CMD ??= 'find ${SSTATE_BUILDDIR} \( -name "${@"\" -o -name 
\"".join(d.getVar("SSTATE_SCAN_FILES").split())}" \) -type f'
-SSTATE_SCAN_CMD_NATIVE ??= 'grep -Irl -e ${RECIPE_SYSROOT} -e 
${RECIPE_SYSROOT_NATIVE} ${SSTATE_BUILDDIR}'
+SSTATE_SCAN_CMD_NATIVE ??= 'grep -Irl -e ${RECIPE_SYSROOT} -e 
${RECIPE_SYSROOT_NATIVE} -e ${HOSTTOOLS_DIR} ${SSTATE_BUILDDIR}'
 
 BB_HASHFILENAME = "False ${SSTATE_PKGSPEC} ${SSTATE_SWSPEC}"
 
-- 
2.7.4

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

[OE-core] [PATCH 4/4] staging: Allow BB_LIMITEDDEPS to avoid BB_TASKDEPDATA

2017-05-11 Thread Richard Purdie 
In the limited dependency case we don't use any of the data from
BB_TASKDEPDATA. Restructure the code so this variable doesn't have
to be set. This allows the function to be called from other contexts
without creating artificial constructs. There should be no functional
change, behaviour remains unchanged.

Signed-off-by: Richard Purdie 
---
 meta/classes/staging.bbclass | 32 
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/meta/classes/staging.bbclass b/meta/classes/staging.bbclass
index 565638f..9c26794 100644
--- a/meta/classes/staging.bbclass
+++ b/meta/classes/staging.bbclass
@@ -331,12 +331,26 @@ python extend_recipe_sysroot() {
 
 taskdepdata = d.getVar("BB_TASKDEPDATA", False)
 mytaskname = d.getVar("BB_RUNTASK")
+if mytaskname.endswith("_setscene"):
+mytaskname = mytaskname.replace("_setscene", "")
 workdir = d.getVar("WORKDIR")
 #bb.warn(str(taskdepdata))
 pn = d.getVar("PN")
 
-if mytaskname.endswith("_setscene"):
-mytaskname = mytaskname.replace("_setscene", "")
+stagingdir = d.getVar("STAGING_DIR")
+sharedmanifests = d.getVar("COMPONENTS_DIR") + "/manifests"
+recipesysroot = d.getVar("RECIPE_SYSROOT")
+recipesysrootnative = d.getVar("RECIPE_SYSROOT_NATIVE")
+current_variant = d.getVar("BBEXTENDVARIANT")
+
+# Detect bitbake -b usage
+nodeps = d.getVar("BB_LIMITEDDEPS") or False
+if nodeps:
+lock = bb.utils.lockfile(recipesysroot + "/sysroot.lock")
+staging_populate_sysroot_dir(recipesysroot, recipesysrootnative, True, 
d)
+staging_populate_sysroot_dir(recipesysroot, recipesysrootnative, 
False, d)
+bb.utils.unlockfile(lock)
+return
 
 start = None
 configuredeps = []
@@ -441,20 +455,6 @@ python extend_recipe_sysroot() {
 
 bb.note("\n".join(msgbuf))
 
-stagingdir = d.getVar("STAGING_DIR")
-sharedmanifests = d.getVar("COMPONENTS_DIR") + "/manifests"
-recipesysroot = d.getVar("RECIPE_SYSROOT")
-recipesysrootnative = d.getVar("RECIPE_SYSROOT_NATIVE")
-current_variant = d.getVar("BBEXTENDVARIANT")
-
-# Detect bitbake -b usage
-nodeps = d.getVar("BB_LIMITEDDEPS") or False
-if nodeps:
-lock = bb.utils.lockfile(recipesysroot + "/sysroot.lock")
-staging_populate_sysroot_dir(recipesysroot, recipesysrootnative, True, 
d)
-staging_populate_sysroot_dir(recipesysroot, recipesysrootnative, 
False, d)
-bb.utils.unlockfile(lock)
-
 depdir = recipesysrootnative + "/installeddeps"
 bb.utils.mkdirhier(depdir)
 bb.utils.mkdirhier(sharedmanifests)
-- 
2.7.4

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

[OE-core] [PATCH 2/4] python.inc: Fix python2/3 hosttools path references

2017-05-11 Thread Richard Purdie 
Both native and target versions of this file reference mkdir and install
in hosttools paths. Use the version from PATH instead.

Signed-off-by: Richard Purdie 
---
 meta/recipes-devtools/python/python.inc | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/meta/recipes-devtools/python/python.inc 
b/meta/recipes-devtools/python/python.inc
index b9ec692..b4bce24 100644
--- a/meta/recipes-devtools/python/python.inc
+++ b/meta/recipes-devtools/python/python.inc
@@ -30,3 +30,9 @@ EXTRA_OECONF = "\
   ac_cv_header_bluetooth_bluetooth_h=no ac_cv_header_bluetooth_h=no \
   ${PYTHONLSBOPTS} \
 "
+
+do_install_append () {
+   sed -i -e 's:${HOSTTOOLS_DIR}/install:install:g' \
+   -e 's:${HOSTTOOLS_DIR}/mkdir:mkdir:g' \
+   ${D}/${libdir}/python${PYTHON_MAJMIN}/_sysconfigdata.py
+}
-- 
2.7.4

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

[OE-core] [PATCH 1/4] rpm: Ensure macros file doesn't reference HOSTTOOLS

2017-05-11 Thread Richard Purdie 
Currently the file encodes full paths to various host tools in the
HOSTTOOLS directory which is bad in native and target cases. We can
simply use the versions from PATH quite safely in OE.

Signed-off-by: Richard Purdie 
---
 meta/recipes-devtools/rpm/rpm_git.bb | 4 
 1 file changed, 4 insertions(+)

diff --git a/meta/recipes-devtools/rpm/rpm_git.bb 
b/meta/recipes-devtools/rpm/rpm_git.bb
index f31932e..2310ee6 100644
--- a/meta/recipes-devtools/rpm/rpm_git.bb
+++ b/meta/recipes-devtools/rpm/rpm_git.bb
@@ -128,6 +128,10 @@ do_install_append_class-target() {
 rm -rf ${D}/var
 }
 
+do_install_append () {
+   sed -i -e 's:${HOSTTOOLS_DIR}/::g' ${D}/${libdir}/rpm/macros
+}
+
 FILES_${PN} += "${libdir}/rpm-plugins/*.so \
"
 
-- 
2.7.4

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

[OE-core] [PATCH] create-pull-request: support format-patch options

2017-05-11 Thread Ed Bartosh 
Added possibility to specify extra format-patch options
in create-pull-request command line:
   create-pull-request -u contrib -r master -- -v3

Signed-off-by: Ed Bartosh 
---
 scripts/create-pull-request | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/scripts/create-pull-request b/scripts/create-pull-request
index e82858b..280880b 100755
--- a/scripts/create-pull-request
+++ b/scripts/create-pull-request
@@ -34,7 +34,7 @@ RFC=0
 usage() {
 CMD=$(basename $0)
 cat <]
   -b branch   Branch name in the specified remote (default: current 
branch)
   -l local branch Local branch name (default: HEAD)
   -c  Create an RFC (Request for Comment) patch series
@@ -57,6 +57,7 @@ Usage: $CMD [-h] [-o output_dir] [-m msg_body_file] [-s 
subject] [-r relative_to
$CMD -u contrib -r master -i misc -b nitin/misc -o pull-misc
$CMD -u contrib -p "RFC PATCH" -b nitin/experimental
$CMD -u contrib -i misc -b nitin/misc -d ./bitbake
+   $CMD -u contrib -r origin/master -o /tmp/out.v3 -- -v3 
--in-reply-to=20170511120134.xx7...@site.com
 EOM
 }
 
@@ -108,9 +109,16 @@ while getopts "b:acd:hi:m:o:p:r:s:u:l:" OPT; do
a)
CPR_CONTRIB_AUTO_PUSH="1"
;;
+   --)
+   shift
+   break
+   ;;
esac
 done
 
+shift "$((OPTIND - 1))"
+extraopts="$@"
+
 if [ -z "$REMOTE" ]; then
echo "ERROR: Missing parameter -u or CPR_CONTRIB_REMOTE in env, no git 
remote!"
usage
@@ -201,7 +209,7 @@ if [ -n "$RELDIR" ]; then
ODIR=$(realpath $ODIR)
pdir=$(pwd)
cd $RELDIR
-   extraopts="--relative"
+   extraopts="$extraopts --relative"
 fi
 
 # Generate the patches and cover letter
@@ -218,7 +226,7 @@ fi
 [ -n "$RELDIR" ] && cd $pdir
 
 # Customize the cover letter
-CL="$ODIR/-cover-letter.patch"
+CL="$(echo $ODIR/*-cover-letter.patch)"
 PM="$ODIR/pull-msg"
 GIT_VERSION=$(`git --version` | tr -d '[:alpha:][:space:].' | sed 
's/\(...\).*/\1/')
 NEWER_GIT_VERSION=210
-- 
2.1.4

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

[OE-core] [PATCH v2 4/5] oe-selftest: add wic tests for generic EFI

2017-05-11 Thread Ed Bartosh 
Added test_generic_efi_grub_qemu and test_generic_efi_systemd_qemu
test cases and wks template to build and boot generic EFI images in qemu.

[YOCTO #10073]

Signed-off-by: Ed Bartosh 
---
 meta-selftest/wic/test_generic_efi.wks.in |  9 
 meta/lib/oeqa/selftest/wic.py | 36 +++
 2 files changed, 45 insertions(+)
 create mode 100644 meta-selftest/wic/test_generic_efi.wks.in

diff --git a/meta-selftest/wic/test_generic_efi.wks.in 
b/meta-selftest/wic/test_generic_efi.wks.in
new file mode 100644
index 000..fecf3fd
--- /dev/null
+++ b/meta-selftest/wic/test_generic_efi.wks.in
@@ -0,0 +1,9 @@
+# short-description: Create an EFI disk image
+# long-description: Creates a partitioned EFI disk image that the user
+# can directly dd to boot media.
+
+part /boot --source rootfs --rootfs-dir=${WORKDIR}/bootfs --fstype=vfat 
--label boot --active --align 1024
+
+part / --source rootfs --fstype=ext4 --label root --align 1024 --uuid 
${ROOTFS_PARTUUID}
+
+bootloader --ptable gpt
diff --git a/meta/lib/oeqa/selftest/wic.py b/meta/lib/oeqa/selftest/wic.py
index cdec80c..9cb9507 100644
--- a/meta/lib/oeqa/selftest/wic.py
+++ b/meta/lib/oeqa/selftest/wic.py
@@ -789,3 +789,39 @@ part /etc --source rootfs --ondisk mmcblk0 --fstype=ext4 
--exclude-path bin/ --r
 # 8 blocks is 4K (physical sector size)
 self.assertEqual(dest_stat.st_blocks, 8)
 os.unlink(dest)
+
+@only_for_arch(['i586', 'i686', 'x86_64'])
+def test_generic_efi_grub_qemu(self):
+"""Test generic efi (grub-efi) image in qemu"""
+config = 'IMAGE_FSTYPES = "wic"\nMACHINE_FEATURES_append = " efi"\n'\
+ 'EFI_PROVIDER = "grub-efi"\n'\
+ 'WKS_FILE = "test_generic_efi.wks.in"\n'
+
+self.append_config(config)
+self.assertEqual(0, bitbake('core-image-minimal ovmf').status)
+self.remove_config(config)
+
+with runqemu('core-image-minimal', ssh=False,
+ runqemuparams='ovmf', image_fstype='wic') as qemu:
+cmd = "grep sda. /proc/partitions  |wc -l"
+status, output = qemu.run_serial(cmd)
+self.assertEqual(1, status, 'Failed to run command "%s": %s' % 
(cmd, output))
+self.assertEqual(output, '2')
+
+@only_for_arch(['i586', 'i686', 'x86_64'])
+def test_generic_efi_systemd_qemu(self):
+"""Test generic efi (systemd-boot) image in qemu"""
+config = 'IMAGE_FSTYPES = "wic"\nMACHINE_FEATURES_append = " efi"\n'\
+ 'EFI_PROVIDER = "systemd-boot"\n'\
+ 'WKS_FILE = "test_generic_efi.wks.in"\n'
+
+self.append_config(config)
+self.assertEqual(0, bitbake('core-image-minimal ovmf').status)
+self.remove_config(config)
+
+with runqemu('core-image-minimal', ssh=False,
+ runqemuparams='ovmf', image_fstype='wic') as qemu:
+cmd = "grep sda. /proc/partitions  |wc -l"
+status, output = qemu.run_serial(cmd)
+self.assertEqual(1, status, 'Failed to run command "%s": %s' % 
(cmd, output))
+self.assertEqual(output, '2')
-- 
2.1.4

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

[OE-core] [PATCH v2 3/5] image_types_wic: merged 2 tasks

2017-05-11 Thread Ed Bartosh 
Merged do_write_wks_template and do_populate_bootfs into
new task do_prepare_wic_build to be able to write the same
partition UUID into bootloader configuration files and
kickstart file.

[YOCTO #10073]

Signed-off-by: Ed Bartosh 
---
 meta/classes/image_types_wic.bbclass | 51 +++-
 1 file changed, 27 insertions(+), 24 deletions(-)

diff --git a/meta/classes/image_types_wic.bbclass 
b/meta/classes/image_types_wic.bbclass
index 0ef587b..f37865f 100644
--- a/meta/classes/image_types_wic.bbclass
+++ b/meta/classes/image_types_wic.bbclass
@@ -43,27 +43,6 @@ do_image_wic[depends] += "wic-tools:do_populate_sysroot"
 WKS_FILE_DEPENDS ??= ''
 DEPENDS += "${@ '${WKS_FILE_DEPENDS}' if d.getVar('USING_WIC') else '' }"
 
-python do_write_wks_template () {
-"""Write out expanded template contents to WKS_FULL_PATH."""
-import re
-
-template_body = d.getVar('_WKS_TEMPLATE')
-
-# Remove any remnant variable references left behind by the expansion
-# due to undefined variables
-expand_var_regexp = re.compile(r"\${[^{}@\n\t :]+}")
-while True:
-new_body = re.sub(expand_var_regexp, '', template_body)
-if new_body == template_body:
-break
-else:
-template_body = new_body
-
-wks_file = d.getVar('WKS_FULL_PATH')
-with open(wks_file, 'w') as f:
-f.write(template_body)
-}
-
 python () {
 if d.getVar('USING_WIC'):
 wks_file_u = d.getVar('WKS_FULL_PATH', False)
@@ -90,7 +69,6 @@ python () {
 # file in process_wks_template as well, so just put it in
 # a variable and let the metadata deal with the deps.
 d.setVar('_WKS_TEMPLATE', body)
-bb.build.addtask('do_write_wks_template', 'do_image_wic', 
None, d)
 }
 
 #
@@ -127,7 +105,11 @@ EFI_PROVIDER ?= "grub-efi"
 EFI_CLASS = "${@bb.utils.contains("MACHINE_FEATURES", "efi", 
"${EFI_PROVIDER}", "", d)}"
 inherit ${EFI_CLASS}
 
-python do_populate_bootfs() {
+python do_prepare_wic_build() {
+# Prepare required artifacts for the wic image build:
+#  - Populate {WORKDIR}/bootfs directory with EFI content
+#  - Write wks.in template into the .wks file
+
 def populate_bootfs(partuuid):
 # remove bootfs dir as it may have files from previous build
 bootfs = os.path.join(d.getVar("WORKDIR"), 'bootfs')
@@ -140,6 +122,23 @@ python do_populate_bootfs() {
 
 bb.build.exec_func('efi_bootfs_populate', d)
 
+def write_wks_template(template_body, wks_file):
+"""Write out expanded template contents to WKS_FULL_PATH."""
+import re
+
+# Remove any remnant variable references left behind by the expansion
+# due to undefined variables
+expand_var_regexp = re.compile(r"\${[^{}@\n\t :]+}")
+while True:
+new_body = re.sub(expand_var_regexp, '', template_body)
+if new_body == template_body:
+break
+else:
+template_body = new_body
+
+with open(wks_file, 'w') as f:
+f.write(template_body)
+
 if d.getVar('USING_WIC'):
 # Generate parition UUID
 from uuid import uuid4
@@ -148,6 +147,10 @@ python do_populate_bootfs() {
 
 if d.getVar("EFI_CLASS"):
 populate_bootfs(partuuid)
+
+template = d.getVar("_WKS_TEMPLATE")
+if template:
+write_wks_template(template, d.getVar('WKS_FULL_PATH'))
 }
 
-addtask do_populate_bootfs after do_image before do_image_wic
+addtask do_prepare_wic_build after do_image before do_image_wic
-- 
2.1.4

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

[OE-core] [PATCH v2 1/5] efi: add efi_bootfs_populate API

2017-05-11 Thread Ed Bartosh 
Added API to populate ${WORKDIR}/bootfs directory with EFI
artifacts to both EFI provider classes(grub-efi and systemd-boot).

This API will be used to prepare artifacts for the wic image
build.

[YOCTO #10073]

Signed-off-by: Ed Bartosh 
---
 meta/classes/grub-efi.bbclass | 6 ++
 meta/classes/systemd-boot.bbclass | 6 ++
 2 files changed, 12 insertions(+)

diff --git a/meta/classes/grub-efi.bbclass b/meta/classes/grub-efi.bbclass
index df7fe18..bacbeb4 100644
--- a/meta/classes/grub-efi.bbclass
+++ b/meta/classes/grub-efi.bbclass
@@ -71,6 +71,12 @@ efi_hddimg_populate() {
efi_populate $1
 }
 
+efi_bootfs_populate() {
+   bootfs_dir="${WORKDIR}/bootfs"
+   efi_populate $bootfs_dir
+   cp --dereference ${DEPLOY_DIR_IMAGE}/${KERNEL_IMAGETYPE} 
$bootfs_dir/vmlinuz
+}
+
 python build_efi_cfg() {
 import sys
 
diff --git a/meta/classes/systemd-boot.bbclass 
b/meta/classes/systemd-boot.bbclass
index 4e69a2c..7e842af 100644
--- a/meta/classes/systemd-boot.bbclass
+++ b/meta/classes/systemd-boot.bbclass
@@ -62,6 +62,12 @@ efi_hddimg_populate() {
 efi_populate $1
 }
 
+efi_bootfs_populate() {
+bootfs_dir="${WORKDIR}/bootfs"
+efi_populate $bootfs_dir
+cp --dereference ${DEPLOY_DIR_IMAGE}/${KERNEL_IMAGETYPE} 
$bootfs_dir/vmlinuz
+}
+
 python build_efi_cfg() {
 s = d.getVar("S")
 labels = d.getVar('LABELS')
-- 
2.1.4

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

[OE-core] [PATCH v2 2/5] image_types_wic: add do_populate_bootfs task

2017-05-11 Thread Ed Bartosh 
This task generates root partition UUID and calls efi_bootfs_populate
API of current EFI provider to populate bootfs directory with
EFI artifacts.

[YOCTO #10073]

Signed-off-by: Ed Bartosh 
---
 meta/classes/image_types_wic.bbclass | 36 
 1 file changed, 36 insertions(+)

diff --git a/meta/classes/image_types_wic.bbclass 
b/meta/classes/image_types_wic.bbclass
index 4711c24..0ef587b 100644
--- a/meta/classes/image_types_wic.bbclass
+++ b/meta/classes/image_types_wic.bbclass
@@ -115,3 +115,39 @@ python do_rootfs_wicenv () {
 addtask do_rootfs_wicenv after do_image before do_image_wic
 do_rootfs_wicenv[vardeps] += "${WICVARS}"
 do_rootfs_wicenv[prefuncs] = 'set_image_size'
+
+# Set variables for efi_bootfs_populate
+GRUB_CFG ?= "${WORKDIR}/grub_wic.cfg"
+SYSTEMD_BOOT_CFG ?= "${WORKDIR}/loader_wic.conf"
+GRUB_GFXSERIAL ?= "1"
+LABELS_WIC ?= "boot install"
+LABELS ?= "${LABELS_WIC}"
+
+EFI_PROVIDER ?= "grub-efi"
+EFI_CLASS = "${@bb.utils.contains("MACHINE_FEATURES", "efi", 
"${EFI_PROVIDER}", "", d)}"
+inherit ${EFI_CLASS}
+
+python do_populate_bootfs() {
+def populate_bootfs(partuuid):
+# remove bootfs dir as it may have files from previous build
+bootfs = os.path.join(d.getVar("WORKDIR"), 'bootfs')
+if os.path.exists(bootfs):
+import shutil
+shutil.rmtree(bootfs)
+
+d.setVar("APPEND", "root=PARTUUID=%s" % partuuid)
+bb.build.exec_func('build_efi_cfg', d)
+
+bb.build.exec_func('efi_bootfs_populate', d)
+
+if d.getVar('USING_WIC'):
+# Generate parition UUID
+from uuid import uuid4
+partuuid = str(uuid4())
+d.setVar("ROOTFS_PARTUUID", partuuid)
+
+if d.getVar("EFI_CLASS"):
+populate_bootfs(partuuid)
+}
+
+addtask do_populate_bootfs after do_image before do_image_wic
-- 
2.1.4

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

[OE-core] [PATCH v2 5/5] grub-efi: fixed default value of GRUB_ROOT

2017-05-11 Thread Ed Bartosh 
Currently GRUB_ROOT assigned a value of literal "${ROOT}" by default
if ROOT variable is not set. This causes kernel commandline to
look like this: "linux /vmlinuz LABEL=boot {ROOT}"

Used weak assignments of ROOT and GRUB_ROOT variables to make
sure GRUB_ROOT is "" by default.

Allowed empty GRUB_ROOT to be able to use only APPEND variable
for both EFI bootloaders (systemd-boot and grub-efi).

Signed-off-by: Ed Bartosh 
---
 meta/classes/grub-efi.bbclass | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/meta/classes/grub-efi.bbclass b/meta/classes/grub-efi.bbclass
index bacbeb4..b55ac96 100644
--- a/meta/classes/grub-efi.bbclass
+++ b/meta/classes/grub-efi.bbclass
@@ -27,7 +27,8 @@ GRUB_TIMEOUT ?= "10"
 GRUB_OPTS ?= "serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1"
 
 EFIDIR = "/EFI/BOOT"
-GRUB_ROOT ?= "${ROOT}"
+ROOT ??= ""
+GRUB_ROOT ??= "${ROOT}"
 APPEND ?= ""
 
 # Need UUID utility code.
@@ -121,8 +122,6 @@ python build_efi_cfg() {
 cfgfile.write('timeout=50\n')
 
 root = d.getVar('GRUB_ROOT')
-if not root:
-bb.fatal('GRUB_ROOT not defined')
 
 if gfxserial == "1":
 btypes = [ [ " graphics console", "" ],
@@ -146,7 +145,8 @@ python build_efi_cfg() {
 lb = "install-efi"
 cfgfile.write('linux /vmlinuz LABEL=%s' % (lb))
 
-cfgfile.write(' %s' % replace_rootfs_uuid(d, root))
+if root:
+cfgfile.write(' %s' % replace_rootfs_uuid(d, root))
 
 append = localdata.getVar('APPEND')
 initrd = localdata.getVar('INITRD')
-- 
2.1.4

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

[OE-core] [PATCH v2 0/5] #10073: generic EFI for wic

2017-05-11 Thread Ed Bartosh 
Hi,

This patchset is an implementation of generic EFI approach for wic images.

Instead of introducing yet another wic plugin it uses existing APIs from
EFI_PROVIDER classes to populate ${WORKDIR}/bootfs directory with EFI artifacts
and bootloader configuration. This directory can be used by wic rootfs plugin
to put into boot partition of the image.

Example kickstart file and 2 test cases were added to wic test suite to better
illustrate the approach.

I personally like this approach much better than duplicating oe image creation
functionality in wic plugins. This way we can have the code in one place and
bootloaders can be configured the same way for oe and wic images.

Changes in v2:
 - added patch: fixed default value of GRUB_ROOT
 - fixed typo in commit message: timage_types_wic > image_types_wic

The following changes since commit cdb9e7aa493d9ed0eb6ffcec37d581ea928b5f2b:

  selftest: fix test_unsupported_subcommand test case (2017-05-02 17:24:23 
+0300)

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib ed/wic/wip
  http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=ed/wic/wip

Ed Bartosh (5):
  efi: add efi_bootfs_populate API
  image_types_wic: add do_populate_bootfs task
  image_types_wic: merged 2 tasks
  oe-selftest: add wic tests for generic EFI
  grub-efi: fixed default value of GRUB_ROOT

 meta-selftest/wic/test_generic_efi.wks.in |  9 
 meta/classes/grub-efi.bbclass | 14 --
 meta/classes/image_types_wic.bbclass  | 83 +++
 meta/classes/systemd-boot.bbclass |  6 +++
 meta/lib/oeqa/selftest/wic.py | 36 ++
 5 files changed, 122 insertions(+), 26 deletions(-)
 create mode 100644 meta-selftest/wic/test_generic_efi.wks.in

-- 
2.1.4

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

Re: [OE-core] [OT?] where to start building for qualcomm snapdragon APQ8016E dragonboard 410C?

2017-05-11 Thread Nicolas Dechesne 
hi Robert,

On Thu, May 11, 2017 at 12:48 PM, Robert P. J. Day
 wrote:
>
>   (i'm sure there's a more appropriate forum to ask this, but i'm just
> going to throw myself on the mercy of the general OE list.)
>
>   i've been asked to help out with lashing together an OE build for a
> target board that will be based on qualcomm's snapdragon 410 APQ8016E,
> so the obvious choice for an initial reference system would be the
> 96boards.org-approved dragonboard 410c from arrow (i'm open to other
> suggestions for more fully-featured boards supported by OE):
>
>  http://www.96boards.org/product/dragonboard410c/
>
> but, wow, are there a bunch of places to start pulling content from.
>
>   i picked out the meta-qcom layer immediately:
>
>  http://git.yoctoproject.org/cgit/cgit.cgi/meta-qcom

As a disclaimer... I am the maintainer for the above layer (and also
very much involved with what Linaro/96boards does with dragonboard in
general).

Note that the layer is more generally maintained on github, and
mirror'd on YP git. So if you want to contribute you should use github
instead:

https://github.com/ndechesne/meta-qcom

>
> which has a machine definition for that very board, and i built a
> core-image-minimal image for that target with no trouble (have not
> loaded and tested yet, board supposedly arrives tomorrow). so far, so
> good. but when i perused further, i found all sorts of URLs with more
> info/content/layers, depending on what you were after:
>
>  git://git.linaro.org/landing-teams/working/qualcomm/kernel.git

This is the kernel tree maintained by Linaro. Everything that we do is
intended to end up in mainline kernel at some point, and in the mean
time we have development and release branches that we maintained for
our own builds.

At Linaro we are doing/supporting "linux" builds (based on Debian or
OE) and we  also have experimental Android builds based on AOSP.

Canonical has been using this tree as a starting point for their
Ubuntu Core port for the board as well. Several other distros are
doing similar things..

The kernel is *very* different from what you would find in shipping
Qualcomm products. Qualcomm has their own kernel tree for each SoC
that they support, and they *never* upgrade kernel. For MSM8916
chipset they shipped with a 3.10 based kernel. For the Linaro/96boards
builds, our kernel is being upgraded once a year, we track LTS
releases, so we currently support 4.9.

For reference the Qualcomm 'product/vendor' tree can be found here:

https://source.codeaurora.org/quic/la/kernel/msm-3.10/

>  
> https://www.codeaurora.org/openembedded-mass-market-and-ioe-qualcomm-snapdragon

This is a build from Qualcomm, which is derived from the Linaro Open
Embedded builds for Dragonboard. There aren't many differences between
what you can get from this build, vs what you can get from Linaro OE
builds for this board. In fact, you can consider this product as a
'downstream' of ours.

>  https://developer.qualcomm.com/hardware/dragonboard-410c

This is Qualcomm official developer page for the board. With chipset
documentation (h/w) and s/w documentation. The s/w documentation is
mostly about Qualcomm Android builds and the vendor kernel. You can
also find there the proprietary bootloader and firmware blob, which we
use even in our Linux builds.

>  https://github.com/96boards/

This is the home for some of the 96boards related projects, it's
mostly irrelevant in your situtation, most of what you expect/want can
be found in meta-qcom.

>  https://createpoint.qti.qualcomm.com/

this is a documentation data base from QCOM. You need to be authorized
for access , here. And based on your level of authorization, you will
have access to more or less documentation..

>
> and i'm not sure that's even the entire list i've seen.

in fact I believe there is also a Linux/OE based 'setup' that exists
somewhere, from Qualcomm, but using their very own vendor (e.g. 3.10)
kernel. I am not sure what this is about, and I don't have any detail
about this one.

>
>   specifically, i'm wondering where the canonical code base is for
> what i'm doing, and i was told that it's at that qualcomm location,
> for which one needs an account. a colleague has an account and let me
> peruse the qualcomm createpoint repo, but it seems that whatever i see
> there is available publicly, particularly at codeaurora.org.
>
>   can someone clarify how all these sites hang together, and where one
> starts? as i said, right now, the meta-qcom layer works right out of
> the box to build an image for that target. is it necessary to get
> access to qualcomm's createpoint repo? or is everything i might need
> available publicly at github and codeaurora?

meta-qcom can be used if what you want to rely *only* on open source
user space (including GPU driver from mesa/freedreno). If you are
required to use the Qualcomm vendor code, it will come with a custom
(and proprietary) user space (and I am not familiar with it).

meta-qcom

[OE-core] [OT?] where to start building for qualcomm snapdragon APQ8016E dragonboard 410C?

2017-05-11 Thread Robert P. J. Day 

  (i'm sure there's a more appropriate forum to ask this, but i'm just
going to throw myself on the mercy of the general OE list.)

  i've been asked to help out with lashing together an OE build for a
target board that will be based on qualcomm's snapdragon 410 APQ8016E,
so the obvious choice for an initial reference system would be the
96boards.org-approved dragonboard 410c from arrow (i'm open to other
suggestions for more fully-featured boards supported by OE):

 http://www.96boards.org/product/dragonboard410c/

but, wow, are there a bunch of places to start pulling content from.

  i picked out the meta-qcom layer immediately:

 http://git.yoctoproject.org/cgit/cgit.cgi/meta-qcom

which has a machine definition for that very board, and i built a
core-image-minimal image for that target with no trouble (have not
loaded and tested yet, board supposedly arrives tomorrow). so far, so
good. but when i perused further, i found all sorts of URLs with more
info/content/layers, depending on what you were after:

 git://git.linaro.org/landing-teams/working/qualcomm/kernel.git
 https://www.codeaurora.org/openembedded-mass-market-and-ioe-qualcomm-snapdragon
 https://developer.qualcomm.com/hardware/dragonboard-410c
 https://github.com/96boards/
 https://createpoint.qti.qualcomm.com/

and i'm not sure that's even the entire list i've seen.

  specifically, i'm wondering where the canonical code base is for
what i'm doing, and i was told that it's at that qualcomm location,
for which one needs an account. a colleague has an account and let me
peruse the qualcomm createpoint repo, but it seems that whatever i see
there is available publicly, particularly at codeaurora.org.

  can someone clarify how all these sites hang together, and where one
starts? as i said, right now, the meta-qcom layer works right out of
the box to build an image for that target. is it necessary to get
access to qualcomm's createpoint repo? or is everything i might need
available publicly at github and codeaurora?

  thanks for any pointers.

rday

-- 


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] PulseAudio with WebRTC echo cancellation (aec): support for webrtc-audio-processing package

2017-05-11 Thread Tanu Kaskinen 
On Tue, 2017-05-09 at 13:59 +0200, Koenraad Verheyden wrote:
> Hi Tanu,
> 
> I've written a script myself, referencing how other scripts did this. Was
> indeed not so hard.
> This is the first time writing such a script so I can't guarantee
> everything is correct or the right way to do (especially the license
> stuff). But this works for me.
> 
> You can do with this script as you want.

Thanks! I already wrote a recipe myself, though. I haven't submitted it
yet, because it doesn't build on mips (and probably not on mips64 or
aarch64 either).

-- 
Tanu

https://www.patreon.com/tanuk
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] libunwind: 1.1 -> 1.2

2017-05-11 Thread zhengrq 
Upgrade libunwind from 1.1 to 1.2.

Signed-off-by: Zheng Ruoqin 
---
 meta/recipes-support/libunwind/libunwind_git.bb | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-support/libunwind/libunwind_git.bb 
b/meta/recipes-support/libunwind/libunwind_git.bb
index b637c5c..2c00f80 100644
--- a/meta/recipes-support/libunwind/libunwind_git.bb
+++ b/meta/recipes-support/libunwind/libunwind_git.bb
@@ -1,8 +1,8 @@
 require libunwind.inc
 
-PV = "1.1+git${SRCPV}"
+PV = "1.2+git${SRCPV}"
 
-SRCREV = "bc8698fd7ed13a629a8ec3cb2a89bd74f9d8b5c0"
+SRCREV = "0326f1048a0d75ea9498360f60a0c711cd190b7b"
 
 SRC_URI = "git://git.sv.gnu.org/libunwind.git \
file://Add-AO_REQUIRE_CAS-to-fix-build-on-ARM-v6.patch \
-- 
2.7.4



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

Re: [OE-core] GUI based images

2017-05-11 Thread Alexander Kanavin 

On 05/09/2017 12:24 PM, Burton, Ross wrote:

The development of Wayland does make the long-term prospect of Sato
interesting: do we port Sato to Wayland too, or keep the Wayland images
using the standard Weston demo shell?


There is a third option: find a functional, pretty, lightweight wayland 
shell, and provide that. I think the prime candidate for that at the 
moment is Maynard, but it has its own issues, mainly that upstream isn't 
really developing it anymore. Jussi is OOO this week, maybe he can add 
his 2c a bit later.


https://github.com/raspberrypi/maynard/wiki


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

Re: [OE-core] [RFC PATCH 00/10] Add openssl 1.1

2017-05-11 Thread Alexander Kanavin 

On 05/11/2017 12:08 AM, Khem Raj wrote:

On Wed, May 10, 2017 at 1:48 PM, Davis, Michael
 wrote:

I think most of the major distros have either switched or are in the process
this year.



are there some info on the policy decisions of other distros ?
we should try to follow the suite then


Both Fedora and Debian default to 1.1 in their upcoming versions. 1.0 is 
provided only as a legacy package. So same as here.


Alex

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

Re: [OE-core] GUI based images

2017-05-11 Thread Alexander Kanavin 

On 05/10/2017 11:15 PM, Paul Eggleton wrote:

If that works then great! By all means let's test it and endorse it. At the
moment we barely even acknowledge it's existence - it's not even in the layer
index (though that is generally up to the layer maintainer, we can certainly
encourage them to submit it.)


Yes, should definitely be tried out. I have only looked at the contents 
of the layer, and the overview part of the documentation, so I might 
have a bit rosier picture of it :)


I'm not sure how much attention Qt wants to draw to it - they probably 
want to lure people into commercial support contracts instead. However, 
the layer *is* licensed under GPLv3, and it pulls all code from public 
repos. And I can also imagine they could be quite happy to have Qt 
designated the official reference UI in YP.



You and I might understand that, but someone coming to the project fresh
won't, mainly because we've never officially stated that anywhere. The only
mention of anything like it is in fact the opposite - in the development
manual we state "The Yocto Project ... also features the Sato reference User
Interface, which is optimized for stylus-driven, low-resolution screens.".
Granted, that statement is probably as old as Sato itself, but I think it
speaks to how organised our messaging is on this topic.


Yes, in 2017 this statement should be changed to reflect reality.

Alex

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