Re: [yocto] [OE-core] [PATCH v4 1/3] image.bbclass: add prohibited-paths QA test
On 11/17/2017 01:21 AM, Leonardo Sandoval wrote: isn't it this class meta/classes/insane.bbclass for this type of checks? This was already discussed - the test should be on the image rather than package level: http://lists.openembedded.org/pipermail/openembedded-core/2017-November/144335.html Alex -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Trying to filter out 2 strings from EXTRA_OECONF, why doesn't this work?
On 11/17/2017 12:37 AM, Matt Schepers wrote: What do I have to do to filter out BOTH configure flags. I realize I can just write a new recipe, but I don't think that's the "correct" answer. The best way to fix this is to modify the original recipe so that all three options become PACKAGECONFIG-configurable, and submit the patch to whoever maintains the recipe. Alex -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] tiny-linux distribution with raspberrypi error
> DISTRO = "poky-tiny" and i get the following What is the difference between core-image-minimal and poky-tiny? Thank you, Zoran On Fri, Nov 17, 2017 at 2:05 AM, Sherif Omran wrote: > hi > > i am trying to compile the yocto-tiny for raspberry pi by adding the > distro to my local.conf > > DISTRO = "poky-tiny" and i get the following > > > ERROR: nothing provides 'virtual/kernel' > ERROR: linux-yocto-tiny Provides virtual/kernel but was skipped: > incompatible with machine raspberrypi0-wifi (not in compatible_machine) > ERROR: linux-yocto-rt Provides virtual/kernel but was skipped: > incompatible with machine raspberrypi0-wifi (not in compatible_machine) > ERROR: linux-yocto Provides virtual/kernel but was skipped: incompatible > with machine raspberrypi0-wifi (not in compatible_machine) > ERROR: linux-yocto-dev Provides virtual/kernel but was skipped: > incompatible with machine raspberrypi0-wifi (not in compatible_machine) > ERROR: required build target 'rpi-basic-image' has no buildable providers. > Missing or unbuildable depency chain was: 'rpi-basic-image', > 'virtual/kernel' > > > any body has a clue to solve it? > > thanks > > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto > > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Trying to filter out 2 strings from EXTRA_OECONF, why doesn't this work?
I would like to filter out two configure flags from EXTRA_OECONF in a
.bbappend. When I filter out only one everything works, when I do the same
thing twice it doesn't.
Here is the .bbappend that works:
EXTRA_OECONF := "${@oe_filter_out('--with-term=rxvt', '${EXTRA_OECONF}',
d)}"
EXTRA_OECONF += " --enable-256-color"
Here is the .bbappend that doesn't work:
EXTRA_OECONF := "${@oe_filter_out('--with-term=rxvt', '${EXTRA_OECONF}',
d)}"
EXTRA_OECONF := "${@oe_filter_out('--with-name=rxvt', '${EXTRA_OECONF}',
d)}"
EXTRA_OECONF += " --enable-256-color"
Here is the error at the command line for the one doesn't work:
Loading cache: 100%
|###|
Time: 0:00:00
Loaded 2806 entries from dependency cache.
ERROR: ExpansionError during parsing
/home/matt/nitrogen6x/yocto/meta/poky/meta/recipes-sato/rxvt-unicode/rxvt-unicode_9.22.bb
| ETA: --:--:--
Traceback (most recent call last):
bb.data_smart.ExpansionError: Failure expanding variable EXTRA_OECONF[:=],
expression was ${@oe_filter_out('--with-name=rxvt',
'${@oe_filter_out('--with-term=rxvt', '--enable-xim --enable-utmp
--enable-wtmp --enable-lastlog--with-term=rxvt --enable-keepscrolling
--enable-xft --with-name=rxvt --enable-frills
--enable-swapscreen --enable-transparency --with-codesets=eu
--enable-pointer-blank --enable-text-blink --enable-rxvt-scroll
--enable-combining --disable-perl
--with-x=/home/matt/nitrogen6x/yocto/build/tmp/work/armv7at2hf-neon-fslc-linux-gnueabi/rxvt-unicode/%-r0/recipe-sysroot/usr
--disable-static ${PACKAGECONFIG_CONFARGS}', d)} --disable-static
${PACKAGECONFIG_CONFARGS}', d)} which triggered exception SyntaxError: invalid
syntax (EXTRA_OECONF[:=], line 1)
Question 1)
Why doesn't this work?
Question 2)
What do I have to do to filter out BOTH configure flags. I realize I can
just write a new recipe, but I don't think that's the "correct" answer.
Thank you.
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] tiny-linux distribution with raspberrypi error
hi i am trying to compile the yocto-tiny for raspberry pi by adding the distro to my local.conf DISTRO = "poky-tiny" and i get the following ERROR: nothing provides 'virtual/kernel' ERROR: linux-yocto-tiny Provides virtual/kernel but was skipped: incompatible with machine raspberrypi0-wifi (not in compatible_machine) ERROR: linux-yocto-rt Provides virtual/kernel but was skipped: incompatible with machine raspberrypi0-wifi (not in compatible_machine) ERROR: linux-yocto Provides virtual/kernel but was skipped: incompatible with machine raspberrypi0-wifi (not in compatible_machine) ERROR: linux-yocto-dev Provides virtual/kernel but was skipped: incompatible with machine raspberrypi0-wifi (not in compatible_machine) ERROR: required build target 'rpi-basic-image' has no buildable providers. Missing or unbuildable depency chain was: 'rpi-basic-image', 'virtual/kernel' any body has a clue to solve it? thanks -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH v4 1/3] image.bbclass: add prohibited-paths QA test
isn't it this class meta/classes/insane.bbclass for this type of checks?
On Thu, 16 Nov 2017 15:05:56 +
Martyn Welch wrote:
> Sometimes we wish to ensure that files or directories are not installed
> somewhere that may prove detrimental to the operation of the system. For
> example, this may be the case if files are placed in a directory that is
> utilised as a mount point at run time, thus making them inaccessible once
> when the mount point is being utilised.
>
> Implement the prohibited paths QA test, which enables such locations to be
> specified in a "IMAGE_QA_PROHIBITED_PATHS" variable. This implementation
> allows for a colon separated list of paths to be provided. Shell style
> wildcards can be used.
>
> Signed-off-by: Fabien Lahoudere
> Signed-off-by: Martyn Welch
> ---
> Changes since v1:
> - Correcting author and SOB.
>
> Changes since v2:
> - Reimplemented as image rather than package level QA test.
> - Changed variable from PROHIBITED_PATH to PROHIBITED_PATHS to better
>reflect its use.
>
> Changes since v3:
> - Rename variable to IMAGE_QA_PROHIBITED_PATHS.
> - Use str.startswith().
> - Simplify if statement.
>
> meta/classes/image.bbclass | 20
> 1 file changed, 20 insertions(+)
>
> diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
> index d93de02..9053ce3 100644
> --- a/meta/classes/image.bbclass
> +++ b/meta/classes/image.bbclass
> @@ -296,6 +296,26 @@ python do_image_complete_setscene () {
> }
> addtask do_image_complete_setscene
>
> +python image_check_prohibited_paths () {
> +import glob
> +from oe.utils import ImageQAFailed
> +
> +rootfs = d.getVar('IMAGE_ROOTFS')
> +
> +path = (d.getVar('IMAGE_QA_PROHIBITED_PATHS') or "")
> +if path != "":
> +for p in path.split(':'):
> +if not p.startswith('/'):
> +raise ImageQAFailed("IMAGE_QA_PROHIBITED_PATHS \"%s\" must
> be an absolute path" % p, image_check_prohibited_paths)
> +
> +match = glob.glob("%s%s" % (rootfs, p))
> +if match:
> +loc = ", ".join(item.replace(rootfs, '') for item in match)
> +raise ImageQAFailed("Match(es) for IMAGE_QA_PROHIBITED_PATHS
> \"%s\": %s" % (p, loc), image_check_prohibited_paths)
> +}
> +
> +IMAGE_QA_COMMANDS += "image_check_prohibited_paths"
> +
> # Add image-level QA/sanity checks to IMAGE_QA_COMMANDS
> #
> # IMAGE_QA_COMMANDS += " \
> --
> 2.1.4
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Detecting all AUTOREV usages in a build, for reproducible stable production builds.
That is EXACTLY what I am looking for. Thanks! A "nice to have" would be a check to see if any AUTOREVs has snuck in since last srcrev.conf generation. I'd like to validate/ensure this with a build task on the build server. On Thu, Nov 16, 2017 at 10:18 AM Leonardo Sandoval < leonardo.sandoval.gonza...@linux.intel.com> wrote: > On Thu, 16 Nov 2017 05:06:30 -0500 > Paul Knopf wrote: > > > I want to store/fix AUTOREV values for production builds. I saw > > BB_CACHE_POLICY, but the format (sqllite) isn't something that can be > > checked in. > > > > Let's say I have an image: > > > > bitbake my-image > > > > How do I detect any dependency that is using AUTOREV? > > > > > would this tool be useful for your needs? I do not fully grasp what you > want to do. > > > > You can use the buildhistory-collect-srcrevs command with the -a option to > collect the stored SRCREV values from build history and report them in a > format suitable for use in global > configuration (e.g., local.conf or a distro include file) to override > floating AUTOREV values to a fixed set of revisions. Here is some example > output from this command: > > > $ buildhistory-collect-srcrevs -a > # i586-poky-linux > SRCREV_pn-glibc = "b8079dd0d360648e4e8de48656c5c38972621072" > SRCREV_pn-glibc-initial = "b8079dd0d360648e4e8de48656c5c38972621072" > SRCREV_pn-opkg-utils = "53274f087565fd45d8452c5367997ba6a682a37a" > SRCREV_pn-kmod = "fd56638aed3fe147015bfa10ed4a5f7491303cb4" > # x86_64-linux > SRCREV_pn-gtk-doc-stub-native = > "1dea266593edb766d6d898c79451ef193eb17cfa" > SRCREV_pn-dtc-native = "65cc4d2748a2c2e6f27f1cf39e07a5dbabd80ebf" > SRCREV_pn-update-rc.d-native = > "eca680ddf28d024954895f59a241a622dd575c11" > SRCREV_glibc_pn-cross-localedef-native = > "b8079dd0d360648e4e8de48656c5c38972621072" > SRCREV_localedef_pn-cross-localedef-native = > "c833367348d39dad7ba018990bfdaffaec8e9ed3" > SRCREV_pn-prelink-native = "faa069deec99bf61418d0bab831c83d7c1b797ca" > SRCREV_pn-opkg-utils-native = > "53274f087565fd45d8452c5367997ba6a682a37a" > SRCREV_pn-kern-tools-native = > "23345b8846fe4bd167efdf1bd8a1224b2ba9a5ff" > SRCREV_pn-kmod-native = "fd56638aed3fe147015bfa10ed4a5f7491303cb4" > # qemux86-poky-linux > SRCREV_machine_pn-linux-yocto = > "38cd560d5022ed2dbd1ab0dca9642e47c98a0aa1" > SRCREV_meta_pn-linux-yocto = > "a227f20eff056e511d504b2e490f3774ab260d6f" > # all-poky-linux > SRCREV_pn-update-rc.d = "eca680ddf28d024954895f59a241a622dd575c11" > > Note > - > > > > > > I'd like to generate a dynamic.conf file that fixes the SRCREV values for > > relevant packages. > > > > I guess I could do a normal build, then read the sqllite database, and > > generate a .conf from it. Does this sound feasible? > > > > Any other strategies? > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] [PATCH v4 1/3] image.bbclass: add prohibited-paths QA test
On Thu, Nov 16, 2017 at 1:05 PM, Martyn Welch
wrote:
> Sometimes we wish to ensure that files or directories are not installed
> somewhere that may prove detrimental to the operation of the system. For
> example, this may be the case if files are placed in a directory that is
> utilised as a mount point at run time, thus making them inaccessible once
> when the mount point is being utilised.
>
> Implement the prohibited paths QA test, which enables such locations to be
> specified in a "IMAGE_QA_PROHIBITED_PATHS" variable. This implementation
> allows for a colon separated list of paths to be provided. Shell style
> wildcards can be used.
>
> Signed-off-by: Fabien Lahoudere
> Signed-off-by: Martyn Welch
> ---
> Changes since v1:
> - Correcting author and SOB.
>
> Changes since v2:
> - Reimplemented as image rather than package level QA test.
> - Changed variable from PROHIBITED_PATH to PROHIBITED_PATHS to better
>reflect its use.
>
> Changes since v3:
> - Rename variable to IMAGE_QA_PROHIBITED_PATHS.
> - Use str.startswith().
> - Simplify if statement.
>
> meta/classes/image.bbclass | 20
> 1 file changed, 20 insertions(+)
>
> diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
> index d93de02..9053ce3 100644
> --- a/meta/classes/image.bbclass
> +++ b/meta/classes/image.bbclass
> @@ -296,6 +296,26 @@ python do_image_complete_setscene () {
> }
> addtask do_image_complete_setscene
>
> +python image_check_prohibited_paths () {
> +import glob
> +from oe.utils import ImageQAFailed
> +
> +rootfs = d.getVar('IMAGE_ROOTFS')
> +
> +path = (d.getVar('IMAGE_QA_PROHIBITED_PATHS') or "")
> +if path != "":
> +for p in path.split(':'):
> +if not p.startswith('/'):
> +raise ImageQAFailed("IMAGE_QA_PROHIBITED_PATHS \"%s\" must
> be an absolute path" % p, image_check_prohibited_paths)
> +
> +match = glob.glob("%s%s" % (rootfs, p))
> +if match:
> +loc = ", ".join(item.replace(rootfs, '') for item in match)
> +raise ImageQAFailed("Match(es) for IMAGE_QA_PROHIBITED_PATHS
> \"%s\": %s" % (p, loc), image_check_prohibited_paths)
> +}
for p in path.split(':'):
if not p.startswith('/'):
so you can drop the if path != "".
An empty list won't go inside the for. Each item needs to be tested.
> +IMAGE_QA_COMMANDS += "image_check_prohibited_paths"
> +
> # Add image-level QA/sanity checks to IMAGE_QA_COMMANDS
> #
> # IMAGE_QA_COMMANDS += " \
> --
> 2.1.4
>
> --
> ___
> Openembedded-core mailing list
> openembedded-c...@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Detecting all AUTOREV usages in a build, for reproducible stable production builds.
On Thu, 16 Nov 2017 05:06:30 -0500 Paul Knopf wrote: > I want to store/fix AUTOREV values for production builds. I saw > BB_CACHE_POLICY, but the format (sqllite) isn't something that can be > checked in. > > Let's say I have an image: > > bitbake my-image > > How do I detect any dependency that is using AUTOREV? > would this tool be useful for your needs? I do not fully grasp what you want to do. You can use the buildhistory-collect-srcrevs command with the -a option to collect the stored SRCREV values from build history and report them in a format suitable for use in global configuration (e.g., local.conf or a distro include file) to override floating AUTOREV values to a fixed set of revisions. Here is some example output from this command: $ buildhistory-collect-srcrevs -a # i586-poky-linux SRCREV_pn-glibc = "b8079dd0d360648e4e8de48656c5c38972621072" SRCREV_pn-glibc-initial = "b8079dd0d360648e4e8de48656c5c38972621072" SRCREV_pn-opkg-utils = "53274f087565fd45d8452c5367997ba6a682a37a" SRCREV_pn-kmod = "fd56638aed3fe147015bfa10ed4a5f7491303cb4" # x86_64-linux SRCREV_pn-gtk-doc-stub-native = "1dea266593edb766d6d898c79451ef193eb17cfa" SRCREV_pn-dtc-native = "65cc4d2748a2c2e6f27f1cf39e07a5dbabd80ebf" SRCREV_pn-update-rc.d-native = "eca680ddf28d024954895f59a241a622dd575c11" SRCREV_glibc_pn-cross-localedef-native = "b8079dd0d360648e4e8de48656c5c38972621072" SRCREV_localedef_pn-cross-localedef-native = "c833367348d39dad7ba018990bfdaffaec8e9ed3" SRCREV_pn-prelink-native = "faa069deec99bf61418d0bab831c83d7c1b797ca" SRCREV_pn-opkg-utils-native = "53274f087565fd45d8452c5367997ba6a682a37a" SRCREV_pn-kern-tools-native = "23345b8846fe4bd167efdf1bd8a1224b2ba9a5ff" SRCREV_pn-kmod-native = "fd56638aed3fe147015bfa10ed4a5f7491303cb4" # qemux86-poky-linux SRCREV_machine_pn-linux-yocto = "38cd560d5022ed2dbd1ab0dca9642e47c98a0aa1" SRCREV_meta_pn-linux-yocto = "a227f20eff056e511d504b2e490f3774ab260d6f" # all-poky-linux SRCREV_pn-update-rc.d = "eca680ddf28d024954895f59a241a622dd575c11" Note - > I'd like to generate a dynamic.conf file that fixes the SRCREV values for > relevant packages. > > I guess I could do a normal build, then read the sqllite database, and > generate a .conf from it. Does this sound feasible? > > Any other strategies? -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH v4 2/3] core-image.bbclass: add default IMAGE_QA_PROHIBIT_PATHS variable
Add a default IMAGE_QA_PROHIBIT_PATHS variable containing paths known to be mounted in the default fstab, which are known mount points or directories which should be populated at runtime. Suggested-by: Alexander Kanavin Signed-off-by: Martyn Welch --- Changes since v3: - This patch added. meta/classes/core-image.bbclass | 5 + 1 file changed, 5 insertions(+) diff --git a/meta/classes/core-image.bbclass b/meta/classes/core-image.bbclass index a9a2cec..8d5fb97 100644 --- a/meta/classes/core-image.bbclass +++ b/meta/classes/core-image.bbclass @@ -56,6 +56,11 @@ IMAGE_FEATURES_REPLACES_ssh-server-openssh = "ssh-server-dropbear" # IMAGE_FEATURES_CONFLICTS_foo = 'bar1 bar2' # An error exception would be raised if both image features foo and bar1(or bar2) are included +# IMAGE_QA_PROHIBITED_PATHS +# Ensure images aren't including files in places that will be used as mount points or that are +# reserved for runtime data. +IMAGE_QA_PROHIBITED_PATHS ?= "/dev/pts/*:/media/*:/mnt/*:/proc/*:/run/*:/tmp/*:/var/run/*:/var/tmp/*:/var/volatile/*" + MACHINE_HWCODECS ??= "" CORE_IMAGE_BASE_INSTALL = '\ -- 2.1.4 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH v4 3/3] ref-manual: Add documentation for prohibited-path QA test
Add documentation for the IMAGE_QA_PROHIBITED_PATHS variable and associated prohibited-path QA test Signed-off-by: Martyn Welch --- Changes since v1: - Correcting author and SOB. Changes since v2: - Reimplemented as image rather than package level QA test, altering documentation to suit. - Changed variable from PROHIBITED_PATH to PROHIBITED_PATHS to better reflect its use. Changes since v3: - Variable changed from PROHIBITED_PATHS to IMAGE_QA_PROHIBITED_PATHS. documentation/ref-manual/ref-variables.xml | 24 1 file changed, 24 insertions(+) diff --git a/documentation/ref-manual/ref-variables.xml b/documentation/ref-manual/ref-variables.xml index e31aa21..57f969f 100644 --- a/documentation/ref-manual/ref-variables.xml +++ b/documentation/ref-manual/ref-variables.xml @@ -6162,6 +6162,30 @@ +IMAGE_QA_PROHIBITED_PATHS + +IMAGE_QA_PROHIBITED_PATHS[doc] = "A colon separated list of paths in which recipes are prohibited from installing." + + + + +A colon separated list of paths in which recipes are +prohibited from installing. +Shell-style wildcards can be used in paths. All paths need +to be absolute paths. + + + +For example, the following +IMAGE_QA_PROHIBITED_PATHS ensures +nothing is installed under /mnt: + + IMAGE_QA_PROHIBITED_PATHS += "/mnt/*" + + + + + IMAGE_ROOTFS IMAGE_ROOTFS[doc] = "The location of the root filesystem while it is under construction (i.e. during do_rootfs)." -- 2.1.4 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH v4 1/3] image.bbclass: add prohibited-paths QA test
Sometimes we wish to ensure that files or directories are not installed
somewhere that may prove detrimental to the operation of the system. For
example, this may be the case if files are placed in a directory that is
utilised as a mount point at run time, thus making them inaccessible once
when the mount point is being utilised.
Implement the prohibited paths QA test, which enables such locations to be
specified in a "IMAGE_QA_PROHIBITED_PATHS" variable. This implementation
allows for a colon separated list of paths to be provided. Shell style
wildcards can be used.
Signed-off-by: Fabien Lahoudere
Signed-off-by: Martyn Welch
---
Changes since v1:
- Correcting author and SOB.
Changes since v2:
- Reimplemented as image rather than package level QA test.
- Changed variable from PROHIBITED_PATH to PROHIBITED_PATHS to better
reflect its use.
Changes since v3:
- Rename variable to IMAGE_QA_PROHIBITED_PATHS.
- Use str.startswith().
- Simplify if statement.
meta/classes/image.bbclass | 20
1 file changed, 20 insertions(+)
diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index d93de02..9053ce3 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -296,6 +296,26 @@ python do_image_complete_setscene () {
}
addtask do_image_complete_setscene
+python image_check_prohibited_paths () {
+import glob
+from oe.utils import ImageQAFailed
+
+rootfs = d.getVar('IMAGE_ROOTFS')
+
+path = (d.getVar('IMAGE_QA_PROHIBITED_PATHS') or "")
+if path != "":
+for p in path.split(':'):
+if not p.startswith('/'):
+raise ImageQAFailed("IMAGE_QA_PROHIBITED_PATHS \"%s\" must be
an absolute path" % p, image_check_prohibited_paths)
+
+match = glob.glob("%s%s" % (rootfs, p))
+if match:
+loc = ", ".join(item.replace(rootfs, '') for item in match)
+raise ImageQAFailed("Match(es) for IMAGE_QA_PROHIBITED_PATHS
\"%s\": %s" % (p, loc), image_check_prohibited_paths)
+}
+
+IMAGE_QA_COMMANDS += "image_check_prohibited_paths"
+
# Add image-level QA/sanity checks to IMAGE_QA_COMMANDS
#
# IMAGE_QA_COMMANDS += " \
--
2.1.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-swupd][PATCH] layer.conf: exclude libarchive (bsdtar) dependency from swupd-client
On Thu, 2017-11-16 at 10:02 +, André Draszik wrote: > From: André Draszik > > The swupd-client doesn't need to be rebuilt if libarchive > changes, because swupd-client just invokes the command line > utility bsdtar from the libarchive recipe, it doesn't link > against libarchive. > The bsdtar binary changing doesn't matter, as bsdtar's ABI > (command line argument handling) wouldn't be changing. This is about to change: https://github.com/clearlinux/swupd-client/issues/285 is being workedon, see https://github.com/clearlinux/swupd-client/pull/327 > Signed-off-by: André Draszik > --- > conf/layer.conf | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/conf/layer.conf b/conf/layer.conf > index 50e7558..3af6992 100644 > --- a/conf/layer.conf > +++ b/conf/layer.conf > @@ -14,4 +14,5 @@ LAYERVERSION_meta-swupd = "1" > SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS += "\ > oe-swupd-helpers->bash \ > oe-swupd-helpers->busybox \ > + swupd-client->libarchive \ > " For now this change is okay. I just have one general problem: I'm not sure whether I should consider myself the maintainer who merges this. I know that I am listed as "tentative" maintainer, but it practice it hasn't been my job and I don't have time for it in my spare time either. I did some work with swupd again recently, resulting in https://github. com/pohly/meta-swupd/commits/master and https://github.com/intel/intel- iot-refkit/pull/318, but that's just a temporary activity. I understand that this isn't a tenable situation for those of you using meta-swupd; hopefully by the end of the year at the latest it'll be resolved. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] SWIG, python, native gcc and multiarch
Hi all,
I'm trying to run a piece of SWIG code while building u-boot (namely
compiling it with BUILD_ROM=y, which requires pylibfdt which is built
with a SWIG interface file and a setup.py). I'm having a problem that
the SWIG setup.py script for a reason I don't quite understand instead
of compiling everythin with plain gcc command (which is my ${BUILD_CC})
tries to run "x86_64-linux-gnu-gcc". I can of course add
"x86_64-linux-gnu-gcc" to HOSTTOOLS and everything will work fine, but
only on my machine. Does anyone have any idea how to make SWIG use plain
'gcc' instead of that monster. Or maybe how to add it to HOSTTOOLS
dynamically based on whatever output of 'gcc --print-multiarch' is.
There is a couple of other recipes unsing swig in meta-openembedded, but
they don't seem to use any workarounds for that.
Thanks,
Anton Gerasimov
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] qt4 sdk problem on rocko
Hi, I'm porting our layers to latest rocko release. I build SDK to be able to crosscompile our cmake based application which is using qt4. To have qt4-tool in sdk I've added: TOOLCHAIN_HOST_TASK_append = " nativesdk-qt4-tools" Then in app CMakelists.txt I've use include(FindQt4) but it's barking with following: CMake Warning at /opt/poky/2.4/sysroots/x86_64-pokysdk-linux/usr/share/cmake-3.8/Modules/FindQt4.cmake:618 (message): /opt/poky/2.4/sysroots/x86_64-pokysdk-linux/usr/bin/qmake reported QT_INSTALL_LIBS as "/opt/poky/2.4/sysroots/x86_64-pokysdk-linux/usr/lib" but QtCore could not be found there. Qt is NOT installed correctly for the target build environment. Call Stack (most recent call first): CMakeLists.txt:85 (include) I did small check and seems that FindQt4 is using some mechanism to find qmake and then based on qmake --query use variables. Problem is that qmake -query report this: /opt/poky/2.4/sysroots/x86_64-pokysdk-linux/usr/bin$ ./qmake -query QT_INSTALL_PREFIX:/opt/poky/2.4/sysroots/x86_64-pokysdk-linux/usr QT_INSTALL_DATA:/opt/poky/2.4/sysroots/x86_64-pokysdk-linux/usr QT_INSTALL_DOCS:/opt/poky/2.4/sysroots/x86_64-pokysdk-linux/usr/doc QT_INSTALL_HEADERS:/opt/poky/2.4/sysroots/x86_64-pokysdk-linux/usr/include QT_INSTALL_LIBS:/opt/poky/2.4/sysroots/x86_64-pokysdk-linux/usr/lib QT_INSTALL_BINS:/opt/poky/2.4/sysroots/x86_64-pokysdk-linux/usr/bin QT_INSTALL_PLUGINS:/opt/poky/2.4/sysroots/x86_64-pokysdk-linux/usr/plugins QT_INSTALL_IMPORTS:/opt/poky/2.4/sysroots/x86_64-pokysdk-linux/usr/imports QT_INSTALL_TRANSLATIONS:/opt/poky/2.4/sysroots/x86_64-pokysdk-linux/usr/translations QT_INSTALL_CONFIGURATION:/etc/xdg QT_INSTALL_EXAMPLES:/opt/poky/2.4/sysroots/x86_64-pokysdk-linux/usr/examples QT_INSTALL_DEMOS:/opt/poky/2.4/sysroots/x86_64-pokysdk-linux/usr/demos QMAKE_MKSPECS:/opt/poky/2.4/sysroots/x86_64-pokysdk-linux/usr/mkspecs QMAKE_VERSION:2.01a QT_VERSION:4.8.7 which is problem because I don't want to link + use included for x86 qt4 but for cross compiled. Any ideas what to check? Thanks a lot. BR, marek -- as simple and primitive as possible - Marek Belisko - OPEN-NANDRA Freelance Developer Ruska Nova Ves 219 | Presov, 08005 Slovak Republic Tel: +421 915 052 184 skype: marekwhite twitter: #opennandra web: http://open-nandra.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] [PATCH v3 1/2] image.bbclass: add prohibited-paths QA test
On 11/15/2017 05:10 PM, Martyn Welch wrote: Sometimes we wish to ensure that files or directories are not installed somewhere that may prove detrimental to the operation of the system. For example, this may be the case if files are placed in a directory that is utilised as a mount point at run time, thus making them inaccessible once when the mount point is being utilised. Implement the prohibited paths QA test, which enables such locations to be specified in a "PROHIBITED_PATHS" variable. This implementation allows for a colon separated list of paths to be provided. Shell style wildcards can be used. The test does nothing if PROHIBITED_PATHS is not set. Can you set it in core-image.bbclass to some reasonable default common to reference images? Something like /mnt /media /tmp /run /var/run /var/tmp (not sure at the moment what the mount points in those images are). Alex -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] [PATCH v3 1/2] image.bbclass: add prohibited-paths QA test
On Wed, 2017-11-15 at 18:46 -0200, Otavio Salvador wrote:
> On Wed, Nov 15, 2017 at 1:10 PM, Martyn Welch
> wrote:
> > Sometimes we wish to ensure that files or directories are not installed
> > somewhere that may prove detrimental to the operation of the system. For
> > example, this may be the case if files are placed in a directory that is
> > utilised as a mount point at run time, thus making them inaccessible once
> > when the mount point is being utilised.
> >
> > Implement the prohibited paths QA test, which enables such locations to be
> > specified in a "PROHIBITED_PATHS" variable. This implementation allows for
> > a colon separated list of paths to be provided. Shell style wildcards can
> > be used.
> >
> > Signed-off-by: Fabien Lahoudere
> > Signed-off-by: Martyn Welch
> > ---
> > Changes since v1:
> > - Correcting author and SOB.
> >
> > Changes since v2:
> > - Reimplemented as image rather than package level QA test.
> > - Changed variable from PROHIBITED_PATH to PROHIBITED_PATHS to better
> >reflect its use.
> >
> > meta/classes/image.bbclass | 20
> > 1 file changed, 20 insertions(+)
> >
> > diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
> > index d93de02..bebb363 100644
> > --- a/meta/classes/image.bbclass
> > +++ b/meta/classes/image.bbclass
> > @@ -296,6 +296,26 @@ python do_image_complete_setscene () {
> > }
> > addtask do_image_complete_setscene
> >
> > +python image_check_prohibited_paths () {
> > +import glob
> > +from oe.utils import ImageQAFailed
> > +
> > +rootfs = d.getVar('IMAGE_ROOTFS')
> > +
> > +path = d.getVar('PROHIBITED_PATHS')
>
> path = (d.getVar('PROHIBITED_PATHS') or "")
>
> I'd use IMAGE_QA_PROHIBITED_PATHS as variable name. It makes easier to
> know what it relates to.
>
> > +if path != None and path != "":
>
> If can die.
>
OK, if is still needed, else the zero length path triggers the "not
p.startswith('/')" error condition.
> > +for p in path.split(':'):
> > +if p[0] != '/':
>
> if not p.startswith('/'):
>
> > +raise ImageQAFailed("PROHIBITED_PATHS \"%s\" must be an
> > absolute path" % p, image_check_prohibited_paths)
> > +
> > +match = glob.glob("%s%s" % (rootfs, p))
> > +if match:
>
> I'd use:
>
> if glob.glob(...):
>
> It is a single use so not sure it is worth the extra variable.
>
> > +loc = ", ".join(item.replace(rootfs, '') for item in match)
> > +raise ImageQAFailed("Match(es) for PROHIBITED_PATHS
> > \"%s\": %s" % (p, loc), image_check_prohibited_paths)
> > +}
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Detecting all AUTOREV usages in a build, for reproducible stable production builds.
I want to store/fix AUTOREV values for production builds. I saw BB_CACHE_POLICY, but the format (sqllite) isn't something that can be checked in. Let's say I have an image: bitbake my-image How do I detect any dependency that is using AUTOREV? I'd like to generate a dynamic.conf file that fixes the SRCREV values for relevant packages. I guess I could do a normal build, then read the sqllite database, and generate a .conf from it. Does this sound feasible? Any other strategies? -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-swupd][PATCH] layer.conf: exclude libarchive (bsdtar) dependency from swupd-client
On Thu, 2017-11-16 at 10:02 +, André Draszik wrote: > From: André Draszik > > The swupd-client doesn't need to be rebuilt if libarchive > changes, because swupd-client just invokes the command line > utility bsdtar from the libarchive recipe, it doesn't link > against libarchive. > The bsdtar binary changing doesn't matter, as bsdtar's ABI > (command line argument handling) wouldn't be changing. > > Signed-off-by: André Draszik > --- > conf/layer.conf | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/conf/layer.conf b/conf/layer.conf > index 50e7558..3af6992 100644 > --- a/conf/layer.conf > +++ b/conf/layer.conf > @@ -14,4 +14,5 @@ LAYERVERSION_meta-swupd = "1" > SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS += "\ >oe-swupd-helpers->bash \ >oe-swupd-helpers->busybox \ > + swupd-client->libarchive \ > " I hope I understood the description of SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS correctly... Cheers, Andre' -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-swupd][PATCH] layer.conf: exclude libarchive (bsdtar) dependency from swupd-client
From: André Draszik The swupd-client doesn't need to be rebuilt if libarchive changes, because swupd-client just invokes the command line utility bsdtar from the libarchive recipe, it doesn't link against libarchive. The bsdtar binary changing doesn't matter, as bsdtar's ABI (command line argument handling) wouldn't be changing. Signed-off-by: André Draszik --- conf/layer.conf | 1 + 1 file changed, 1 insertion(+) diff --git a/conf/layer.conf b/conf/layer.conf index 50e7558..3af6992 100644 --- a/conf/layer.conf +++ b/conf/layer.conf @@ -14,4 +14,5 @@ LAYERVERSION_meta-swupd = "1" SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS += "\ oe-swupd-helpers->bash \ oe-swupd-helpers->busybox \ + swupd-client->libarchive \ " -- 2.15.0.rc1 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] [PATCH v3 1/2] image.bbclass: add prohibited-paths QA test
On Wed, 2017-11-15 at 18:46 -0200, Otavio Salvador wrote:
> On Wed, Nov 15, 2017 at 1:10 PM, Martyn Welch
> wrote:
> > Sometimes we wish to ensure that files or directories are not installed
> > somewhere that may prove detrimental to the operation of the system. For
> > example, this may be the case if files are placed in a directory that is
> > utilised as a mount point at run time, thus making them inaccessible once
> > when the mount point is being utilised.
> >
> > Implement the prohibited paths QA test, which enables such locations to be
> > specified in a "PROHIBITED_PATHS" variable. This implementation allows for
> > a colon separated list of paths to be provided. Shell style wildcards can
> > be used.
> >
> > Signed-off-by: Fabien Lahoudere
> > Signed-off-by: Martyn Welch
> > ---
> > Changes since v1:
> > - Correcting author and SOB.
> >
> > Changes since v2:
> > - Reimplemented as image rather than package level QA test.
> > - Changed variable from PROHIBITED_PATH to PROHIBITED_PATHS to better
> >reflect its use.
> >
> > meta/classes/image.bbclass | 20
> > 1 file changed, 20 insertions(+)
> >
> > diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
> > index d93de02..bebb363 100644
> > --- a/meta/classes/image.bbclass
> > +++ b/meta/classes/image.bbclass
> > @@ -296,6 +296,26 @@ python do_image_complete_setscene () {
> > }
> > addtask do_image_complete_setscene
> >
> > +python image_check_prohibited_paths () {
> > +import glob
> > +from oe.utils import ImageQAFailed
> > +
> > +rootfs = d.getVar('IMAGE_ROOTFS')
> > +
> > +path = d.getVar('PROHIBITED_PATHS')
>
> path = (d.getVar('PROHIBITED_PATHS') or "")
>
> I'd use IMAGE_QA_PROHIBITED_PATHS as variable name. It makes easier to
> know what it relates to.
>
> > +if path != None and path != "":
>
> If can die.
>
> > +for p in path.split(':'):
> > +if p[0] != '/':
>
> if not p.startswith('/'):
>
> > +raise ImageQAFailed("PROHIBITED_PATHS \"%s\" must be an
> > absolute path" % p, image_check_prohibited_paths)
> > +
> > +match = glob.glob("%s%s" % (rootfs, p))
> > +if match:
>
> I'd use:
>
> if glob.glob(...):
>
> It is a single use so not sure it is worth the extra variable.
>
> > +loc = ", ".join(item.replace(rootfs, '') for item in match)
match is used here.
> > +raise ImageQAFailed("Match(es) for PROHIBITED_PATHS
> > \"%s\": %s" % (p, loc), image_check_prohibited_paths)
> > +}
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
