[OE-core] [PATCH] matchbox-session-sato: Make the battery applet depend on machine features

2018-05-02 Thread Jaewon Lee
From: Eran Matityahu 

matchbox-panel enables the battery plugin only if the
acpi/apm machine features are enabled,
so enable the battery applet in the session script
under the same conditions.

This avoids the 'Failed to load applet "battery"' warning at runtime,
in case these machine features are not defined.

Signed-off-by: Eran Matityahu 
---
 meta/recipes-sato/matchbox-sato/matchbox-session-sato/session | 5 -
 meta/recipes-sato/matchbox-sato/matchbox-session-sato_0.1.bb  | 2 +-
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-sato/matchbox-sato/matchbox-session-sato/session 
b/meta/recipes-sato/matchbox-sato/matchbox-session-sato/session
index f6313bd..3a70574 100644
--- a/meta/recipes-sato/matchbox-sato/matchbox-session-sato/session
+++ b/meta/recipes-sato/matchbox-sato/matchbox-session-sato/session
@@ -20,7 +20,10 @@ matchbox-desktop &
 # doesn't have the feature "foo".

 START_APPLETS=showdesktop,windowselector
-END_APPLETS=clock,battery,$KEYBOARD_APPLET,systray,startup-notify,notify
+END_APPLETS=$KEYBOARD_APPLET,systray,startup-notify,notify
+END_APPLETS=battery,$END_APPLETS # feature-acpi
+END_APPLETS=battery,$END_APPLETS # feature-apm
+END_APPLETS=clock,$END_APPLETS
 END_APPLETS=openmoko-panel-gsm,$END_APPLETS # feature-phone

 matchbox-panel --start-applets $START_APPLETS --end-applets $END_APPLETS &
diff --git a/meta/recipes-sato/matchbox-sato/matchbox-session-sato_0.1.bb 
b/meta/recipes-sato/matchbox-sato/matchbox-session-sato_0.1.bb
index d146e83..8230e95 100644
--- a/meta/recipes-sato/matchbox-sato/matchbox-session-sato_0.1.bb
+++ b/meta/recipes-sato/matchbox-sato/matchbox-session-sato_0.1.bb
@@ -26,7 +26,7 @@ FILES_${PN} += "${datadir}/themes/Sato/index.theme"

 do_install() {
# This is the set of machine features that the script has markers for
-   FEATURES="phone"
+   FEATURES="acpi apm phone"
SCRIPT="${S}/sedder"
rm -f $SCRIPT
touch $SCRIPT
--
2.7.4

This email and any attachments are intended for the sole use of the named 
recipient(s) and contain(s) confidential information that may be proprietary, 
privileged or copyrighted under applicable law. If you are not the intended 
recipient, do not read, copy, or forward this email message or any attachments. 
Delete this email message and any attachments immediately.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH] devtool-source.bbclass: Support kernel fragments not in SRC_URI

2018-07-30 Thread Jaewon Lee
When using a recipe space kernel-meta, scc files are added through
SRC_URI, but they may include corresponding kernel fragments that are
not necessarily in SRC_URI.

For bitbake, this is not a problem because the kernel-yocto class adds
the path where the .scc file was found to includes which consequentially
makes the .cfg file available to the kernel build.

However, when using devtool, only files specified in SRC_URI are copied
to oe-local-files in devtool's workspace. So if the cfg file is not in
SRC_URI, it won't be copied, causing a kernel build failure when trying
to find it.

This fix parses local .scc files in SRC_URI, copies the corresponding .cfg
file to devtool's workdir, and also adds it to local_files so it is
available when doing a devtool build for the kernel.

[YOCTO #12858]

Signed-off-by: Jaewon Lee 
Signed-off-by: Alejandro Enedino Hernandez Samaniego 
---
 meta/classes/devtool-source.bbclass | 12 
 1 file changed, 12 insertions(+)

diff --git a/meta/classes/devtool-source.bbclass 
b/meta/classes/devtool-source.bbclass
index 56882a4..c70fea2 100644
--- a/meta/classes/devtool-source.bbclass
+++ b/meta/classes/devtool-source.bbclass
@@ -90,11 +90,23 @@ python devtool_post_unpack() {
 fname in files])
 return ret
 
+is_kernel_yocto = bb.data.inherits_class('kernel-yocto', d)
 # Move local source files into separate subdir
 recipe_patches = [os.path.basename(patch) for patch in
 oe.recipeutils.get_recipe_patches(d)]
 local_files = oe.recipeutils.get_recipe_local_files(d)
 
