[OE-core] [PATCH] matchbox-session-sato: Make the battery applet depend on machine features
From: Eran Matityahumatchbox-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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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