Re: [OE-core] [PATCH] rm_work.bbclass: re-enable recursive do_rm_work_all

2017-03-17 Thread Patrick Ohly
On Thu, 2017-03-16 at 22:32 +, Burton, Ross wrote:
> If I do a build with rm_work enabled I tend to get this error at
> rootfs time:
> 
> 
> ERROR: core-image-sato-1.0-r0 do_image_wic: Error executing a python
> function in exec_python_func() autogenerated:

> Exception: FileExistsError: [Errno 17] File exists:
> '/data/poky-master/tmp/sysroots-components/corei7-64/glibc/usr/lib/crt1.o' -> 
> '/data/poky-master/tmp/work/intel_corei7_64-poky-linux/core-image-sato/1.0-r0/recipe-sysroot/usr/lib/crt1.o'
> 
> 
> ERROR: core-image-sato-1.0-r0 do_image_wic: Function failed:
> extend_recipe_sysroot
> ERROR: Logfile of failure stored
> in: 
> /data/poky-master/tmp/work/intel_corei7_64-poky-linux/core-image-sato/1.0-r0/temp/log.do_image_wic.21552
> ERROR: Task
> (/home/ross/Yocto/poky/meta/recipes-sato/images/core-image-sato.bb:do_image_wic)
>  failed with exit code '1'
> 
> 
> Reverting this patch makes it go away.

I think I have seen that before, but not necessarily (not sure anymore)
in the context of rm_work. If I remember correctly, these were really
two different crt1.o files, one from glibc, the other from
glibc-initial.

I couldn't reproduce it at that time. I'll check whether I can trigger
it now.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.



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


Re: [OE-core] [PATCH 1/1] gen-lockedsig-cache: catch os.link error

2017-03-17 Thread Richard Purdie
On Tue, 2017-03-14 at 17:04 -0700, brian avery wrote:
> We do a hard link to speed up sdk creation but if your sstate-cache
> is
> across a file system boundary, this tries and fails. This patch
> catches
> that error and does a copy instead.
> 
> Signed-off-by: brian avery 
> ---
>  scripts/gen-lockedsig-cache | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/scripts/gen-lockedsig-cache b/scripts/gen-lockedsig-
> cache
> index 49de74ed..1cfbeae 100755
> --- a/scripts/gen-lockedsig-cache
> +++ b/scripts/gen-lockedsig-cache
> @@ -63,6 +63,12 @@ for f in files:
>  if (os.stat(src).st_dev == os.stat(destdir).st_dev):
>  print('linking')
>  os.link(src, dst)
> +try:
> +os.link(src, dst)
> +except Exception:
> +print('hard linking failed, copying')
> +shutil.copyfile(src, dst)
> +os.link(src, dst)
>  else:
>  print('copying')
>  shutil.copyfile(src, dst)

Really? How many os.link() calls do we need?

Also, "Exception" without a specific exception you want to catch tends
to be a bad idea.

Cheers,

Richard


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


[OE-core] [PATCH] image_types: increase filesystem size for BTRFS

2017-03-17 Thread Ed Bartosh
16777216 bytes is a minimal possible filesystem size for BTRFS.
mkfs.btrfs fails to create a filesystem if rootfs size is too small.

Increased filesystem size to make it possible for mkfs.btrfs
to create an image for small rootfs directories,
e.g. for core-image-minimal.

