date:20160323

Re: [linux-yocto] Backport Device Property from Linux-4.4 to linux-yocto-4.1

2016-03-23 Thread Yong, Jonathan


On 03/24/2016 06:09, Bruce Ashfield wrote:


No worries. I fetched the branch. I see 18 commits in your summary, but I'm
still seeing duplicates
on what I fetched.

i.e. the branch I just grabbed, still has: a7e1dabefaf8 klist: implement
klist_prev(), fetched from: https://github.com/jyong2/yocto-backports.git
for-linux-yocto-4.1



Now it's down to 4 patches, Yocto sure moves fast! Rebased again, same 
repo, same branch.


Stats:

Andy Shevchenko (3):
  device property: check fwnode type in to_of_node()
  device property: return -EINVAL when property isn't found in ACPI
  mfd: make mfd_remove_devices() iterate in reverse order

Mika Westerberg (1):
  driver core: Do not overwrite secondary fwnode with NULL if it is set




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

[yocto] [meta-security][PATCH] nmap: update to 7.11

2016-03-23 Thread Armin Kuster

https://nmap.org/changelog.html

Signed-off-by: Armin Kuster 
---
 recipes-security/nmap/nmap_7.01.bb | 56 --
 recipes-security/nmap/nmap_7.11.bb | 56 ++
 2 files changed, 56 insertions(+), 56 deletions(-)
 delete mode 100644 recipes-security/nmap/nmap_7.01.bb
 create mode 100644 recipes-security/nmap/nmap_7.11.bb

