Re: [yocto] pseudo interaction issue
On Fri, 23 Mar 2012 11:21:26 +0800 "Xu, Dongxiao" wrote: > What do you mean by first build? Did you click "Just bake" button? Yes. The original reproducer I saw said that it worked the first time, but failed the second time. > 1) build_target(packages) > 2) build_target(image) > I noticed the pseudo error will happen when calling > build_target(image). Therefore I also treated it as second build. Interesting. I am, currently, sort of stumped on this. The failures are coming from the git log/git branch commands using os.popen(), and those calls appear to be happening in a process: 1. Which did not have the pseudo library loaded, at all. 2. Which has LD_PRELOAD set to include pseudo. 3. Which has most of the PSEUDO_BINDIR, etc., values set. 4. Which does not have PSEUDO_PREFIX set. I can't figure out how to get there. I can't reproduce this outside of hob, yet. And obviously, if the pseudo library isn't loaded, I can't add more debugging or logging to pseudo to fix it. (I infer that it's not loaded because os.popen() isn't hitting diagnostic messages in pseudo's new popen() wrapper, even if they're completely unconditional.) I added an abort(), and got a core file. The core file shows a backtrace in /bin/sh: #0 0x7f1232cd8a75 in raise () from /lib/libc.so.6 #1 0x7f1232cdc5c0 in abort () from /lib/libc.so.6 #2 0x7f1233497489 in pseudo_get_prefix (pathname=0x7f123349ac9d "") at pseudo_util.c:1060 #3 0x7f1233498244 in pseudo_setupenv () at pseudo_util.c:717 #4 0x7f12334955dd in wrap_fork () at ports/common/guts/fork.c:14 #5 0x7f1233495675 in fork () at ports/common/pseudo_wrappers.c:322 #6 0x0044339c in make_child () #7 0x00436f04 in ?? () #8 0x00433fa4 in execute_command_internal () #9 0x0043475e in execute_command_internal () #10 0x0047262a in parse_and_execute () #11 0x0041fd04 in ?? () #12 0x00420e01 in main () I haven't found an obvious way to look at the arguments to main, but I'm pretty sure it's one of the "cd REPO; git log..." commands. So... Basically, I can't see how we can get here. Currently leaning towards a theory that the issue may be that we only set PSEUDO_PREFIX when we think we want pseudo, and it looks like in the PSEUDO_DISABLED=1 case, it may be that we can end up with a task being run in an environment where LD_PRELOAD had been set, but we've cleaned up our environment, and the disabled path is skipping part of the environment setup. Still really weird to me that I can't reproduce this outside of hob. I am pretty sure there exists a series of forks and execs and environment changes such that this will end up happening. -s -- Listen, get this. Nobody with a good compiler needs to be justified. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] pseudo interaction issue
On Friday 23 March 2012 02:16:35 Peter Seebach wrote:
> Still really weird to me that I can't reproduce this outside of hob.
> I am pretty sure there exists a series of forks and execs and
> environment changes such that this will end up happening.
I now have a fairly simple test case outside of hob. Put the attached file in
meta/classes/ and then add the following to your local.conf:
INHERIT += "breakit"
Then, just run something that will actually execute a real task. If bzip2 has
already been built you can trigger it just with this, which doesn't take very
long:
bitbake -c package -f bzip2
This should give you a stream of "pseudo: You must set the PSEUDO_PREFIX
environment variable to run pseudo." after the task summary.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centrebreakit_break() {
cat > ${TMPDIR}/test123 <___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH] ia32-base.inc: Use '=' for IMAGE_FSTYPES
As per http://lists.linuxtogo.org/pipermail/openembedded-core/2012-March/019772.html a machine conf file should use '=' to set IMAGE_FSTYPES. Cc: Kishore Bodke Cc: Tom Zanussi Cc: Darren Hart Signed-off-by: Tom Rini --- conf/machine/include/ia32-base.inc |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/conf/machine/include/ia32-base.inc b/conf/machine/include/ia32-base.inc index 9b2ef5a..74ab5a5 100644 --- a/conf/machine/include/ia32-base.inc +++ b/conf/machine/include/ia32-base.inc @@ -11,7 +11,7 @@ MACHINE_FEATURES += "kernel26 screen keyboard pci usbhost ext2 ext3 x86 \ MACHINE_EXTRA_RRECOMMENDS += "kernel-modules eee-acpi-scripts" MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "grub" -IMAGE_FSTYPES += "ext3 cpio.gz live" +IMAGE_FSTYPES = "ext3 cpio.gz live" KERNEL_IMAGETYPE ?= "bzImage" -- 1.7.0.4 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] pseudo interaction issue
On Fri, 23 Mar 2012 12:20:08 + Paul Eggleton wrote: > On Friday 23 March 2012 02:16:35 Peter Seebach wrote: > > Still really weird to me that I can't reproduce this outside of hob. > > I am pretty sure there exists a series of forks and execs and > > environment changes such that this will end up happening. > > I now have a fairly simple test case outside of hob. Put the attached > file in meta/classes/ and then add the following to your local.conf: > > INHERIT += "breakit" Confirmed, this produces the problem for me, reducing the reproduction window from something over an hour to about 7 seconds. THANK YOU! -s -- Listen, get this. Nobody with a good compiler needs to be justified. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] first pass at cleaning up ref manual: dead(?) variables in glossary
as part of a concerted effort to tidy up more of the docs, i'm currently perusing the variable glossary in the yocto/poky ref manual: file:///home/rpjday/yocto/yocto-docs/documentation/poky-ref-manual/poky-ref-manual.html#ref-variables-glos and cross-checking entries against their actual usage, and one simple observation is that some of those entries appear to be obsolete and can be removed entirely. some examples of dead content appear to be PACKAGE_SUMMARY, PACKAGE_DESCRIPTION and perhaps anything starting with the string "POKY" (POKY_EXTRA_INSTALL, POKYMODE, POKYLIBC). rather than remove this chaff one or two entries at a time, can people suggest any other deadwood that can be tossed from that glossary, and i can put together a patch that does it all in one shot? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 0/1] [meta-intel] meta-romley switching kernel to 3.2
From: Kishore Bodke These patch set is to switch the kernel version to 3.2 for romley bsp. Please pull into meta-intel/master. Thanks Kishore. The following changes since commit f89405e115d73426c8a6450b6e795b5885d6bdf3: MAINTAINERS: Add FRI2 maintainer (2012-03-23 09:46:15 -0700) are available in the git repository at: git://git.pokylinux.org/meta-intel-contrib kishore/romley-kernel-3.2-update http://git.pokylinux.org/cgit.cgi/meta-intel-contrib/log/?h=kishore/romley-kernel-3.2-update Kishore Bodke (1): meta-romley: switch to linux-yocto-3.2 kernel meta-romley/conf/machine/romley.conf |3 +++ .../linux/linux-yocto-rt_3.2.bbappend |8 .../recipes-kernel/linux/linux-yocto_3.2.bbappend | 10 ++ 3 files changed, 21 insertions(+), 0 deletions(-) create mode 100644 meta-romley/recipes-kernel/linux/linux-yocto-rt_3.2.bbappend create mode 100644 meta-romley/recipes-kernel/linux/linux-yocto_3.2.bbappend -- 1.7.5.4 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 1/1] [meta-intel] meta-romley: switch to linux-yocto-3.2 kernel
From: Kishore Bodke
Switch romley to the 3.2 kernel and update kernel SRCREVs.
Signed-off-by: Kishore Bodke
---
meta-romley/conf/machine/romley.conf |3 +++
.../linux/linux-yocto-rt_3.2.bbappend |8
.../recipes-kernel/linux/linux-yocto_3.2.bbappend | 10 ++
3 files changed, 21 insertions(+), 0 deletions(-)
create mode 100644 meta-romley/recipes-kernel/linux/linux-yocto-rt_3.2.bbappend
create mode 100644 meta-romley/recipes-kernel/linux/linux-yocto_3.2.bbappend
diff --git a/meta-romley/conf/machine/romley.conf
b/meta-romley/conf/machine/romley.conf
index aa334c0..9c93874 100644
--- a/meta-romley/conf/machine/romley.conf
+++ b/meta-romley/conf/machine/romley.conf
@@ -4,9 +4,12 @@
#@DESCRIPTION: Machine configuration for Romley systems
# i.e. Sandy Bridge + Patsburg Chipset
+PREFERRED_VERSION_linux-yocto ?= "3.2%"
+
require conf/machine/include/tune-x86_64.inc
require conf/machine/include/ia32-base.inc
+
XSERVER ?= "${XSERVER_IA32_BASE} \
${XSERVER_IA32_EXT} \
xserver-xorg-module-xaa \
diff --git a/meta-romley/recipes-kernel/linux/linux-yocto-rt_3.2.bbappend
b/meta-romley/recipes-kernel/linux/linux-yocto-rt_3.2.bbappend
new file mode 100644
index 000..1551ccf
--- /dev/null
+++ b/meta-romley/recipes-kernel/linux/linux-yocto-rt_3.2.bbappend
@@ -0,0 +1,8 @@
+FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+COMPATIBLE_MACHINE_romley = "romley"
+KMACHINE_romley = "romley"
+
+# Update the following to use a different BSP branch or meta SRCREV
+#KBRANCH_romley = "yocto/standard/preempt-rt/base"
+#SRCREV_machine_pn-linux-yocto-rt_romley ?=
+#SRCREV_meta_pn-linux-yocto-rt_romley ?=
diff --git a/meta-romley/recipes-kernel/linux/linux-yocto_3.2.bbappend
b/meta-romley/recipes-kernel/linux/linux-yocto_3.2.bbappend
new file mode 100644
index 000..7c8c024
--- /dev/null
+++ b/meta-romley/recipes-kernel/linux/linux-yocto_3.2.bbappend
@@ -0,0 +1,10 @@
+FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+
+COMPATIBLE_MACHINE_romley = "romley"
+KMACHINE_romley = "yocto/standard/common-pc-64/romley"
+
+KERNEL_FEATURES_append_romley += " cfg/smp.scc"
+
+SRCREV_machine_pn-linux-yocto_romley ?=
"4716ac6af37c0c0dcc78690a4a0ba3b857f8bda2"
+SRCREV_meta_pn-linux-yocto_romley ?= "42fff722188e0de7246a3a6900af69f87047"
+
--
1.7.5.4
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 0/1] [linux-yocto-3.2][meta] common-pc: Add PCNET32 to the config
In support of the self-hosted-image, add CONFIG_PCNET32 to the common-pc BSP default cfg. This enables the qemux86 image to be run on both qemux86 machines as well as the vmware 32b machine. Since the qemux86 machine optionally supports pcnet, this seems a reasonable compromise to managing a dedicated BSP for a self-hosted-image machine which would be superset of the qemux86 machine. As this is a single CONFIG_ option, add it to the common-pc.cfg directly, rather than defining a new feature. The following changes since commit 514847185c78c07f52e02750fbe0a03ca3a31d8f: meta: update kver to v3.2.11 (2012-03-16 10:42:41 -0400) are available in the git repository at: git://git.yoctoproject.org/linux-yocto-2.6.37-contrib dvhart/meta/pcnet http://git.yoctoproject.org/cgit.cgi/linux-yocto-2.6.37-contrib/log/?h=dvhart/meta/pcnet Darren Hart (1): [meta] common-pc: Add PCNET32 to the config meta/cfg/kernel-cache/bsp/common-pc/common-pc.cfg |3 +++ meta/cfg/kernel-cache/bsp/common-pc/hardware.cfg |1 + 2 files changed, 4 insertions(+), 0 deletions(-) -- 1.7.5.4 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 1/1] [meta] common-pc: Add PCNET32 to the config
Qemu and VM Ware both support PCNET32 and the latter requires it for 32 bit images. Signed-off-by: Darren Hart --- meta/cfg/kernel-cache/bsp/common-pc/common-pc.cfg |3 +++ meta/cfg/kernel-cache/bsp/common-pc/hardware.cfg |1 + 2 files changed, 4 insertions(+), 0 deletions(-) diff --git a/meta/cfg/kernel-cache/bsp/common-pc/common-pc.cfg b/meta/cfg/kernel-cache/bsp/common-pc/common-pc.cfg index 6d576ee..c0c899e 100644 --- a/meta/cfg/kernel-cache/bsp/common-pc/common-pc.cfg +++ b/meta/cfg/kernel-cache/bsp/common-pc/common-pc.cfg @@ -45,6 +45,9 @@ CONFIG_MAC80211=y CONFIG_WLAN=y CONFIG_ATH_COMMON=y CONFIG_ATH5K=y + +CONFIG_PCNET32=y + CONFIG_INPUT=y CONFIG_INPUT_MOUSEDEV=y CONFIG_INPUT_EVDEV=y diff --git a/meta/cfg/kernel-cache/bsp/common-pc/hardware.cfg b/meta/cfg/kernel-cache/bsp/common-pc/hardware.cfg index 34c6200..869cf62 100644 --- a/meta/cfg/kernel-cache/bsp/common-pc/hardware.cfg +++ b/meta/cfg/kernel-cache/bsp/common-pc/hardware.cfg @@ -6,3 +6,4 @@ CONFIG_MAC80211 CONFIG_SND_HDA_INTEL CONFIG_SERIAL_8250 CONFIG_SERIAL_8250_CONSOLE +CONFIG_PCNET32 -- 1.7.5.4 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] pseudo interaction issue
On Fri, 23 Mar 2012 12:20:08 + Paul Eggleton wrote: > On Friday 23 March 2012 02:16:35 Peter Seebach wrote: > > Still really weird to me that I can't reproduce this outside of hob. > > I am pretty sure there exists a series of forks and execs and > > environment changes such that this will end up happening. > > I now have a fairly simple test case outside of hob. Put the attached > file in meta/classes/ and then add the following to your local.conf: > > INHERIT += "breakit" Okay, some notes. The magic seems to come from the interpolated Python output that itself calls os.popen from inside the shell script. A bit of poking about turns up the following: 1. The environment setup and teardown in runqueue.py don't seem to be atomic at all, such that if I annotate the stashing in envbackup with a bb.note for each variable stashed, I sometimes see a fork() call in pseudo BETWEEN two variables. Which is to say, we can be forking WHILE changing the environment. 2. The func_exec_shell calls seem to be able to call the git_branch stuff (which uses os.popen()) in a way that does not hit the runqueue code AT ALL. Meaning it operates with Whatever Environment Seems Handy. 3. I am inclined to suggest that a first pass would be to distinguish between "we need to set this, but we never need to unset it" (PSEUDO_PREFIX) and "we need to set this and then revert it" (PSEUDO_UNLOAD). 4. We should have a handler for popen() anyway, but it will not in and of itself fix the problem. I am still getting the hang of finding my way around bitbake and figuring out who's calling what. I'd guess that just making sure PSEUDO_PREFIX never gets unset would effectively mitigate the problem, but I suspect that we'll still be vulnerable to Weird Race Conditions. -s -- Listen, get this. Nobody with a good compiler needs to be justified. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] poky ref manual still confuses BB_ENV_WHITELIST and BB_ENV_EXTRAWHITE
Okay - I dug into this a bit with the help of Scott Garman. He uncovered a bit in the BitBake changelog. It states the following: By default it will now only pass certain whitelisted variables into the data store. If BB_PRESERVE_ENV is set bitbake will use all variable from the environment. If BB_ENV_WHITELIST is set, that whitelist will be used instead of the internal bitbake one. Alternatively, BB_ENV_EXTRAWHITE can be used to extend the internal whitelist This entry is by no means clear but has some information. It implies that BitBake has an internal list of environment variables that can be preserved if the user sets BB_PRESERVE_ENV. Where those variables are set and what they are I don't know. Maybe BB_ENV_WHITELIST defines them. But, Scott Garman said that BB_ENV_WHITELIST doesn't seem to be getting set in the sources. Does this mean the user has to set it up? I don't know. Maybe there is an internal list separate from everything and then if the user sets BB_ENV_WHITELIST to anything that list becomes the BB environment list. Regarding BB_ENV_EXTRAWHITE, I think it is pretty clear that is just used to append or augment BB_ENV_WHITELIST. I think the actual example in the section B.5 is valid if you take it as augmenting a set of whitelisted variables. What I need a clearer understanding of BB_ENV_WHITELIST, the existence or non-existence of a set of internal environment variables outside these lists as a default, and the effects of BB_PRESERVE_ENV. I need help from the audience here Thanks, scott -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Robert P. J. Day Sent: Thursday, March 22, 2012 9:37 AM To: Yocto discussion list Subject: [yocto] poky ref manual still confuses BB_ENV_WHITELIST and BB_ENV_EXTRAWHITE in ref manual, B.5, "Running a Task", "Tell BitBake to load what you want from the environment into the data store. You can do so through the BB_ENV_WHITELIST variable. For example, assume you want to prevent the build system from accessing your $HOME/.ccache directory. The following command tells BitBake to load CCACHE_DIR from the environment into the data store: export BB_ENV_EXTRAWHITE="$BB_ENV_EXTRAWHITE CCACHE_DIR"" as you can see, the para refers to one variable, while the export command refers to another. not sure how someone wants to word that so i'll leave it for someone else to fix. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ 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] yocto docs: confusion between shell env vars and bitbake env vars
I clarified about 5 instances of this problem in the reference manual. As usual, see http://www.yoctoprojects.org/docs/latest/poky-ref-manual/poky-ref-manual.html for the latest. Scott -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Robert P. J. Day Sent: Thursday, March 22, 2012 9:29 AM To: Yocto discussion list Subject: [yocto] yocto docs: confusion between shell env vars and bitbake env vars since i'm reading this out of the yocto/poky reference manual, i might as well point it out here. there is occasional confusion when the docs refer to "environment variables", since it's not clear when that means *shell* env vars or *bitbake* env vars. for instance, in the ref manual, section B.1, "Parsing", you read: "The first thing BitBake does is look for the bitbake.conf file. The Yocto Project keeps this file in the Yocto Project file's meta/conf/ directory. BitBake finds it by examining the BBPATH environment variable and looking for the meta/conf/ directory." but there is no BBPATH shell environment variable. in fact, oe-init-build-env explicitly *unsets* that shell variable at the very end. however, you can check the *bitbake* environment with "bitbake -e" and there it is, and i think that not being clear about the difference has the potential to massively confuse readers. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