[YOCTO #11163]

Signed-off-by: Ed Bartosh 
---
 meta/classes/image_types.bbclass | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
index d2eb99d..99adeb3 100644
--- a/meta/classes/image_types.bbclass
+++ b/meta/classes/image_types.bbclass
@@ -82,12 +82,13 @@ IMAGE_CMD_ext4 = "oe_mkext234fs ext4 ${EXTRA_IMAGECMD}"
 
 MIN_BTRFS_SIZE ?= "16384"
 IMAGE_CMD_btrfs () {
-   if [ ${ROOTFS_SIZE} -gt ${MIN_BTRFS_SIZE} ]; then
-   dd if=/dev/zero 
of=${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.btrfs count=${ROOTFS_SIZE} 
bs=1024
-   mkfs.btrfs ${EXTRA_IMAGECMD} -r ${IMAGE_ROOTFS} 
${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.btrfs
-   else
-   bbfatal "Rootfs is too small for BTRFS (Rootfs Actual Size: 
${ROOTFS_SIZE}, BTRFS Minimum Size: ${MIN_BTRFS_SIZE})"
+   size=${ROOTFS_SIZE}
+   if [ ${size} -lt ${MIN_BTRFS_SIZE} ] ; then
+   size=${MIN_BTRFS_SIZE}
+   bbwarn "Rootfs size is too small for BTRFS. Filesystem will be 
extended to ${size}K"
fi
+   dd if=/dev/zero 
of=${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.btrfs count=${size} bs=1024
+   mkfs.btrfs ${EXTRA_IMAGECMD} -r ${IMAGE_ROOTFS} 
${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.btrfs
 }
 
 IMAGE_CMD_squashfs = "mksquashfs ${IMAGE_ROOTFS} 
${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.squashfs ${EXTRA_IMAGECMD} 
-noappend"
-- 
2.1.4

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


Re: [OE-core] [PATCH 4/6] oeqa/targetcontrol.py: modify it to test runqemu

2017-03-17 Thread Richard Purdie
On Thu, 2017-03-16 at 03:13 -0700, Robert Yang wrote:
> Modify the following files to test runqemu:
> targetcontrol.py
> utils/commands.py
> utils/qemurunner.py
> 
> We need simulate how "runqemu" works in command line, so when test
> "runqemu", the targetcontrol.py, utils/commands.py and
> utils/qemurunner.py don't have to find the rootfs or set env vars.
> 
> [YOCTO #10249]
> 
> Signed-off-by: Robert Yang 
> ---
>  meta/lib/oeqa/targetcontrol.py| 20 +++-
>  meta/lib/oeqa/utils/commands.py   | 13 +++--
>  meta/lib/oeqa/utils/qemurunner.py | 28 +---
>  3 files changed, 43 insertions(+), 18 deletions(-)

This change breaks "oe-selftest -r wic.Wic.test_qemu_efi" which just
hangs afterwards.

Cheers,

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


[OE-core] [PATCH] neard: Fix parallel build issue

2017-03-17 Thread Jussi Kukkonen
This only started showing up now for some reason but it does seem like
a legitimate bug in Makefile.am.

Signed-off-by: Jussi Kukkonen 
---
 ...0001-Add-header-dependency-to-nciattach.o.patch | 35 ++
 meta/recipes-connectivity/neard/neard_0.16.bb  |  1 +
 2 files changed, 36 insertions(+)
 create mode 100644 
meta/recipes-connectivity/neard/neard/0001-Add-header-dependency-to-nciattach.o.patch

diff --git 
a/meta/recipes-connectivity/neard/neard/0001-Add-header-dependency-to-nciattach.o.patch
 
b/meta/recipes-connectivity/neard/neard/0001-Add-header-dependency-to-nciattach.o.patch
new file mode 100644
index 000..d8e8a5e
--- /dev/null
+++ 
b/meta/recipes-connectivity/neard/neard/0001-Add-header-dependency-to-nciattach.o.patch
@@ -0,0 +1,35 @@
+From affaa2021a54c30353e4e1fee09c13a4de2196be Mon Sep 17 00:00:00 2001
+From: Jussi Kukkonen 
+Date: Fri, 17 Mar 2017 14:24:29 +0200
+Subject: [PATCH] Add header dependency to nciattach.o
+
+This can happen when compiling nciattach.o:
+
+| In file included from ../neard-0.16/tools/nciattach.c:47:0:
+| ../neard-0.16/src/near.h:30:27: fatal error: near/nfc_copy.h: No such
+file or directory
+|  #include 
+
+Add the missing dependency to local headers.
+
+Signed-off-by: Jussi Kukkonen 
+Upstream-Status: Submitted [mailinglist]
+---
+ Makefile.am | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/Makefile.am b/Makefile.am
+index fa552ee..acef6ba 100644
+--- a/Makefile.am
 b/Makefile.am
+@@ -253,6 +253,7 @@ se/builtin.h: src/genbuiltin $(builtin_se_sources)
+ 
+ $(src_neard_OBJECTS) \
+ $(tools_nfctool_nfctool_OBJECTS) \
++$(tools_nciattach_OBJECTS) \
+ $(plugin_objects) \
+ $(se_seeld_OBJECTS) \
+ $(unit_test_ndef_parse_OBJECTS) \
+-- 
+2.11.0
+
diff --git a/meta/recipes-connectivity/neard/neard_0.16.bb 
b/meta/recipes-connectivity/neard/neard_0.16.bb
index d6157a8..cc6af4e 100644
--- a/meta/recipes-connectivity/neard/neard_0.16.bb
+++ b/meta/recipes-connectivity/neard/neard_0.16.bb
@@ -9,6 +9,7 @@ SRC_URI = "${KERNELORG_MIRROR}/linux/network/nfc/${BP}.tar.xz \
file://neard.in \
file://Makefile.am-fix-parallel-issue.patch \
file://Makefile.am-do-not-ship-version.h.patch \
+   file://0001-Add-header-dependency-to-nciattach.o.patch \
   "
 SRC_URI[md5sum] = "5c691fb7872856dc0d909c298bc8cb41"
 SRC_URI[sha256sum] = 
"eae3b11c541a988ec11ca94b7deab01080cd5b58cfef3ced6ceac9b6e6e65b36"
-- 
2.1.4

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


[OE-core] [PATCH 1/4] runqemu: output network configuration

2017-03-17 Thread Ed Bartosh
runqemu adds network configuration parameters to the kernel
command line to configure guest networking. This works only
for the images that run with external kernel using qemu -kernel
parameter. It doesn't work for the images that use bootloader
to boot kernel as -kernel parameter is not used and network
configuration is not possible to get.

Added host and guest ip addresses and netmask of tap link
to the runqemu output. This should allow external programs
that execute runqemu to get network configuration.

[YOCTO #10833]

Signed-off-by: Ed Bartosh 
---
 scripts/runqemu | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/scripts/runqemu b/scripts/runqemu
index 1721956..453f9d8 100755
--- a/scripts/runqemu
+++ b/scripts/runqemu
@@ -917,7 +917,9 @@ class BaseConfig(object):
 client = gateway + 1
 if self.fstype == 'nfs':
 self.setup_nfs()
-self.kernel_cmdline_script += " 
ip=192.168.7.%s::192.168.7.%s:255.255.255.0" % (client, gateway)
+netconf = "192.168.7.%s::192.168.7.%s:255.255.255.0" % (client, 
gateway)
+logger.info("Network configuration: %s", netconf)
+self.kernel_cmdline_script += " ip=%s" % netconf
 mac = "%s%02x" % (self.mac_tap, client)
 qb_tap_opt = self.get('QB_TAP_OPT')
 if qb_tap_opt:
-- 
2.1.4

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


[OE-core] [PATCH 0/4] #10833: fix testing of wic images by testimage

2017-03-17 Thread Ed Bartosh
Hi,

It was not possible to test wic images with testimage as this framework 
configured
guest networking by passing "ip=:::" to the kernel.
This approach doesn't work for wic images as kernel is run by bootloader and the
kernel command line is defined when image is built.

This patchset implements networking configuration by running commands on 
guests's
serial console. runqemu script was modified to output IP addresses and netmask 
to
be able to get these parameters from its output in testimage code.

The following changes since commit 8e9769773fd6d04402581c005bb423530a726457:

  meta-yocto-bsp: bump to the latest linux stable kernel for the non-x86 BSPs 
(2017-03-16 22:12:07 +)

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib ed/oe-core/tap-networking-wic-10833
  
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=ed/oe-core/tap-networking-wic-10833

Ed Bartosh (4):
  runqemu: output network configuration
  qemurunner: get network params from runqemu output
  qemurunner: configure guest networking
  bitbake.conf: add sudo to HOSTTOOLS_NONFATAL

 meta/conf/bitbake.conf|  2 +-
 meta/lib/oeqa/utils/qemurunner.py | 49 ---
 scripts/runqemu   |  4 +++-
 3 files changed, 39 insertions(+), 16 deletions(-)

--
Regards,
Ed

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


[OE-core] [PATCH 4/4] bitbake.conf: add sudo to HOSTTOOLS_NONFATAL

2017-03-17 Thread Ed Bartosh
runqemu is using sudo to configure tap networking. Without sudo
in HOSTTOOLS_NONFATAL it may cause bitbake -c testimage to fail
with this error:
runqemu - INFO - Setting up tap interface under sudo
/bin/sh: sudo: command not found

Signed-off-by: Ed Bartosh 
---
 meta/conf/bitbake.conf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 9fdbdfd..649dcef 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -469,7 +469,7 @@ HOSTTOOLS += " \
 HOSTTOOLS += "ps stty ip ssh scp ping vi"
 
 # Link to these if present
-HOSTTOOLS_NONFATAL += "ccache ld.bfd ld.gold gcc-ar gpg sftp nc socat"
+HOSTTOOLS_NONFATAL += "ccache ld.bfd ld.gold gcc-ar gpg sftp nc socat sudo"
 
 CCACHE ??= ""
 # Disable ccache explicitly if CCACHE is null since gcc may be a symlink
-- 
2.1.4

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


[OE-core] [PATCH 3/4] qemurunner: configure guest networking

2017-03-17 Thread Ed Bartosh
Configured guest network interface through serial connection
when kernel is not run by qemu.

This should make it possible to test wic images with testimage.

[YOCTO #10833]

Signed-off-by: Ed Bartosh 
---
 meta/lib/oeqa/utils/qemurunner.py | 13 +
 1 file changed, 13 insertions(+)

diff --git a/meta/lib/oeqa/utils/qemurunner.py 
b/meta/lib/oeqa/utils/qemurunner.py
index 7e5f588..9ef7629 100644
--- a/meta/lib/oeqa/utils/qemurunner.py
+++ b/meta/lib/oeqa/utils/qemurunner.py
@@ -195,6 +195,7 @@ class QemuRunner:
 time.sleep(1)
 
 out = self.getOutput(output)
+netconf = False # network configuration is not required by default
 if self.is_alive():
 logger.info("qemu started - qemu procces pid is %s" % self.qemupid)
 if get_ip:
@@ -215,6 +216,10 @@ class QemuRunner:
  out, re.MULTILINE|re.DOTALL)
 if match:
 self.ip, self.server_ip, self.netmask = match.groups()
+# network configuration is required as we couldn't get 
it
+# from the runqemu command line, so qemu doesn't run 
kernel
+# and guest networking is not configured
+netconf = True
 else:
 logger.error("Couldn't get ip from qemu command line 
and runqemu output! "
  "Here is the qemu command line 
used:\n%s\n"
@@ -287,6 +292,14 @@ class QemuRunner:
 if re.search("root@[a-zA-Z0-9\-]+:~#", output):
 self.logged = True
 logger.info("Logged as root in serial console")
+if netconf:
+# configure guest networking
+cmd = "ifconfig eth0 %s netmask %s up\n" % (self.ip, 
self.netmask)
+output = self.run_serial(cmd, raw=True)[1]
+if re.search("root@[a-zA-Z0-9\-]+:~#", output):
+logger.info("configured ip address %s", self.ip)
+else:
+logger.info("Couldn't configure guest networking")
 else:
 logger.info("Couldn't login into serial console"
 " as root using blank password")
-- 
2.1.4

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


[OE-core] [PATCH 2/4] qemurunner: get network params from runqemu output

2017-03-17 Thread Ed Bartosh
Parsed runqemu output to get guest network configuration
if it's not present in runqemu command line.

[YOCTO #10833]

Signed-off-by: Ed Bartosh 
---
 meta/lib/oeqa/utils/qemurunner.py | 36 ++--
 1 file changed, 22 insertions(+), 14 deletions(-)

diff --git a/meta/lib/oeqa/utils/qemurunner.py 
b/meta/lib/oeqa/utils/qemurunner.py
index 59dc11d..7e5f588 100644
--- a/meta/lib/oeqa/utils/qemurunner.py
+++ b/meta/lib/oeqa/utils/qemurunner.py
@@ -37,10 +37,12 @@ class QemuRunner:
 self.runqemu = None
 # pid of the qemu process that runqemu will start
 self.qemupid = None
-# target ip - from the command line
+# target ip - from the command line or runqemu output
 self.ip = None
 # host ip - where qemu is running
 self.server_ip = None
+# target ip netmask
+self.netmask = None
 
 self.machine = machine
 self.rootfs = rootfs
@@ -192,6 +194,7 @@ class QemuRunner:
 return False
 time.sleep(1)
 
+out = self.getOutput(output)
 if self.is_alive():
 logger.info("qemu started - qemu procces pid is %s" % self.qemupid)
 if get_ip:
@@ -203,17 +206,23 @@ class QemuRunner:
 cmdline = re_control_char.sub('', cmdline)
 try:
 ips = re.findall("((?:[0-9]{1,3}\.){3}[0-9]{1,3})", 
cmdline.split("ip=")[1])
-if not ips or len(ips) != 3:
-raise ValueError
-else:
-self.ip = ips[0]
-self.server_ip = ips[1]
+self.ip = ips[0]
+self.server_ip = ips[1]
+logger.info("qemu cmdline used:\n{}".format(cmdline))
 except (IndexError, ValueError):
-logger.info("Couldn't get ip from qemu process arguments! 
Here is the qemu command line used:\n%s\nand output from runqemu:\n%s" % 
(cmdline, self.getOutput(output)))
-self._dump_host()
-self.stop()
-return False
-logger.info("qemu cmdline used:\n{}".format(cmdline))
+# Try to get network configuration from runqemu output
+match = re.match('.*Network configuration: 
([0-9.]+)::([0-9.]+):([0-9.]+)$.*',
+ out, re.MULTILINE|re.DOTALL)
+if match:
+self.ip, self.server_ip, self.netmask = match.groups()
+else:
+logger.error("Couldn't get ip from qemu command line 
and runqemu output! "
+ "Here is the qemu command line 
used:\n%s\n"
+ "and output from runqemu:\n%s" % 
(cmdline, out))
+self._dump_host()
+self.stop()
+return False
+
 logger.info("Target IP: %s" % self.ip)
 logger.info("Server IP: %s" % self.server_ip)
 
@@ -222,12 +231,11 @@ class QemuRunner:
 if not self.thread.connection_established.wait(self.boottime):
 logger.error("Didn't receive a console connection from qemu. "
  "Here is the qemu command line used:\n%s\nand "
- "output from runqemu:\n%s" % (cmdline,
-   
self.getOutput(output)))
+ "output from runqemu:\n%s" % (cmdline, out))
 self.stop_thread()
 return False
 
-logger.info("Output from runqemu:\n%s", self.getOutput(output))
+logger.info("Output from runqemu:\n%s", out)
 logger.info("Waiting at most %d seconds for login banner" % 
self.boottime)
 endtime = time.time() + self.boottime
 socklist = [self.server_socket]
-- 
2.1.4

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


Re: [OE-core] [PATCH v3 0/5] wic: selftest: enhancements for non-x86 MACHINE support & fixed-size tests

2017-03-17 Thread Ed Bartosh
Hi Maciej,

Thank you for the patchset!

Can you fix these pylint regressions?

C: 49, 0: Exactly one space required after comma
def __call__(self,f):
 ^ (bad-whitespace)
C: 53, 0: No space allowed before :
if self.archs and arch not in self.archs :
 ^ (bad-whitespace)
C: 40, 0: Missing function docstring (missing-docstring)
C: 44, 0: Invalid class name "onlyForArch" (invalid-name)
C: 44, 0: Missing class docstring (missing-docstring)
C: 49, 4: Invalid argument name "f" (invalid-name)
C: 51, 8: Missing function docstring (missing-docstring)
R: 44, 0: Too few public methods (0/2) (too-few-public-methods)
C:422,12: Missing function docstring (missing-docstring)
C:628,69: Invalid variable name "tf" (invalid-name)
R:623, 4: Method could be a function (no-self-use)
R: 60, 0: Too many public methods (50/20) (too-many-public-methods)


Is it possible to use functools.wraps to make onlyforarc decorator a function?
would be nice to get rid of CamelCase in its name.

Other than this the patchset looks great! Thank you!

On Thu, Mar 16, 2017 at 01:44:31PM +0100, Maciej Borzecki wrote:
> A series with enhancements and new test cases for wic selftest. The
> enhancements allow for running wic selftest for non-x86 MACHINE, such as
> qemuarm (the whole series was verified on qemux86-64 and qemuarm).
> 
> The first patch adds a machine independent kickstart file - wictestdisk.
> Most of test cases build a disk image using one of the kickstart files
> shipped in Poky (mostly directdisk. These are usually x86 oriented due
> to use of syslinux and cannot be used when running with non-x86
> compatible MACHINE. On the other hand, the image built during tests does
> not need to be bootable (with exception of TCs that verify if the image
> is indeed bootable).
> 
> Patch 2 introduces wictestdisk in test cases where its use is possible.
> 
> Patch 3 adds onlyForArch() convenience decorator and applies it to test
> cases where x86 specific image must be used. In the end, only 13 TCs are
> skipped on qemuarm.
> 
> Patch 4 removes some assumptions about kernel image type.
> 
> Patch 5 adds tests for --fixed-size partition flags
> 
> Maciej Borzecki (5):
>   selftest: wictestdisk: machine agnostic WKS for use with selftest
>   selftest: wic: replace directdisk with wictestdisk where possible
>   wic: selftest: avoid COMPATIBLE_HOST issues
>   wic: selftest: do not assume bzImage kernel image
>   wic: selftest: add tests for --fixed-size partition flags
> 
>  meta-selftest/wic/wictestdisk.wks |   7 ++
>  meta/lib/oeqa/selftest/wic.py | 167 
> ++
>  2 files changed, 140 insertions(+), 34 deletions(-)
>  create mode 100644 meta-selftest/wic/wictestdisk.wks
> 
> -- 
> 2.9.3
> 

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


[OE-core] [PATCH] meta: replace uses of bb.data.expand(VARNAME, d) with d.expand(VARNAME)

2017-03-17 Thread Joshua Lock
bb.data.expand(x, d) is deprecated API.

[YOCTO #10678]

Signed-off-by: Joshua Lock 
---
 meta/classes/archiver.bbclass  | 2 +-
 meta/classes/package.bbclass   | 4 ++--
 meta/classes/utility-tasks.bbclass | 2 +-
 meta/lib/oe/patch.py   | 2 +-
 meta/recipes-extended/pam/libpam_1.3.0.bb  | 2 +-
 meta/recipes-multimedia/alsa/alsa-plugins_1.1.1.bb | 2 +-
 6 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/meta/classes/archiver.bbclass b/meta/classes/archiver.bbclass
index ee4790d..2c04557 100644
--- a/meta/classes/archiver.bbclass
+++ b/meta/classes/archiver.bbclass
@@ -365,7 +365,7 @@ python do_ar_recipe () {
 elif include_re.match(line):
 incfile = include_re.match(line).group(1)
 if incfile:
-incfile = bb.data.expand(incfile, d)
+incfile = d.expand(incfile)
 incfile = bb.utils.which(bbpath, incfile)
 if incfile:
 shutil.copy(incfile, outdir)
diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
index 871263f..b23458b 100644
--- a/meta/classes/package.bbclass
+++ b/meta/classes/package.bbclass
@@ -778,7 +778,7 @@ python fixup_perms () {
 dir = d.getVar(path) or ""
 if dir == "":
 continue
-fs_perms_table[dir] = fs_perms_entry(bb.data.expand("%s 0755 root root 
false - - -" % (dir), d))
+fs_perms_table[dir] = fs_perms_entry(d.expand("%s 0755 root root false 
- - -" % (dir)))
 
 # Now we actually load from the configuration files
 for conf in get_fs_perms_list(d).split():
@@ -1801,7 +1801,7 @@ python package_do_pkgconfig () {
 m = field_re.match(l)
 if m:
 hdr = m.group(1)
-exp = bb.data.expand(m.group(2), pd)
+exp = pd.expand(m.group(2))
 if hdr == 'Requires':
 pkgconfig_needed[pkg] += exp.replace(',', ' 
').split()
 
diff --git a/meta/classes/utility-tasks.bbclass 
b/meta/classes/utility-tasks.bbclass
index da69c3a..587bfd4 100644
--- a/meta/classes/utility-tasks.bbclass
+++ b/meta/classes/utility-tasks.bbclass
@@ -28,7 +28,7 @@ python do_clean() {
 bb.note("Removing " + dir)
 oe.path.remove(dir)
 
-dir = "%s.*" % bb.data.expand(d.getVar('STAMP', False), d)
+dir = "%s.*" % d.getVar('STAMP')
 bb.note("Removing " + dir)
 oe.path.remove(dir)
 
diff --git a/meta/lib/oe/patch.py b/meta/lib/oe/patch.py
index aaa2d3a..f1ab3dd 100644
--- a/meta/lib/oe/patch.py
+++ b/meta/lib/oe/patch.py
@@ -81,7 +81,7 @@ class PatchSet(object):
 patch[param] = PatchSet.defaults[param]
 
 if patch.get("remote"):
-patch["file"] = 
bb.data.expand(bb.fetch2.localpath(patch["remote"], self.d), self.d)
+patch["file"] = self.d.expand(bb.fetch2.localpath(patch["remote"], 
self.d))
 
 patch["filemd5"] = bb.utils.md5_file(patch["file"])
 
diff --git a/meta/recipes-extended/pam/libpam_1.3.0.bb 
b/meta/recipes-extended/pam/libpam_1.3.0.bb
index 67b9d53..df56d27 100644
--- a/meta/recipes-extended/pam/libpam_1.3.0.bb
+++ b/meta/recipes-extended/pam/libpam_1.3.0.bb
@@ -116,7 +116,7 @@ python populate_packages_prepend () {
 d.setVar('RPROVIDES_' + pkg, provides)
 
 mlprefix = d.getVar('MLPREFIX') or ''
-dvar = bb.data.expand('${WORKDIR}/package', d, True)
+dvar = d.expand('${WORKDIR}/package')
 pam_libdir = d.expand('${base_libdir}/security')
 pam_sbindir = d.expand('${sbindir}')
 pam_filterdir = d.expand('${base_libdir}/security/pam_filter')
diff --git a/meta/recipes-multimedia/alsa/alsa-plugins_1.1.1.bb 
b/meta/recipes-multimedia/alsa/alsa-plugins_1.1.1.bb
index 3928fb1..16686a0 100644
--- a/meta/recipes-multimedia/alsa/alsa-plugins_1.1.1.bb
+++ b/meta/recipes-multimedia/alsa/alsa-plugins_1.1.1.bb
@@ -59,7 +59,7 @@ do_install_append() {
 }
 
 python populate_packages_prepend() {
-plugindir = bb.data.expand('${libdir}/alsa-lib/', d)
+plugindir = d.expand('${libdir}/alsa-lib/')
 packages = " ".join(do_split_packages(d, plugindir, 
'^libasound_module_(.*)\.so$', 'libasound-module-%s', 'Alsa plugin for %s', 
extra_depends=''))
 d.setVar("RDEPENDS_alsa-plugins", packages)
 }
-- 
2.9.3

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


Re: [OE-core] [PATCH] pinentry: update to 1.0.0

2017-03-17 Thread Burton, Ross
On 14 March 2017 at 02:39, Armin Kuster  wrote:

> add pkg-config support for libassuan and gpg-error
> updated config options
>

This didn't quite make M3 so strictly speaking upgrades have to wait.  Can
you backport the fixes to 0.9.2, or is there a sufficiently good reason to
make an exception for the 1.0 upgrade?

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


Re: [OE-core] [PATCH] python*-git: Upgrade to version 2.1.3

2017-03-17 Thread Burton, Ross
On 14 March 2017 at 08:41, Jussi Kukkonen  wrote:

> M3 freeze was scheduled for Feb 28, more than two weeks ago. I think all
> version upgrades after that should have clear justification in the commit
> message or cover letter.
>

Agreed, is there a good reason to merge this (security problems, for
example) or should this wait until 2.4 opens?

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


[OE-core] [PATCH] ltp: Fix __sighandler_t for mips

2017-03-17 Thread Khem Raj
mips definition of kernel_sigaction was added later
and the patch did not apply to mips part which ended
in ltp failing to compile on mips parts

In file included from rt_sigaction01.c:42:0:
../../../../include/lapi/rt_sigaction.h:39:2: error: unknown type name 
'__sighandler_t'
  __sighandler_t k_sa_handler;
  ^~

Signed-off-by: Khem Raj 
---
 ...n.h-Use-sighandler_t-instead-of-__sighand.patch | 31 --
 1 file changed, 17 insertions(+), 14 deletions(-)

diff --git 
a/meta/recipes-extended/ltp/ltp/0028-rt_sigaction.h-Use-sighandler_t-instead-of-__sighand.patch
 
b/meta/recipes-extended/ltp/ltp/0028-rt_sigaction.h-Use-sighandler_t-instead-of-__sighand.patch
index fc82ff9239..b26aa133e9 100644
--- 
a/meta/recipes-extended/ltp/ltp/0028-rt_sigaction.h-Use-sighandler_t-instead-of-__sighand.patch
+++ 
b/meta/recipes-extended/ltp/ltp/0028-rt_sigaction.h-Use-sighandler_t-instead-of-__sighand.patch
@@ -13,23 +13,29 @@ Signed-off-by: Khem Raj 
  testcases/kernel/syscalls/rt_sigsuspend/Makefile | 3 +++
  2 files changed, 4 insertions(+), 1 deletion(-)
 
-diff --git a/include/lapi/rt_sigaction.h b/include/lapi/rt_sigaction.h
-index 3a5a763..870918c 100644
 a/include/lapi/rt_sigaction.h
-+++ b/include/lapi/rt_sigaction.h
-@@ -34,7 +34,7 @@
- #define INVAL_SA_PTR ((void *)-1)
- 
+Index: git/include/lapi/rt_sigaction.h
+===
+--- git.orig/include/lapi/rt_sigaction.h
 git/include/lapi/rt_sigaction.h
+@@ -36,12 +36,12 @@
+ #if defined(__mips__)
+ struct kernel_sigaction {
+   unsigned int sa_flags;
+-  __sighandler_t k_sa_handler;
++  sighandler_t k_sa_handler;
+   sigset_t sa_mask;
+ };
+ #else
  struct kernel_sigaction {
 -  __sighandler_t k_sa_handler;
 +  sighandler_t k_sa_handler;
unsigned long sa_flags;
void (*sa_restorer) (void);
sigset_t sa_mask;
-diff --git a/testcases/kernel/syscalls/rt_sigsuspend/Makefile 
b/testcases/kernel/syscalls/rt_sigsuspend/Makefile
-index 37bc3a9..2ca7f7c 100644
 a/testcases/kernel/syscalls/rt_sigsuspend/Makefile
-+++ b/testcases/kernel/syscalls/rt_sigsuspend/Makefile
+Index: git/testcases/kernel/syscalls/rt_sigsuspend/Makefile
+===
+--- git.orig/testcases/kernel/syscalls/rt_sigsuspend/Makefile
 git/testcases/kernel/syscalls/rt_sigsuspend/Makefile
 @@ -19,4 +19,7 @@
  top_srcdir?= ../../../..
  
@@ -38,6 +44,3 @@ index 37bc3a9..2ca7f7c 100644
 +CFLAGS+= -D_GNU_SOURCE
 +
  include $(top_srcdir)/include/mk/generic_leaf_target.mk
--- 
-2.7.0
-
-- 
2.12.0

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


Re: [OE-core] [PATCH] pinentry: update to 1.0.0

2017-03-17 Thread akuster808



On 03/17/2017 09:53 AM, Burton, Ross wrote:


On 14 March 2017 at 02:39, Armin Kuster > wrote:


add pkg-config support for libassuan and gpg-error
updated config options


This didn't quite make M3
Didn't expect it make it in. My intend was for 
master-to-exclude-2.3-changes branch.
so strictly speaking upgrades have to wait.  Can you backport the 
fixes to 0.9.2,
geez, you are making me think now. I don't recall if there where any 
issues with 0.9.2 building. I am traveling and wont have a chance to 
look into it for a day or two.
or is there a sufficiently good reason to make an exception for the 
1.0 upgrade?

nope. Finally sat down to hammer out the update.

thanks for getting back to me.

kind regards,
Armin


Ross


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


Re: [OE-core] [PATCH] pinentry: update to 1.0.0

2017-03-17 Thread Burton, Ross
On 17 March 2017 at 17:52, akuster808  wrote:

> Didn't expect it make it in. My intend was for
> master-to-exclude-2.3-changes branch.
>

Cool, good to know.  It can be the inaugural patch in ross/later. :)

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


[OE-core] [PATCH] image_types_wic.bbclass: tighten dependency to help do_rm_work_all

2017-03-17 Thread Patrick Ohly
Depending on wic-tools:do_build pulls a lot of additional, indirect
dependencies into the image sysroot during do_image_wic as soon as
rm_work.bbclass is active, because then we have
do_build->do_rm_work_all->[all dependencies]. One of those
dependencies is libgcc-initial, which clashes with libgcc itself,
leading to errors in extend_recipe_sysroot like this:

   Exception: FileExistsError: [Errno 17] File exists: 
'.../tmp/sysroots-components/corei7-64/glibc-initial/usr/include/fstab.h' -> 
'.../tmp/work/intel_corei7_64-poky-linux/core-image-minimal/1.0-r0/recipe-sysroot/usr/include/fstab.h'

As the image recipe only needs the sysroot of wic-tools and does not
need to wait for the build of wic-tools to finish, depending on
do_populate_sysroot is the better choice and happens to avoid
the problem above.

Signed-off-by: Patrick Ohly 
---
 meta/classes/image_types_wic.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/image_types_wic.bbclass 
b/meta/classes/image_types_wic.bbclass
index 500c8c5653e..4711c24593b 100644
--- a/meta/classes/image_types_wic.bbclass
+++ b/meta/classes/image_types_wic.bbclass
@@ -39,7 +39,7 @@ IMAGE_CMD_wic[vardepsexclude] = "WKS_FULL_PATH WKS_FILES"
 USING_WIC = "${@bb.utils.contains_any('IMAGE_FSTYPES', 'wic ' + ' 
'.join('wic.%s' % c for c in '${CONVERSIONTYPES}'.split()), '1', '', d)}"
 WKS_FILE_CHECKSUM = "${@'${WKS_FULL_PATH}:%s' % 
os.path.exists('${WKS_FULL_PATH}') if '${USING_WIC}' else ''}"
 do_image_wic[file-checksums] += "${WKS_FILE_CHECKSUM}"
-do_image_wic[depends] += "wic-tools:do_build"
+do_image_wic[depends] += "wic-tools:do_populate_sysroot"
 WKS_FILE_DEPENDS ??= ''
 DEPENDS += "${@ '${WKS_FILE_DEPENDS}' if d.getVar('USING_WIC') else '' }"
 
-- 
2.11.0

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


[OE-core] [PATCH 0/1] gen-lockedsig-cache: catch os.link error V2

2017-03-17 Thread brian avery
If your sstate-cache directory is on a different filesystem from the one your 
build is on, gen-lockedsig-cache fails which causes the esdk creation to fail. 
This catches the hard link failure and does a copy in those cases.

This is a V2 because I took a copy/paste shortcut when I sent in the last one 
and that went as well as I should have expected. This one is sent from the 
machine it was tested on... My bad :(.

-brian


The following changes since commit 7e0985bab68547f946163828a16beab7542fca2e:

  nativesdk-packagegroup-sdk-host.bb: add cmake (2017-03-17 16:53:06 +)

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib bavery/gen-sigs-linkfix
  
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=bavery/gen-sigs-linkfix

brian avery (1):
  gen-lockedsig-cache: catch os.link error

 scripts/gen-lockedsig-cache | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

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


[OE-core] [PATCH 1/1] gen-lockedsig-cache: catch os.link error V2

2017-03-17 Thread brian avery
We do a hard link to speed up sdk creation but if your sstate-cache is
across a file system boundary, this tries and fails. This patch catches
that error and does a copy instead.

Signed-off-by: brian avery 
---
 scripts/gen-lockedsig-cache | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/scripts/gen-lockedsig-cache b/scripts/gen-lockedsig-cache
index 49de74ed..6765891 100755
--- a/scripts/gen-lockedsig-cache
+++ b/scripts/gen-lockedsig-cache
@@ -62,7 +62,11 @@ for f in files:
 os.remove(dst)
 if (os.stat(src).st_dev == os.stat(destdir).st_dev):
 print('linking')
-os.link(src, dst)
+try:
+os.link(src, dst)
+except OSError as e:
+print('hard linking failed, copying')
+shutil.copyfile(src, dst)
 else:
 print('copying')
 shutil.copyfile(src, dst)
--
2.7.4
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH 0/1] gen-lockedsig-cache: catch os.link error V2

2017-03-17 Thread Peter Kjellerstedt
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> brian avery
> Sent: den 17 mars 2017 13:50
> To: openembedded-core@lists.openembedded.org
> Subject: [OE-core] [PATCH 0/1] gen-lockedsig-cache: catch os.link error V2
> 
> If your sstate-cache directory is on a different filesystem from the
> one your build is on, gen-lockedsig-cache fails which causes the esdk
> creation to fail. This catches the hard link failure and does a copy in
> those cases.
> 
> This is a V2 because I took a copy/paste shortcut when I sent in the
> last one and that went as well as I should have expected. This one is
> sent from the machine it was tested on... My bad :(.

Do not make the "V2" part of the subject, make it part of the PATCH 
prefix, e.g.:

  [PATCH v2 0/1] gen-lockedsig-cache: catch os.link error

Otherwise it will become part of the commit message where it does not 
make any sense (since there obviously is no V1 committed...)

> -brian

//Peter

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


[OE-core] Confusion regarding the image feature ssh-server-openssh and what it pulls in

2017-03-17 Thread Peter Kjellerstedt
How come an image feature with a name like ssh-server-openssh has the 
following chain of dependencies:

FEATURE_PACKAGES_ssh-server-openssh ->
  packagegroup-core-ssh-openssh ->
openssh ->
  openssh-scp
  openssh-ssh
  openssh-sshd ->
openssh-keygen
  openssh-keygen

rather than:

FEATURE_PACKAGES_ssh-server-openssh ->
  openssh-sshd ->
openssh-keygen

The name clearly suggests that using it will install an SSH server, 
not also the client tools (scp and ssh).

Would a patch to change the FEATURE_PACKAGES_ssh-server-openssh to 
do the right thing and depend on openssh-sshd instead be accepted?

//Peter

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


[OE-core] [PATCH] python-3.3-multilib.patch: Fixes getpath on multilib configurations

2017-03-17 Thread Jose Lamego
When using multilib configurations either on arm/arm64 and x86/x86-64
python3 failed to execute due to a failure when looking for its
platform independent and dependent libraries.

This patch fixes this issue by assigning lib_python to the appropriate
macro.

[YOCTO #10812]

Signed-off-by: Alejandro Hernandez 
Signed-off-by: Jose Lamego 
---
 .../python/python3/python-3.3-multilib.patch| 17 +
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/meta/recipes-devtools/python/python3/python-3.3-multilib.patch 
b/meta/recipes-devtools/python/python3/python-3.3-multilib.patch
index 056e8e7..8601903 100644
--- a/meta/recipes-devtools/python/python3/python-3.3-multilib.patch
+++ b/meta/recipes-devtools/python/python3/python-3.3-multilib.patch
@@ -138,6 +138,15 @@ Index: Python-3.5.2/Modules/getpath.c
  
  /* Get file status. Encode the path to the locale encoding. */
  
+@@ -494,7 +502,7 @@ calculate_path(void)
+ _pythonpath = Py_DecodeLocale(PYTHONPATH, NULL);
+ _prefix = Py_DecodeLocale(PREFIX, NULL);
+ _exec_prefix = Py_DecodeLocale(EXEC_PREFIX, NULL);
+-lib_python = Py_DecodeLocale("lib/python" VERSION, NULL);
++lib_python = Py_DecodeLocale(LIB_PYTHON, NULL);
+ 
+ if (!_pythonpath || !_prefix || !_exec_prefix || !lib_python) {
+ Py_FatalError(
 Index: Python-3.5.2/Python/getplatform.c
 ===
 --- Python-3.5.2.orig/Python/getplatform.c
@@ -185,7 +194,7 @@ Index: Python-3.5.2/setup.py
 ===
 --- Python-3.5.2.orig/setup.py
 +++ Python-3.5.2/setup.py
-@@ -492,7 +492,7 @@ class PyBuildExt(build_ext):
+@@ -495,7 +495,7 @@ class PyBuildExt(build_ext):
  # directories (i.e. '.' and 'Include') must be first.  See issue
  # 10520.
  if not cross_compiling:
@@ -194,7 +203,7 @@ Index: Python-3.5.2/setup.py
  add_dir_to_list(self.compiler.include_dirs, '/usr/local/include')
  # only change this for cross builds for 3.3, issues on Mageia
  if cross_compiling:
-@@ -550,8 +550,7 @@ class PyBuildExt(build_ext):
+@@ -553,8 +553,7 @@ class PyBuildExt(build_ext):
  # be assumed that no additional -I,-L directives are needed.
  if not cross_compiling:
  lib_dirs = self.compiler.library_dirs + [
@@ -204,7 +213,7 @@ Index: Python-3.5.2/setup.py
  ]
  inc_dirs = self.compiler.include_dirs + ['/usr/include']
  else:
-@@ -743,11 +742,11 @@ class PyBuildExt(build_ext):
+@@ -746,11 +745,11 @@ class PyBuildExt(build_ext):
  elif curses_library:
  readline_libs.append(curses_library)
  elif self.compiler.find_library_file(lib_dirs +
@@ -268,7 +277,7 @@ Index: Python-3.5.2/configure.ac
 ===
 --- Python-3.5.2.orig/configure.ac
 +++ Python-3.5.2/configure.ac
-@@ -876,6 +876,41 @@ PLATDIR=plat-$MACHDEP
+@@ -883,6 +883,41 @@ PLATDIR=plat-$MACHDEP
  AC_SUBST(PLATDIR)
  AC_SUBST(PLATFORM_TRIPLET)
  
-- 
1.8.3.1

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


Re: [OE-core] [PATCH] file: update SRCREV for 5.30 to fix fetch fail on missing commit

2017-03-17 Thread Denys Dmytriyenko
We would need to do the same for past releases - morty/5.28, krogoth/5.25, 
jethro/5.24...


On Thu, Mar 16, 2017 at 02:42:14PM -0400, Paul Gortmaker wrote:
> Machines that cloned a while ago will have the commit, but new
> deployments won't because it seems the upstream changed/rebased
> and the old commit ID has been garbage-collected away.  Hence
> the fetch fails to check out the named commit ID.
> 
> Both the old (gone) commit, and the "new" commit show the same
> dates and commit log and point at 5.30, so hopefully this is
> the right thing to do.  A git diff of the two seems to only show
> a blanket uprev of CVS tags and deletion of a couple autogen'd
> files, and no real source changes.
> 
> Cc: Christos Zoulas 
> Signed-off-by: Paul Gortmaker 
> 
> diff --git a/meta/recipes-devtools/file/file_5.30.bb 
> b/meta/recipes-devtools/file/file_5.30.bb
> index 0998fcfa8990..112bf105781e 100644
> --- a/meta/recipes-devtools/file/file_5.30.bb
> +++ b/meta/recipes-devtools/file/file_5.30.bb
> @@ -19,7 +19,7 @@ SRC_URI = "git://github.com/file/file.git \
>  file://0001-Add-P-prompt-into-Usage-info.patch \
>  "
>  
> -SRCREV = "79814950aafb81ecd6a910c2a8a3b8ec12f3e4a6"
> +SRCREV = "3050419355566d2a96c5be97fef0ffae097bbb96"
>  S = "${WORKDIR}/git"
>  
>  inherit autotools
> -- 
> 2.11.1
> 
> -- 
> ___
> 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] [morty][PATCH] file: update SRCREV for 5.28 to fix fetch fail on missing commit

2017-03-17 Thread Denys Dmytriyenko
From: Paul Gortmaker 

Machines that cloned a while ago will have the commit, but new
deployments won't because it seems the upstream changed/rebased
and the old commit ID has been garbage-collected away.  Hence
the fetch fails to check out the named commit ID.

Both the old (gone) commit, and the "new" commit show the same
dates and commit log and point at 5.28, so hopefully this is
the right thing to do.  A git diff of the two seems to only show
a blanket uprev of CVS tags and deletion of a couple autogen'd
files, and no real source changes.

(From OE-Core rev: adb71e06768adadda7b69c3b5e81ca3ad67237f4)

Cc: Christos Zoulas 
Signed-off-by: Paul Gortmaker 
Signed-off-by: Richard Purdie 
Signed-off-by: Denys Dmytriyenko 
---
 meta/recipes-devtools/file/file_5.28.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/file/file_5.28.bb 
b/meta/recipes-devtools/file/file_5.28.bb
index e64a89c..048fb8e 100644
--- a/meta/recipes-devtools/file/file_5.28.bb
+++ b/meta/recipes-devtools/file/file_5.28.bb
@@ -19,7 +19,7 @@ SRC_URI = "git://github.com/file/file.git \
 file://0001-Add-P-prompt-into-Usage-info.patch \
 "
 
-SRCREV = "3c521817322a6bf5160cfeb09b9145ccde587b2a"
+SRCREV = "acbaf156236cbc54b3cf3bc6cbf05d80cb196451"
 S = "${WORKDIR}/git"
 
 inherit autotools
-- 
2.7.4

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


[OE-core] [krogoth][PATCH] file: update SRCREV for 5.25 to fix fetch fail on missing commit

2017-03-17 Thread Denys Dmytriyenko
From: Paul Gortmaker 

Machines that cloned a while ago will have the commit, but new
deployments won't because it seems the upstream changed/rebased
and the old commit ID has been garbage-collected away.  Hence
the fetch fails to check out the named commit ID.

Both the old (gone) commit, and the "new" commit show the same
dates and commit log and point at 5.25, so hopefully this is
the right thing to do.  A git diff of the two seems to only show
a blanket uprev of CVS tags and deletion of a couple autogen'd
files, and no real source changes.

(From OE-Core rev: adb71e06768adadda7b69c3b5e81ca3ad67237f4)

Cc: Christos Zoulas 
Signed-off-by: Paul Gortmaker 
Signed-off-by: Richard Purdie 
Signed-off-by: Denys Dmytriyenko 
---
 meta/recipes-devtools/file/file_5.25.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/file/file_5.25.bb 
b/meta/recipes-devtools/file/file_5.25.bb
index 68bad69..f89931c 100644
--- a/meta/recipes-devtools/file/file_5.25.bb
+++ b/meta/recipes-devtools/file/file_5.25.bb
@@ -20,7 +20,7 @@ SRC_URI = "git://github.com/file/file.git \
 file://host-file.patch \
 "
 
-SRCREV = "f45db89ddc91692b662fffbabbdafc7bc4c00f5e"
+SRCREV = "789cfc7d727cee1c7cfb7d29c09162e2399285c5"
 S = "${WORKDIR}/git"
 
 inherit autotools
-- 
2.7.4

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


[OE-core] Hints on submitting to OE-Core

2017-03-17 Thread Daniel Dickinson
Hi all,

I've got a pre-alpha 'distro' and some layers I think that could get to
an interesting state.  The intent is to work them up to where they are
suitable to be submitted as patches to oe-core rather than the
current .bbappend and related files.

There's rather a lot of reading (which is good in the sense that I like
actually have documentation, although that's definitely an area I need
to improve on for the layers I've got in the works), and I haven't
nearly got through it all yet, but I was hoping for pointers on the
most important bits to read for prepping patches submission.

Also, in the layers list I'll be asking about some build issues that I
don't see with a manual bitbake, that look like missing preqs on a build
server, unless the layer should be requesting installation of host files
somewhere.

Regards,

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


Re: [OE-core] Hints on submitting to OE-Core

2017-03-17 Thread Gary Thomas

On 2017-03-18 00:55, Daniel Dickinson wrote:

Hi all,

I've got a pre-alpha 'distro' and some layers I think that could get to
an interesting state.  The intent is to work them up to where they are
suitable to be submitted as patches to oe-core rather than the
current .bbappend and related files.

There's rather a lot of reading (which is good in the sense that I like
actually have documentation, although that's definitely an area I need
to improve on for the layers I've got in the works), and I haven't
nearly got through it all yet, but I was hoping for pointers on the
most important bits to read for prepping patches submission.


Have you read this?
  http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded



Also, in the layers list I'll be asking about some build issues that I
don't see with a manual bitbake, that look like missing preqs on a build
server, unless the layer should be requesting installation of host files
somewhere.


Some tools required by ${HOSTTOOLS} are missing:
  cpio chrpath gawk diffstat makeinfo

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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


Re: [OE-core] Hints on submitting to OE-Core

2017-03-17 Thread Daniel Dickinson
On Sat, 18 Mar 2017 02:21:30 +0100
Gary Thomas  wrote:

> 
> Have you read this?
>http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded

I hadn't read in detail yet (I've seen similar before and from
skimming, it's about mechanics of the process), but I was looking more
in terms of coding and/or style guidelines for the meat of the patch,
and/or hints/tips on getting things accepted from the point of view of
things other than mechanics of patch submission.
 
> >
> > Also, in the layers list I'll be asking about some build issues
> > that I don't see with a manual bitbake, that look like missing
> > preqs on a build server, unless the layer should be requesting
> > installation of host files somewhere.  
> 
> Some tools required by ${HOSTTOOLS} are missing:
>cpio chrpath gawk diffstat makeinfo

As mentioned these are openembedded.org autobuilds of submitted layers,
so I was kind of hoping there were something I could change in the
layer to make it work.  I guess the build host or chroot is missing
packges.

Regards,

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


Re: [OE-core] Hints on submitting to OE-Core

2017-03-17 Thread Khem Raj


On 3/17/17 6:38 PM, Daniel Dickinson wrote:
> On Sat, 18 Mar 2017 02:21:30 +0100
> Gary Thomas  wrote:
> 
>>
>> Have you read this?
>>http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded
> 
> I hadn't read in detail yet (I've seen similar before and from
> skimming, it's about mechanics of the process), but I was looking more
> in terms of coding and/or style guidelines for the meat of the patch,
> and/or hints/tips on getting things accepted from the point of view of
> things other than mechanics of patch submission.

If you read through that link Gary pointed, there are links to two other
documents one of style and other one patch message guidelines

there is styling scripts for metadata files, you could use that
https://github.com/openembedded/meta-openembedded/blob/master/contrib/oe-stylize.py

As of meat of patch, if its fixing something and you are articulate to
explain it in your commit message and in general review cycle, you have
a better chance of getting it accepted, but you have to start submitting

>  
>>>
>>> Also, in the layers list I'll be asking about some build issues
>>> that I don't see with a manual bitbake, that look like missing
>>> preqs on a build server, unless the layer should be requesting
>>> installation of host files somewhere.  
>>
>> Some tools required by ${HOSTTOOLS} are missing:
>>cpio chrpath gawk diffstat makeinfo
> 
> As mentioned these are openembedded.org autobuilds of submitted layers,
> so I was kind of hoping there were something I could change in the
> layer to make it work.  I guess the build host or chroot is missing
> packges.
> 
> Regards,
> 
> Daniel
> 



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


Re: [OE-core] Hints on submitting to OE-Core

2017-03-17 Thread Daniel Dickinson
On Fri, 17 Mar 2017 19:17:36 -0700
Khem Raj  wrote:

> On 3/17/17 6:38 PM, Daniel Dickinson wrote:
> > On Sat, 18 Mar 2017 02:21:30 +0100
> > Gary Thomas  wrote:
> >   
> >>
> >> Have you read this?
> >>http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded  
> > 
> > I hadn't read in detail yet (I've seen similar before and from
> > skimming, it's about mechanics of the process), but I was looking
> > more in terms of coding and/or style guidelines for the meat of the
> > patch, and/or hints/tips on getting things accepted from the point
> > of view of things other than mechanics of patch submission.  
> 
> If you read through that link Gary pointed, there are links to two
> other documents one of style and other one patch message guidelines
> 

Ah, missed that on initial perusal, thank you.

> there is styling scripts for metadata files, you could use that
> https://github.com/openembedded/meta-openembedded/blob/master/contrib/oe-stylize.py


Will use thatt.

> As of meat of patch, if its fixing something and you are articulate to
> explain it in your commit message and in general review cycle, you
> have a better chance of getting it accepted, but you have to start
> submitting

I'm kind of hoping to get some feedback on the meta-runit-init, and
meta-earlyinit layers I've submitted to the layers listing (and to find
things I've missed) (perhaps as well as meta-cshored, but I don't think
there is as much there that's as likely to be generally useful) before
looking at working on getting them integrated into core.  Of course it
helps if the layers listing doesn't show builds failing (in this case
not because of an error on my part).

Regards,

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