diff --git a/recipes-security/nmap/nmap_7.01.bb 
b/recipes-security/nmap/nmap_7.01.bb
deleted file mode 100644
index 32996dd..000
--- a/recipes-security/nmap/nmap_7.01.bb
+++ /dev/null
@@ -1,56 +0,0 @@
-SUMMARY = "network auditing tool"
-DESCRIPTION = "Nmap ("Network Mapper") is a free and open source (license) 
utility for network discovery and security auditing.\nGui support via appending 
to IMAGE_FEATURES x11-base in local.conf"
-SECTION = "security"
-LICENSE = "GPL-2.0"
-
-LIC_FILES_CHKSUM = 
"file://COPYING;beginline=7;endline=12;md5=51f7052ac85aaf1a2127f7803de1261e"
-
-SRC_URI = "http://nmap.org/dist/${BP}.tar.bz2;
-
-SRC_URI[md5sum] = "7fa4edc592184c7addc14f5acb3fe6f7"
-SRC_URI[sha256sum] = 
"cf1fcd2643ba2ef52f47acb3c18e52fa12a4ae4b722804da0e54560704627705"
-
-inherit autotools-brokensep pkgconfig distro_features_check
-
-PACKAGECONFIG = "ncat nping ndiff pcap"
-PACKAGECONFIG += " ${@bb.utils.contains("IMAGE_FEATURES", "x11-base", 
"zenmap", "", d)}"
-
-PACKAGECONFIG[pcap] = "--with-pcap=linux, --without-pcap, libpcap, libpcap"
-PACKAGECONFIG[ssl] = "--with-openssl=${STAGING_LIBDIR}/.., --without-openssl, 
openssl, openssl"
-
-#disable/enable packages
-PACKAGECONFIG[nping] = ",--without-nping,"
-PACKAGECONFIG[ncat] = ",--without-ncat,"
-PACKAGECONFIG[ndiff] = ",--without-ndiff,"
-
-PACKAGECONFIG[pcre] = "--with-libpcre=${STAGING_LIBDIR}/.., 
--with-libpcre=included, libpre"
-
-#Add gui
-PACKAGECONFIG[zenmap] = "--with-zenmap, --without-zenmap, gtk+ python-core 
python-codecs python-io python-logging python-unittest python-xml 
python-netclient python-doctest python-subprocess python-pygtk, python-core 
python-codecs python-io python-logging python-netclient python-xml 
python-unittest python-doctest python-subprocess  python-pygtk gtk+"
-
-EXTRA_OECONF = "--with-libdnet=included --with-liblinear=included 
--without-subversion --with-liblua=included"
-
-do_configure() {
-# strip hard coded python2#
-sed -i -e 's=python2\.*=python=g'  ${S}/configure.ac
-sed -i -e 's=python2\.*=python=g'  ${S}/configure
-autoconf
-oe_runconf
-}
-
-
-PACKAGES = "${PN} ${PN}-dbg ${PN}-doc"
-
-FILES_${PN} = "${bindir}/nmap ${datadir}/nmap/* ${bindir}/uninstall_ndiff"
-
-# append packages if enabled
-FILES_${PN} += "${@bb.utils.contains("PACKAGECONFIG", "ncat", "${bindir}/ncat 
${target_datadir}/ncat", "", d)}"
-FILES_${PN} += "${@bb.utils.contains("PACKAGECONFIG", "nping", 
"${bindir}/nping", "", d)}"
-FILES_${PN} += "${@bb.utils.contains("PACKAGECONFIG", "ndiff", 
"${bindir}/ndiff 
${libdir}/python${PYTHON_BASEVERSION}/site-packages/ndiff.py*", "", d)}"
-
-PACKAGES += "${@bb.utils.contains("PACKAGECONFIG", "zenmap", "${PN}-zenmap", 
"", d)}"
-
-FILES_${PN}-zenmap = "${@bb.utils.contains("PACKAGECONFIG", "zenmap", 
"${bindir}/*zenmap ${bindir}/xnmap ${datadir}/applications/*  ${bindir}/nmapfe 
${datadir}/zenmap/* 
${libdir}/python${PYTHON_BASEVERSION}/site-packages/radialnet/* 
${libdir}/python${PYTHON_BASEVERSION}/site-packages/zenmap*", "", d)}"
-
-RDEPENDS_${PN} = "python"
-RDEPENDS_${PN}-zenmap = "nmap"
diff --git a/recipes-security/nmap/nmap_7.11.bb 
b/recipes-security/nmap/nmap_7.11.bb
new file mode 100644
index 000..27efe7b
--- /dev/null
+++ b/recipes-security/nmap/nmap_7.11.bb
@@ -0,0 +1,56 @@
+SUMMARY = "network auditing tool"
+DESCRIPTION = "Nmap ("Network Mapper") is a free and open source (license) 
utility for network discovery and security auditing.\nGui support via appending 
to IMAGE_FEATURES x11-base in local.conf"
+SECTION = "security"
+LICENSE = "GPL-2.0"
+
+LIC_FILES_CHKSUM = 
"file://COPYING;beginline=7;endline=12;md5=51f7052ac85aaf1a2127f7803de1261e"
+
+SRC_URI = "http://nmap.org/dist/${BP}.tar.bz2;
+
+SRC_URI[md5sum] = "0dc7fcde978b4891ba9fd91d16f19fce"
+SRC_URI[sha256sum] = 
"13fa971555dec00e495a5b72c1f9efa1363b8e6c7388a2f05117cb0778c0954a"
+
+inherit autotools-brokensep pkgconfig distro_features_check
+
+PACKAGECONFIG = "ncat nping ndiff pcap"
+PACKAGECONFIG += " ${@bb.utils.contains("IMAGE_FEATURES", "x11-base", 
"zenmap", "", d)}"
+
+PACKAGECONFIG[pcap] = "--with-pcap=linux, --without-pcap, libpcap, libpcap"
+PACKAGECONFIG[ssl] = "--with-openssl=${STAGING_LIBDIR}/.., --without-openssl, 
openssl, openssl"
+
+#disable/enable packages
+PACKAGECONFIG[nping] = ",--without-nping,"
+PACKAGECONFIG[ncat] = ",--without-ncat,"
+PACKAGECONFIG[ndiff] = ",--without-ndiff,"
+
+PACKAGECONFIG[pcre] = "--with-libpcre=${STAGING_LIBDIR}/.., 
--with-libpcre=included, libpre"
+
+#Add gui
+PACKAGECONFIG[zenmap] = "--with-zenmap, --without-zenmap, gtk+ python-core 
python-codecs

Re: [yocto] [OE-core] [oe] OEDAM, April 8 in San Diego after ELC

2016-03-23 Thread Philip Balister

OK, All outstanding requests approved. I'm not getting all the email
notifications I expect, so feel free to nag me.

Philip

On 03/23/2016 02:11 PM, Fred Ollinger wrote:
> I'm coming and I'm probably brining another person.
> 
> I still have to make the wiki account which failed for some reason before.
> 
> Frederick
> 
> From: yocto-boun...@yoctoproject.org  on 
> behalf of Trevor Woerner 
> Sent: Wednesday, March 23, 2016 2:08 PM
> To: akuster808; openembedded-de...@lists.openembedded.org; openembedded-core; 
> Yocto Project; openembedded-memb...@lists.openembedded.org
> Subject: Re: [yocto] [OE-core] [oe] OEDAM, April 8 in San Diego after ELC
> 
> On Wed 2016-03-23 @ 09:36:40 AM, akuster808 wrote:
>> There are only 10 people signed up.
>> Is that enough people to justify the expense room or even meet?
> 
> I have no idea what the budget might be or what a room might cost. I'll leave
> it to those who do know to worry about the costs versus the benefits.
> 
> In any case I certainly think it's still worth meeting. A smaller, more
> focused group can sometimes get more done than a larger group. Secondly, it's
> my experience that more people always show up than sign up.
> 
> With a project like this there will always be things to discuss, and sometimes
> a discussion goes better in person rather than online.
> 
> Best regards,
> Trevor
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
> 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] [oe] OEDAM, April 8 in San Diego after ELC

2016-03-23 Thread akuster808



On 03/23/2016 03:03 PM, Jeff Osier-Mixon wrote:
 There are only 10 people signed up.
 Is that enough people to justify the expense room or even meet?
>>>
>>> I have no idea what the budget might be or what a room might cost. I'll 
>>> leave
>>> it to those who do know to worry about the costs versus the benefits.
> 
> I would give an unequivocal "yes" to this (as the guy with the credit
> card). We need reliable internet access to loop in those who can't be
> there in person, plus this was actually a reasonable rate for the
> immediate area. 

tijuana? OEDMX

We can take up to 25 and these meetings usually gain 5
> or 6 people who never sign up on the wiki, so I think we are in
> excellent shape.
> 


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

Re: [linux-yocto] [PATCH 0/9] Backport SMBus/iTCO patches from mainline kernel into linux-yocto-4.1

2016-03-23 Thread Bruce Ashfield

On Tue, Mar 22, 2016 at 11:44 PM, Tan Jui Nee  wrote:

> Hi Bruce,
>
> The patches are to backport Intel Broxton and Denverton
> patches that are available in the mainline Linux kernel.
>
> The following patches are to enable SMBus and iTCO watchdog
> drivers support for Intel Broxton and Denverton.
> i2c: i801: Create iTCO device on newer Intel PCHs
> mfd: watchdog: iTCO_wdt: Expose watchdog properties using platform
> data
> watchdog: iTCO_wdt: Add support for TCO on Intel Sunrisepoint
> i2c: i801: Add support for Intel Broxton
>
> The rest of the patches are dependency patches, to ensure
> the above patches applied cleanly to the branch.
>
> The patches are targeted to merge into linux-yocto-4.1 on
> standard/base branch.
>
> Please review and provide feedback if any.
>

I've staged the changes, build testing started.

Bruce


>
> Thanks and best regards,
> Juinee
>
> Jarkko Nikula (1):
>   i2c: i801: Add support for Intel Broxton
>
> Matt Fleming (2):
>   mfd: watchdog: iTCO_wdt: Expose watchdog properties using platform
> data
>   watchdog: iTCO_wdt: Add support for TCO on Intel Sunrisepoint
>
> Mika Westerberg (3):
>   i2c: i801: Create iTCO device on newer Intel PCHs
>   mfd: lpc_ich: Assign subdevice ids automatically
>   i2c: i801: Add support for Intel DNV
>
> qipeng.zha (3):
>   intel_pmc_ipc: Add Intel Apollo Lake PMC IPC driver
>   intel_pmc_ipc: Fix compiler casting warnings
>   intel_pmc_ipc: Update kerneldoc formatting
>
>  MAINTAINERS|   7 +
>  arch/x86/include/asm/intel_pmc_ipc.h   |  55 +++
>  drivers/i2c/busses/i2c-i801.c  | 127 +-
>  drivers/mfd/lpc_ich.c  |  40 +-
>  drivers/platform/x86/Kconfig   |   7 +
>  drivers/platform/x86/Makefile  |   1 +
>  drivers/platform/x86/intel_pmc_ipc.c   | 779
> +
>  drivers/watchdog/Kconfig   |   3 +-
>  drivers/watchdog/iTCO_wdt.c|  82 ++--
>  include/linux/mfd/lpc_ich.h|   6 -
>  include/linux/platform_data/itco_wdt.h |  19 +
>  11 files changed, 1078 insertions(+), 48 deletions(-)
>  create mode 100644 arch/x86/include/asm/intel_pmc_ipc.h
>  create mode 100644 drivers/platform/x86/intel_pmc_ipc.c
>  create mode 100644 include/linux/platform_data/itco_wdt.h
>
> --
> 1.9.1
>
> --
> ___
> linux-yocto mailing list
> linux-yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/linux-yocto
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] Backport Device Property from Linux-4.4 to linux-yocto-4.1

2016-03-23 Thread Bruce Ashfield

On Wed, Mar 23, 2016 at 2:31 AM, Yong, Jonathan 
wrote:

> On 03/23/2016 14:10, Yong, Jonathan wrote:
>
>> Hi Bruce,
>>
>> This changeset from kernel 4.4 (29 commits) is a bit large but should
>> not impact any existing drivers.
>>
>> The commits are for linux-yocto-4.1 standard/base branch.
>>
>> URL: https://github.com/jyong2/yocto-backports.git
>> Branch: for-linux-yocto-4.1
>>
>>
> Oops, didn't know Voon was working on the same thing, now rebased with
> duplicates removed.
>

No worries. I fetched the branch. I see 18 commits in your summary, but I'm
still seeing duplicates
on what I fetched.

i.e. the branch I just grabbed, still has: a7e1dabefaf8 klist: implement
klist_prev(), fetched from: https://github.com/jyong2/yocto-backports.git
for-linux-yocto-4.1

Bruce


>
> Stats:
>
>> Andrew Morton (1):
>>   include/linux/property.h: fix build issues with gcc-4.4.4
>>
>> Andy Shevchenko (11):
>>   klist: implement klist_prev()
>>   device property: check fwnode type in to_of_node()
>>   device property: rename helper functions
>>   device property: refactor built-in properties support
>>   device property: keep single value inplace
>>   device property: improve readability of macros
>>   device property: Fallback to secondary fwnode if primary misses the
>> property
>>   device property: avoid allocations of 0 length
>>   device property: return -EINVAL when property isn't found in ACPI
>>   mfd: core: propagate device properties to sub devices drivers
>>   device property: add spaces to PROPERTY_ENTRY_STRING macro
>>
>> Heikki Krogerus (2):
>>   device property: the secondary fwnode needs to depend on the primary
>>   device property: helper macros for property entry creation
>>
>> Mika Westerberg (4):
>>   device property: Add fwnode_property_match_string()
>>   device property: Take a copy of the property set
>>   driver core: platform: Add support for built-in device properties
>>   driver core: Do not overwrite secondary fwnode with NULL if it is set
>>
>>  drivers/acpi/property.c |  10 +-
>>  drivers/base/core.c |   5 +-
>>  drivers/base/platform.c |  25 ++
>>  drivers/base/property.c | 569
>> +---
>>  drivers/mfd/mfd-core.c  |   7 +
>>  include/linux/klist.h   |   1 +
>>  include/linux/mfd/core.h|   5 +
>>  include/linux/of.h  |   3 +-
>>  include/linux/platform_device.h |   5 +
>>  include/linux/property.h| 111 ++--
>>  lib/klist.c |  41 +++
>>  11 files changed, 662 insertions(+), 120 deletions(-)
>>
>>
> --
> ___
> linux-yocto mailing list
> linux-yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/linux-yocto
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [yocto] [OE-core] [oe] OEDAM, April 8 in San Diego after ELC

2016-03-23 Thread Jeff Osier-Mixon

>>> There are only 10 people signed up.
>>> Is that enough people to justify the expense room or even meet?
>>
>> I have no idea what the budget might be or what a room might cost. I'll leave
>> it to those who do know to worry about the costs versus the benefits.

I would give an unequivocal "yes" to this (as the guy with the credit
card). We need reliable internet access to loop in those who can't be
there in person, plus this was actually a reasonable rate for the
immediate area. We can take up to 25 and these meetings usually gain 5
or 6 people who never sign up on the wiki, so I think we are in
excellent shape.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] [oe] OEDAM, April 8 in San Diego after ELC

2016-03-23 Thread Philip Balister

If you are having trouble with wiki accounts contact me directly and we
will figure it out.

Philip

On 03/23/2016 02:11 PM, Fred Ollinger wrote:
> I'm coming and I'm probably brining another person.
> 
> I still have to make the wiki account which failed for some reason before.
> 
> Frederick
> 
> From: yocto-boun...@yoctoproject.org  on 
> behalf of Trevor Woerner 
> Sent: Wednesday, March 23, 2016 2:08 PM
> To: akuster808; openembedded-de...@lists.openembedded.org; openembedded-core; 
> Yocto Project; openembedded-memb...@lists.openembedded.org
> Subject: Re: [yocto] [OE-core] [oe] OEDAM, April 8 in San Diego after ELC
> 
> On Wed 2016-03-23 @ 09:36:40 AM, akuster808 wrote:
>> There are only 10 people signed up.
>> Is that enough people to justify the expense room or even meet?
> 
> I have no idea what the budget might be or what a room might cost. I'll leave
> it to those who do know to worry about the costs versus the benefits.
> 
> In any case I certainly think it's still worth meeting. A smaller, more
> focused group can sometimes get more done than a larger group. Secondly, it's
> my experience that more people always show up than sign up.
> 
> With a project like this there will always be things to discuss, and sometimes
> a discussion goes better in person rather than online.
> 
> Best regards,
> Trevor
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
> 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] [oe] OEDAM, April 8 in San Diego after ELC

2016-03-23 Thread Fred Ollinger

I'm coming and I'm probably brining another person.

I still have to make the wiki account which failed for some reason before.

Frederick

From: yocto-boun...@yoctoproject.org  on behalf 
of Trevor Woerner 
Sent: Wednesday, March 23, 2016 2:08 PM
To: akuster808; openembedded-de...@lists.openembedded.org; openembedded-core; 
Yocto Project; openembedded-memb...@lists.openembedded.org
Subject: Re: [yocto] [OE-core] [oe] OEDAM, April 8 in San Diego after ELC

On Wed 2016-03-23 @ 09:36:40 AM, akuster808 wrote:
> There are only 10 people signed up.
> Is that enough people to justify the expense room or even meet?

I have no idea what the budget might be or what a room might cost. I'll leave
it to those who do know to worry about the costs versus the benefits.

In any case I certainly think it's still worth meeting. A smaller, more
focused group can sometimes get more done than a larger group. Secondly, it's
my experience that more people always show up than sign up.

With a project like this there will always be things to discuss, and sometimes
a discussion goes better in person rather than online.

Best regards,
Trevor
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] [oe] OEDAM, April 8 in San Diego after ELC

2016-03-23 Thread Trevor Woerner

On Wed 2016-03-23 @ 09:36:40 AM, akuster808 wrote:
> There are only 10 people signed up.
> Is that enough people to justify the expense room or even meet?

I have no idea what the budget might be or what a room might cost. I'll leave
it to those who do know to worry about the costs versus the benefits.

In any case I certainly think it's still worth meeting. A smaller, more
focused group can sometimes get more done than a larger group. Secondly, it's
my experience that more people always show up than sign up.

With a project like this there will always be things to discuss, and sometimes
a discussion goes better in person rather than online.

Best regards,
Trevor
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH v2] poky-sanity.bbclass: update conf/templateconf.cfg for existing installations

2016-03-23 Thread Bill Randle

V2 fixes a typo in the original version where it had POKY_BBLAYERS_CONF_VERS
instead of POKY_BBLAYERS_CONF_VERSION in one place and also bumps the
version number in the bblayers.conf.sample file.

Updates of existing installations for the meta-yocto to meta-poky transition 
will
update the bblayers.conf file, but not the templateconf.cfg file. This
patch updates the template file to point to meta-poky/conf, if necessary.

Fixes [YOCTO #9278]

Signed-off-by: Bill Randle 
---
 meta-poky/classes/poky-sanity.bbclass | 42 +++
 meta-poky/conf/bblayers.conf.sample   |  2 +-
 meta-poky/conf/layer.conf |  2 +-
 3 files changed, 40 insertions(+), 6 deletions(-)

diff --git a/meta-poky/classes/poky-sanity.bbclass 
b/meta-poky/classes/poky-sanity.bbclass
index 287a9e3..4add57e 100644
--- a/meta-poky/classes/poky-sanity.bbclass
+++ b/meta-poky/classes/poky-sanity.bbclass
@@ -3,10 +3,44 @@
 python poky_update_bblayersconf() {
 current_version = int(d.getVar('POKY_BBLAYERS_CONF_VERSION', True) or -1)
 latest_version = int(d.getVar('REQUIRED_POKY_BBLAYERS_CONF_VERSION', True) 
or -1)
+if current_version == -1 or latest_version == -1:
+# one or the other missing => malformed configuration
+raise NotImplementedError("You need to update bblayers.conf manually 
for this version transition")
 
-# No version transitions here yet
-raise NotImplementedError("You need to update bblayers.conf manually for 
this version transision")
+success = True
+
+# check for out of date templateconf.cfg file
+lines = []
+fn = os.path.join(d.getVar('TOPDIR', True), 'conf/templateconf.cfg')
+
+lines = sanity_conf_read(fn)
+index, meta_yocto_line = sanity_conf_find_line(r'^meta-yocto/', lines)
+if meta_yocto_line:
+lines[index] = meta_yocto_line.replace('meta-yocto', 'meta-poky')
+with open(fn, "w") as f:
+f.write(''.join(lines))
+bb.note("Your conf/templateconf.cfg file was updated from meta-yocto 
to meta-poky")
+
+# add any additional layer checks/changes here
+
+if success:
+current_version = latest_version
+bblayers_fn = bblayers_conf_file(d)
+lines = sanity_conf_read(bblayers_fn)
+# sanity_conf_update() will erroneously find a match when the var name
+# is used in a comment, so do our own here. The code below can be
+# removed when sanity_conf_update() is fixed in OE-Core.
+#sanity_conf_update(bblayers_fn, lines, 'POKY_BBLAYERS_CONF_VERSION', 
current_version)
+index, line = sanity_conf_find_line(r'^POKY_BBLAYERS_CONF_VERSION', 
lines)
+lines[index] = 'POKY_BBLAYERS_CONF_VERSION = "%d"\n' % current_version
+with open(bblayers_fn, "w") as f:
+f.write(''.join(lines))
+bb.note("Your conf/bblayers.conf has been automatically updated.")
+if success:
+return
+
+raise NotImplementedError("You need to update bblayers.conf manually for 
this version transition")
 }
 
-# Prepend to ensure our function runs before the OE-Core one
-BBLAYERS_CONF_UPDATE_FUNCS =+ 
"conf/bblayers.conf:POKY_BBLAYERS_CONF_VERSION:REQUIRED_POKY_BBLAYERS_CONF_VERSION:poky_update_bblayersconf"
+# ensure our function runs after the OE-Core one
+BBLAYERS_CONF_UPDATE_FUNCS += 
"conf/bblayers.conf:POKY_BBLAYERS_CONF_VERSION:REQUIRED_POKY_BBLAYERS_CONF_VERSION:poky_update_bblayersconf"
diff --git a/meta-poky/conf/bblayers.conf.sample 
b/meta-poky/conf/bblayers.conf.sample
index a371994..8b1cbdf 100644
--- a/meta-poky/conf/bblayers.conf.sample
+++ b/meta-poky/conf/bblayers.conf.sample
@@ -1,6 +1,6 @@
 # POKY_BBLAYERS_CONF_VERSION is increased each time build/conf/bblayers.conf
 # changes incompatibly
-POKY_BBLAYERS_CONF_VERSION = "1"
+POKY_BBLAYERS_CONF_VERSION = "2"
 
 BBPATH = "${TOPDIR}"
 BBFILES ?= ""
diff --git a/meta-poky/conf/layer.conf b/meta-poky/conf/layer.conf
index b5ffd9e..8b7b33d 100644
--- a/meta-poky/conf/layer.conf
+++ b/meta-poky/conf/layer.conf
@@ -15,4 +15,4 @@ LAYERVERSION_yocto = "3"
 
 LAYERDEPENDS_yocto = "core"
 
-REQUIRED_POKY_BBLAYERS_CONF_VERSION = "1"
+REQUIRED_POKY_BBLAYERS_CONF_VERSION = "2"
-- 
2.5.0
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] perl 5.22 and 32 bit targets

2016-03-23 Thread Gary Thomas

On 2016-03-23 13:17, Jens Rehsack wrote:

Am 23.03.2016 um 13:07 schrieb Gary Thomas :

On 2016-03-23 12:43, Jens Rehsack wrote:

Am 23.03.2016 um 12:05 schrieb Gary Thomas :

On 2016-03-23 10:48, Jens Rehsack wrote:

Am 23.03.2016 um 10:14 schrieb Jens Rehsack :

Am 23.03.2016 um 10:09 schrieb Gary Thomas :

On 2016-03-23 09:57, Jens Rehsack wrote:

Am 23.03.2016 um 09:40 schrieb Gary Thomas :

On 2016-03-23 09:09, Gary Thomas wrote:

On 2016-03-23 06:36, Khem Raj wrote:

On Tue, Mar 22, 2016 at 9:53 PM, Gary Thomas wrote:

I hope this is the correct place to discuss this problem. It
is all about a difference in behavior between a program built
using bitbake/OE (only OE-core is needed) vs building the program
on the target hardware itself.

I've been struggling with this problem since perl was upgraded
to version 5.22. I'm working on Amanda (Advanced Maryland Archive
tool) which is written primarily in perl and uses swig interfaces
to access native C functions. This code works great when using
the previous perl (5.20.x) but fails on all 32 bit targets with
perl 5.22

The interesting thing is that if I build Amanda on my target
directly (using SDK tools), it works perfectly even with perl
5.22, so it seems that there is some [subtle] difference between
building using bitbake/OE than when built on the self-hosted
target. I've compared the builds and the only thing I could
find (from the output of configure) is a difference in sizeof(off_t)
Sadly, when I tried to adjust this in the OE build, it didn't
make any difference, but perhaps I didn't make this change
correctly or completely.

do you have largefile support turned on ? if you do then it might
be detecting it wrongly during configure since we cache it to a
non-largefile case

so try to add something like

EXTRA_OECONF += "${@bb.utils.contains('DISTRO_FEATURES', 'largefile',
'ac_cv_sizeof_off_t=8', '', d)}"

while building perl or the affected program and see if that helps

Thanks for the idea, but that didn't help. I also forced some CFLAGS
to match, in particular:
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
but this didn't make any difference either.

On a whim I just tried a little experiment where I took the *.o files
from the perl subdirectory (where all the swig shims live) from a working
(self-hosted) build and moved them to my bitbake/OE build. I then touched
all the *.o and *.lo files in the perl tree to force a relink. I then ran
% bitbake amanda -C compile && bitbake core-image-base
to my surprise, amanda works! So the culprit lies somewhere within the
swig generated glue. I've tried comparing these files before and I didn't
find anything other than cosmetic differences (mostly comments about the
name of the file processed, etc). I've added this subtree to "results"
in my github layer in case someone can see what might be relevant.

Any ideas what might be different and make this swig generated glue fail?
Note that the swig interface files are rebuilt as part of the build process
and both bitbake/OE and self-hosted are using the same swig version.

I digged a bit through your layer (while my up2date scanner over meta-cpan
blocks my build chain :P) and realized that you use perl-5.20.0 as it was
in poky. A "simple" downgrade would be more reasonable ... if reason applys
here in general :)

In practice, I am doing that. However, I want to understand why perl 5.22
breaks things and get it fixed.

I did a diff between your 5.20 and poky's 5.22 and realize some fixes applied
in 5.22 regarding library path's aren't applied in your copy. Maybe swig relies
on wrong library locations and when we know, we can fix.

So it's maybe not a 5.20 vs. 5.22 problem, it's maybe a weird swig setup
problem.

When you fail on cross-build and succeed in target build, try to compare the
C files and includes (even swig libraries) used.

It smells more like a "wrong source" than a "perl problem" (and even when
I never would read any python thread, the same problem would likely occur
there, too ^^).

Which perl headers are used in your build? To dig down, more logs would
be reasonable ...

Everything comes from the same sources, same revisions, etc, as I'm using
either a bitbake/OE build or the embedded (self-hosted) version from the
same build plus SDK tools.

And your SDK does not include any host tools? Did you prove the intermediate
amanda build files (eg. generated by SWIG) for relicts from wrong source?
Did you check the logs which include directories had been used?

I give it a quick shot and got:

../../arm-poky-linux-gnueabi-libtool --tag=CC --mode=compile
arm-poky-linux-gnueabi-gcc -march=armv7-a -marm -mthumb-interwork
-mfloat-abi=hard -mfpu=neon -mtune=cortex-a9
--sysroot=/homes/sno/fsl-release-bsp/ornithologen-kann-man-mit-voegeln-eine-freude-machen/tmp/sysroots/curie
-DHAVE_CONFIG_H -I.

Re: [yocto] [oe] OEDAM, April 8 in San Diego after ELC

2016-03-23 Thread akuster808



On 03/08/2016 08:10 AM, Philip Balister wrote:
> On the Friday after ELC in San Diego (Yocto Project Dev Day is
> Thursday), we will have a developer meeting near the conference venue
> (need to double check with Jefro about exact location).

There are only 10 people signed up.

Is that enough people to justify the expense room or even meet?

- armin
> 
> http://openembedded.org/wiki/OEDAM_2016
> 
> At these meetings we try to follow an agenda we develop before hand on
> the wiki page. I've created a rough agenda by posting notes from the
> meeting in Dublin. Everyone, please go over the notes and add remarks
> for completed items.
> 
> You can also bring up issues at the meeting. We only have one day
> scheduled for the meeting, so a little pre-planning helps keep us on time.
> 
> Everyone involved in the project is welcome to attend, no how
> knowledgeable in the overall OpenEmbedded project We like to hear from
> people from many different use cases.
> 
> Thanks,
> 
> Philip
> 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] extra deploy for image

2016-03-23 Thread Dvorkin Dmitry


Hello, guys!

I'm building the image and getting it in the .../deploy/
together with uImage, DTSes and modules (as separate files).
It's standard recipes behavior.

I need one more extra tool for the host system to build and place into 
/deploy/

I created a recipe, added
///
inherit deploy

do_deploy() {
}
do_deploy-native() {
 install ${S}/mytool ${DEPLOYDIR}/mytool
}
addtask deploy before do_build after do_compile
BBCLASSEXTEND = "native nativesdk"
//
into it's recipe, added

EXTRA_IMAGEDEPENDS += "mytool-native"

into myarch.conf
, build the image successfully. Image recipe (I see it) builds 
mytool-native also, but does not call deploy for it.


Do anybody knows how to deploy mytool-native together with my Linux 
image if mytool.bb is a separate recipe?


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

[yocto] How to configure SDK_POST_INSTALL_COMMAND

2016-03-23 Thread Terry Farnham

Hello,



Looking through the populate_sdk_base class, I found
“SDK_POST_INSTALL_COMMAND”.  I am very interested in what this feature
makes available, but all of my efforts to use it have failed.  Does anyone
have any information on how I should configure and use this variable?



Thanks,



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

Re: [yocto] Question about XEN-hypervisor and Yocto build system

2016-03-23 Thread Chris Patterson

(CCing meta-virtualization)

On Wed, Mar 23, 2016 at 8:46 AM, Olsson Rikard (RBSN/ESW1)
 wrote:
> Hello Yocto Members,
>
> I am looking into xen-hypervisor and have downloaded the meta-virtualization 
> layer and updated bblayers.conf to pull in the layer. However I am unsure how 
> to proceed:
> 1) How do I configure the meta-virtualization to use Xen hypervisor

You will need to add "xen" to your DISTRO_FEATURES to toggle on the
yocto kernel config fragment for xen support, as well as libvirt.

> 2) What target do I build/bb file do I build.
>
> I usually build either:
> bitbake core-image-minimal ==> Standard Linux for our HW board
> bitbake core-image-XXX--XXX ==> Standard Linux for our HW board + additional 
> application layers.
>
> I am however unable to understand the connection between the images I 
> currently build and the Xen-hypervisor, for example:
> recipes-extended/libvirt/libvirt_1.2.19.bb:# xen-minimal config
> recipes-extended/images/kvm-image-minimal.bb:DESCRIPTION = "A minimal kvm 
> image"
> recipes-extended/images/xen-image-minimal.bb:DESCRIPTION = "A minimal xen 
> image"
> What are above bitbake recipes, should I build xen-image-minimal.bb instead 
> of core-image-minimal or
>

This largely depends on what you are trying to do, your BSP, if you
are using the yocto kernel, etc..  Building xen-image-minimal should
provide a bootable dom0 out of the box (at least for typical x86-64)
that can start/stop VMs using xl toolstack (not libvirt).

Adding xen support is largely about getting the appropriate kernel
bits enabled (meta-virtualization provides a config fragment).  For
dom0, you will also need to configure your bootloader to boot xen, and
then you will need to add the packages you desire (qemu, libvirt,
xen-base, etc.) to your specific image.

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

Re: [yocto] Question about XEN-hypervisor and Yocto build system

2016-03-23 Thread M. Gregory



On 03/23/2016 08:46 AM, Olsson Rikard (RBSN/ESW1) wrote:
> Hello Yocto Members,
>
> I am looking into xen-hypervisor and have downloaded the meta-virtualization 
> layer and updated bblayers.conf to pull in the layer. However I am unsure how 
> to proceed:
> 1) How do I configure the meta-virtualization to use Xen hypervisor
> 2) What target do I build/bb file do I build.
>
> I usually build either:
> bitbake core-image-minimal ==> Standard Linux for our HW board
> bitbake core-image-XXX--XXX ==> Standard Linux for our HW board + additional 
> application layers.
>
> I am however unable to understand the connection between the images I 
> currently build and the Xen-hypervisor, for example:
> recipes-extended/libvirt/libvirt_1.2.19.bb:# xen-minimal config
> recipes-extended/images/kvm-image-minimal.bb:DESCRIPTION = "A minimal kvm 
> image"
> recipes-extended/images/xen-image-minimal.bb:DESCRIPTION = "A minimal xen 
> image"
> What are above bitbake recipes, should I build xen-image-minimal.bb instead 
> of core-image-minimal or
>
> I have looked at:
> https://wiki.yoctoproject.org/wiki/Virtualization_with_KVM
> and the two README files:
> ./docs/00-README
> ./README
> but there is not much information on Yocto and xen-hypervisor so I am unsure 
> how to setup the build system.
>
> Appreciate any advice or input.
>
> Best regards
> Rikard Olsson
>
You should send your meta-virtualization questions to
meta-virtualizat...@yoctoproject.org.

The xen-image-minimal will build an image with the Xen hypervisor. You
need to include xen in your DISTRO_FEATURES to ensure all other required
components are built.

-- 
Machon Gregory

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

[yocto] Question about XEN-hypervisor and Yocto build system

2016-03-23 Thread Olsson Rikard (RBSN/ESW1)

Hello Yocto Members,

I am looking into xen-hypervisor and have downloaded the meta-virtualization 
layer and updated bblayers.conf to pull in the layer. However I am unsure how 
to proceed:
1) How do I configure the meta-virtualization to use Xen hypervisor
2) What target do I build/bb file do I build.

I usually build either:
bitbake core-image-minimal ==> Standard Linux for our HW board
bitbake core-image-XXX--XXX ==> Standard Linux for our HW board + additional 
application layers.

I am however unable to understand the connection between the images I currently 
build and the Xen-hypervisor, for example:
recipes-extended/libvirt/libvirt_1.2.19.bb:# xen-minimal config
recipes-extended/images/kvm-image-minimal.bb:DESCRIPTION = "A minimal kvm image"
recipes-extended/images/xen-image-minimal.bb:DESCRIPTION = "A minimal xen image"
What are above bitbake recipes, should I build xen-image-minimal.bb instead of 
core-image-minimal or

I have looked at:
https://wiki.yoctoproject.org/wiki/Virtualization_with_KVM
and the two README files:
./docs/00-README
./README
but there is not much information on Yocto and xen-hypervisor so I am unsure 
how to setup the build system.

Appreciate any advice or input.

Best regards
Rikard Olsson

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

Re: [yocto] perl 5.22 and 32 bit targets

2016-03-23 Thread Jens Rehsack


> Am 23.03.2016 um 13:07 schrieb Gary Thomas :
> 
> On 2016-03-23 12:43, Jens Rehsack wrote:
>> 
>>> Am 23.03.2016 um 12:05 schrieb Gary Thomas :
>>> 
>>> On 2016-03-23 10:48, Jens Rehsack wrote:
 
> Am 23.03.2016 um 10:14 schrieb Jens Rehsack :
> 
>> 
>> Am 23.03.2016 um 10:09 schrieb Gary Thomas :
>> 
>> On 2016-03-23 09:57, Jens Rehsack wrote:
>>> 
 Am 23.03.2016 um 09:40 schrieb Gary Thomas :
 
 On 2016-03-23 09:09, Gary Thomas wrote:
> On 2016-03-23 06:36, Khem Raj wrote:
>> On Tue, Mar 22, 2016 at 9:53 PM, Gary Thomas  
>> wrote:
>>> I hope this is the correct place to discuss this problem.  It
>>> is all about a difference in behavior between a program built
>>> using bitbake/OE (only OE-core is needed) vs building the program
>>> on the target hardware itself.
>>> 
>>> I've been struggling with this problem since perl was upgraded
>>> to version 5.22.  I'm working on Amanda (Advanced Maryland Archive
>>> tool) which is written primarily in perl and uses swig interfaces
>>> to access native C functions.  This code works great when using
>>> the previous perl (5.20.x) but fails on all 32 bit targets with
>>> perl 5.22
>>> 
>>> The interesting thing is that if I build Amanda on my target
>>> directly (using SDK tools), it works perfectly even with perl
>>> 5.22, so it seems that there is some [subtle] difference between
>>> building using bitbake/OE than when built on the self-hosted
>>> target.  I've compared the builds and the only thing I could
>>> find (from the output of configure) is a difference in sizeof(off_t)
>>> Sadly, when I tried to adjust this in the OE build, it didn't
>>> make any difference, but perhaps I didn't make this change
>>> correctly or completely.
>> 
>> do you have largefile support turned on ? if you do then it might
>> be detecting it wrongly during configure since we cache it to a
>> non-largefile case
>> 
>> so try to add something like
>> 
>> EXTRA_OECONF += "${@bb.utils.contains('DISTRO_FEATURES', 'largefile',
>> 'ac_cv_sizeof_off_t=8', '', d)}"
>> 
>> while building perl or the affected program and see if that helps
> 
> Thanks for the idea, but that didn't help.  I also forced some CFLAGS
> to match, in particular:
>  -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
> but this didn't make any difference either.
> 
 
 On a whim I just tried a little experiment where I took the *.o files
 from the perl subdirectory (where all the swig shims live) from a 
 working
 (self-hosted) build and moved them to my bitbake/OE build.  I then 
 touched
 all the *.o and *.lo files in the perl tree to force a relink. I then 
 ran
 % bitbake amanda -C compile && bitbake core-image-base
 to my surprise, amanda works!  So the culprit lies somewhere within the
 swig generated glue.  I've tried comparing these files before and I 
 didn't
 find anything other than cosmetic differences (mostly comments about 
 the
 name of the file processed, etc).  I've added this subtree to "results"
 in my github layer in case someone can see what might be relevant.
 
 Any ideas what might be different and make this swig generated glue 
 fail?
 Note that the swig interface files are rebuilt as part of the build 
 process
 and both bitbake/OE and self-hosted are using the same swig version.
>>> 
>>> I digged a bit through your layer (while my up2date scanner over 
>>> meta-cpan
>>> blocks my build chain :P) and realized that you use perl-5.20.0 as it 
>>> was
>>> in poky. A "simple" downgrade would be more reasonable ... if reason 
>>> applys
>>> here in general :)
>> 
>> In practice, I am doing that.  However, I want to understand why perl 
>> 5.22
>> breaks things and get it fixed.
> 
> I did a diff between your 5.20 and poky's 5.22 and realize some fixes 
> applied
> in 5.22 regarding library path's aren't applied in your copy. Maybe swig 
> relies
> on wrong library locations and when we know, we can fix.
> 
> So it's maybe not a 5.20 vs. 5.22 problem, it's maybe a weird swig setup 
> problem.
> 
>>> When you fail on cross-build and succeed in target build, try to 
>>> compare the
>>> C files and includes (even swig libraries) used.
>>> 
>>> It smells more like a "wrong source" than a "perl problem" (and even 
>>> when
>>> I