[yocto] test cases: Depending on other tests
Hello all I have been working with the test functionality of yocto and have created some testcases in a single python file. Now I wanted refactor my code and split some of the cases across smaller unit tests files. I have 2 functionalities required to achieve this spliting: * Be able to import a common piece of code In the cases directory i created a GTestUtills.py and in my case i import it. I get a syntax error on the import. Both GTestUtils.py and my_testcase.py are in the cases directory. * Be able to depend on tests from other cases When mycase1.py has a testA which depends on a mycase2.mycaseTest.testB it gives me an error saying that mycase2.mycaseTest.testB is not available even though it clearly is. It is not a typo because no options are available at all in the failures' suggestion. Interestingly open embedded testcases are available as well as the mycase1 tests. Paulo Neves -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] nativesdk-gcc tries to link with host
Hello Raj, > target sysroot poisoning is naturally not needed we could do that but it is > not useful, for nativesdk it behaves like a native gcc except that it prefers > the libraries from SDK rootfs, now should be limit it to just the > rootfs and blind > it from system rootfs .. may be I dont know if thats useful. In my case it is useful because the machine i use the SDK on, has a very old glibc 2.12 which misbehaves for a lot of software. An example is the error I showed you. I have poisoned the nativesdk-gcc and now I am trying to build an image. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] nativesdk-gcc tries to link with host
Hello,
I am trying to use nativesdk-gcc to have a gcc compiler for my sdk
machine. Everything looks to work correctly but some code make the
linker attempt to use host libraries.
This is weird because this only happens when I use libraries that are
in the ${SDKROOT}/lib and not in ${SDKROOT}/usr/lib. Examples librt or
libpthread.
An example program[1], build with [2] results in
//lib64/libpthread.so.0: undefined reference to `h_errno@GLIBC_PRIVATE'
//lib64/libpthread.so.0: undefined reference to
`__vdso_clock_gettime@GLIBC_PRIVATE'
//lib64/libpthread.so.0: undefined reference to
`__libc_dl_error_tsd@GLIBC_PRIVATE'
One thing I noticed is that the sysroot of this nativesdk-gcc is not
poisoned. I am not sure if this on purpose or not because gcc-7.3.bb
requires gcc-7.3.inc gcc-target.inc in this order. The problem is
that gcc-7.3.inc poisons the sysroot and gcc-target.inc "unpoisons"
the sysroot. Basically gcc-target overwrites EXTRA_OECONF_PATHS that
was set by gcc-7.3.inc.
Let me know if you are aware of what is wrong.
Paulo Neves
[1] d.c
#define _GNU_SOURCE
#include
#include
#include
#include
#ifdef __STDC__
# include
#else
# include
#endif
#undef timer_create
char timer_create ();
int
main ()
{
return timer_create ();
;
return 0;
}
[2] bash -c "PATH=./buildtools/sysroots/x86_64-pokysdk-linux/usr/bin/
&& gcc -lrt d.c"
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [yocto-docs] documentation: Updated testimage targets.
The documentation of available names for TEST_TARGET have
been updated to match the convention of using the
class names of controllers.
Signed-off-by: Paulo Neves
---
documentation/dev-manual/dev-manual-common-tasks.xml | 8
documentation/ref-manual/ref-variables.xml | 19 ---
2 files changed, 8 insertions(+), 19 deletions(-)
diff --git a/documentation/dev-manual/dev-manual-common-tasks.xml
b/documentation/dev-manual/dev-manual-common-tasks.xml
index 0cb967f..2fcdad0 100644
--- a/documentation/dev-manual/dev-manual-common-tasks.xml
+++ b/documentation/dev-manual/dev-manual-common-tasks.xml
@@ -11400,7 +11400,7 @@
within a separately started QEMU or any
other virtual machine manager.
-
"Systemd-bootTarget":
+
"SystemdbootTarget":
Choose "Systemd-bootTarget" if your hardware is
an EFI-based machine with
systemd-boot as bootloader and
@@ -11459,10 +11459,10 @@
-Selecting Systemd-bootTarget
+Selecting SystemdbootTarget
-If you did not set TEST_TARGET to
+If you did not set TEST_TARG
"Systemd-bootTarget", then you do not need any information
in this section.
You can skip down to the
@@ -11472,7 +11472,7 @@
If you did set TEST_TARGET to
-"Systemd-bootTarget", you also need to perform a one-time
+"SystemdbootTarget", you also need to perform a one-time
setup of your master image by doing the following:
Set
EFI_PROVIDER:
diff --git a/documentation/ref-manual/ref-variables.xml
b/documentation/ref-manual/ref-variables.xml
index 2465553..a61fee6 100644
--- a/documentation/ref-manual/ref-variables.xml
+++ b/documentation/ref-manual/ref-variables.xml
@@ -15162,35 +15162,24 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR =
"${INC_PR}.3"
You can provide the following arguments with
TEST_TARGET:
-"qemu" and
"QemuTarget":
+"QemuTarget":
Boots a QEMU image and runs the tests.
See the
"Enabling Runtime Tests on
QEMU"
section in the Yocto Project Development Tasks
Manual for more information.
-"simpleremote" and
"SimpleRemoteTarget":
+
"SimpleRemoteTarget":
Runs the tests on target hardware that is already
up and running.
The hardware can be on the network or it can be
a device running an image on QEMU.
You must also set
TEST_TARGET_IP
-when you use "simpleremote" or
"SimpleRemoteTarget".
+when you use "SimpleRemoteTarget".
This argument is defined in
-
meta/lib/oeqa/targetcontrol.py.
-The small caps names are kept for compatibility
-reasons.
-
-
-"GummibootTarget":
-Automatically deploys and runs tests on an
-EFI-enabled machine that has a master image
-installed.
-
-This argument is defined in
-
meta/lib/oeqa/controllers/masterimage.py.
+
meta/lib/oeqa/controllers/simpleremote.py.
--
2.7.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Cannot use any TEST_TARGET besides simpleremote or qemu
Hello Paul, I find this functionality very useful for test benches of embedded systems. Now that you said it was broken i started pruning code and have 3 ways we can and save the current functionality: 1 In the testimage.bbclass, pass the td variable to OERuntimeTestContextExecutor.getTarget(). Also greatly simplifying argument passing. 2 In the testimage.bbclass add the td variable to the kwargs so that controllers can access the datastore at __init__ time. 3 Have the user set a variable with a list of variables (!) that should available in kwargs. I will give it a try by simply passing td. This way we give all the information that controllers might need to work. As td is retrieved by the json file generated at the image creation time the external test (bitbakeless) functionality should be unaffected. Let me know if you have different opinions. Paulo Neves On Thu, Aug 2, 2018 at 10:35 AM, Paul Eggleton wrote: > Hi Paulo, > > On Thursday, 2 August 2018 12:11:37 AM BST Paulo Neves wrote: >> I am trying to create my own test controller. After copy pasting and >> adapting the skeleton from BeagleBoneTarget to >> $MYLAYER/lib/oeqa/controllers I set the appropriate TEST_TARGET. >> >> When I run the testimage task I always have errors like in [1]. The >> actual keyword that is unexpected changes from invocation to >> invocation. There was a similar error previously reported in this >> mailing list but the presented solution was to actually stop using the >> TEST_TARGET variable, which is not applicable. >> >> I have tried setting TEST_TARGET to any of the proposed options in the >> manual [2] and the same unhelping error shows. I know that some of >> that these controller targets, are not appropriate for my target >> (odroid [cortex-arm15]), but the errors seems to not be related to any >> functionality or these boards. >> >> I have analyzed and cannot really understand also how all the example >> targets classes have a constructor which takes the d variable, while >> the context.py call has some more variables including a dictionary, >> kwargs, which does not actually have the d variable. > > I discovered this as well: > > https://bugzilla.yoctoproject.org/show_bug.cgi?id=12842 > > This code got broken during the refactoring a while ago, and I think the > person doing the work considered it to be legacy functionality and was going > to remove it. Personally I'd like to see it stay and get fixed up, but the > issue is having the time to fix it and maintain it - if you do by any chance > then that would be great. > > At the moment I believe "simpleremote" does still work, it's just the actual > classes that are broken, but I didn't give it extensive testing. > > Cheers, > Paul > > -- > > Paul Eggleton > Intel Open Source Technology Centre > > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Cannot use any TEST_TARGET besides simpleremote or qemu
Hello I am trying to create my own test controller. After copy pasting and adapting the skeleton from BeagleBoneTarget to $MYLAYER/lib/oeqa/controllers I set the appropriate TEST_TARGET. When I run the testimage task I always have errors like in [1]. The actual keyword that is unexpected changes from invocation to invocation. There was a similar error previously reported in this mailing list but the presented solution was to actually stop using the TEST_TARGET variable, which is not applicable. I have tried setting TEST_TARGET to any of the proposed options in the manual [2] and the same unhelping error shows. I know that some of that these controller targets, are not appropriate for my target (odroid [cortex-arm15]), but the errors seems to not be related to any functionality or these boards. I have analyzed and cannot really understand also how all the example targets classes have a constructor which takes the d variable, while the context.py call has some more variables including a dictionary, kwargs, which does not actually have the d variable. I am not interested in anything qemu in this case. [1] Exception: TypeError: __init__() got an unexpected keyword argument 'boottime' [2] https://www.yoctoproject.org/docs/2.1/mega-manual/mega-manual.html#var-TEST_TARGET Paulo Neves -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Fwd: Basehash value changed issue
Does this happen always or only sometimes? If only sometimes you probably made changes to the recipe or dependent recipes while building. You cannot do that. On Mon, Jul 2, 2018 at 7:27 AM, techi eth wrote: > Hi, > > Can anybody give me hint over below issue. > > Thanks > > -- Forwarded message -- > From: techi eth > Date: Thu, Jun 21, 2018 at 6:30 PM > Subject: Basehash value changed issue > To: yocto@yoctoproject.org > > > Hi, > > I am facing issue with basehash value changed while building image on one of > my test board (Ref of beagle bone) on morty branch. > > Error : > gateway.bb.do_rootfs, the basehash value changed from > e685a429b8df6dcff60063f087d425ee to 3f98a102f48ea8722835ad0d65bfbc1f. The > metadata is not deterministic and this needs to be fixed > > When i run bitbake-diffsigs -t gateway do_rootfs > I found below O/P. > basehash changed from 8e6b9498c9704590bd016491efcbf9f9 to > 3f98a102f48ea8722835ad0d65bfbc1f > Variable TIME value changed from '112854' to '115745' > > After googling I found that TIME need's to be added in vardepsexclude list. > I added below in conf/distro/machine.conf but error persist. > do_rootfs[vardepsexclude] = "TIME DATE DATETIME" > > Please suggest me where & what has to be added to come out of issue. > > > -- > ___ > 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] populate_sdk in image class
A long time ago the image class got an inherit to the populate_sdk* class which brings a lot of dependencies on python modules. Is it strictly necessary that to build an image, i need to satisfy nativesdk-libgcc among others? Is there not a performance and complexity impact? I never needed to use the nativesdk separately as "the primary way of running builds within the extensible SDK is to use the 'devtool' command" (quote from SHA1 545673). Should not this class inheritance be moved into devtool or at least make the dependencies be triggered with the do_populate_sdk* task? -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] ROOTFS_RPM_DEBUG undocumented
Ouch you are right. Damn me for using pyro still? After applying this patch I will report on the remaining issues. On Fri, May 4, 2018 at 2:41 PM, Alexander Kanavin <alexander.kana...@linux.intel.com> wrote: > On 05/04/2018 03:42 PM, Paulo Neves wrote: >> >> I will propose a patch with a default bb.debug, and always have the >> verbose on dnf. Let's see how it affects the performance. I cannot >> test this in a docker container because of the problems described >> below: >> >> In the mean time I found what was happening with my slow do_rootfs. I >> was running bitbake with RPM packaging in a docker instance. It seems >> there is a problem with RPM/dnf in bitbake where it is extremely slow >> inside a docker container (1 file per second). After changing to IPK >> packages everything went smoothly. >> >> Others have had the same problem[1]. I will later report this to >> openembedded mailing list as this effectively makes RPM unusable in a >> container. I will also provide a Dockerfile to reproduce this problem. >> >> [1] https://github.com/moby/moby/issues/23137#issuecomment-359097008 > > > No need to report. We have already fixed this and reported upstream: > > http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-devtools/rpm/files/0001-Revert-Set-FD_CLOEXEC-on-opened-files-before-exec-fr.patch > > https://bugzilla.redhat.com/show_bug.cgi?id=1537564 > > > Alex -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] ROOTFS_RPM_DEBUG undocumented
I will propose a patch with a default bb.debug, and always have the verbose on dnf. Let's see how it affects the performance. I cannot test this in a docker container because of the problems described below: In the mean time I found what was happening with my slow do_rootfs. I was running bitbake with RPM packaging in a docker instance. It seems there is a problem with RPM/dnf in bitbake where it is extremely slow inside a docker container (1 file per second). After changing to IPK packages everything went smoothly. Others have had the same problem[1]. I will later report this to openembedded mailing list as this effectively makes RPM unusable in a container. I will also provide a Dockerfile to reproduce this problem. [1] https://github.com/moby/moby/issues/23137#issuecomment-359097008 Paulo Neves On Thu, May 3, 2018 at 3:03 PM, Alexander Kanavin <alexander.kana...@linux.intel.com> wrote: > On 05/03/2018 01:42 PM, Paulo Neves wrote: >> >> # Add ROOTFS_RPM_DEBUG to the documentation; > > > I'd rather get rid of it, the less variables the better :) > >> # Detect if we are running with debug output and enable the debugging >> output. This is the most elegant solution but I do not know how to >> detect if debug log level is turned on; > > > I don't think you are meant to detect that; bitbake's debug level is not > meant to affect what is being printed, but merely whether it's printed or > discarded. > >> # Have dnf always print in verbose mode and print the output to >> bb.debug instead of bb.note. > > > I think this is the best solution actually. > >> I am happy to provide a patch upon decision or suggestions. > > > Thank you :) Do measure the performance before and after as we don't want to > introduce a significant slowdown here. > > > Alex -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] ROOTFS_RPM_DEBUG undocumented
Hello all, I recently had the problem where the do_rootfs task seemed to hang. The output where it hang looked like [1] and stayed that way for the better part of an hour. When I ran bitbake with -vD arguments not more relevant output was given [2], also hanging for a lot of time. As noted in another mailing list post about rootfs hanging[3], the culprit was the enormous amount of kernel modules which were being built. I only discovered this because I was able to strace and see that actually bitbake was not hanging but actually running dnf install. When I searched for the code responsible for the invocation of dnf I notice there is an undocumented variable called ROOTFS_RPM_DEBUG that enables verbosity of the dnf and prints it out. This would have been very helpful output for my 'bitbake -vD' invocation, and truly debugging information would have helped. What I ask is a decision on which option would better suite this issue: # Add ROOTFS_RPM_DEBUG to the documentation; # Detect if we are running with debug output and enable the debugging output. This is the most elegant solution but I do not know how to detect if debug log level is turned on; # Have dnf always print in verbose mode and print the output to bb.debug instead of bb.note. I am happy to provide a patch upon decision or suggestions. Paulo Neves [1] NOTE: recipe drotag-cloud-image-debug-1.0-r0: task do_rootfs: Started [2] DEBUG: drotag-cloud-image-debug-1.0-r0 do_rootfs: Executing python function do_rootfs [3] https://lists.yoctoproject.org/pipermail/yocto/2017-May/036293.html -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] COMPATIBLE_MACHINE not honored in native extended recipes
Hello I am having a problem where I want a recipe, along with its
-native version to only be available when allowed by compatible
machine.
In the non native case, COMPATIBLE_MACHINE is correctly honored. But
in the -native version the COMPATIBLE_MACHINE is not honored because
in the native.bbclass there is:
MACHINEOVERRIDES = ""
This change was introduced in d09e6d883042e5d094cd08d829327c4bbbfae135.
While the explanation provided by the commit is accurate for specific
case mentioned it also breaks the COMPATIBLE_MACHINE mechanism which
relies on the MACHINEOVERRIDES variable.
Further evidence that this was not intended is that the exception text is false:
ERROR: Nothing PROVIDES 'x-filter-native'
x-filter-native was skipped: incompatible with machine m1 (not in
COMPATIBLE_MACHINE)
And the x-filter-native'.bb recipe header contains:
COMPATIBLE_MACHINE = "^m1$"
So the exception uses ${MACHINE} to report that a ${MACHINEOVERRIDE}
was not matched with the COMPATIBLE_MACHINE, which is a false
statement.
My solution is very simple and does not break the fix that
d09e6d883042e5d094cd08d829327c4bbbfae135 did:
From 8b78c81dc1d21bc23aeb1387c201e090f031a14a Mon Sep 17 00:00:00 2001
From: Paulo Neves <paulo.de_sousa_ne...@nokia.com>
Date: Fri, 12 Jan 2018 15:58:39 +0100
Subject: [PATCH 1/1] Fix COMPATIBLE_MACHINE for -native recipe variants.
Hello I am having a problem where I want a recipe, along
with its -native version to only be available when allowed
by compatible machine.
In the non native case, COMPATIBLE_MACHINE is correctly
honored. But in the -native version the COMPATIBLE_MACHINE
is not honored because in the native.bbclass there is:
MACHINEOVERRIDES = ""
This change was introduced in
d09e6d883042e5d094cd08d829327c4bbbfae135.
While the explanation provided by the commit is accurate for
specific case mentioned it also breaks the
COMPATIBLE_MACHINE mechanism which relies on the
MACHINEOVERRIDES variable.
Further evidence that this was not intended is that the
exception text is false:
ERROR: Nothing PROVIDES 'x-filter-native'
x-filter-native was skipped: incompatible with machine m1
(not in COMPATIBLE_MACHINE)
And the x-filter-native'.bb recipe header contains:
COMPATIBLE_MACHINE = "^m1$"
So the exception uses ${MACHINE} to report that a
${MACHINEOVERRIDE} was not matched with the
COMPATIBLE_MACHINE, which is a false statement.
This fix attempts to correct the issue with minimal
changes.
Change-Id: If5085e4e92550b8154033dd56149eb4e358ef266
---
meta/classes/base.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index c3c2669939c6f0b9080727378a26a324072d7e51..b4051102d0eccfb576d8b76f6f47ce8cd763af55 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -473,7 +473,7 @@ python () {
need_machine = d.getVar('COMPATIBLE_MACHINE', True)
if need_machine:
import re
-compat_machines = (d.getVar('MACHINEOVERRIDES', True) or "").split(":")
+compat_machines = (d.getVar('MACHINEOVERRIDES', True) or d.getVar('MACHINE', True)).split(":")
for m in compat_machines:
if re.match(need_machine, m):
break
--
2.6.2
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] user space package recommends kernel fragment with builting CONFIG
Hello all, I have the idea I am doing someting in a strange way but correct me if I am wrong. I want to make hostapd RRECOMEND .config fragments which have wireless drivers. How do I achieve this? Paulo Neves -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH] fetch2/__init_.py removed bb.error which caused exit code 1
http://lists.openembedded.org/pipermail/openembedded-core/2012-September/069448.html
Workaround to avoid exit 1 status.
The reason it happens is that there are 2 missions
the state cache uses the normal fetcher to get
its's stuff and it is acceptable for it to fail.
On the other hand it is not acceptable for fetch
to fail.
In it's code the state cache code catches the exception that the
fetcher launches and discards. The problem
is that before this exception is caught it prints
a bb.error and bb.error prints something and
continues on like no problem happened. but marks
the exit code as 1 which is a disaster.
From 140d8209895e3effd4f8ee5c92e49f0c653bf3e2 Mon Sep 17 00:00:00 2001
From: Paulo Neves <paulo.de_sousa_ne...@nokia.com>
Date: Wed, 5 Jul 2017 14:49:28 +0200
Subject: [PATCH 1/2] Workaround to avoid exit 1 status.
The reason it happens is that there are 2 missions
the state cache uses the normal fetcher to get
its's stuff and it is acceptable for it to fail.
On the other hand it is not acceptable for fetch
to fail.
In it's code the state cache code catches the exception that the
fetcher launches and discards. The problem
is that before this exception is caught it prints
a bb.error and bb.error prints something and
continues on like no problem happened. but marks
the exit code as 1 which is a disaster.
---
bitbake/lib/bb/fetch2/__init__.py | 2 --
1 file changed, 2 deletions(-)
diff --git a/bitbake/lib/bb/fetch2/__init__.py b/bitbake/lib/bb/fetch2/__init__.py
index 4079e3bb4ca9ab229d917171d76f41d962218ded..96c31830ecb8fb6272ca5528b2ce51382c2959d5 100644
--- a/bitbake/lib/bb/fetch2/__init__.py
+++ b/bitbake/lib/bb/fetch2/__init__.py
@@ -1620,8 +1620,6 @@ class Fetch(object):
localpath = try_mirrors(self, self.d, ud, mirrors)
if not localpath or ((not os.path.exists(localpath)) and localpath.find("*") == -1):
-if firsterr:
-logger.error(str(firsterr))
raise FetchError("Unable to fetch URL from any source.", u)
update_stamp(ud, self.d)
--
2.6.2
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH] staging.bbclass: Refactored sysroot_stage_dir* functions.
staging.bbclass: Refactored sysroot_stage_dir* functions.
Removed sysroot_stage_libdir because it just forwarded the
arguments to sysroot_stage_libdir with no other function.
git grep for sysroot_stage_libdir did not show any recipe
appending or overrriding sysroot_stage_libdir.
Removed checks for directories in sysroot_stage_dirs because
sysroot_stage_dir already handles the check.
This block of code had tabs instead of spaces, as in the
rest of the staging.bbclass. This commit replaces tabs with
whitespaces where appropriate.
From 3768fa5b5f8c446c96590df54dde59beadd15e5f Mon Sep 17 00:00:00 2001
From: Paulo Neves <paulo.de_sousa_ne...@nokia.com>
Date: Tue, 18 Jul 2017 15:15:32 +0200
Subject: [PATCH 1/1] staging.bbclass: Refactored sysroot_stage_dir* functions.
Removed sysroot_stage_libdir because it just forwarded the
arguments to sysroot_stage_libdir with no other function.
git grep for sysroot_stage_libdir did not show any recipe
appending or overrriding sysroot_stage_libdir.
Removed checks for directories in sysroot_stage_dirs because
sysroot_stage_dir already handles the check.
This block of code had tabs instead of spaces, as in the
rest of the staging.bbclass. This commit replaces tabs with
whitespaces where appropriate.
---
meta/classes/staging.bbclass | 83 ++--
1 file changed, 34 insertions(+), 49 deletions(-)
diff --git a/meta/classes/staging.bbclass b/meta/classes/staging.bbclass
index bc5dfa81af3cfae84ec2dbcbbc61d20cf92dd97a..8606b0e47f6519603db95508893e411989cf87c5 100644
--- a/meta/classes/staging.bbclass
+++ b/meta/classes/staging.bbclass
@@ -1,60 +1,45 @@
sysroot_stage_dir() {
- src="$1"
- dest="$2"
- # if the src doesn't exist don't do anything
- if [ ! -d "$src" ]; then
- return
- fi
-
- mkdir -p "$dest"
- (
- cd $src
- find . -print0 | cpio --null -pdlu $dest
- )
-}
-
-sysroot_stage_libdir() {
- src="$1"
- dest="$2"
-
- sysroot_stage_dir $src $dest
+src="$1"
+dest="$2"
+# if the src doesn't exist don't do anything
+if [ ! -d "$src" ]; then
+ return
+fi
+
+mkdir -p "$dest"
+(
+cd $src
+find . -print0 | cpio --null -pdlu $dest
+)
}
sysroot_stage_dirs() {
- from="$1"
- to="$2"
-
- sysroot_stage_dir $from${includedir} $to${includedir}
- if [ "${BUILD_SYS}" = "${HOST_SYS}" ]; then
- sysroot_stage_dir $from${bindir} $to${bindir}
- sysroot_stage_dir $from${sbindir} $to${sbindir}
- sysroot_stage_dir $from${base_bindir} $to${base_bindir}
- sysroot_stage_dir $from${base_sbindir} $to${base_sbindir}
- sysroot_stage_dir $from${libexecdir} $to${libexecdir}
- sysroot_stage_dir $from${sysconfdir} $to${sysconfdir}
- sysroot_stage_dir $from${localstatedir} $to${localstatedir}
- fi
- if [ -d $from${libdir} ]
- then
- sysroot_stage_libdir $from${libdir} $to${libdir}
- fi
- if [ -d $from${base_libdir} ]
- then
- sysroot_stage_libdir $from${base_libdir} $to${base_libdir}
- fi
- if [ -d $from${nonarch_base_libdir} ]
- then
- sysroot_stage_libdir $from${nonarch_base_libdir} $to${nonarch_base_libdir}
- fi
- sysroot_stage_dir $from${datadir} $to${datadir}
- # We don't care about docs/info/manpages/locales
- rm -rf $to${mandir}/ $to${docdir}/ $to${infodir}/ ${to}${datadir}/locale/
- rm -rf $to${datadir}/applications/ $to${datadir}/fonts/ $to${datadir}/pixmaps/
+from="$1"
+to="$2"
+
+sysroot_stage_dir $from${includedir} $to${includedir}
+if [ "${BUILD_SYS}" = "${HOST_SYS}" ]; then
+sysroot_stage_dir $from${bindir} $to${bindir}
+sysroot_stage_dir $from${sbindir} $to${sbindir}
+sysroot_stage_dir $from${base_bindir} $to${base_bindir}
+sysroot_stage_dir $from${base_sbindir} $to${base_sbindir}
+sysroot_stage_dir $from${libexecdir} $to${libexecdir}
+sysroot_stage_dir $from${sysconfdir} $to${sysconfdir}
+sysroot_stage_dir $from${localstatedir} $to${localstatedir}
+fi
+
+sysroot_stage_dir $from${libdir} $to${libdir}
+sysroot_stage_dir $from${base_libdir} $to${base_libdir}
+sysroot_stage_dir $from${nonarch_base_libdir} $to${nonarch_base_libdir}
+sysroot_stage_dir $from${datadir} $to${datadir}
+# We don't care about docs/info/manpages/locales
+rm -rf $to${mandir}/ $to${docdir}/ $to${infodir}/ ${to}${datadir}/locale/
+rm -rf $to${datadir}/applications/ $to${datadir}/fonts/ $to${datadir}/pixmaps/
}
sysroot_stage_all() {
- sysroot_stage_dirs ${D} ${SYSROOT_DESTDIR}
+sysroot_stage_dirs ${D} ${SYSROOT_DESTDIR}
}
python sysroot_strip () {
--
2.6.2
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] multiconfig samples not put in the build dir.
>Not really my call to make. Also, please keep this discussion on the >mailing list so that everyone benefits. Sorry forgot to hit the reply all. Thanks for the suggestion I am now waiting input from the rest of the community regarding the applicability of rename command. On Wed, Apr 12, 2017 at 9:28 AM, Gary Thomas <g...@mlbassoc.com> wrote: > On 2017-04-12 09:15, Paulo Neves wrote: >> >> Hello Gary. >> >> I didn't know it was not a coreutil. To do it in another way i think >> this simple code will grow. Before refactoring could I have other >> opinions? >> >> We have a very limited environment and even so the rename exists. It >> is part of the util-linux-ng from the kernel... > > > Not really my call to make. Also, please keep this discussion on the > mailing list so that everyone benefits. > >> On Wed, Apr 12, 2017 at 9:10 AM, Gary Thomas <g...@mlbassoc.com> wrote: >>> >>> On 2017-04-12 09:02, Paulo Neves wrote: >>>> >>>> >>>> I expect it to rename all the .conf.sample files from .conf.sample to >>>> .conf. Give it a try ;) >>> >>> >>> >>> This introduces a new dependency for the rename tool/program which is >>> a Perl script. It seems to me that much effort has been made recently >>> to minimize these scripts, removing bash-isms, etc, and adding this >>> dependency would drift from that path. >>> >>> Just my 2c >>> >>>> >>>> On Wed, Apr 12, 2017 at 8:54 AM, Gary Thomas <g...@mlbassoc.com> wrote: >>>>> >>>>> >>>>> On 2017-04-12 08:48, Paulo Neves wrote: >>>>>> >>>>>> >>>>>> >>>>>> Hello, >>>>>> >>>>>> I thought it would be consistent to have the multiconfig samples to >>>>>> also be populated just like the local.conf. >>>>>> >>>>>> I produced a patch accordingly: >>>>>> >>>>>>> From 6091978f666463c46093203b74f28b82a9bf4d47 Mon Sep 17 00:00:00 >>>>>>> 2001 >>>>>> >>>>>> >>>>>> >>>>>> From: Paulo Neves <paulo.de_sousa_ne...@nokia.com> >>>>>> Date: Mon, 3 Apr 2017 11:23:12 +0200 >>>>>> Subject: [PATCH 1/2] multiconfig samples are now put in the build dir. >>>>>> >>>>>> The users of multiconfig which use the templateconf >>>>>> mechanism may also want the multiconfig samples to >>>>>> be retrieved from the template configuration >>>>>> directories. This patch allows for that. >>>>>> >>>>>> It only copies the .conf.sample files. It does not >>>>>> create the multiconfig directory if the templateconf >>>>>> directory does not exist or have any sample files. >>>>>> --- >>>>>> scripts/oe-setup-builddir | 10 +- >>>>>> 1 file changed, 9 insertions(+), 1 deletion(-) >>>>>> >>>>>> diff --git a/scripts/oe-setup-builddir b/scripts/oe-setup-builddir >>>>>> index >>>>>> >>>>>> >>>>>> ef495517aaafd8150313ac1f8f5eb5079c90d09b..783ed20dd49d23fe38fa28d6a105918200a54610 >>>>>> 100755 >>>>>> --- a/scripts/oe-setup-builddir >>>>>> +++ b/scripts/oe-setup-builddir >>>>>> @@ -77,11 +77,11 @@ if [ -n "$TEMPLATECONF" ]; then >>>>>> OECORELOCALCONF="$TEMPLATECONF/local.conf.sample" >>>>>> OECORENOTESCONF="$TEMPLATECONF/conf-notes.txt" >>>>>> fi >>>>>> - >>>>>> unset SHOWYPDOC >>>>>> if [ -z "$OECORELOCALCONF" ]; then >>>>>> OECORELOCALCONF="$OEROOT/meta/conf/local.conf.sample" >>>>>> fi >>>>>> + >>>>>> if [ ! -r "$BUILDDIR/conf/local.conf" ]; then >>>>>> cat <>>>>> You had no conf/local.conf file. This configuration file has >>>>>> therefore >>>>>> been >>>>>> @@ -91,12 +91,20 @@ for more information as common configuration >>>>>> options are commented. >>>>>> >>>>>> EOM >>>>>> cp -f $OECORELOCALCONF "$BUILDDIR/conf/local.conf" >>>>>> +if ( find "$TEMPLATECONF/multiconfig/" -iname '*.conf.sample' >>>>>> 2>&1 > /dev/null ); then >>>>>> + mkdir -p "$BUILDDIR/conf/multiconfig/" >>>>>> +cp -fa "$TEMPLATECONF/multiconfig" "$BUILDDIR/conf/" >>>>>> +(cd "$BUILDDIR/conf/multiconfig/" && >>>>>> +rename .conf.sample .conf *.conf.sample) >>>>> >>>>> >>>>> >>>>> >>>>> This doesn't look right to me - what are you expecting the 'rename' >>>>> command >>>>> to do? >>>>> >>>>>> +echo "Multiconfig samples detected copying them also.\n" >>>>>> +fi >>>>>> SHOWYPDOC=yes >>>>>> fi >>>>>> >>>>>> if [ -z "$OECORELAYERCONF" ]; then >>>>>> OECORELAYERCONF="$OEROOT/meta/conf/bblayers.conf.sample" >>>>>> fi >>>>>> + >>>>>> if [ ! -r "$BUILDDIR/conf/bblayers.conf" ]; then >>>>>> cat <>>>>> You had no conf/bblayers.conf file. This configuration file has >>>>>> therefore >>>>>> been > > > -- > > Gary Thomas | Consulting for the > MLB Associates |Embedded world > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] multiconfig samples not put in the build dir.
I expect it to rename all the .conf.sample files from .conf.sample to .conf. Give it a try ;) On Wed, Apr 12, 2017 at 8:54 AM, Gary Thomas <g...@mlbassoc.com> wrote: > On 2017-04-12 08:48, Paulo Neves wrote: >> >> Hello, >> >> I thought it would be consistent to have the multiconfig samples to >> also be populated just like the local.conf. >> >> I produced a patch accordingly: >> >>> From 6091978f666463c46093203b74f28b82a9bf4d47 Mon Sep 17 00:00:00 2001 >> >> From: Paulo Neves <paulo.de_sousa_ne...@nokia.com> >> Date: Mon, 3 Apr 2017 11:23:12 +0200 >> Subject: [PATCH 1/2] multiconfig samples are now put in the build dir. >> >> The users of multiconfig which use the templateconf >> mechanism may also want the multiconfig samples to >> be retrieved from the template configuration >> directories. This patch allows for that. >> >> It only copies the .conf.sample files. It does not >> create the multiconfig directory if the templateconf >> directory does not exist or have any sample files. >> --- >> scripts/oe-setup-builddir | 10 +- >> 1 file changed, 9 insertions(+), 1 deletion(-) >> >> diff --git a/scripts/oe-setup-builddir b/scripts/oe-setup-builddir >> index >> ef495517aaafd8150313ac1f8f5eb5079c90d09b..783ed20dd49d23fe38fa28d6a105918200a54610 >> 100755 >> --- a/scripts/oe-setup-builddir >> +++ b/scripts/oe-setup-builddir >> @@ -77,11 +77,11 @@ if [ -n "$TEMPLATECONF" ]; then >> OECORELOCALCONF="$TEMPLATECONF/local.conf.sample" >> OECORENOTESCONF="$TEMPLATECONF/conf-notes.txt" >> fi >> - >> unset SHOWYPDOC >> if [ -z "$OECORELOCALCONF" ]; then >> OECORELOCALCONF="$OEROOT/meta/conf/local.conf.sample" >> fi >> + >> if [ ! -r "$BUILDDIR/conf/local.conf" ]; then >> cat <> You had no conf/local.conf file. This configuration file has therefore >> been >> @@ -91,12 +91,20 @@ for more information as common configuration >> options are commented. >> >> EOM >> cp -f $OECORELOCALCONF "$BUILDDIR/conf/local.conf" >> +if ( find "$TEMPLATECONF/multiconfig/" -iname '*.conf.sample' >> 2>&1 > /dev/null ); then >> + mkdir -p "$BUILDDIR/conf/multiconfig/" >> +cp -fa "$TEMPLATECONF/multiconfig" "$BUILDDIR/conf/" >> +(cd "$BUILDDIR/conf/multiconfig/" && >> +rename .conf.sample .conf *.conf.sample) > > > This doesn't look right to me - what are you expecting the 'rename' command > to do? > >> +echo "Multiconfig samples detected copying them also.\n" >> +fi >> SHOWYPDOC=yes >> fi >> >> if [ -z "$OECORELAYERCONF" ]; then >> OECORELAYERCONF="$OEROOT/meta/conf/bblayers.conf.sample" >> fi >> + >> if [ ! -r "$BUILDDIR/conf/bblayers.conf" ]; then >> cat <> You had no conf/bblayers.conf file. This configuration file has therefore >> been >> > > > -- > > Gary Thomas | Consulting for the > MLB Associates |Embedded world > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] multiconfig samples not put in the build dir.
Hello, I thought it would be consistent to have the multiconfig samples to also be populated just like the local.conf. I produced a patch accordingly: >From 6091978f666463c46093203b74f28b82a9bf4d47 Mon Sep 17 00:00:00 2001 From: Paulo Neves <paulo.de_sousa_ne...@nokia.com> Date: Mon, 3 Apr 2017 11:23:12 +0200 Subject: [PATCH 1/2] multiconfig samples are now put in the build dir. The users of multiconfig which use the templateconf mechanism may also want the multiconfig samples to be retrieved from the template configuration directories. This patch allows for that. It only copies the .conf.sample files. It does not create the multiconfig directory if the templateconf directory does not exist or have any sample files. --- scripts/oe-setup-builddir | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/scripts/oe-setup-builddir b/scripts/oe-setup-builddir index ef495517aaafd8150313ac1f8f5eb5079c90d09b..783ed20dd49d23fe38fa28d6a105918200a54610 100755 --- a/scripts/oe-setup-builddir +++ b/scripts/oe-setup-builddir @@ -77,11 +77,11 @@ if [ -n "$TEMPLATECONF" ]; then OECORELOCALCONF="$TEMPLATECONF/local.conf.sample" OECORENOTESCONF="$TEMPLATECONF/conf-notes.txt" fi - unset SHOWYPDOC if [ -z "$OECORELOCALCONF" ]; then OECORELOCALCONF="$OEROOT/meta/conf/local.conf.sample" fi + if [ ! -r "$BUILDDIR/conf/local.conf" ]; then cat <&1 > /dev/null ); then + mkdir -p "$BUILDDIR/conf/multiconfig/" +cp -fa "$TEMPLATECONF/multiconfig" "$BUILDDIR/conf/" +(cd "$BUILDDIR/conf/multiconfig/" && +rename .conf.sample .conf *.conf.sample) +echo "Multiconfig samples detected copying them also.\n" +fi SHOWYPDOC=yes fi if [ -z "$OECORELAYERCONF" ]; then OECORELAYERCONF="$OEROOT/meta/conf/bblayers.conf.sample" fi + if [ ! -r "$BUILDDIR/conf/bblayers.conf" ]; then cat <https://lists.yoctoproject.org/listinfo/yocto
[yocto] Bug 11307 - sstate.bbclass tries to modify mirror files
Commit 51edde653707e7a3cd2186082458f01f32cd1996 makes a wrong
assumption that SSTATE_MIRRORS have write permissions.
A mirror is by definition outside of it's user control. In my use case
it happens I does not have permissions to update the access time of
the dereferenced symbolic-link file.
If we had the possibility to modify the sstate-mirror we would have
set SSTATE_DIR instead. There are 3 possible fixes:
* Revert this patch. It seems tailored to a very special use case
which breaks the definition of mirror.
* Only touch the file if the file access time is writeable.
* Set (yet) another option to touch SSTATE_MIRROR files.
I also can imagine this raising sever performance issues if the mirror
is used by several users at the same time. The server will need to
update the file meta data every time
This patch fixes the bug with minimal impact on the original
functionality. Option 2
Related to (https://bugzilla.yoctoproject.org/show_bug.cgi?id=10857)
>From aa8cab9660744c8d5277f8e82f10a844884aff78 Mon Sep 17 00:00:00 2001
From: Paulo Neves <paulo.de_sousa_ne...@nokia.com>
Date: Tue, 11 Apr 2017 10:57:47 +0300
Subject: [PATCH] Added test for write ability of sstate-mirror .siginfo
---
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
af588548c2ef85d966787df7ae1432e1744bdba6..36cbbd151aa1c93f4ca377b3a23c011a527389d8
100644
--- a/meta/classes/sstate.bbclass
+++ b/meta/classes/sstate.bbclass
@@ -753,7 +753,7 @@ python sstate_sign_package () {
sstate_unpack_package () {
tar -xvzf ${SSTATE_PKG}
# update .siginfo atime on local/NFS mirror
- [ -h ${SSTATE_PKG}.siginfo ] && touch -a ${SSTATE_PKG}.siginfo
+ [ -w ${SSTATE_PKG}.siginfo ] && [ -h ${SSTATE_PKG}.siginfo ] &&
touch -a ${SSTATE_PKG}.siginfo
# Use "! -w ||" to return true for read only files
[ ! -w ${SSTATE_PKG} ] || touch --no-dereference ${SSTATE_PKG}
[ ! -w ${SSTATE_PKG}.sig ] || [ ! -e ${SSTATE_PKG}.sig ] || touch
--no-dereference ${SSTATE_PKG}.sig
--
2.6.2
Best regards
Paulo Neves
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] (no subject)
Hello Yocto list from time to time my builds are getting this error and I can't understand why is this happening. Every package is in local IO, only the sstate cache i think is in an NFS mount. Can you hint me at why this error could come up in yocto do_rootfs? ERROR: lfs-release-full-x86-64-build-pc-linux-gnu-1.0-r0 do_rootfs: Unable to install packages. Command '/workspace/builds/yoctobuild/tmp/sysroots/x86_64-linux/usr/bin/opkg --volatile-cache -f /workspace/builds/yoctobuild/tmp/work/x86_64_build_pc_linux_gnu-poky-linux/lfs-release-full-x86-64-build-pc-linux-gnu/1.0-r0/opkg.conf -o /workspace/builds/yoctobuild/tmp/work/x86_64_build_pc_linux_gnu-poky-linux/lfs-release-full-x86-64-build-pc-linux-gnu/1.0-r0/rootfs --force_postinstall --prefer-arch-to-version install run-postinsts fullsysroot all-vcf-wmp' returned 255: Collected errors: * opkg_install_pkg: Failed to download fullsysroot. Perhaps you need to run 'opkg update'? * opkg_install: Cannot install package fullsysroot. Installing run-postinsts (1.0-r0) on root. Best regards Paulo Neves -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Using files from package dependencies
Hello Nicolas, thank you for your advice and hints but I "need" to
corrupt a bit the conventions of yocto and use specific package names
(due to compatibility with other older build systems)
The magic behind the fact that my special package sysroot directories
were not being moved to the yocto sysroot was due to the fact that
do_populate_sysroot does not match all the toplevel directories in
${D}. For additional directories sysroot_stage_all needs to be
appended with the desired directories. I am perfectly ok with that but
why not make a notification that there were directories that were
packaged but will not be expanded in the sysroots? The lack of
notification is extremely confusing, as files just do not appear where
they should.
A similar question to mine can be found here:
http://stackoverflow.com/questions/35354802/how-to-create-do-populate-sysroot-append-task-in-yocto/40976056#40976056
Best regards
Paulo Neves
On Mon, Dec 5, 2016 at 10:08 AM, Nicolas Dechesne
<nicolas.deche...@linaro.org> wrote:
> On Mon, Dec 5, 2016 at 10:10 AM, Paulo Neves <ptsne...@gmail.com> wrote:
>> Sorry for my ambiguity. When I mentioned binaries I meant general
>> binary data, not necessarily executable. Their only need is that the
>> new recipe needs to be fed these data from the other package so it can
>> produce it's own output. This binary data only needs to be available
>> in the host pc, in the recipe bake.
>
> in that case, i suppose you can consider these 'binary files' as
> development files like other .h or libs, and package them in the -dev
> package of the dependency. You can control which files get into the
> -dev package using FILES_${PN}-dev in your recipe.
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Using files from package dependencies
Sorry for my ambiguity. When I mentioned binaries I meant general binary data, not necessarily executable. Their only need is that the new recipe needs to be fed these data from the other package so it can produce it's own output. This binary data only needs to be available in the host pc, in the recipe bake. Thanks Paulo Neves On Mon, Dec 5, 2016 at 8:58 AM, Nicolas Dechesne <nicolas.deche...@linaro.org> wrote: > On Mon, Dec 5, 2016 at 9:54 AM, Paulo Neves <ptsne...@gmail.com> wrote: >> The files form this other package are mostly binaries in a directory >> structure. I have to create an additional package which works with the >> other package's(the dependency) installed directory structure. >> Also you hinted at something I didn't know before, which was that >> packages need to be additionally exported to the sysroot and this was >> typically done through the -dev package. Can you point me at where >> this is documented? I am having a huge difficulty trying to find these >> conventions in the manual or by googling. > > > are the binaries "native" binaries (eg. that are intended to run on > the host PC) or target binaries (libraries) that would want to link > against to build your new package? -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Using files from package dependencies
Hi Nicolas, The files form this other package are mostly binaries in a directory structure. I have to create an additional package which works with the other package's(the dependency) installed directory structure. Also you hinted at something I didn't know before, which was that packages need to be additionally exported to the sysroot and this was typically done through the -dev package. Can you point me at where this is documented? I am having a huge difficulty trying to find these conventions in the manual or by googling. Thanks Paulo Neves On Mon, Dec 5, 2016 at 8:42 AM, Nicolas Dechesne <nicolas.deche...@linaro.org> wrote: > On Mon, Dec 5, 2016 at 7:59 AM, Paulo Neves <ptsne...@gmail.com> wrote: >> I have a recipe which depends on another package's file to do it's >> job. How can I arbitrarily access a file from another package which my >> recipe depends on? >> >> I searched for this kind of problem but did not find it > > you can't access (reliably) temporary files from another package. Each > package is built independently in their own 'sandbox'. If files from > one package are needed for other packages they need to be exported in > the sysroot (through the -dev package typically). > > you don't say much about what 'files' you need, but if you need source > code to recompile them into another package, you might need to fetch > the source code directly. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Using files from package dependencies
Hello, I have a recipe which depends on another package's file to do it's job. How can I arbitrarily access a file from another package which my recipe depends on? I searched for this kind of problem but did not find it Best regards Paulo Neves -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