+if is_kernel_yocto:
+  for key in local_files.copy():
+if key.endswith('scc'):
+  sccfile = open(local_files[key], 'r')
+  for l in sccfile:
+line = l.split()
+if line and line[0] == 'kconf' and line[-1].endswith('.cfg'):
+  local_files[line[-1]] = 
os.path.join(os.path.dirname(local_files[key]), line[-1])
+  shutil.copy2(os.path.join(os.path.dirname(local_files[key]), 
line[-1]), workdir)
+  sccfile.close()
+
 # Ignore local files with subdir={BP}
 srcabspath = os.path.abspath(srcsubdir)
 local_files = [fname for fname in local_files if
-- 
2.7.4

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


[OE-core] [PATCH] kernel-yocto.bbclass: Adds oe-local-files path (devtool) to include directives

2018-07-30 Thread Jaewon Lee
The devtool-source class moves all local files specified in SRC_URI to
an oe-local-files directory. When using devtool and a recipe space kernel-meta,
devtool modify throws an error because the paths the kernel-yocto class
is looking for feature directories in, don't include the oe-local-files
directory which devtool is using.

This patch checks for feature directories in oe-local-files,
and if present, adds that path to include directives.

[YOCTO #12855]

Signed-off-by: Jaewon Lee 
Signed-off-by: Alejandro Enedino Hernandez Samaniego 
---
 meta/classes/kernel-yocto.bbclass | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/classes/kernel-yocto.bbclass 
b/meta/classes/kernel-yocto.bbclass
index 82d8074..077a1ab 100644
--- a/meta/classes/kernel-yocto.bbclass
+++ b/meta/classes/kernel-yocto.bbclass
@@ -140,6 +140,8 @@ do_kernel_metadata() {
includes="$includes -I${WORKDIR}/$f/kernel-meta"
elif [ -d "${WORKDIR}/$f" ]; then
includes="$includes -I${WORKDIR}/$f"
+   elif [ -d "${WORKDIR}/../oe-local-files/$f" ]; then
+   includes="$includes -I${WORKDIR}/../oe-local-files/$f"
fi
done
for s in ${sccs} ${patches}; do
-- 
2.7.4

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


[OE-core] [PATCH v2] devtool-source.bbclass: Support kernel-fragments/patch not in SRC_URI

2018-08-01 Thread Jaewon Lee
When using a recipe space kernel-meta, scc files are added through
SRC_URI, but they may include corresponding kernel fragments or patches
that are not necessarily in SRC_URI.

For bitbake, this is not a problem because the kernel-yocto class adds
the path where the .scc file was found to includes which consequentially
makes the .cfg, .patch file available to the kernel build.

However, when using devtool, only files specified in SRC_URI are copied
to oe-local-files in devtool's workspace. So if the cfg/patch file is not in
SRC_URI, it won't be copied, causing a kernel build failure when trying
to find it.

This fix parses local .scc files in SRC_URI, copies the corresponding
.cfg/.patch file to devtool's workdir, and also adds it to local_files
so it is available when doing a devtool build for the kernel.

[YOCTO #12858]

Signed-off-by: Jaewon Lee 
Signed-off-by: Alejandro Enedino Hernandez Samaniego 
---
 meta/classes/devtool-source.bbclass | 12 
 1 file changed, 12 insertions(+)

diff --git a/meta/classes/devtool-source.bbclass 
b/meta/classes/devtool-source.bbclass
index 56882a4..623b335 100644
--- a/meta/classes/devtool-source.bbclass
+++ b/meta/classes/devtool-source.bbclass
@@ -90,11 +90,23 @@ python devtool_post_unpack() {
 fname in files])
 return ret
 
+is_kernel_yocto = bb.data.inherits_class('kernel-yocto', d)
 # Move local source files into separate subdir
 recipe_patches = [os.path.basename(patch) for patch in
 oe.recipeutils.get_recipe_patches(d)]
 local_files = oe.recipeutils.get_recipe_local_files(d)
 
+if is_kernel_yocto:
+  for key in local_files.copy():
+if key.endswith('scc'):
+  sccfile = open(local_files[key], 'r')
+  for l in sccfile:
+line = l.split()
+if line and line[0] in ('kconf', 'patch'):
+  local_files[line[-1]] = 
os.path.join(os.path.dirname(local_files[key]), line[-1])
+  shutil.copy2(os.path.join(os.path.dirname(local_files[key]), 
line[-1]), workdir)
+  sccfile.close()
+
 # Ignore local files with subdir={BP}
 srcabspath = os.path.abspath(srcsubdir)
 local_files = [fname for fname in local_files if
-- 
2.7.4

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


Re: [OE-core] [PATCH] devicetree.bbclass: User/BSP device tree source compilation class

2018-08-06 Thread Jaewon Lee
Hi Nathan, 

What do you think about adding support for dts include files as well (.dtsi)?

Thanks,
Jaewon
 

-Original Message-
From: openembedded-core-boun...@lists.openembedded.org 
[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Nathan 
Rossi
Sent: Thursday, August 2, 2018 1:55 AM
To: openembedded-core@lists.openembedded.org
Subject: [OE-core] [PATCH] devicetree.bbclass: User/BSP device tree source 
compilation class

This bbclass implements the device tree compilation for user provided device 
trees. In order to use this class, it should be inherited in a BSP recipe which 
provides the sources. The default setup enables inclusion of kernel device tree 
sources (though can be disabled by the recipe by overriding DT_INCLUDE or 
KERNEL_INCLUDE).

This provides an additional mechanism for BSPs to provide device trees and 
device tree overlays for their target machines. Whilst still enabling access to 
the kernel device trees for base SoC includes and headers.

This approach to providing device trees has benefits for certain use cases over 
patching the device trees into the kernel source.

* device trees are separated from kernel source, allows for selection of kernel 
and or kernel versions without needing to explicitly patch the kernel (or 
appending to the kernel recipes).

* providing device trees from separate sources, from the layer, generated by 
the recipe or other recipes.

This class also implements some additional features that are not available in 
the kernel-devicetree flow. This includes population of device tree blobs into 
the sysroot which allows for other recipes to consume built dtbs (e.g. U-Boot 
with EXT_DTB compilation), device tree overlay compilation and customizing DTC 
compilation args (boot cpu/padding/etc.).

Signed-off-by: Nathan Rossi 
Acked-by: Martin Hundebøll 
---
In addition to this patch I have written some documentation for the Yocto BSP 
guide that covers details about both methods.

The meta-xilinx layer has a recipe (device-tree.bb) that behaves exactly like 
this class for some time. It has been very useful for out-of-kernel device tree 
compilation as well as for a mechanism so that users of Xilinx SoCs can provide 
their customizations (FPGA devices) and board specific configuration. This 
compilation flow also makes sense for other BSPs, which is the reason for 
creating this bbclass for common shared use by other BSPs.

Examples of this classes usage can be seen for meta-xilinx:
https://github.com/nathanrossi/meta-xilinx/blob/nrossi/devicetree-classify/meta-xilinx-bsp/recipes-bsp/device-tree/device-tree.bb
---
 meta/classes/devicetree.bbclass | 140 
 1 file changed, 140 insertions(+)
 create mode 100644 meta/classes/devicetree.bbclass

diff --git a/meta/classes/devicetree.bbclass b/meta/classes/devicetree.bbclass 
new file mode 100644 index 00..dbc83f2a1d
--- /dev/null
+++ b/meta/classes/devicetree.bbclass
@@ -0,0 +1,140 @@
+# This bbclass implements device tree compliation for user provided 
+device tree # sources. The compilation of the device tree sources is 
+the same as the kernel # device tree compilation process, this includes 
+being able to include sources # from the kernel such as soc dtsi files 
+or header files such as gpio.h. In # addition to device trees this 
+bbclass also handles compilation of device tree # overlays.
+#
+# The output of this class behaves similar to how 
+kernel-devicetree.bbclass # operates in that the output files are installed 
into /boot/devicetree.
+# However this class on purpose separates the deployed device trees 
+into the # 'devicetree' subdirectory. This prevents clashes with the 
+kernel-devicetree # output. Additionally the device trees are populated 
+into the sysroot for # access via the sysroot from within other recipes.
+
+SECTION ?= "bsp"
+
+# The default inclusion of kernel device tree includes and headers 
+means that # device trees built with them are at least GPLv2 (and in 
+some cases dual # licensed). Default to GPLv2 if the recipe does not specify a 
license.
+LICENSE ?= "GPLv2"
+LIC_FILES_CHKSUM ?= 
"file://${COMMON_LICENSE_DIR}/GPL-2.0;md5=801f80980d171dd6425610833a22dbe6"
+
+INHIBIT_DEFAULT_DEPS = "1"
+DEPENDS += "dtc-native"
+
+inherit deploy kernel-arch
+
+COMPATIBLE_MACHINE ?= "^$"
+
+PACKAGE_ARCH = "${MACHINE_ARCH}"
+
+SYSROOT_DIRS += "/boot/devicetree"
+FILES_${PN} = "/boot/devicetree/*.dtb /boot/devicetree/*.dtbo"
+
+S = "${WORKDIR}"
+B = "${WORKDIR}/build"
+
+# Default kernel includes, these represent what are normally used for 
+in-kernel # sources.
+KERNEL_INCLUDE ??= " \
+${STAGING_KERNEL_DIR}/arch/${ARCH}/boot/dts \
+${STAGING_KERNEL_DIR}/arch/${ARCH}/boot/dts/* \
+${STAGING_KERNEL_DIR}/scripts/dtc/include-prefixes \
+"
+
+DT_INCLUDE[doc] = "Search paths to be made available to both the device tree 
compiler and preprocessor for inclusion."
+DT_INCLUDE ?= "${DT_FILES_PATH} 

Re: [OE-core] [PATCH] devicetree.bbclass: User/BSP device tree source compilation class

2018-08-07 Thread Jaewon Lee


Hi Nathan,


On 08/07/2018 04:59 AM, Nathan Rossi wrote:

On 7 August 2018 at 07:16, Jaewon Lee  wrote:

Hi Nathan,

What do you think about adding support for dts include files as well (.dtsi)?

Hi Jaewon,

Device tree include files already work with the implementation in this
patch. The default include path is the same as the path of the dts
files, so if you use "/include/ ".dtsi";" (dtc) or "#include
" (preprocessor) it will search within the DT_FILES_PATH
(which is WORKDIR by default) and then the KERNEL_INCLUDE paths.
Though if the dtsi is in another path you can add it to DT_INCLUDE,
and it will be searched.
If i'm understanding correctly, this flow just supports compiling a dts 
file that has a plugin tag (it can include dtsi files)

in short I can't compile the dtsi file itself to a dtbo

Does this cover the support you are after or is there another
configuration you would like it to support?
Yes for us, if dt overlays are enabled, we don't include a dtsi in the 
base dts and compile that dtsi separately as a dtbo which is loaded later.
so would be great to loop through all dtsi files as well and compile if 
it has a plugin tag.


Your thoughts?

Thanks,
Jaewon



Thanks,
Nathan


Thanks,
Jaewon


-Original Message-
From: openembedded-core-boun...@lists.openembedded.org 
[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Nathan 
Rossi
Sent: Thursday, August 2, 2018 1:55 AM
To: openembedded-core@lists.openembedded.org
Subject: [OE-core] [PATCH] devicetree.bbclass: User/BSP device tree source 
compilation class

This bbclass implements the device tree compilation for user provided device 
trees. In order to use this class, it should be inherited in a BSP recipe which 
provides the sources. The default setup enables inclusion of kernel device tree 
sources (though can be disabled by the recipe by overriding DT_INCLUDE or 
KERNEL_INCLUDE).

This provides an additional mechanism for BSPs to provide device trees and 
device tree overlays for their target machines. Whilst still enabling access to 
the kernel device trees for base SoC includes and headers.

This approach to providing device trees has benefits for certain use cases over 
patching the device trees into the kernel source.

* device trees are separated from kernel source, allows for selection of kernel 
and or kernel versions without needing to explicitly patch the kernel (or 
appending to the kernel recipes).

* providing device trees from separate sources, from the layer, generated by 
the recipe or other recipes.

This class also implements some additional features that are not available in 
the kernel-devicetree flow. This includes population of device tree blobs into 
the sysroot which allows for other recipes to consume built dtbs (e.g. U-Boot 
with EXT_DTB compilation), device tree overlay compilation and customizing DTC 
compilation args (boot cpu/padding/etc.).

Signed-off-by: Nathan Rossi 
Acked-by: Martin Hundebøll 
---
In addition to this patch I have written some documentation for the Yocto BSP 
guide that covers details about both methods.

The meta-xilinx layer has a recipe (device-tree.bb) that behaves exactly like 
this class for some time. It has been very useful for out-of-kernel device tree 
compilation as well as for a mechanism so that users of Xilinx SoCs can provide 
their customizations (FPGA devices) and board specific configuration. This 
compilation flow also makes sense for other BSPs, which is the reason for 
creating this bbclass for common shared use by other BSPs.

Examples of this classes usage can be seen for meta-xilinx:
https://github.com/nathanrossi/meta-xilinx/blob/nrossi/devicetree-classify/meta-xilinx-bsp/recipes-bsp/device-tree/device-tree.bb
---
  meta/classes/devicetree.bbclass | 140 
  1 file changed, 140 insertions(+)
  create mode 100644 meta/classes/devicetree.bbclass

diff --git a/meta/classes/devicetree.bbclass b/meta/classes/devicetree.bbclass 
new file mode 100644 index 00..dbc83f2a1d
--- /dev/null
+++ b/meta/classes/devicetree.bbclass
@@ -0,0 +1,140 @@
+# This bbclass implements device tree compliation for user provided
+device tree # sources. The compilation of the device tree sources is
+the same as the kernel # device tree compilation process, this includes
+being able to include sources # from the kernel such as soc dtsi files
+or header files such as gpio.h. In # addition to device trees this
+bbclass also handles compilation of device tree # overlays.
+#
+# The output of this class behaves similar to how
+kernel-devicetree.bbclass # operates in that the output files are installed 
into /boot/devicetree.
+# However this class on purpose separates the deployed device trees
+into the # 'devicetree' subdirectory. This prevents clashes with the
+kernel-devicetree # output. Additionally the device trees are populated
+into the sysroot for # access via the sysroot from within oth

[OE-core] [PATCH v3] devtool-source.bbclass: Support kernel-fragments/patch not in SRC_URI

2018-08-09 Thread Jaewon Lee
When using a recipe space kernel-meta, scc files are added through
SRC_URI, but they may include corresponding kernel fragments or patches
that are not necessarily in SRC_URI.

For bitbake, this is not a problem because the kernel-yocto class adds
the path where the .scc file was found to includes which consequentially
makes the .cfg, .patch file available to the kernel build.

However, when using devtool, only files specified in SRC_URI are copied
to oe-local-files in devtool's workspace. So if the cfg/patch file is not in
SRC_URI, it won't be copied, causing a kernel build failure when trying
to find it.

This fix parses local .scc files in SRC_URI, copies the corresponding
.cfg/.patch file to devtool's workdir, and also adds it to local_files
so it is available when doing a devtool build for the kernel.

[YOCTO #12858]

v2: also supporting patch not in SRC_URI
v3: fix spacing issues

Signed-off-by: Jaewon Lee 
Signed-off-by: Alejandro Enedino Hernandez Samaniego 
---
 meta/classes/devtool-source.bbclass | 12 
 1 file changed, 12 insertions(+)

diff --git a/meta/classes/devtool-source.bbclass 
b/meta/classes/devtool-source.bbclass
index 56882a4..67cd0ba 100644
--- a/meta/classes/devtool-source.bbclass
+++ b/meta/classes/devtool-source.bbclass
@@ -90,11 +90,23 @@ python devtool_post_unpack() {
 fname in files])
 return ret
 
+is_kernel_yocto = bb.data.inherits_class('kernel-yocto', d)
 # Move local source files into separate subdir
 recipe_patches = [os.path.basename(patch) for patch in
 oe.recipeutils.get_recipe_patches(d)]
 local_files = oe.recipeutils.get_recipe_local_files(d)
 
+if is_kernel_yocto:
+for key in local_files.copy():
+if key.endswith('scc'):
+sccfile = open(local_files[key], 'r')
+for l in sccfile:
+line = l.split()
+if line and line[0] in ('kconf', 'patch'):
+local_files[line[-1]] = 
os.path.join(os.path.dirname(local_files[key]), line[-1])
+
shutil.copy2(os.path.join(os.path.dirname(local_files[key]), line[-1]), workdir)
+sccfile.close()
+
 # Ignore local files with subdir={BP}
 srcabspath = os.path.abspath(srcsubdir)
 local_files = [fname for fname in local_files if
-- 
2.7.4

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


[OE-core] [oe-core][PATCH] gconf: fix saving of settings when config folder doesnt exist

2018-04-10 Thread Jaewon Lee
In some circumstances, gconf isn't able to save configurations
because ~/.config folder aka root_dir doesn't exist.

For example when saving settings using matchbox-appearance,
the following error is shown:

GConf Error: Configuration server couldn't be contacted: D-BUS error:
Can't overwrite existing read-only value: Value for
`/desktop/poky/interface/font_name' set in a read-only source at the
front of your configuration path

This issue was not seen before because ~/.config directory is shared
between several packages and one of those packages usually creates it
by the time gconf wants to use it.

This patch makes sure that gconf creates the .config directory if it
doesn't exist, along with the gconf directory inside it.

[YOCTO #12632]

Signed-off-by: Alejandro Hernandez <aleja...@xilinx.com>
Signed-off-by: Jaewon Lee <jaewon@xilinx.com>
---
 .../gnome/gconf/create_config_directory.patch  | 28 ++
 meta/recipes-gnome/gnome/gconf_3.2.6.bb|  1 +
 2 files changed, 29 insertions(+)
 create mode 100644 meta/recipes-gnome/gnome/gconf/create_config_directory.patch

diff --git a/meta/recipes-gnome/gnome/gconf/create_config_directory.patch 
b/meta/recipes-gnome/gnome/gconf/create_config_directory.patch
new file mode 100644
index 000..e02932c
--- /dev/null
+++ b/meta/recipes-gnome/gnome/gconf/create_config_directory.patch
@@ -0,0 +1,28 @@
+Upstream-Status: Pending
+
+In some circumstances, gconf isn't able to save configurations
+because ~/.config folder aka root_dir doesn't exist.
+This issue was not seen before because ~/.config directory is shared
+between several packages and one of those packages usually creates it
+by the time gconf wants to use it.
+
+This patch makes sure that gconf creates the .config directory if it
+doesn't exist, along with the gconf directory inside it.
+
+Signed-off-by: Jaewon Lee <jaewon@xilinx.com>
+Signed-off-by: Alejandro Hernandez <aleja...@xilinx.com>
+
+
+Index: GConf-3.2.6/backends/markup-backend.c
+===
+--- GConf-3.2.6.orig/backends/markup-backend.c
 GConf-3.2.6/backends/markup-backend.c
+@@ -276,7 +276,7 @@ resolve_address (const char *address,
+   /* dir_mode without search bits */
+   file_mode = dir_mode & (~0111);
+ }
+-  else if (g_mkdir (root_dir, dir_mode) < 0)
++  else if (g_mkdir_with_parents (root_dir, dir_mode) < 0)
+ {
+   /* Error out even on EEXIST - shouldn't happen anyway */
+   gconf_set_error (err, GCONF_ERROR_FAILED,
diff --git a/meta/recipes-gnome/gnome/gconf_3.2.6.bb 
b/meta/recipes-gnome/gnome/gconf_3.2.6.bb
index 92fd12c..120ae3e 100644
--- a/meta/recipes-gnome/gnome/gconf_3.2.6.bb
+++ b/meta/recipes-gnome/gnome/gconf_3.2.6.bb
@@ -11,6 +11,7 @@ inherit gnomebase gtk-doc gettext gobject-introspection 
gio-module-cache
 SRC_URI = 
"${GNOME_MIRROR}/GConf/${@gnome_verdir("${PV}")}/GConf-${PV}.tar.xz;name=archive
 \
file://remove_plus_from_invalid_characters_list.patch \
file://unable-connect-dbus.patch \
+   file://create_config_directory.patch \
 "

 SRC_URI[archive.md5sum] = "2b16996d0e4b112856ee5c59130e822c"
--
2.7.4

This email and any attachments are intended for the sole use of the named 
recipient(s) and contain(s) confidential information that may be proprietary, 
privileged or copyrighted under applicable law. If you are not the intended 
recipient, do not read, copy, or forward this email message or any attachments. 
Delete this email message and any attachments immediately.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH] device-tree.bbclass: Add support to compile overlays separately

2018-12-14 Thread Jaewon Lee
Currently only dts files are considered when looping through files to
compile. Modifying the loop to compile other files that are overlays.
Also surrounding this check with a try block as the function to find
overlays parses the file for a '/plugin/' tag, and there may be files in
the DT_FILES_PATH directory that are not parseable.

Signed-off-by: Jaewon Lee 
Signed-off-by: Alejandro Enedino Hernandez Samaniego 
Signed-off-by: Manjukumar Matha 
---
 meta/classes/devicetree.bbclass | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/meta/classes/devicetree.bbclass b/meta/classes/devicetree.bbclass
index 8fe5a5e..db10b86 100644
--- a/meta/classes/devicetree.bbclass
+++ b/meta/classes/devicetree.bbclass
@@ -120,9 +120,12 @@ python devicetree_do_compile() {
 includes = expand_includes("DT_INCLUDE", d)
 listpath = d.getVar("DT_FILES_PATH")
 for dts in os.listdir(listpath):
-if not dts.endswith(".dts"):
-continue # skip non-.dts files
 dtspath = os.path.join(listpath, dts)
+try:
+if not(os.path.isfile(dtspath)) or not(dts.endswith(".dts") or 
devicetree_source_is_overlay(dtspath)
+continue # skip non-.dts files and non-overlay files
+except:
+continue # skip if can't determine if overlay
 devicetree_compile(dtspath, includes, d)
 }
 
-- 
2.7.5

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


[OE-core] [PATCH] Support kmeta directory usage with devtool modify/finish

2018-12-14 Thread Jaewon Lee
When using Kmeta directories, devtool finish will add every single file
in the directory to the bbappend. This is because in the current
implementation, the get_recipe_local_files function treats the kmeta
directory like a file. Modifying the function to loop through the
provided directories and return all included files instead of just the
top level directory. This will enable correct file to file comparison
when determing which files are new/changed and need to be added to the
bbappend.

Adding an extra check in devtool-source.bbclass to not copy the cfg file
if its already included somewhere in the kmeta directory

Also during 'modify', when moving necessary files in the kmeta directory
from the workdir to oe-local-files, the dangling parent directories are
left behind.  This in itself is not an issue as the temporary devtool
workspace is automatically deleted, but this causes an incorrect include
directory to be added in kernel-yocto.bbclass.  Changing the order of
the if statements to catch the correct conditional. This is safe to do
as when not in the devtool context, there will be no oe-local-files
directory.

Signed-off-by: Jaewon Lee 
Signed-off-by: Alejandro Enedino Hernandez Samaniego 
---
 meta/classes/devtool-source.bbclass | 6 --
 meta/classes/kernel-yocto.bbclass   | 4 ++--
 meta/lib/oe/recipeutils.py  | 9 -
 3 files changed, 14 insertions(+), 5 deletions(-)

diff --git a/meta/classes/devtool-source.bbclass 
b/meta/classes/devtool-source.bbclass
index 1372e32..a811000 100644
--- a/meta/classes/devtool-source.bbclass
+++ b/meta/classes/devtool-source.bbclass
@@ -103,8 +103,10 @@ python devtool_post_unpack() {
 for l in sccfile:
 line = l.split()
 if line and line[0] in ('kconf', 'patch'):
-local_files[line[-1]] = 
os.path.join(os.path.dirname(local_files[key]), line[-1])
-
shutil.copy2(os.path.join(os.path.dirname(local_files[key]), line[-1]), workdir)
+cfg = os.path.join(os.path.dirname(local_files[key]), 
line[-1])
+if not cfg in local_files.values():
+local_files[line[-1]] = cfg
+shutil.copy2(cfg, workdir)
 sccfile.close()
 
 # Ignore local files with subdir={BP}
diff --git a/meta/classes/kernel-yocto.bbclass 
b/meta/classes/kernel-yocto.bbclass
index 496c8a7..2f556ca 100644
--- a/meta/classes/kernel-yocto.bbclass
+++ b/meta/classes/kernel-yocto.bbclass
@@ -138,10 +138,10 @@ do_kernel_metadata() {
for f in ${feat_dirs}; do
if [ -d "${WORKDIR}/$f/meta" ]; then
includes="$includes -I${WORKDIR}/$f/kernel-meta"
-   elif [ -d "${WORKDIR}/$f" ]; then
-   includes="$includes -I${WORKDIR}/$f"
elif [ -d "${WORKDIR}/../oe-local-files/$f" ]; then
includes="$includes -I${WORKDIR}/../oe-local-files/$f"
+   elif [ -d "${WORKDIR}/$f" ]; then
+   includes="$includes -I${WORKDIR}/$f"
fi
done
for s in ${sccs} ${patches}; do
diff --git a/meta/lib/oe/recipeutils.py b/meta/lib/oe/recipeutils.py
index 9c99164..e63f7ae 100644
--- a/meta/lib/oe/recipeutils.py
+++ b/meta/lib/oe/recipeutils.py
@@ -480,7 +480,14 @@ def get_recipe_local_files(d, patches=False, 
archives=False):
 unpack = fetch.ud[uri].parm.get('unpack', True)
 if unpack:
 continue
-ret[fname] = localpath
+if os.path.isdir(localpath):
+for root, dirs, files in os.walk(localpath):
+for fname in files:
+fileabspath = os.path.join(root,fname)
+srcdir = os.path.dirname(localpath)
+ret[os.path.relpath(fileabspath,srcdir)] = fileabspath
+else:
+ret[fname] = localpath
 return ret
 
 
-- 
2.7.5

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


[OE-core] [PATCH v2] device-tree.bbclass: Add support to compile overlays separately

2018-12-15 Thread Jaewon Lee
Currently only dts files are considered when looping through files to
compile. Modifying the loop to compile other files that are overlays.
Also surrounding this check with a try block as the function to find
overlays parses the file for a '/plugin/' tag, and there may be files in
the DT_FILES_PATH directory that are not parseable.

Signed-off-by: Jaewon Lee 
Signed-off-by: Alejandro Enedino Hernandez Samaniego 
Signed-off-by: Manjukumar Matha 
---
 meta/classes/devicetree.bbclass | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/meta/classes/devicetree.bbclass b/meta/classes/devicetree.bbclass
index 8fe5a5e..d785285 100644
--- a/meta/classes/devicetree.bbclass
+++ b/meta/classes/devicetree.bbclass
@@ -120,9 +120,12 @@ python devicetree_do_compile() {
 includes = expand_includes("DT_INCLUDE", d)
 listpath = d.getVar("DT_FILES_PATH")
 for dts in os.listdir(listpath):
-if not dts.endswith(".dts"):
-continue # skip non-.dts files
 dtspath = os.path.join(listpath, dts)
+try:
+if not(os.path.isfile(dtspath)) or not(dts.endswith(".dts") or 
devicetree_source_is_overlay(dtspath)):
+continue # skip non-.dts files and non-overlay files
+except:
+continue # skip if can't determine if overlay
 devicetree_compile(dtspath, includes, d)
 }
 
-- 
2.7.5

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


Re: [OE-core] [oe-core][THUD][PATCH] Introduce mechanism to keep nativesdk* sstate in esdk

2019-04-02 Thread Jaewon Lee
Disregard, will send on master branch

Thanks,
Jaewon

-Original Message-
From: Jaewon Lee  
Sent: Monday, April 1, 2019 4:58 PM
To: openembedded-core@lists.openembedded.org; Alejandro Enedino Hernandez 
Samaniego ; Manjukumar Harthikote Matha 
; Bruce Ashfield 
Cc: Jaewon Lee 
Subject: [oe-core][THUD][PATCH] Introduce mechanism to keep nativesdk* sstate 
in esdk

Using SDK_INCLUDE_NATIVESDK flag to toggle inclusion of all nativesdk* sstate 
into esdk Currently locked-sigs.inc is generated during do_sdk_depends which 
doesn't pull in nativesdk packages. Generating another locked-sigs.inc in 
do_populate_sdk_ext and pruning it to only nativesdk* packages by using a 
modified version of the already existing function prune_locked_sigs and merging 
it with the current locked-sigs.inc Also adding SDK_INCLUDE_NATIVESDK 
tasklistfn to the logic surrounding setting tasklist file to not prune esdk 
sstate during creation

Signed-off-by: Jaewon Lee 
---
 meta/classes/populate_sdk_ext.bbclass | 28 +++-
 meta/lib/oe/copy_buildsystem.py   |  8 ++--
 2 files changed, 33 insertions(+), 3 deletions(-)

diff --git a/meta/classes/populate_sdk_ext.bbclass 
b/meta/classes/populate_sdk_ext.bbclass
index 40b0375..d98b0e5 100644
--- a/meta/classes/populate_sdk_ext.bbclass
+++ b/meta/classes/populate_sdk_ext.bbclass
@@ -20,6 +20,7 @@ SDK_EXT_task-populate-sdk-ext = "-ext"
 SDK_EXT_TYPE ?= "full"
 SDK_INCLUDE_PKGDATA ?= "0"
 SDK_INCLUDE_TOOLCHAIN ?= "${@'1' if d.getVar('SDK_EXT_TYPE') == 'full' else 
'0'}"
+SDK_INCLUDE_NATIVESDK ?= "0"
 
 SDK_RECRDEP_TASKS ?= ""
 
@@ -401,9 +402,27 @@ python copy_buildsystem () {
 excluded_targets = get_sdk_install_targets(d, images_only=True)
 sigfile = d.getVar('WORKDIR') + '/locked-sigs.inc'
 lockedsigs_pruned = baseoutpath + '/conf/locked-sigs.inc'
+#nativesdk-only sigfile to merge into locked-sigs.inc
+sdk_include_nativesdk = (d.getVar("SDK_INCLUDE_NATIVESDK") == '1')
+nativesigfile = d.getVar('WORKDIR') + '/locked-sigs_nativesdk.inc'
+nativesigfile_pruned = d.getVar('WORKDIR') + 
'/locked-sigs_nativesdk_pruned.inc'
+
+if sdk_include_nativesdk:
+oe.copy_buildsystem.prune_lockedsigs([],
+excluded_targets.split(),
+nativesigfile,
+ True,
+ nativesigfile_pruned)
+
+oe.copy_buildsystem.merge_lockedsigs([],
+sigfile,
+nativesigfile_pruned,
+sigfile)
+
 oe.copy_buildsystem.prune_lockedsigs([],
  excluded_targets.split(),
  sigfile,
+ False,
  lockedsigs_pruned)
 
 sstate_out = baseoutpath + '/sstate-cache'
@@ -414,7 +433,7 @@ python copy_buildsystem () {
 
 sdk_include_toolchain = (d.getVar('SDK_INCLUDE_TOOLCHAIN') == '1')
 sdk_ext_type = d.getVar('SDK_EXT_TYPE')
-if sdk_ext_type != 'minimal' or sdk_include_toolchain or derivative:
+if (sdk_ext_type != 'minimal' or sdk_include_toolchain or derivative) and 
not sdk_include_nativesdk:
 # Create the filtered task list used to generate the sstate cache 
shipped with the SDK
 tasklistfn = d.getVar('WORKDIR') + '/tasklist.txt'
 create_filtered_tasklist(d, baseoutpath, tasklistfn, conf_initpath) @@ 
-658,9 +677,16 @@ fakeroot python do_populate_sdk_ext() {
 d.setVar('SDKDEPLOYDIR', '${SDKEXTDEPLOYDIR}')
 # ESDKs have a libc from the buildtools so ensure we don't ship linguas 
twice
 d.delVar('SDKIMAGE_LINGUAS')
+if d.getVar("SDK_INCLUDE_NATIVESDK") == '1':
+generate_nativesdk_lockedsigs(d)
 populate_sdk_common(d)
 }
 
+def generate_nativesdk_lockedsigs(d):
+import oe.copy_buildsystem
+sigfile = d.getVar('WORKDIR') + '/locked-sigs_nativesdk.inc'
+oe.copy_buildsystem.generate_locked_sigs(sigfile, d)
+
 def get_ext_sdk_depends(d):
 # Note: the deps varflag is a list not a string, so we need to specify 
expand=False
 deps = d.getVarFlag('do_image_complete', 'deps', False) diff --git 
a/meta/lib/oe/copy_buildsystem.py b/meta/lib/oe/copy_buildsystem.py index 
7cb784c..5bc728e 100644
--- a/meta/lib/oe/copy_buildsystem.py
+++ b/meta/lib/oe/copy_buildsystem.py
@@ -168,7 +168,7 @@ def generate_locked_sigs(sigfile, d):
 tasks = ['%s.%s' % (v[2], v[1]) for v in depd.values()]
 bb.parse.siggen.dump_lockedsigs(sigfile, tasks)
 
-def prune_lockedsigs(excluded_tasks, excluded_targets, lockedsigs, 
pruned_output):
+def prune_lockedsigs(excluded_tasks, excluded_targets, lockedsigs, onlynative, 
pruned_output):
 with open(locke

[OE-core] [oe-core][master][PATCH] Introduce mechanism to keep nativesdk* sstate in esdk

2019-04-02 Thread Jaewon Lee
Using SDK_INCLUDE_NATIVESDK flag to toggle inclusion of all nativesdk*
sstate into esdk
Currently locked-sigs.inc is generated during do_sdk_depends which
doesn't pull in nativesdk packages. Generating another locked-sigs.inc
in do_populate_sdk_ext and pruning it to only nativesdk* packages by
using a modified version of the already existing function
prune_locked_sigs and merging it with the current locked-sigs.inc
Also adding SDK_INCLUDE_NATIVESDK tasklistfn to the logic surrounding
setting tasklist file to not prune esdk sstate during creation

Signed-off-by: Jaewon Lee 
---
 meta/classes/populate_sdk_ext.bbclass | 28 +++-
 meta/lib/oe/copy_buildsystem.py   |  8 ++--
 2 files changed, 33 insertions(+), 3 deletions(-)

diff --git a/meta/classes/populate_sdk_ext.bbclass 
b/meta/classes/populate_sdk_ext.bbclass
index 40b0375..d98b0e5 100644
--- a/meta/classes/populate_sdk_ext.bbclass
+++ b/meta/classes/populate_sdk_ext.bbclass
@@ -20,6 +20,7 @@ SDK_EXT_task-populate-sdk-ext = "-ext"
 SDK_EXT_TYPE ?= "full"
 SDK_INCLUDE_PKGDATA ?= "0"
 SDK_INCLUDE_TOOLCHAIN ?= "${@'1' if d.getVar('SDK_EXT_TYPE') == 'full' else 
'0'}"
+SDK_INCLUDE_NATIVESDK ?= "0"
 
 SDK_RECRDEP_TASKS ?= ""
 
@@ -401,9 +402,27 @@ python copy_buildsystem () {
 excluded_targets = get_sdk_install_targets(d, images_only=True)
 sigfile = d.getVar('WORKDIR') + '/locked-sigs.inc'
 lockedsigs_pruned = baseoutpath + '/conf/locked-sigs.inc'
+#nativesdk-only sigfile to merge into locked-sigs.inc
+sdk_include_nativesdk = (d.getVar("SDK_INCLUDE_NATIVESDK") == '1')
+nativesigfile = d.getVar('WORKDIR') + '/locked-sigs_nativesdk.inc'
+nativesigfile_pruned = d.getVar('WORKDIR') + 
'/locked-sigs_nativesdk_pruned.inc'
+
+if sdk_include_nativesdk:
+oe.copy_buildsystem.prune_lockedsigs([],
+excluded_targets.split(),
+nativesigfile,
+ True,
+ nativesigfile_pruned)
+
+oe.copy_buildsystem.merge_lockedsigs([],
+sigfile,
+nativesigfile_pruned,
+sigfile)
+
 oe.copy_buildsystem.prune_lockedsigs([],
  excluded_targets.split(),
  sigfile,
+ False,
  lockedsigs_pruned)
 
 sstate_out = baseoutpath + '/sstate-cache'
@@ -414,7 +433,7 @@ python copy_buildsystem () {
 
 sdk_include_toolchain = (d.getVar('SDK_INCLUDE_TOOLCHAIN') == '1')
 sdk_ext_type = d.getVar('SDK_EXT_TYPE')
-if sdk_ext_type != 'minimal' or sdk_include_toolchain or derivative:
+if (sdk_ext_type != 'minimal' or sdk_include_toolchain or derivative) and 
not sdk_include_nativesdk:
 # Create the filtered task list used to generate the sstate cache 
shipped with the SDK
 tasklistfn = d.getVar('WORKDIR') + '/tasklist.txt'
 create_filtered_tasklist(d, baseoutpath, tasklistfn, conf_initpath)
@@ -658,9 +677,16 @@ fakeroot python do_populate_sdk_ext() {
 d.setVar('SDKDEPLOYDIR', '${SDKEXTDEPLOYDIR}')
 # ESDKs have a libc from the buildtools so ensure we don't ship linguas 
twice
 d.delVar('SDKIMAGE_LINGUAS')
+if d.getVar("SDK_INCLUDE_NATIVESDK") == '1':
+generate_nativesdk_lockedsigs(d)
 populate_sdk_common(d)
 }
 
+def generate_nativesdk_lockedsigs(d):
+import oe.copy_buildsystem
+sigfile = d.getVar('WORKDIR') + '/locked-sigs_nativesdk.inc'
+oe.copy_buildsystem.generate_locked_sigs(sigfile, d)
+
 def get_ext_sdk_depends(d):
 # Note: the deps varflag is a list not a string, so we need to specify 
expand=False
 deps = d.getVarFlag('do_image_complete', 'deps', False)
diff --git a/meta/lib/oe/copy_buildsystem.py b/meta/lib/oe/copy_buildsystem.py
index 7cb784c..5bc728e 100644
--- a/meta/lib/oe/copy_buildsystem.py
+++ b/meta/lib/oe/copy_buildsystem.py
@@ -168,7 +168,7 @@ def generate_locked_sigs(sigfile, d):
 tasks = ['%s.%s' % (v[2], v[1]) for v in depd.values()]
 bb.parse.siggen.dump_lockedsigs(sigfile, tasks)
 
-def prune_lockedsigs(excluded_tasks, excluded_targets, lockedsigs, 
pruned_output):
+def prune_lockedsigs(excluded_tasks, excluded_targets, lockedsigs, onlynative, 
pruned_output):
 with open(lockedsigs, 'r') as infile:
 bb.utils.mkdirhier(os.path.dirname(pruned_output))
 with open(pruned_output, 'w') as f:
@@ -178,7 +178,11 @@ def prune_lockedsigs(excluded_tasks, excluded_targets, 
lockedsigs, pruned_output
 if line.endswith('\\\n'):
 splitval = line.strip().split(':')
 if not splitval[1] in excluded_task

[OE-core] [oe-core][THUD][PATCH] Introduce mechanism to keep nativesdk* sstate in esdk

2019-04-03 Thread Jaewon Lee
Using SDK_INCLUDE_NATIVESDK flag to toggle inclusion of all nativesdk*
sstate into esdk
Currently locked-sigs.inc is generated during do_sdk_depends which
doesn't pull in nativesdk packages. Generating another locked-sigs.inc
in do_populate_sdk_ext and pruning it to only nativesdk* packages by
using a modified version of the already existing function
prune_locked_sigs and merging it with the current locked-sigs.inc
Also adding SDK_INCLUDE_NATIVESDK tasklistfn to the logic surrounding
setting tasklist file to not prune esdk sstate during creation

Signed-off-by: Jaewon Lee 
---
 meta/classes/populate_sdk_ext.bbclass | 28 +++-
 meta/lib/oe/copy_buildsystem.py   |  8 ++--
 2 files changed, 33 insertions(+), 3 deletions(-)

diff --git a/meta/classes/populate_sdk_ext.bbclass 
b/meta/classes/populate_sdk_ext.bbclass
index 40b0375..d98b0e5 100644
--- a/meta/classes/populate_sdk_ext.bbclass
+++ b/meta/classes/populate_sdk_ext.bbclass
@@ -20,6 +20,7 @@ SDK_EXT_task-populate-sdk-ext = "-ext"
 SDK_EXT_TYPE ?= "full"
 SDK_INCLUDE_PKGDATA ?= "0"
 SDK_INCLUDE_TOOLCHAIN ?= "${@'1' if d.getVar('SDK_EXT_TYPE') == 'full' else 
'0'}"
+SDK_INCLUDE_NATIVESDK ?= "0"
 
 SDK_RECRDEP_TASKS ?= ""
 
@@ -401,9 +402,27 @@ python copy_buildsystem () {
 excluded_targets = get_sdk_install_targets(d, images_only=True)
 sigfile = d.getVar('WORKDIR') + '/locked-sigs.inc'
 lockedsigs_pruned = baseoutpath + '/conf/locked-sigs.inc'
+#nativesdk-only sigfile to merge into locked-sigs.inc
+sdk_include_nativesdk = (d.getVar("SDK_INCLUDE_NATIVESDK") == '1')
+nativesigfile = d.getVar('WORKDIR') + '/locked-sigs_nativesdk.inc'
+nativesigfile_pruned = d.getVar('WORKDIR') + 
'/locked-sigs_nativesdk_pruned.inc'
+
+if sdk_include_nativesdk:
+oe.copy_buildsystem.prune_lockedsigs([],
+excluded_targets.split(),
+nativesigfile,
+ True,
+ nativesigfile_pruned)
+
+oe.copy_buildsystem.merge_lockedsigs([],
+sigfile,
+nativesigfile_pruned,
+sigfile)
+
 oe.copy_buildsystem.prune_lockedsigs([],
  excluded_targets.split(),
  sigfile,
+ False,
  lockedsigs_pruned)
 
 sstate_out = baseoutpath + '/sstate-cache'
@@ -414,7 +433,7 @@ python copy_buildsystem () {
 
 sdk_include_toolchain = (d.getVar('SDK_INCLUDE_TOOLCHAIN') == '1')
 sdk_ext_type = d.getVar('SDK_EXT_TYPE')
-if sdk_ext_type != 'minimal' or sdk_include_toolchain or derivative:
+if (sdk_ext_type != 'minimal' or sdk_include_toolchain or derivative) and 
not sdk_include_nativesdk:
 # Create the filtered task list used to generate the sstate cache 
shipped with the SDK
 tasklistfn = d.getVar('WORKDIR') + '/tasklist.txt'
 create_filtered_tasklist(d, baseoutpath, tasklistfn, conf_initpath)
@@ -658,9 +677,16 @@ fakeroot python do_populate_sdk_ext() {
 d.setVar('SDKDEPLOYDIR', '${SDKEXTDEPLOYDIR}')
 # ESDKs have a libc from the buildtools so ensure we don't ship linguas 
twice
 d.delVar('SDKIMAGE_LINGUAS')
+if d.getVar("SDK_INCLUDE_NATIVESDK") == '1':
+generate_nativesdk_lockedsigs(d)
 populate_sdk_common(d)
 }
 
+def generate_nativesdk_lockedsigs(d):
+import oe.copy_buildsystem
+sigfile = d.getVar('WORKDIR') + '/locked-sigs_nativesdk.inc'
+oe.copy_buildsystem.generate_locked_sigs(sigfile, d)
+
 def get_ext_sdk_depends(d):
 # Note: the deps varflag is a list not a string, so we need to specify 
expand=False
 deps = d.getVarFlag('do_image_complete', 'deps', False)
diff --git a/meta/lib/oe/copy_buildsystem.py b/meta/lib/oe/copy_buildsystem.py
index 7cb784c..5bc728e 100644
--- a/meta/lib/oe/copy_buildsystem.py
+++ b/meta/lib/oe/copy_buildsystem.py
@@ -168,7 +168,7 @@ def generate_locked_sigs(sigfile, d):
 tasks = ['%s.%s' % (v[2], v[1]) for v in depd.values()]
 bb.parse.siggen.dump_lockedsigs(sigfile, tasks)
 
-def prune_lockedsigs(excluded_tasks, excluded_targets, lockedsigs, 
pruned_output):
+def prune_lockedsigs(excluded_tasks, excluded_targets, lockedsigs, onlynative, 
pruned_output):
 with open(lockedsigs, 'r') as infile:
 bb.utils.mkdirhier(os.path.dirname(pruned_output))
 with open(pruned_output, 'w') as f:
@@ -178,7 +178,11 @@ def prune_lockedsigs(excluded_tasks, excluded_targets, 
lockedsigs, pruned_output
 if line.endswith('\\\n'):
 splitval = line.strip().split(':')
 if not splitval[1] in excluded_task

[OE-core] [PATCH] devtool sdk-update: unconditionally append updateserver to sstate mirrors

2019-03-14 Thread Jaewon Lee
The code in sdk.py which checks if SSTATE_MIRRORS is set before
appending the updateserver to SSTATE_MIRRORS was written before
it was being set in the eSDK's local.conf (OE-Core commit
6b9e8b780dcd8d5ffba3df35cfe41674413ee26d).
Unconditionally appending updateserver to SSTATE_MIRRORS as this is
pretty safe to do.

[YOCTO #12884]

Signed-off-by: Jaewon Lee 
Signed-off-by: Alejandro Enedino Hernandez Samaniego 
Signed-off-by: Manjukumar Matha 
---
 scripts/lib/devtool/sdk.py | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/scripts/lib/devtool/sdk.py b/scripts/lib/devtool/sdk.py
index 4616753797..37f2af3f5c 100644
--- a/scripts/lib/devtool/sdk.py
+++ b/scripts/lib/devtool/sdk.py
@@ -214,10 +214,9 @@ def sdk_update(args, config, basepath, workspace):
 shutil.rmtree(os.path.join(basepath, 'downloads', 'uninative'))
 shutil.move(os.path.join(tmpsdk_dir, 'downloads', 'uninative'), 
os.path.join(basepath, 'downloads'))
 
-if not sstate_mirrors:
-with open(os.path.join(conf_dir, 'site.conf'), 'a') as f:
-f.write('SCONF_VERSION = "%s"\n' % site_conf_version)
-f.write('SSTATE_MIRRORS_append = " file://.* 
%s/sstate-cache/PATH \\n "\n' % updateserver)
+with open(os.path.join(conf_dir, 'site.conf'), 'a') as f:
+f.write('SCONF_VERSION = "%s"\n' % site_conf_version)
+f.write('SSTATE_MIRRORS_append = " file://.* %s/sstate-cache/PATH 
\\n "\n' % updateserver)
 finally:
 shutil.rmtree(tmpsdk_dir)
 
-- 
2.18.1

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


[OE-core] [OE-CORE][thud][PATCH] python3_3.5.6.bb: Remove setting of PYTHONHOME

2019-03-07 Thread Jaewon Lee
PYTHONHOME was set in python wrapper to 'ensure that the nativesdk
python functions correctly without needing to set PYTHONHOME in the sdk
environment setup script' (From OE-Core 
rev:c5629268b0f8ae0a425c98337d13e8dc83107e13)
But thud doesnt use python3 libraries from buildtools like python2 does
so oe-buildenv-internal throws the following error when running any
devtool command from an extracted esdk:

ImportError: No module named site
OpenEmbedded requires 'python' to be python v2 (>= 2.7.3), not python v3.
Please upgrade your python v2.

There is no lib/python3 in the path PYTHONHOME is being set to
( buildtools/sysroots/x86_64.../usr ).
Taking out the setting of PYTHONHOME in the python3 wrapper to get rid
of this issue

[YOCTO #13208]

Signed-off-by: Jaewon Lee 
Signed-off-by: Alejandro Enedino Hernandez Samaniego 
---
 meta/recipes-devtools/python/python3_3.5.6.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/python/python3_3.5.6.bb 
b/meta/recipes-devtools/python/python3_3.5.6.bb
index 2cb6504..c2fe943 100644
--- a/meta/recipes-devtools/python/python3_3.5.6.bb
+++ b/meta/recipes-devtools/python/python3_3.5.6.bb
@@ -178,7 +178,7 @@ do_install() {
 }
 
 do_install_append_class-nativesdk () {
-   create_wrapper ${D}${bindir}/python${PYTHON_MAJMIN} 
PYTHONHOME='${prefix}' 
TERMINFO_DIRS='${sysconfdir}/terminfo:/etc/terminfo:/usr/share/terminfo:/usr/share/misc/terminfo:/lib/terminfo'
 PYTHONNOUSERSITE='1'
+   create_wrapper ${D}${bindir}/python${PYTHON_MAJMIN} 
TERMINFO_DIRS='${sysconfdir}/terminfo:/etc/terminfo:/usr/share/terminfo:/usr/share/misc/terminfo:/lib/terminfo'
 PYTHONNOUSERSITE='1'
 }
 
 SSTATE_SCAN_FILES += "Makefile"
-- 
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 v2] device-tree.bbclass: Add support to compile overlays separately

2019-02-11 Thread Jaewon Lee
Ping

-Original Message-
From: Jaewon Lee 
Sent: Monday, January 28, 2019 3:19 PM
To: Jaewon Lee ; openembedded-core@lists.openembedded.org; 
nat...@nathanrossi.com
Cc: Alejandro Enedino Hernandez Samaniego ; Manjukumar 
Harthikote Matha 
Subject: RE: [OE-core][PATCH v2] device-tree.bbclass: Add support to compile 
overlays separately

ping

-Original Message-
From: Jaewon Lee [mailto:jaewon@xilinx.com] 
Sent: Friday, December 14, 2018 9:54 AM
To: openembedded-core@lists.openembedded.org; nat...@nathanrossi.com
Cc: Jaewon Lee ; Alejandro Enedino Hernandez Samaniego 
; Manjukumar Harthikote Matha 
Subject: [OE-core][PATCH v2] device-tree.bbclass: Add support to compile 
overlays separately

Currently only dts files are considered when looping through files to compile. 
Modifying the loop to compile other files that are overlays.
Also surrounding this check with a try block as the function to find overlays 
parses the file for a '/plugin/' tag, and there may be files in the 
DT_FILES_PATH directory that are not parseable.

Signed-off-by: Jaewon Lee 
Signed-off-by: Alejandro Enedino Hernandez Samaniego 
Signed-off-by: Manjukumar Matha 
---
 meta/classes/devicetree.bbclass | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/meta/classes/devicetree.bbclass b/meta/classes/devicetree.bbclass 
index 8fe5a5e..d785285 100644
--- a/meta/classes/devicetree.bbclass
+++ b/meta/classes/devicetree.bbclass
@@ -120,9 +120,12 @@ python devicetree_do_compile() {
 includes = expand_includes("DT_INCLUDE", d)
 listpath = d.getVar("DT_FILES_PATH")
 for dts in os.listdir(listpath):
-if not dts.endswith(".dts"):
-continue # skip non-.dts files
 dtspath = os.path.join(listpath, dts)
+try:
+if not(os.path.isfile(dtspath)) or not(dts.endswith(".dts") or 
devicetree_source_is_overlay(dtspath)):
+continue # skip non-.dts files and non-overlay files
+except:
+continue # skip if can't determine if overlay
 devicetree_compile(dtspath, includes, d)  }
 
--
2.7.5

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


Re: [OE-core] [PATCH] Support kmeta directory usage with devtool modify/finish

2019-02-11 Thread Jaewon Lee
ping

-Original Message-
From: Jaewon Lee 
Sent: Monday, January 28, 2019 3:18 PM
To: Jaewon Lee ; openembedded-core@lists.openembedded.org
Cc: Alejandro Enedino Hernandez Samaniego 
Subject: RE: [OE-core][PATCH] Support kmeta directory usage with devtool 
modify/finish

ping

-Original Message-
From: Jaewon Lee [mailto:jaewon@xilinx.com] 
Sent: Friday, December 14, 2018 4:39 PM
To: openembedded-core@lists.openembedded.org
Cc: Jaewon Lee ; Alejandro Enedino Hernandez Samaniego 

Subject: [OE-core][PATCH] Support kmeta directory usage with devtool 
modify/finish

When using Kmeta directories, devtool finish will add every single file in the 
directory to the bbappend. This is because in the current implementation, the 
get_recipe_local_files function treats the kmeta directory like a file. 
Modifying the function to loop through the provided directories and return all 
included files instead of just the top level directory. This will enable 
correct file to file comparison when determing which files are new/changed and 
need to be added to the bbappend.

Adding an extra check in devtool-source.bbclass to not copy the cfg file if its 
already included somewhere in the kmeta directory

Also during 'modify', when moving necessary files in the kmeta directory from 
the workdir to oe-local-files, the dangling parent directories are left behind. 
 This in itself is not an issue as the temporary devtool workspace is 
automatically deleted, but this causes an incorrect include directory to be 
added in kernel-yocto.bbclass.  Changing the order of the if statements to 
catch the correct conditional. This is safe to do as when not in the devtool 
context, there will be no oe-local-files directory.

Signed-off-by: Jaewon Lee 
Signed-off-by: Alejandro Enedino Hernandez Samaniego 
---
 meta/classes/devtool-source.bbclass | 6 --
 meta/classes/kernel-yocto.bbclass   | 4 ++--
 meta/lib/oe/recipeutils.py  | 9 -
 3 files changed, 14 insertions(+), 5 deletions(-)

diff --git a/meta/classes/devtool-source.bbclass 
b/meta/classes/devtool-source.bbclass
index 1372e32..a811000 100644
--- a/meta/classes/devtool-source.bbclass
+++ b/meta/classes/devtool-source.bbclass
@@ -103,8 +103,10 @@ python devtool_post_unpack() {
 for l in sccfile:
 line = l.split()
 if line and line[0] in ('kconf', 'patch'):
-local_files[line[-1]] = 
os.path.join(os.path.dirname(local_files[key]), line[-1])
-
shutil.copy2(os.path.join(os.path.dirname(local_files[key]), line[-1]), workdir)
+cfg = os.path.join(os.path.dirname(local_files[key]), 
line[-1])
+if not cfg in local_files.values():
+local_files[line[-1]] = cfg
+shutil.copy2(cfg, workdir)
 sccfile.close()
 
 # Ignore local files with subdir={BP} diff --git 
a/meta/classes/kernel-yocto.bbclass b/meta/classes/kernel-yocto.bbclass
index 496c8a7..2f556ca 100644
--- a/meta/classes/kernel-yocto.bbclass
+++ b/meta/classes/kernel-yocto.bbclass
@@ -138,10 +138,10 @@ do_kernel_metadata() {
for f in ${feat_dirs}; do
if [ -d "${WORKDIR}/$f/meta" ]; then
includes="$includes -I${WORKDIR}/$f/kernel-meta"
-   elif [ -d "${WORKDIR}/$f" ]; then
-   includes="$includes -I${WORKDIR}/$f"
elif [ -d "${WORKDIR}/../oe-local-files/$f" ]; then
includes="$includes -I${WORKDIR}/../oe-local-files/$f"
+   elif [ -d "${WORKDIR}/$f" ]; then
+   includes="$includes -I${WORKDIR}/$f"
fi
done
for s in ${sccs} ${patches}; do
diff --git a/meta/lib/oe/recipeutils.py b/meta/lib/oe/recipeutils.py index 
9c99164..e63f7ae 100644
--- a/meta/lib/oe/recipeutils.py
+++ b/meta/lib/oe/recipeutils.py
@@ -480,7 +480,14 @@ def get_recipe_local_files(d, patches=False, 
archives=False):
 unpack = fetch.ud[uri].parm.get('unpack', True)
 if unpack:
 continue
-ret[fname] = localpath
+if os.path.isdir(localpath):
+for root, dirs, files in os.walk(localpath):
+for fname in files:
+fileabspath = os.path.join(root,fname)
+srcdir = os.path.dirname(localpath)
+ret[os.path.relpath(fileabspath,srcdir)] = fileabspath
+else:
+ret[fname] = localpath
 return ret
 
 
--
2.7.5

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


Re: [OE-core] [PATCH] Support kmeta directory usage with devtool modify/finish

2019-01-29 Thread Jaewon Lee
ping

-Original Message-
From: Jaewon Lee [mailto:jaewon@xilinx.com] 
Sent: Friday, December 14, 2018 4:39 PM
To: openembedded-core@lists.openembedded.org
Cc: Jaewon Lee ; Alejandro Enedino Hernandez Samaniego 

Subject: [OE-core][PATCH] Support kmeta directory usage with devtool 
modify/finish

When using Kmeta directories, devtool finish will add every single file in the 
directory to the bbappend. This is because in the current implementation, the 
get_recipe_local_files function treats the kmeta directory like a file. 
Modifying the function to loop through the provided directories and return all 
included files instead of just the top level directory. This will enable 
correct file to file comparison when determing which files are new/changed and 
need to be added to the bbappend.

Adding an extra check in devtool-source.bbclass to not copy the cfg file if its 
already included somewhere in the kmeta directory

Also during 'modify', when moving necessary files in the kmeta directory from 
the workdir to oe-local-files, the dangling parent directories are left behind. 
 This in itself is not an issue as the temporary devtool workspace is 
automatically deleted, but this causes an incorrect include directory to be 
added in kernel-yocto.bbclass.  Changing the order of the if statements to 
catch the correct conditional. This is safe to do as when not in the devtool 
context, there will be no oe-local-files directory.

Signed-off-by: Jaewon Lee 
Signed-off-by: Alejandro Enedino Hernandez Samaniego 
---
 meta/classes/devtool-source.bbclass | 6 --
 meta/classes/kernel-yocto.bbclass   | 4 ++--
 meta/lib/oe/recipeutils.py  | 9 -
 3 files changed, 14 insertions(+), 5 deletions(-)

diff --git a/meta/classes/devtool-source.bbclass 
b/meta/classes/devtool-source.bbclass
index 1372e32..a811000 100644
--- a/meta/classes/devtool-source.bbclass
+++ b/meta/classes/devtool-source.bbclass
@@ -103,8 +103,10 @@ python devtool_post_unpack() {
 for l in sccfile:
 line = l.split()
 if line and line[0] in ('kconf', 'patch'):
-local_files[line[-1]] = 
os.path.join(os.path.dirname(local_files[key]), line[-1])
-
shutil.copy2(os.path.join(os.path.dirname(local_files[key]), line[-1]), workdir)
+cfg = os.path.join(os.path.dirname(local_files[key]), 
line[-1])
+if not cfg in local_files.values():
+local_files[line[-1]] = cfg
+shutil.copy2(cfg, workdir)
 sccfile.close()
 
 # Ignore local files with subdir={BP} diff --git 
a/meta/classes/kernel-yocto.bbclass b/meta/classes/kernel-yocto.bbclass
index 496c8a7..2f556ca 100644
--- a/meta/classes/kernel-yocto.bbclass
+++ b/meta/classes/kernel-yocto.bbclass
@@ -138,10 +138,10 @@ do_kernel_metadata() {
for f in ${feat_dirs}; do
if [ -d "${WORKDIR}/$f/meta" ]; then
includes="$includes -I${WORKDIR}/$f/kernel-meta"
-   elif [ -d "${WORKDIR}/$f" ]; then
-   includes="$includes -I${WORKDIR}/$f"
elif [ -d "${WORKDIR}/../oe-local-files/$f" ]; then
includes="$includes -I${WORKDIR}/../oe-local-files/$f"
+   elif [ -d "${WORKDIR}/$f" ]; then
+   includes="$includes -I${WORKDIR}/$f"
fi
done
for s in ${sccs} ${patches}; do
diff --git a/meta/lib/oe/recipeutils.py b/meta/lib/oe/recipeutils.py index 
9c99164..e63f7ae 100644
--- a/meta/lib/oe/recipeutils.py
+++ b/meta/lib/oe/recipeutils.py
@@ -480,7 +480,14 @@ def get_recipe_local_files(d, patches=False, 
archives=False):
 unpack = fetch.ud[uri].parm.get('unpack', True)
 if unpack:
 continue
-ret[fname] = localpath
+if os.path.isdir(localpath):
+for root, dirs, files in os.walk(localpath):
+for fname in files:
+fileabspath = os.path.join(root,fname)
+srcdir = os.path.dirname(localpath)
+ret[os.path.relpath(fileabspath,srcdir)] = fileabspath
+else:
+ret[fname] = localpath
 return ret
 
 
--
2.7.5

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


Re: [OE-core] [PATCH v2] device-tree.bbclass: Add support to compile overlays separately

2019-01-28 Thread Jaewon Lee
ping

-Original Message-
From: Jaewon Lee [mailto:jaewon@xilinx.com] 
Sent: Friday, December 14, 2018 9:54 AM
To: openembedded-core@lists.openembedded.org; nat...@nathanrossi.com
Cc: Jaewon Lee ; Alejandro Enedino Hernandez Samaniego 
; Manjukumar Harthikote Matha 
Subject: [OE-core][PATCH v2] device-tree.bbclass: Add support to compile 
overlays separately

Currently only dts files are considered when looping through files to compile. 
Modifying the loop to compile other files that are overlays.
Also surrounding this check with a try block as the function to find overlays 
parses the file for a '/plugin/' tag, and there may be files in the 
DT_FILES_PATH directory that are not parseable.

Signed-off-by: Jaewon Lee 
Signed-off-by: Alejandro Enedino Hernandez Samaniego 
Signed-off-by: Manjukumar Matha 
---
 meta/classes/devicetree.bbclass | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/meta/classes/devicetree.bbclass b/meta/classes/devicetree.bbclass 
index 8fe5a5e..d785285 100644
--- a/meta/classes/devicetree.bbclass
+++ b/meta/classes/devicetree.bbclass
@@ -120,9 +120,12 @@ python devicetree_do_compile() {
 includes = expand_includes("DT_INCLUDE", d)
 listpath = d.getVar("DT_FILES_PATH")
 for dts in os.listdir(listpath):
-if not dts.endswith(".dts"):
-continue # skip non-.dts files
 dtspath = os.path.join(listpath, dts)
+try:
+if not(os.path.isfile(dtspath)) or not(dts.endswith(".dts") or 
devicetree_source_is_overlay(dtspath)):
+continue # skip non-.dts files and non-overlay files
+except:
+continue # skip if can't determine if overlay
 devicetree_compile(dtspath, includes, d)  }
 
--
2.7.5

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


[OE-core] [PATCH] devtool: build: add deploy to the tasks run for devtool build

2019-06-07 Thread Jaewon Lee
Right now `devtool build` runs populate_sysroot and packagedata tasks.
Adding deploy to this list so that the newly built artifacts are
available in the deploy directory.

Signed-off-by: Jaewon Lee 

[YOCTO #13382]

Signed-off-by: Jaewon Lee 
---
 scripts/lib/devtool/build.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/lib/devtool/build.py b/scripts/lib/devtool/build.py
index 7543398..aff5710 100644
--- a/scripts/lib/devtool/build.py
+++ b/scripts/lib/devtool/build.py
@@ -37,7 +37,7 @@ def _set_file_values(fn, values):
 return updated
 
 def _get_build_tasks(config):
-tasks = config.get('Build', 'build_task', 
'populate_sysroot,packagedata').split(',')
+tasks = config.get('Build', 'build_task', 
'deploy,populate_sysroot,packagedata').split(',')
 return ['do_%s' % task.strip() for task in tasks]
 
 def build(args, config, basepath, workspace):
-- 
2.7.4

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


[OE-core] [PATCH v2] devtool: build: Also run deploy for devtool build if applicable

2019-06-14 Thread Jaewon Lee
Right now `devtool build` runs populate_sysroot and packagedata tasks.
Adding deploy to this list, if the recipe has the deploy task, so that
the newly built artifacts are available in the deploy directory.
Applicable only for packages with deploy task, such as kernel.

[YOCTO#13382]

Signed-off-by: Jaewon Lee 
Signed-off-by: Alejandro Enedino Hernandez Samaniego 
---
v2: tested with oe-selftest, add deploy to build_tasks if deploy in __BBTASKS
---
 scripts/lib/devtool/build.py | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/scripts/lib/devtool/build.py b/scripts/lib/devtool/build.py
index 7543398..935ffab 100644
--- a/scripts/lib/devtool/build.py
+++ b/scripts/lib/devtool/build.py
@@ -11,7 +11,8 @@ import bb
 import logging
 import argparse
 import tempfile
-from devtool import exec_build_env_command, check_workspace_recipe, 
DevtoolError
+from devtool import exec_build_env_command, setup_tinfoil, 
check_workspace_recipe, DevtoolError
+from devtool import parse_recipe
 
 logger = logging.getLogger('devtool')
 
@@ -43,12 +44,22 @@ def _get_build_tasks(config):
 def build(args, config, basepath, workspace):
 """Entry point for the devtool 'build' subcommand"""
 workspacepn = check_workspace_recipe(workspace, args.recipename, 
bbclassextend=True)
+tinfoil = setup_tinfoil(config_only=False, basepath=basepath)
+try:
+rd = parse_recipe(config, tinfoil, args.recipename, appends=True, 
filter_workspace=False)
+if not rd:
+return 1
+deploytask = 'do_deploy' in rd.getVar('__BBTASKS')
+finally:
+tinfoil.shutdown()
 
 if args.clean:
 # use clean instead of cleansstate to avoid messing things up in eSDK
 build_tasks = ['do_clean']
 else:
 build_tasks = _get_build_tasks(config)
+if deploytask:
+build_tasks.append('do_deploy')
 
 bbappend = workspace[workspacepn]['bbappend']
 if args.disable_parallel_make:
-- 
2.7.4

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


[OE-core] [PATCH] gstreamer1.0-python_1.16.0.bb: Override libpython dir

2019-06-11 Thread Jaewon Lee
As mentioned in upstream commit a2cf84a8a78fdaa8fabcfa9b40be1936678e,
"gstpythonplugin hardcodes the location of the libpython from the build
workspace and then fails at runtime."

In other words, PYTHON_LIB_LOC was set to the recipe-sysroot-native dir
in the gstreamer1.0-python workspace on the host. Overriding
PYTHON_LIB_LOC with /usr/lib by adding --with-libpython-dir=${libdir} to
EXTRA_OECONF to fix this issue.

The error that was seen is:
** (gst-plugin-scanner:2343): CRITICAL **: 23:08:18.327: Couldn't
g_module_open libpython. Reason: ${project}/build/tmp/work/${arch}/
gstreamer1.0-python/1.14.4-r0/recipe-sysroot-native/usr/lib/libpython3.5m.so:
cannot open shared object file: No such file or directory

The comment continues and says "it still fails because it looks for
a symlinked library ending in .so instead of the actually library with
LIBNAME.so.MAJOR.MINOR. Although we could patch the code to use the path
we want, it will break again if the library version ever changes."
This isn't the case anymore as the package is deploying
/usr/lib/gstreamer-1.0/libgstpython.cpython-37m-i386-linux-gnu.so, a
versionless so.

Signed-off-by: Jaewon Lee 
Signed-off-by: Alejandro Enedino Hernandez Samaniego 
---
 .../gstreamer/gstreamer1.0-python_1.16.0.bb  | 12 +++-
 1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-python_1.16.0.bb 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-python_1.16.0.bb
index af9f3f2..0f3aac1 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-python_1.16.0.bb
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-python_1.16.0.bb
@@ -22,16 +22,10 @@ UNKNOWN_CONFIGURE_WHITELIST_append = " 
--enable-introspection --disable-introspe
 
 inherit autotools pkgconfig distutils3-base upstream-version-is-even 
gobject-introspection distro_features_check
 
+EXTRA_OECONF += "--with-libpython-dir=${libdir}"
+
 do_install_append() {
-# gstpythonplugin hardcodes the location of the libpython from the build
-# workspace and then fails at runtime. We can override it using
-# --with-libpython-dir=${libdir}, but it still fails because it looks for a
-# symlinked library ending in .so instead of the actually library with
-# LIBNAME.so.MAJOR.MINOR. Although we could patch the code to use the path
-# we want, it will break again if the library version ever changes. We need
-# to think about the best way of handling this and possibly consult
-# upstream.
-#
+
 # Note that this particular find line is taken from the Debian packaging 
for
 # gst-python1.0.
 find "${D}" \
-- 
2.7.4

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


Re: [OE-core] [PATCH] devtool: build: add deploy to the tasks run for devtool build

2019-06-08 Thread Jaewon Lee
Sorry about that Richard 
Will be sure to test with that 

Thanks,
Jaewon


> On Jun 8, 2019, at 5:15 AM, Richard Purdie 
>  wrote:
> 
>> On Fri, 2019-06-07 at 15:17 -0700, Jaewon Lee wrote:
>> Right now `devtool build` runs populate_sysroot and packagedata
>> tasks.
>> Adding deploy to this list so that the newly built artifacts are
>> available in the deploy directory.
>> 
>> Signed-off-by: Jaewon Lee 
>> 
>> [YOCTO #13382]
>> 
>> Signed-off-by: Jaewon Lee 
>> ---
>> scripts/lib/devtool/build.py | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/scripts/lib/devtool/build.py
>> b/scripts/lib/devtool/build.py
>> index 7543398..aff5710 100644
>> --- a/scripts/lib/devtool/build.py
>> +++ b/scripts/lib/devtool/build.py
>> @@ -37,7 +37,7 @@ def _set_file_values(fn, values):
>> return updated
>> 
>> def _get_build_tasks(config):
>> -tasks = config.get('Build', 'build_task',
>> 'populate_sysroot,packagedata').split(',')
>> +tasks = config.get('Build', 'build_task',
>> 'deploy,populate_sysroot,packagedata').split(',')
>> return ['do_%s' % task.strip() for task in tasks]
>> 
>> def build(args, config, basepath, workspace):
> 
> This frustrates me a bit.
> 
> The key question you have to ask here is "What happens for recipes that
> don't have a do_deploy task?".
> 
> The answer is it breaks:
> 
> https://autobuilder.yoctoproject.org/typhoon/#/builders/56/builds/506
> 
> *Please*, when sending devtool patches, test with:
> 
> oe-selftest -r devtool
> 
> Cheers,
> 
> Richard
> 
> 
> 
> 
> 

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


[OE-core] [PATCH] devicetree.bbclass: Combine stderr into stdout to see actual dtc error

2019-06-12 Thread Jaewon Lee
Previously the subprocess command to run dtc was not properly displaying
the error on console. Combining stderr into stdout for the dtc subprocess
so the actual error can be seen on console without having to open the
do_compile log.

For example, previously on a dtc error, just the following stack trace
and dtc command was being shown on console:

File: 'exec_python_func() autogenerated', lineno: 2, function: 
 0001:
 *** 0002:devicetree_do_compile(d)
 0003:
File:
function: devicetree_do_compile
 0127:if not(os.path.isfile(dtspath)) or
not(dts.endswith(".dts") or devicetree_source_is_overlay(dtspath)):
 0128:continue # skip non-.dts files and non-overlay
files
 0129:except:
 0130:continue # skip if can't determine if overlay
 *** 0131:devicetree_compile(dtspath, includes, d)

...

Exception: subprocess.CalledProcessError: Command '['dtc', '-R', '8',
'-b', '0', '-p', '0x1000', '-i', '${INCLUDES}, '-o', 'system-top.dtb',
'-I', 'dts', '-O', 'dtb', 'system-top.dts.pp']' returned non-zero exit
status 1

with this patch, the actual error from the dtc command will be appended
like the following:

Subprocess output:
Error: Label or path not found
FATAL ERROR: Syntax error parsing input tree

Signed-off-by: Jaewon Lee 
---
 meta/classes/devicetree.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/devicetree.bbclass b/meta/classes/devicetree.bbclass
index 5c03e4b..d8779c7 100644
--- a/meta/classes/devicetree.bbclass
+++ b/meta/classes/devicetree.bbclass
@@ -116,7 +116,7 @@ def devicetree_compile(dtspath, includes, d):
 dtcargs += ["-o", "{0}.{1}".format(dtname, "dtbo" if isoverlay else "dtb")]
 dtcargs += ["-I", "dts", "-O", "dtb", "{0}.pp".format(dts)]
 bb.note("Running {0}".format(" ".join(dtcargs)))
-subprocess.run(dtcargs, check = True)
+subprocess.run(dtcargs, check = True, stdout=subprocess.PIPE, 
stderr=subprocess.STDOUT)
 
 python devicetree_do_compile() {
 includes = expand_includes("DT_INCLUDE", d)
-- 
2.7.4

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


Re: [OE-core] [master][RFC] Adding back wrapper and using OEPYTHON3HOME variable for python3

2019-04-25 Thread Jaewon Lee
Hi Richard,

Agreed, will send a v2

Thanks,
Jaewon

-Original Message-
From: richard.pur...@linuxfoundation.org  
Sent: Thursday, April 25, 2019 1:50 PM
To: Jaewon Lee ; openembedded-core@lists.openembedded.org; 
Manjukumar Harthikote Matha ; Alejandro Enedino Hernandez 
Samaniego 
Subject: Re: [OE-core][master][RFC] Adding back wrapper and using OEPYTHON3HOME 
variable for python3

On Thu, 2019-04-25 at 12:56 -0700, Jaewon Lee wrote:
> +diff --git a/Modules/main.c b/Modules/main.c index a745381..25ca435 
> +100644
> +--- a/Modules/main.c
>  b/Modules/main.c
> +@@ -1857,6 +1857,11 @@ config_init_home(_PyCoreConfig *config)
> + }
> + 
> + int res = config_get_env_var_dup(, L"PYTHONHOME", 
> + "PYTHONHOME");
> ++
> ++const char *oepython3home = config_get_env_var("OEPYTHON3HOME");
> ++if (oepython3home) {
> ++res = config_get_env_var_dup(, L"OEPYTHON3HOME", 
> "OEPYTHON3HOME");
> ++}
> + if (res < 0) {
> + return DECODE_LOCALE_ERR("PYTHONHOME", res);
> + }
> +--
> +2.7.4

I think the above will leak memory.

Instead I think the code should be something like:

int res;
const char *oepython3home = config_get_env_var("OEPYTHON3HOME");
if (oepython3home) {
res = config_get_env_var_dup(, L"OEPYTHON3HOME", "OEPYTHON3HOME");
if (res < 0)
return DECODE_LOCALE_ERR("OEPYTHON3HOME", res); } else {
res = config_get_env_var_dup(, L"PYTHONHOME", "PYTHONHOME");
if (res < 0)
return DECODE_LOCALE_ERR("PYTHONHOME", res); }

and then a copy of PYTHONHOME isn't created in the OEPYTHON3HOME case.

Cheers,

Richard

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


[OE-core] [master][RFC] Adding back wrapper and using OEPYTHON3HOME variable for python3

2019-04-26 Thread Jaewon Lee
Adding back the python wrapper and adding a patch to use OEPYTHON3HOME
instead of PYTHONHOME if set, for python3.

If we add back the wrapper as is, we would see the following error that
we also see in Thud:

ImportError: No module named site
OpenEmbedded requires 'python' to be python v2 (>= 2.7.3), not python
v3.
Please upgrade your python v2

This is because python3 would've set PYTHONHOME to use nativesdk
python3 libraries but when the oe-buildenv-internal script tries to call
python2 for the py_v27_check, there will be no python2 libraries in the
PYTHONHOME directory.
In other words, bitbake needs host python2 and the env variable set from
the wrapper contaminates the env and host python2 won't be able to find
its libraries

Creating another variable OEPYTHON3HOME and using this in the python3
wrapper to allow for a way to set a different paths for python3 and
python2

[YOCTO #13208]

Signed-off-by: Jaewon Lee 
Signed-off-by: Alejandro Enedino Hernandez Samaniego 
---
 ...EPYTHON3HOME-is-set-use-instead-of-PYTHON.patch | 35 ++
 meta/recipes-devtools/python/python3_3.7.3.bb  |  7 +
 2 files changed, 42 insertions(+)
 create mode 100644 
meta/recipes-devtools/python/python3/0001-main.c-if-OEPYTHON3HOME-is-set-use-instead-of-PYTHON.patch

diff --git 
a/meta/recipes-devtools/python/python3/0001-main.c-if-OEPYTHON3HOME-is-set-use-instead-of-PYTHON.patch
 
b/meta/recipes-devtools/python/python3/0001-main.c-if-OEPYTHON3HOME-is-set-use-instead-of-PYTHON.patch
new file mode 100644
index 000..12aeab9
--- /dev/null
+++ 
b/meta/recipes-devtools/python/python3/0001-main.c-if-OEPYTHON3HOME-is-set-use-instead-of-PYTHON.patch
@@ -0,0 +1,35 @@
+From e4363ca1d84b4014184a79a847fb2affb3dfe86e Mon Sep 17 00:00:00 2001
+From: Jaewon Lee 
+Date: Tue, 23 Apr 2019 17:01:08 -0700
+Subject: [PATCH] main.c: if OEPYTHON3HOME is set use instead of PYTHONHOME
+
+There is one variable PYTHONHOME to determine where libraries are coming
+from for both python2 and python3. This becomes an issue if only one has
+libraries in the specified PYTHONHOME path, but they are using the same
+PYTHONHOME. Creating another variable OEPYTHON3HOME to allow for a way
+to set a different path for python3
+
+Signed-off-by: Jaewon Lee 
+---
+ Modules/main.c | 5 +
+ 1 file changed, 5 insertions(+)
+
+diff --git a/Modules/main.c b/Modules/main.c
+index a745381..25ca435 100644
+--- a/Modules/main.c
 b/Modules/main.c
+@@ -1857,6 +1857,11 @@ config_init_home(_PyCoreConfig *config)
+ }
+ 
+ int res = config_get_env_var_dup(, L"PYTHONHOME", "PYTHONHOME");
++
++const char *oepython3home = config_get_env_var("OEPYTHON3HOME");
++if (oepython3home) {
++res = config_get_env_var_dup(, L"OEPYTHON3HOME", 
"OEPYTHON3HOME");
++}
+ if (res < 0) {
+ return DECODE_LOCALE_ERR("PYTHONHOME", res);
+ }
+-- 
+2.7.4
+
diff --git a/meta/recipes-devtools/python/python3_3.7.3.bb 
b/meta/recipes-devtools/python/python3_3.7.3.bb
index ea46b05..af7ede1 100644
--- a/meta/recipes-devtools/python/python3_3.7.3.bb
+++ b/meta/recipes-devtools/python/python3_3.7.3.bb
@@ -28,6 +28,9 @@ SRC_URI_append_class-native = " \

file://0001-distutils-sysconfig-append-STAGING_LIBDIR-python-sys.patch \
file://12-distutils-prefix-is-inside-staging-area.patch \
"
+SRC_URI_append_class-nativesdk = " \
+   
file://0001-main.c-if-OEPYTHON3HOME-is-set-use-instead-of-PYTHON.patch \
+   "
 
 SRC_URI[md5sum] = "93df27aec0cd18d6d42173e601ffbbfd"
 SRC_URI[sha256sum] = 
"da60b54064d4cfcd9c26576f6df2690e62085123826cff2e667e72a91952d318"
@@ -131,6 +134,10 @@ do_install_append() {
 ${D}${libdir}/python-sysconfigdata/_sysconfigdata.py
 }
 
+do_install_append_class-nativesdk () {
+create_wrapper ${D}${bindir}/python${PYTHON_MAJMIN} 
OEPYTHON3HOME='${prefix}' 
TERMINFO_DIRS='${sysconfdir}/terminfo:/etc/terminfo:/usr/share/terminfo:/usr/share/misc/terminfo:/lib/terminfo'
 PYTHONNOUSERSITE='1'
+}
+
 SSTATE_SCAN_FILES += "Makefile _sysconfigdata.py"
 PACKAGE_PREPROCESS_FUNCS += "py_package_preprocess"
 
-- 
2.7.4

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


[OE-core] [master][RFC v3] Adding back wrapper and using OEPYTHON3HOME variable for python3

2019-04-26 Thread Jaewon Lee
Adding back the python wrapper and adding a patch to use OEPYTHON3HOME
instead of PYTHONHOME if set, for python3.

If we add back the wrapper as is, we would see the following error that
we also see in Thud:

ImportError: No module named site
OpenEmbedded requires 'python' to be python v2 (>= 2.7.3), not python
v3.
Please upgrade your python v2

This is because python3 would've set PYTHONHOME to use nativesdk
python3 libraries but when the oe-buildenv-internal script tries to call
python2 for the py_v27_check, there will be no python2 libraries in the
PYTHONHOME directory.
In other words, bitbake needs host python2 and the env variable set from
the wrapper contaminates the env and host python2 won't be able to find
its libraries

Creating another variable OEPYTHON3HOME and using this in the python3
wrapper to allow for a way to set a different paths for python3 and
python2

[YOCTO #13208]

Signed-off-by: Jaewon Lee 
Signed-off-by: Alejandro Enedino Hernandez Samaniego 
---
changelog:
v2: change python3 patch to avoid mem leak
v3: fix tabs and spaces issue

---
 ...EPYTHON3HOME-is-set-use-instead-of-PYTHON.patch | 47 ++
 meta/recipes-devtools/python/python3_3.7.3.bb  |  7 
 2 files changed, 54 insertions(+)
 create mode 100644 
meta/recipes-devtools/python/python3/0001-main.c-if-OEPYTHON3HOME-is-set-use-instead-of-PYTHON.patch

diff --git 
a/meta/recipes-devtools/python/python3/0001-main.c-if-OEPYTHON3HOME-is-set-use-instead-of-PYTHON.patch
 
b/meta/recipes-devtools/python/python3/0001-main.c-if-OEPYTHON3HOME-is-set-use-instead-of-PYTHON.patch
new file mode 100644
index 000..06eb2bd
--- /dev/null
+++ 
b/meta/recipes-devtools/python/python3/0001-main.c-if-OEPYTHON3HOME-is-set-use-instead-of-PYTHON.patch
@@ -0,0 +1,47 @@
+From ffe7797637f08cd6ee4c82e2d67462c5e194d30a Mon Sep 17 00:00:00 2001
+From: Jaewon Lee 
+Date: Thu, 25 Apr 2019 15:34:26 -0700
+Subject: [PATCH] main.c: if OEPYTHON3HOME is set use instead of PYTHONHOME
+
+There is one variable PYTHONHOME to determine where libraries are coming
+from for both python2 and python3. This becomes an issue if only one has
+libraries in the specified PYTHONHOME path, but they are using the same
+PYTHONHOME. Creating another variable OEPYTHON3HOME to allow for a way
+to set a different path for python3
+
+Signed-off-by: Jaewon Lee 
+---
+ Modules/main.c | 17 +
+ 1 file changed, 13 insertions(+), 4 deletions(-)
+
+diff --git a/Modules/main.c b/Modules/main.c
+index a745381..b553e30 100644
+--- a/Modules/main.c
 b/Modules/main.c
+@@ -1855,10 +1855,19 @@ config_init_home(_PyCoreConfig *config)
+ }
+ return _Py_INIT_OK();
+ }
+-
+-int res = config_get_env_var_dup(, L"PYTHONHOME", "PYTHONHOME");
+-if (res < 0) {
+-return DECODE_LOCALE_ERR("PYTHONHOME", res);
++int res;
++const char *oepython3home = config_get_env_var("OEPYTHON3HOME");
++if (oepython3home) {
++res = config_get_env_var_dup(, L"OEPYTHON3HOME", 
"OEPYTHON3HOME");
++if (res < 0) {
++return DECODE_LOCALE_ERR("OEPYTHON3HOME", res);
++}
++}
++else {
++res = config_get_env_var_dup(, L"PYTHONHOME", "PYTHONHOME");
++if (res < 0) {
++return DECODE_LOCALE_ERR("PYTHONHOME", res);
++}
+ }
+ config->home = home;
+ return _Py_INIT_OK();
+-- 
+2.7.4
+
diff --git a/meta/recipes-devtools/python/python3_3.7.3.bb 
b/meta/recipes-devtools/python/python3_3.7.3.bb
index ea46b05..af7ede1 100644
--- a/meta/recipes-devtools/python/python3_3.7.3.bb
+++ b/meta/recipes-devtools/python/python3_3.7.3.bb
@@ -28,6 +28,9 @@ SRC_URI_append_class-native = " \

file://0001-distutils-sysconfig-append-STAGING_LIBDIR-python-sys.patch \
file://12-distutils-prefix-is-inside-staging-area.patch \
"
+SRC_URI_append_class-nativesdk = " \
+   
file://0001-main.c-if-OEPYTHON3HOME-is-set-use-instead-of-PYTHON.patch \
+   "
 
 SRC_URI[md5sum] = "93df27aec0cd18d6d42173e601ffbbfd"
 SRC_URI[sha256sum] = 
"da60b54064d4cfcd9c26576f6df2690e62085123826cff2e667e72a91952d318"
@@ -131,6 +134,10 @@ do_install_append() {
 ${D}${libdir}/python-sysconfigdata/_sysconfigdata.py
 }
 
+do_install_append_class-nativesdk () {
+create_wrapper ${D}${bindir}/python${PYTHON_MAJMIN} 
OEPYTHON3HOME='${prefix}' 
TERMINFO_DIRS='${sysconfdir}/terminfo:/etc/terminfo:/usr/share/terminfo:/usr/share/misc/terminfo:/lib/terminfo'
 PYTHONNOUSERSITE='1'
+}
+
 SSTATE_SCAN_FILES += "Makefile _sysconfigdata.py"
 PACKAGE_PREPROCESS_FUNCS += "py_package_preprocess"
 
-- 
2.7.4

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


[OE-core] [master][RFC v2] Adding back wrapper and using OEPYTHON3HOME variable for python3

2019-04-26 Thread Jaewon Lee
Adding back the python wrapper and adding a patch to use OEPYTHON3HOME
instead of PYTHONHOME if set, for python3.

If we add back the wrapper as is, we would see the following error that
we also see in Thud:

ImportError: No module named site
OpenEmbedded requires 'python' to be python v2 (>= 2.7.3), not python
v3.
Please upgrade your python v2

This is because python3 would've set PYTHONHOME to use nativesdk
python3 libraries but when the oe-buildenv-internal script tries to call
python2 for the py_v27_check, there will be no python2 libraries in the
PYTHONHOME directory.
In other words, bitbake needs host python2 and the env variable set from
the wrapper contaminates the env and host python2 won't be able to find
its libraries

Creating another variable OEPYTHON3HOME and using this in the python3
wrapper to allow for a way to set a different paths for python3 and
python2

[YOCTO #13208]

Signed-off-by: Jaewon Lee 
Signed-off-by: Alejandro Enedino Hernandez Samaniego 
---
 ...EPYTHON3HOME-is-set-use-instead-of-PYTHON.patch | 47 ++
 meta/recipes-devtools/python/python3_3.7.3.bb  |  7 
 2 files changed, 54 insertions(+)
 create mode 100644 
meta/recipes-devtools/python/python3/0001-main.c-if-OEPYTHON3HOME-is-set-use-instead-of-PYTHON.patch

diff --git 
a/meta/recipes-devtools/python/python3/0001-main.c-if-OEPYTHON3HOME-is-set-use-instead-of-PYTHON.patch
 
b/meta/recipes-devtools/python/python3/0001-main.c-if-OEPYTHON3HOME-is-set-use-instead-of-PYTHON.patch
new file mode 100644
index 000..5a59a67
--- /dev/null
+++ 
b/meta/recipes-devtools/python/python3/0001-main.c-if-OEPYTHON3HOME-is-set-use-instead-of-PYTHON.patch
@@ -0,0 +1,47 @@
+From 347e5e080f5bbd2e18562d5f99ec61d706cb1cd8 Mon Sep 17 00:00:00 2001
+From: Jaewon Lee 
+Date: Thu, 25 Apr 2019 15:34:26 -0700
+Subject: [PATCH] main.c: if OEPYTHON3HOME is set use instead of PYTHONHOME
+
+There is one variable PYTHONHOME to determine where libraries are coming
+from for both python2 and python3. This becomes an issue if only one has
+libraries in the specified PYTHONHOME path, but they are using the same
+PYTHONHOME. Creating another variable OEPYTHON3HOME to allow for a way
+to set a different path for python3
+
+Signed-off-by: Jaewon Lee 
+---
+ Modules/main.c | 17 +
+ 1 file changed, 13 insertions(+), 4 deletions(-)
+
+diff --git a/Modules/main.c b/Modules/main.c
+index a745381..27ce112 100644
+--- a/Modules/main.c
 b/Modules/main.c
+@@ -1855,10 +1855,19 @@ config_init_home(_PyCoreConfig *config)
+ }
+ return _Py_INIT_OK();
+ }
+-
+-int res = config_get_env_var_dup(, L"PYTHONHOME", "PYTHONHOME");
+-if (res < 0) {
+-return DECODE_LOCALE_ERR("PYTHONHOME", res);
++int res;
++const char *oepython3home = config_get_env_var("OEPYTHON3HOME");
++if (oepython3home) {
++res = config_get_env_var_dup(, L"OEPYTHON3HOME", 
"OEPYTHON3HOME");
++if (res < 0) {
++return DECODE_LOCALE_ERR("OEPYTHON3HOME", res);
++}
++}
++else {
++  res = config_get_env_var_dup(, L"PYTHONHOME", "PYTHONHOME");
++if (res < 0) {
++return DECODE_LOCALE_ERR("PYTHONHOME", res);
++}
+ }
+ config->home = home;
+ return _Py_INIT_OK();
+-- 
+2.7.4
+
diff --git a/meta/recipes-devtools/python/python3_3.7.3.bb 
b/meta/recipes-devtools/python/python3_3.7.3.bb
index ea46b05..af7ede1 100644
--- a/meta/recipes-devtools/python/python3_3.7.3.bb
+++ b/meta/recipes-devtools/python/python3_3.7.3.bb
@@ -28,6 +28,9 @@ SRC_URI_append_class-native = " \

file://0001-distutils-sysconfig-append-STAGING_LIBDIR-python-sys.patch \
file://12-distutils-prefix-is-inside-staging-area.patch \
"
+SRC_URI_append_class-nativesdk = " \
+   
file://0001-main.c-if-OEPYTHON3HOME-is-set-use-instead-of-PYTHON.patch \
+   "
 
 SRC_URI[md5sum] = "93df27aec0cd18d6d42173e601ffbbfd"
 SRC_URI[sha256sum] = 
"da60b54064d4cfcd9c26576f6df2690e62085123826cff2e667e72a91952d318"
@@ -131,6 +134,10 @@ do_install_append() {
 ${D}${libdir}/python-sysconfigdata/_sysconfigdata.py
 }
 
+do_install_append_class-nativesdk () {
+create_wrapper ${D}${bindir}/python${PYTHON_MAJMIN} 
OEPYTHON3HOME='${prefix}' 
TERMINFO_DIRS='${sysconfdir}/terminfo:/etc/terminfo:/usr/share/terminfo:/usr/share/misc/terminfo:/lib/terminfo'
 PYTHONNOUSERSITE='1'
+}
+
 SSTATE_SCAN_FILES += "Makefile _sysconfigdata.py"
 PACKAGE_PREPROCESS_FUNCS += "py_package_preprocess"
 
-- 
2.7.4

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


Re: [OE-core] [oe-core][master][PATCH] Introduce mechanism to keep nativesdk* sstate in esdk

2019-08-29 Thread Jaewon Lee
ping

> -Original Message-
> From: Jaewon Lee 
> Sent: Monday, April 1, 2019 5:07 PM
> To: openembedded-core@lists.openembedded.org; Alejandro Enedino
> Hernandez Samaniego ; Manjukumar Harthikote
> Matha ; Bruce Ashfield 
> Cc: Jaewon Lee 
> Subject: [oe-core][master][PATCH] Introduce mechanism to keep nativesdk*
> sstate in esdk
> 
> Using SDK_INCLUDE_NATIVESDK flag to toggle inclusion of all nativesdk*
> sstate into esdk Currently locked-sigs.inc is generated during
> do_sdk_depends which doesn't pull in nativesdk packages. Generating
> another locked-sigs.inc in do_populate_sdk_ext and pruning it to only
> nativesdk* packages by using a modified version of the already existing
> function prune_locked_sigs and merging it with the current locked-sigs.inc
> Also adding SDK_INCLUDE_NATIVESDK tasklistfn to the logic surrounding
> setting tasklist file to not prune esdk sstate during creation
> 
> Signed-off-by: Jaewon Lee 
> ---
>  meta/classes/populate_sdk_ext.bbclass | 28
> +++-
>  meta/lib/oe/copy_buildsystem.py   |  8 ++--
>  2 files changed, 33 insertions(+), 3 deletions(-)
> 
> diff --git a/meta/classes/populate_sdk_ext.bbclass
> b/meta/classes/populate_sdk_ext.bbclass
> index 40b0375..d98b0e5 100644
> --- a/meta/classes/populate_sdk_ext.bbclass
> +++ b/meta/classes/populate_sdk_ext.bbclass
> @@ -20,6 +20,7 @@ SDK_EXT_task-populate-sdk-ext = "-ext"
>  SDK_EXT_TYPE ?= "full"
>  SDK_INCLUDE_PKGDATA ?= "0"
>  SDK_INCLUDE_TOOLCHAIN ?= "${@'1' if d.getVar('SDK_EXT_TYPE') == 'full'
> else '0'}"
> +SDK_INCLUDE_NATIVESDK ?= "0"
> 
>  SDK_RECRDEP_TASKS ?= ""
> 
> @@ -401,9 +402,27 @@ python copy_buildsystem () {
>  excluded_targets = get_sdk_install_targets(d, images_only=True)
>  sigfile = d.getVar('WORKDIR') + '/locked-sigs.inc'
>  lockedsigs_pruned = baseoutpath + '/conf/locked-sigs.inc'
> +#nativesdk-only sigfile to merge into locked-sigs.inc
> +sdk_include_nativesdk = (d.getVar("SDK_INCLUDE_NATIVESDK") == '1')
> +nativesigfile = d.getVar('WORKDIR') + '/locked-sigs_nativesdk.inc'
> +nativesigfile_pruned = d.getVar('WORKDIR') + '/locked-
> sigs_nativesdk_pruned.inc'
> +
> +if sdk_include_nativesdk:
> +oe.copy_buildsystem.prune_lockedsigs([],
> +  excluded_targets.split(),
> +  nativesigfile,
> + True,
> + nativesigfile_pruned)
> +
> +oe.copy_buildsystem.merge_lockedsigs([],
> +  sigfile,
> +  nativesigfile_pruned,
> +  sigfile)
> +
>  oe.copy_buildsystem.prune_lockedsigs([],
>   excluded_targets.split(),
>   sigfile,
> + False,
>   lockedsigs_pruned)
> 
>  sstate_out = baseoutpath + '/sstate-cache'
> @@ -414,7 +433,7 @@ python copy_buildsystem () {
> 
>  sdk_include_toolchain = (d.getVar('SDK_INCLUDE_TOOLCHAIN') == '1')
>  sdk_ext_type = d.getVar('SDK_EXT_TYPE')
> -if sdk_ext_type != 'minimal' or sdk_include_toolchain or derivative:
> +if (sdk_ext_type != 'minimal' or sdk_include_toolchain or derivative) and
> not sdk_include_nativesdk:
>  # Create the filtered task list used to generate the sstate cache 
> shipped
> with the SDK
>  tasklistfn = d.getVar('WORKDIR') + '/tasklist.txt'
>  create_filtered_tasklist(d, baseoutpath, tasklistfn, conf_initpath) 
> @@ -
> 658,9 +677,16 @@ fakeroot python do_populate_sdk_ext() {
>  d.setVar('SDKDEPLOYDIR', '${SDKEXTDEPLOYDIR}')
>  # ESDKs have a libc from the buildtools so ensure we don't ship linguas
> twice
>  d.delVar('SDKIMAGE_LINGUAS')
> +if d.getVar("SDK_INCLUDE_NATIVESDK") == '1':
> +generate_nativesdk_lockedsigs(d)
>  populate_sdk_common(d)
>  }
> 
> +def generate_nativesdk_lockedsigs(d):
> +import oe.copy_buildsystem
> +sigfile = d.getVar('WORKDIR') + '/locked-sigs_nativesdk.inc'
> +oe.copy_buildsystem.generate_locked_sigs(sigfile, d)
> +
>  def get_ext_sdk_depends(d):
>  # Note: the deps varflag is a list not a string, so we need to specify
> expand=False
>  deps = d.getVarFlag('do_image_complete', 'deps', False) diff --git
> a/meta/lib/oe/copy_buildsystem.py b/meta/lib/oe/copy_buildsystem.py
> index 7cb784c..5bc728e 100644
> --- a/meta/lib/oe/copy_

[OE-core] [master][PATCH v2] Introduce mechanism to keep nativesdk* sstate in esdk

2019-09-17 Thread Jaewon Lee
When doing a devtool build-sdk from within an esdk all nativesdk
components would be rebuilt. This patch introduces SDK_INCLUDE_NATIVESDK
flag to toggle the inclusion of nativesdk packages when creating the
esdk sstate

Currently locked-sigs.inc is generated during do_sdk_depends which
doesn't pull in nativesdk packages. Generating another locked-sigs.inc
in do_populate_sdk_ext and pruning it to only nativesdk* packages by
using a modified version of the already existing function
prune_locked_sigs and merging it with the current locked-sigs.inc
Also adding SDK_INCLUDE_NATIVESDK tasklistfn to the logic surrounding
setting tasklist file to not prune esdk sstate during creation

Fixes [YOCTO #13261]

Signed-off-by: Jaewon Lee 
---
Changes in v2:
change to commit message to include reason
got rid of some tabs
rebased to apply on master
---
 meta/classes/populate_sdk_ext.bbclass | 28 +++-
 meta/lib/oe/copy_buildsystem.py   |  8 ++--
 2 files changed, 33 insertions(+), 3 deletions(-)

diff --git a/meta/classes/populate_sdk_ext.bbclass 
b/meta/classes/populate_sdk_ext.bbclass
index 800e117..086f55d 100644
--- a/meta/classes/populate_sdk_ext.bbclass
+++ b/meta/classes/populate_sdk_ext.bbclass
@@ -20,6 +20,7 @@ SDK_EXT_task-populate-sdk-ext = "-ext"
 SDK_EXT_TYPE ?= "full"
 SDK_INCLUDE_PKGDATA ?= "0"
 SDK_INCLUDE_TOOLCHAIN ?= "${@'1' if d.getVar('SDK_EXT_TYPE') == 'full' else 
'0'}"
+SDK_INCLUDE_NATIVESDK ?= "0"
 
 SDK_RECRDEP_TASKS ?= ""
 
@@ -401,9 +402,27 @@ python copy_buildsystem () {
 excluded_targets = get_sdk_install_targets(d, images_only=True)
 sigfile = d.getVar('WORKDIR') + '/locked-sigs.inc'
 lockedsigs_pruned = baseoutpath + '/conf/locked-sigs.inc'
+#nativesdk-only sigfile to merge into locked-sigs.inc
+sdk_include_nativesdk = (d.getVar("SDK_INCLUDE_NATIVESDK") == '1')
+nativesigfile = d.getVar('WORKDIR') + '/locked-sigs_nativesdk.inc'
+nativesigfile_pruned = d.getVar('WORKDIR') + 
'/locked-sigs_nativesdk_pruned.inc'
+
+if sdk_include_nativesdk:
+oe.copy_buildsystem.prune_lockedsigs([],
+ excluded_targets.split(),
+ nativesigfile,
+ True,
+ nativesigfile_pruned)
+
+oe.copy_buildsystem.merge_lockedsigs([],
+ sigfile,
+ nativesigfile_pruned,
+ sigfile)
+
 oe.copy_buildsystem.prune_lockedsigs([],
  excluded_targets.split(),
  sigfile,
+ False,
  lockedsigs_pruned)
 
 sstate_out = baseoutpath + '/sstate-cache'
@@ -414,7 +433,7 @@ python copy_buildsystem () {
 
 sdk_include_toolchain = (d.getVar('SDK_INCLUDE_TOOLCHAIN') == '1')
 sdk_ext_type = d.getVar('SDK_EXT_TYPE')
-if sdk_ext_type != 'minimal' or sdk_include_toolchain or derivative:
+if (sdk_ext_type != 'minimal' or sdk_include_toolchain or derivative) and 
not sdk_include_nativesdk:
 # Create the filtered task list used to generate the sstate cache 
shipped with the SDK
 tasklistfn = d.getVar('WORKDIR') + '/tasklist.txt'
 create_filtered_tasklist(d, baseoutpath, tasklistfn, conf_initpath)
@@ -657,9 +676,16 @@ fakeroot python do_populate_sdk_ext() {
 d.setVar('SDKDEPLOYDIR', '${SDKEXTDEPLOYDIR}')
 # ESDKs have a libc from the buildtools so ensure we don't ship linguas 
twice
 d.delVar('SDKIMAGE_LINGUAS')
+if d.getVar("SDK_INCLUDE_NATIVESDK") == '1':
+generate_nativesdk_lockedsigs(d)
 populate_sdk_common(d)
 }
 
+def generate_nativesdk_lockedsigs(d):
+import oe.copy_buildsystem
+sigfile = d.getVar('WORKDIR') + '/locked-sigs_nativesdk.inc'
+oe.copy_buildsystem.generate_locked_sigs(sigfile, d)
+
 def get_ext_sdk_depends(d):
 # Note: the deps varflag is a list not a string, so we need to specify 
expand=False
 deps = d.getVarFlag('do_image_complete', 'deps', False)
diff --git a/meta/lib/oe/copy_buildsystem.py b/meta/lib/oe/copy_buildsystem.py
index cb663b2..31a84f5 100644
--- a/meta/lib/oe/copy_buildsystem.py
+++ b/meta/lib/oe/copy_buildsystem.py
@@ -177,7 +177,7 @@ def generate_locked_sigs(sigfile, d):
 tasks = ['%s:%s' % (v[2], v[1]) for v in depd.values()]
 bb.parse.siggen.dump_lockedsigs(sigfile, tasks)
 
-def prune_lockedsigs(excluded_tasks, excluded_targets, lockedsigs, 
pruned_output):
+def prune_lockedsigs(excluded_tasks, excluded_targets, lockedsigs, onlynative, 
pruned_output):
 with open(lockedsigs, 'r') as infile:
 bb.utils.mkdirhier(os.path.dirname(pruned_output))
 with open(pr

Re: [OE-core] [oe-core][master][PATCH] Introduce mechanism to keep nativesdk* sstate in esdk

2019-09-17 Thread Jaewon Lee
Hi Paul,

> -Original Message-
> From: Paul Eggleton 
> Sent: Tuesday, September 17, 2019 3:05 PM
> To: Jaewon Lee 
> Cc: openembedded-core@lists.openembedded.org; Alejandro Enedino
> Hernandez Samaniego ; Manjukumar Harthikote
> Matha ; Bruce Ashfield 
> Subject: Re: [OE-core] [oe-core][master][PATCH] Introduce mechanism to
> keep nativesdk* sstate in esdk
> 
> Hi Jaewon
> 
> Richard was waiting for me to review this - unfortunately another one that
> fell between the cracks - sorry about that.
[Jaewon] No  problem!

> 
> On Friday, 30 August 2019 5:13:39 AM NZST Jaewon Lee wrote:
> > > -Original Message-
> > > From: Jaewon Lee 
> > > Sent: Monday, April 1, 2019 5:07 PM
> > > To: openembedded-core@lists.openembedded.org; Alejandro Enedino
> > > Hernandez Samaniego ; Manjukumar Harthikote
> > > Matha ; Bruce Ashfield 
> > > Cc: Jaewon Lee 
> > > Subject: [oe-core][master][PATCH] Introduce mechanism to keep
> > > nativesdk* sstate in esdk
> > >
> > > Using SDK_INCLUDE_NATIVESDK flag to toggle inclusion of all
> > > nativesdk* sstate into esdk Currently locked-sigs.inc is generated
> > > during do_sdk_depends which doesn't pull in nativesdk packages.
> > > Generating another locked-sigs.inc in do_populate_sdk_ext and
> > > pruning it to only
> > > nativesdk* packages by using a modified version of the already
> > > existing function prune_locked_sigs and merging it with the current
> > > locked-sigs.inc Also adding SDK_INCLUDE_NATIVESDK tasklistfn to the
> > > logic surrounding setting tasklist file to not prune esdk sstate
> > > during creation
> > >
> > > Signed-off-by: Jaewon Lee 
> 
> The commit message doesn't actually explain why you are adding this
> functionality. You explained it elsewhere (bug 13261) but it needs to be in
> here. I would also recommend adding a "Fixes [YOCTO #13261]" at the end so
> there's a reference back to the bug as well.
[Jaewon] Ok I will resend with commit fixed

> 
> > > @@ -414,7 +433,7 @@ python copy_buildsystem () {
> > >
> > >  sdk_include_toolchain = (d.getVar('SDK_INCLUDE_TOOLCHAIN') == '1')
> > >  sdk_ext_type = d.getVar('SDK_EXT_TYPE')
> > > -if sdk_ext_type != 'minimal' or sdk_include_toolchain or derivative:
> > > +if (sdk_ext_type != 'minimal' or sdk_include_toolchain or derivative)
> and not sdk_include_nativesdk:
> > >  # Create the filtered task list used to generate the sstate cache
> shipped with the SDK
> > >  tasklistfn = d.getVar('WORKDIR') + '/tasklist.txt'
> > >  create_filtered_tasklist(d, baseoutpath, tasklistfn,
> > > conf_initpath) @@ -
> 
> This logic change looks a bit odd. Are you sure this is correct?
[Jaewon] I kept the original logic and did a "and not" my flag 
Because if flag sdk_include_nativesdk is set I want tasklistfn to be none so 
esdksstate is not pruned during creation

Thanks,
Jaewon

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


[OE-core] [master][PATCH v3] esdk: Introduce mechanism to keep nativesdk* sstate in esdk

2019-09-18 Thread Jaewon Lee
When doing a devtool build-sdk from within an esdk all nativesdk
components would be rebuilt. This patch introduces SDK_INCLUDE_NATIVESDK
flag to toggle the inclusion of nativesdk packages when creating the
esdk sstate

Currently locked-sigs.inc is generated during do_sdk_depends which
doesn't pull in nativesdk packages. Generating another locked-sigs.inc
in do_populate_sdk_ext and pruning it to only nativesdk* packages by
using a modified version of the already existing function
prune_locked_sigs and merging it with the current locked-sigs.inc
Also adding SDK_INCLUDE_NATIVESDK tasklistfn to the logic surrounding
setting tasklist file to not prune esdk sstate during creation

Fixes [YOCTO #13261]

Signed-off-by: Jaewon Lee 
---
changes in v2:
change to commit message to include reason
got rid of some tabs
rebased to apply on master
changes in v3:
fix patchwork failure for format of short commit message
---
 meta/classes/populate_sdk_ext.bbclass | 28 +++-
 meta/lib/oe/copy_buildsystem.py   |  8 ++--
 2 files changed, 33 insertions(+), 3 deletions(-)

diff --git a/meta/classes/populate_sdk_ext.bbclass 
b/meta/classes/populate_sdk_ext.bbclass
index 800e117..086f55d 100644
--- a/meta/classes/populate_sdk_ext.bbclass
+++ b/meta/classes/populate_sdk_ext.bbclass
@@ -20,6 +20,7 @@ SDK_EXT_task-populate-sdk-ext = "-ext"
 SDK_EXT_TYPE ?= "full"
 SDK_INCLUDE_PKGDATA ?= "0"
 SDK_INCLUDE_TOOLCHAIN ?= "${@'1' if d.getVar('SDK_EXT_TYPE') == 'full' else 
'0'}"
+SDK_INCLUDE_NATIVESDK ?= "0"
 
 SDK_RECRDEP_TASKS ?= ""
 
@@ -401,9 +402,27 @@ python copy_buildsystem () {
 excluded_targets = get_sdk_install_targets(d, images_only=True)
 sigfile = d.getVar('WORKDIR') + '/locked-sigs.inc'
 lockedsigs_pruned = baseoutpath + '/conf/locked-sigs.inc'
+#nativesdk-only sigfile to merge into locked-sigs.inc
+sdk_include_nativesdk = (d.getVar("SDK_INCLUDE_NATIVESDK") == '1')
+nativesigfile = d.getVar('WORKDIR') + '/locked-sigs_nativesdk.inc'
+nativesigfile_pruned = d.getVar('WORKDIR') + 
'/locked-sigs_nativesdk_pruned.inc'
+
+if sdk_include_nativesdk:
+oe.copy_buildsystem.prune_lockedsigs([],
+ excluded_targets.split(),
+ nativesigfile,
+ True,
+ nativesigfile_pruned)
+
+oe.copy_buildsystem.merge_lockedsigs([],
+ sigfile,
+ nativesigfile_pruned,
+ sigfile)
+
 oe.copy_buildsystem.prune_lockedsigs([],
  excluded_targets.split(),
  sigfile,
+ False,
  lockedsigs_pruned)
 
 sstate_out = baseoutpath + '/sstate-cache'
@@ -414,7 +433,7 @@ python copy_buildsystem () {
 
 sdk_include_toolchain = (d.getVar('SDK_INCLUDE_TOOLCHAIN') == '1')
 sdk_ext_type = d.getVar('SDK_EXT_TYPE')
-if sdk_ext_type != 'minimal' or sdk_include_toolchain or derivative:
+if (sdk_ext_type != 'minimal' or sdk_include_toolchain or derivative) and 
not sdk_include_nativesdk:
 # Create the filtered task list used to generate the sstate cache 
shipped with the SDK
 tasklistfn = d.getVar('WORKDIR') + '/tasklist.txt'
 create_filtered_tasklist(d, baseoutpath, tasklistfn, conf_initpath)
@@ -657,9 +676,16 @@ fakeroot python do_populate_sdk_ext() {
 d.setVar('SDKDEPLOYDIR', '${SDKEXTDEPLOYDIR}')
 # ESDKs have a libc from the buildtools so ensure we don't ship linguas 
twice
 d.delVar('SDKIMAGE_LINGUAS')
+if d.getVar("SDK_INCLUDE_NATIVESDK") == '1':
+generate_nativesdk_lockedsigs(d)
 populate_sdk_common(d)
 }
 
+def generate_nativesdk_lockedsigs(d):
+import oe.copy_buildsystem
+sigfile = d.getVar('WORKDIR') + '/locked-sigs_nativesdk.inc'
+oe.copy_buildsystem.generate_locked_sigs(sigfile, d)
+
 def get_ext_sdk_depends(d):
 # Note: the deps varflag is a list not a string, so we need to specify 
expand=False
 deps = d.getVarFlag('do_image_complete', 'deps', False)
diff --git a/meta/lib/oe/copy_buildsystem.py b/meta/lib/oe/copy_buildsystem.py
index cb663b2..31a84f5 100644
--- a/meta/lib/oe/copy_buildsystem.py
+++ b/meta/lib/oe/copy_buildsystem.py
@@ -177,7 +177,7 @@ def generate_locked_sigs(sigfile, d):
 tasks = ['%s:%s' % (v[2], v[1]) for v in depd.values()]
 bb.parse.siggen.dump_lockedsigs(sigfile, tasks)
 
-def prune_lockedsigs(excluded_tasks, excluded_targets, lockedsigs, 
pruned_output):
+def prune_lockedsigs(excluded_tasks, excluded_targets, lockedsigs, onlynative, 
pruned_output):
 with open(lockedsigs, 'r') as infile:
 bb.util

[OE-core] [master][PATCH] standard.py: Not filtering devtool workspace for devtool finish

2019-09-19 Thread Jaewon Lee
All devtool commands right now are filtering out the devtool workspace
bbappends in build/workspace/appends when calling parse_recipe. While
this may make sense for devtool add and modify, we need devtool finish
to include those appends.

A specific breakage that is caused because devtool finish filters devtool
appends is the cmake/cml1 flow where a file is created in the WORKDIR
that finish needs access to, to commit those files. Particularly for
git packages with SRCPV in PV, SRCPV is only changed to 999 when using
external source, hence when creating the cfg or cmake config files using
for instance bitbake -c diffconfig, these files are created in the
git999 workdir correctly (as in the devtool bbapends, we are inheriting
externalsrc class). But when devtool finish is run, the devtool appends
are not parsed, hence SRCPV is not changed to 999 and devtool is looking
for the fragment files in the wrong WORKDIR.

Changing the parse_recipe call just in devtool finish to not filter out
the devtool workspace.

Fixes [YOCTO #13533]

Signed-off-by: Jaewon Lee 
---
 scripts/lib/devtool/standard.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/lib/devtool/standard.py b/scripts/lib/devtool/standard.py
index 9eeaefb..e87b433 100644
--- a/scripts/lib/devtool/standard.py
+++ b/scripts/lib/devtool/standard.py
@@ -2011,7 +2011,7 @@ def finish(args, config, basepath, workspace):
 no_clean = False
 tinfoil = setup_tinfoil(basepath=basepath, tracking=True)
 try:
-rd = parse_recipe(config, tinfoil, args.recipename, True)
+rd = parse_recipe(config, tinfoil, args.recipename, True, False)
 if not rd:
 return 1
 
-- 
2.7.4

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


Re: [OE-core] [master][PATCH] standard.py: Not filtering devtool workspace for devtool finish

2019-10-02 Thread Jaewon Lee
ping

> -Original Message-
> From: Jaewon Lee 
> Sent: Thursday, September 19, 2019 5:13 PM
> To: openembedded-core@lists.openembedded.org;
> paul.eggle...@linux.intel.com; Manjukumar Harthikote Matha
> ; Alejandro Enedino Hernandez Samaniego
> 
> Cc: Jaewon Lee 
> Subject: [OE-core][master][PATCH] standard.py: Not filtering devtool
> workspace for devtool finish
> 
> All devtool commands right now are filtering out the devtool workspace
> bbappends in build/workspace/appends when calling parse_recipe. While
> this may make sense for devtool add and modify, we need devtool finish to
> include those appends.
> 
> A specific breakage that is caused because devtool finish filters devtool
> appends is the cmake/cml1 flow where a file is created in the WORKDIR that
> finish needs access to, to commit those files. Particularly for git packages 
> with
> SRCPV in PV, SRCPV is only changed to 999 when using external source,
> hence when creating the cfg or cmake config files using for instance bitbake -
> c diffconfig, these files are created in the
> git999 workdir correctly (as in the devtool bbapends, we are inheriting
> externalsrc class). But when devtool finish is run, the devtool appends are
> not parsed, hence SRCPV is not changed to 999 and devtool is looking for the
> fragment files in the wrong WORKDIR.
> 
> Changing the parse_recipe call just in devtool finish to not filter out the
> devtool workspace.
> 
> Fixes [YOCTO #13533]
> 
> Signed-off-by: Jaewon Lee 
> ---
>  scripts/lib/devtool/standard.py | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/scripts/lib/devtool/standard.py b/scripts/lib/devtool/standard.py
> index 9eeaefb..e87b433 100644
> --- a/scripts/lib/devtool/standard.py
> +++ b/scripts/lib/devtool/standard.py
> @@ -2011,7 +2011,7 @@ def finish(args, config, basepath, workspace):
>  no_clean = False
>  tinfoil = setup_tinfoil(basepath=basepath, tracking=True)
>  try:
> -rd = parse_recipe(config, tinfoil, args.recipename, True)
> +rd = parse_recipe(config, tinfoil, args.recipename, True,
> + False)
>  if not rd:
>  return 1
> 
> --
> 2.7.4

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


[OE-core] [master][PATCH] devtool: ccmake: Pulling in available ccmake functionality to devtool

2019-10-02 Thread Jaewon Lee
Pulling in available ccmake functionality to devtool.  Running devtool
ccmake ${PN} will call bitbake -c ccmake which will pull up an ncurses
menu where the user can modify config options. After the menu is exited
it will use the same logic available in ccmake.bbclass to generate
configuration.inc and site-file.cmake file and place into
oe-local-files.

The changes can be tested, then committed using:

devtool finish ${PN} /pathtolayer -f

The '-f' is needed as ${B}/CMakeCache.txt is soft linked to
${S}/CMakeCache.txt.new as devtool is not able to access ${B} because
it ignores the bbappends in build/workspace and this is the only way to
reflect the changes from bitbake -c ccmake.

Multiple devtool ccmake calls will create the diff between the
original CMakeCache.txt file (when calling devtool modify) and final
configuration.

Signed-off-by: Jaewon Lee 
---
 scripts/lib/devtool/ccmake.py   | 73 +
 scripts/lib/devtool/standard.py | 68 ++
 2 files changed, 141 insertions(+)
 create mode 100644 scripts/lib/devtool/ccmake.py

diff --git a/scripts/lib/devtool/ccmake.py b/scripts/lib/devtool/ccmake.py
new file mode 100644
index 000..c9597c3
--- /dev/null
+++ b/scripts/lib/devtool/ccmake.py
@@ -0,0 +1,73 @@
+# OpenEmbedded Development tool - ccmake command plugin
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License version 2 as
+# published by the Free Software Foundation.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License along
+# with this program; if not, write to the Free Software Foundation, Inc.,
+# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+
+"""Devtool ccmake plugin"""
+
+import os
+import bb
+import logging
+import argparse
+import re
+import glob
+from devtool import setup_tinfoil, parse_recipe, DevtoolError, standard, 
exec_build_env_command
+
+logger = logging.getLogger('devtool')
+
+def ccmake(args, config, basepath, workspace):
+"""Entry point for the devtool 'ccmake' subcommand"""
+
+rd = ""
+localfilesdir = ""
+
+tinfoil = setup_tinfoil(basepath=basepath)
+try:
+  rd = parse_recipe(config, tinfoil, args.component, appends=True, 
filter_workspace=False)
+  if not rd:
+ return 1
+
+  pn =  rd.getVar('PN', True)
+  if pn not in workspace:
+ raise DevtoolError("Run devtool modify before calling ccmake for %s" 
%pn)
+
+  if not rd.getVarFlag('do_ccmake','task'):
+ raise DevtoolError("This package does not support ccmake option")
+
+  srctree=rd.getVar('S',True)
+
+  #add check to see if oe_local_files exists or not
+  localfilesdir = os.path.join(srctree,'oe-local-files')
+  if not os.path.exists(localfilesdir):
+  bb.utils.mkdirhier(localfilesdir)
+  #Add gitignore to ensure source tree is clean
+  gitignorefile = os.path.join(localfilesdir,'.gitignore')
+  with open(gitignorefile, 'w') as f:
+  f.write('# Ignore local files, by default. Remove this file 
if you want to commit the directory to Git\n')
+  f.write('*\n')
+
+finally:
+  tinfoil.shutdown()
+
+logger.info('Launching ccmake')
+exec_build_env_command(config.init_path, basepath, 'bitbake -c ccmake %s' 
% pn, watch=True)
+
+standard._create_cmake_diff(srctree,rd)
+
+return 0
+
+def register_commands(subparsers, context):
+"""register devtool subcommands from this plugin"""
+parser_ccmake = subparsers.add_parser('ccmake',help='HELP', 
description='Launches the make ccmake command(for recipes where do_ccmake is 
available), allowing users to make changes to the build-time configuration. 
Creates a config fragment corresponding to changes made.', group='advanced')
+parser_ccmake.add_argument('component', help='component to alter config')
+parser_ccmake.set_defaults(func=ccmake,fixed_setup=context.fixed_setup)
diff --git a/scripts/lib/devtool/standard.py b/scripts/lib/devtool/standard.py
index 60c9a04..c942798 100644
--- a/scripts/lib/devtool/standard.py
+++ b/scripts/lib/devtool/standard.py
@@ -943,6 +943,11 @@ def modify(args, config, basepath, workspace):
 'cp ${B}/.config ${S}/.config.baseline\n'
 'ln -sfT ${B}/.config ${S}/.config.new\n'
 '}\n')
+if rd.getVarFlag('do_ccmake','task'):
+f.write('\ndo_configure_append() {\n'
+'cp ${B}/CMakeCache.txt ${S}/CMakeCache.txt.orig\n'
+ 

[OE-core] [PATCH] sstate.bbclass: fix issue while handling long sstate filenames

2020-02-05 Thread Jaewon Lee
When moving to python3, divison using '/' now returns float instead of
an integer. In upstream commit b8025e972081b70960ffcbcbe43a7118041556a1
sstate filenames longer than the limit are changed to just include
necessary info + 3 fields just for information. The space left over
after the necessary info is divided into 3 for each of the fields.
Casting the outcome of that division to int to solve the following error
message:

avail = (254 - len(hash + "_" + taskname + extension) -
len(components[0]) - len(components[1]) - len(components[5]) -
len(components[6]) - 7) / 3
>components[2] = components[2][:avail]
 components[3] = components[3][:avail]
TypeError: slice indices must be integers or None or have an __index__
method

Signed-off-by: Jaewon Lee 
Signed-off-by: Mark Hatle 
---
 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 faa6470..53a6d06 100644
--- a/meta/classes/sstate.bbclass
+++ b/meta/classes/sstate.bbclass
@@ -20,7 +20,7 @@ def generate_sstatefn(spec, hash, taskname, siginfo, d):
 components = spec.split(":")
 # Fields 0,5,6 are mandatory, 1 is most useful, 2,3,4 are just for 
information
 # 7 is for the separators
-avail = (254 - len(hash + "_" + taskname + extension) - 
len(components[0]) - len(components[1]) - len(components[5]) - 
len(components[6]) - 7) / 3
+avail = int((254 - len(hash + "_" + taskname + extension) - 
len(components[0]) - len(components[1]) - len(components[5]) - 
len(components[6]) - 7) / 3)
 components[2] = components[2][:avail]
 components[3] = components[3][:avail]
 components[4] = components[4][:avail]
-- 
2.7.4

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


[OE-core] [PATCH v2] sstate.bbclass: fix issue while handling long sstate filenames

2020-02-06 Thread Jaewon Lee
When moving to python3, divison using '/' now returns float instead of
an integer. In upstream commit b8025e972081b70960ffcbcbe43a7118041556a1
sstate filenames longer than the limit are changed to just include
necessary info + 3 fields just for information. The space left over
after the necessary info is divided into 3 for each of the fields.
Using '//' instead to do the division to solve the following error
message:

avail = (254 - len(hash + "_" + taskname + extension) -
len(components[0]) - len(components[1]) - len(components[5]) -
len(components[6]) - 7) / 3
>components[2] = components[2][:avail]
 components[3] = components[3][:avail]
TypeError: slice indices must be integers or None or have an __index__
method

Signed-off-by: Jaewon Lee 
Signed-off-by: Mark Hatle 
---
v2: used '//' instead of casting to int
---
 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 faa6470..0beeb33 100644
--- a/meta/classes/sstate.bbclass
+++ b/meta/classes/sstate.bbclass
@@ -20,7 +20,7 @@ def generate_sstatefn(spec, hash, taskname, siginfo, d):
 components = spec.split(":")
 # Fields 0,5,6 are mandatory, 1 is most useful, 2,3,4 are just for 
information
 # 7 is for the separators
-avail = (254 - len(hash + "_" + taskname + extension) - 
len(components[0]) - len(components[1]) - len(components[5]) - 
len(components[6]) - 7) / 3
+avail = (254 - len(hash + "_" + taskname + extension) - 
len(components[0]) - len(components[1]) - len(components[5]) - 
len(components[6]) - 7) // 3
 components[2] = components[2][:avail]
 components[3] = components[3][:avail]
 components[4] = components[4][:avail]
-- 
2.7.4

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


[OE-core] [PATCH] tune-cortexa72-cortexa53.inc: Adding missing TUNE_FEATURES

2020-01-23 Thread Jaewon Lee
Without the proper default tune in TUNE_FEATURES, certain variables
won't expand correctly. MACHINEOVERRIDES won't add cortexa72-cortexa53:
TUNE_CCARGS won't add -mtune=cortexa72.cortexa-53, generating the toolchain
incorrectly.
Adding missing 'cortexa72-cortexa53' to both
TUNE_FEATURES_tune-cortexa72-cortexa53 and
TUNE_FEATURES_tune-cortexa72-cortexa53-crypto

Signed-off-by: Jaewon Lee 
Signed-off-by: Alejandro Enedino Hernandez Samaniego 
---
 meta/conf/machine/include/tune-cortexa72-cortexa53.inc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/conf/machine/include/tune-cortexa72-cortexa53.inc 
b/meta/conf/machine/include/tune-cortexa72-cortexa53.inc
index 0d43531..f208b98 100644
--- a/meta/conf/machine/include/tune-cortexa72-cortexa53.inc
+++ b/meta/conf/machine/include/tune-cortexa72-cortexa53.inc
@@ -14,8 +14,8 @@ TUNE_CCARGS .= "${@bb.utils.contains("TUNE_FEATURES", 
"cortexa72-cortexa53", " -
 AVAILTUNES += "cortexa72-cortexa53 cortexa72-cortexa53-crypto"
 ARMPKGARCH_tune-cortexa72-cortexa53  = "cortexa72-cortexa53"
 ARMPKGARCH_tune-cortexa72-cortexa53-crypto   = "cortexa72-cortexa53"
-TUNE_FEATURES_tune-cortexa72-cortexa53   = 
"${TUNE_FEATURES_tune-armv8a-crc}"
-TUNE_FEATURES_tune-cortexa72-cortexa53-crypto= 
"${TUNE_FEATURES_tune-armv8a-crc-crypto}"
+TUNE_FEATURES_tune-cortexa72-cortexa53   = 
"${TUNE_FEATURES_tune-armv8a-crc} cortexa72-cortexa53"
+TUNE_FEATURES_tune-cortexa72-cortexa53-crypto= 
"${TUNE_FEATURES_tune-armv8a-crc-crypto} cortexa72-cortexa53"
 PACKAGE_EXTRA_ARCHS_tune-cortexa72-cortexa53 = 
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc}cortexa72-cortexa53"
 PACKAGE_EXTRA_ARCHS_tune-cortexa72-cortexa53-crypto  = 
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto} cortexa72-cortexa53 
cortexa72-cortexa53-crypto"
 BASE_LIB_tune-cortexa72-cortexa53= "lib64"
-- 
2.7.4

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