thanks your reply, indeed, this is not the first email thread about the
gconf compile problem. it in there only because of no echo.

I have installed python2, and made a symlink in the build directory, and
exported to the env var PATH.

this is the script I used to build (located in the build directory):
#!/bin/bash
loc_dir="`pwd`"
. ${loc_dir}/../optimus/oe-init-build-env ${loc_dir}
export PATH="${loc_dir}:$PATH"
bitbake $@

OS: x86-64 arch / desktop env: gnome 3.2
local.conf ( modified section ):
MACHINE ??= "qemux86-64"
DISTRO ?= "poky-lsb"
SOURCE_MIRROR_URL = "http://10.10.20.149/optimussources/"
INHERIT += "own-mirrors"
BB_GENERATE_MIRROR_TARBALLS = "0"
INHERIT += "rm_work"
CCACHE = ""

when build gconf, got error:
/usr/lib/../lib/libXrandr.so.2: undefined reference to
`memcpy@...'
when 'do_compile' at sanity-check step.

the log of do_compile is attached, here is the last cmd (only reserve
rpath):
../x86_64-poky-linux-libtool ... -Wl,-rpath -Wl,/usr/lib/../lib

the libXrandr.so.2 (depended by the libgtk/libgdk) not appear in the
command explicitly.

I have add --verbose in the command, and found the ld find it in the
host's rootfs, but it should search it in the sysroot arg.

If remove the rpath arg or with the rpath arg prefixed by sysroot arg, I
can build success. (wich will search the libXrandr in the sysroot arg
correctly)

so I think the error is focused on the `ld' which should search in the
sysroot arg at first for implicit dependended libs, but not host's
rootfs.

--
Yi Qingliang
niqingliang@...
https://niqingliang2003.wordpress.com

On Tuesday 27 March 2012 11:07:55 Samuel Stirtzel wrote:

2012/3/26 Paul Eggleton <paul.eggleton@...>:

On Monday 26 March 2012 14:55:40 Samuel Stirtzel wrote:

meta-kde has no mailing list, so I'm looking for a list to host the
discussion, any suggestions?

Probably just the oe-devel list - if the volume of commits gets too high
then we can look at splitting off a separate one.

Do I need an official statement, and from whom can I get it in case?

I don't think any is needed (at least I don't think anyone asked for any of
the other layers).

My assumption is that the initial request, that started this
discussion, was made with the idea in mind not to include any
"overhead" from meta-oe.

Too bad it isn't possible to include only a subset of recipes from a layer..
But it just looks like layers don't work like that.

That's right, the layer is supposed to be used as a unit; which means those
units are supposed to be kept reasonably small and focused where possible.
meta-oe is the exception here, but we should continue to try to improve it.

As an aside it would be interesting to know why KDE requires additional
gif support from giflib when gif loading is already built into Qt (and we
do enable it in our Qt recipes).

The KDE gifloader code is from 2004.
It looks like this was a possible solution and it worked, so they kept it.

Fair enough.

But since it is KHTML depending on giflib, KDE could replace it with
Webkit in the "future" (this is really old news).

Right, I won't be holding my breath on that one ;)

Cheers,
Paul

--

Paul Eggleton
Intel Open Source Technology Centre

2012/3/26 Paul Eggleton <paul.eggleton@...>:

On Monday 26 March 2012 14:55:40 Samuel Stirtzel wrote:

the development of meta-kde has come to a point where kde-applications
can be tested (and maybe used).

Status of meta-kde:
Most common applications work, for example:
Calligra (not all of the toolkit), Kate, KCalc, Konqueror, Kwin &
Kwin_gles (KDE window manager), Okular and the applications from
KDE-baseapps.

Plasma Active (and Desktop) do not work correctly, but I'm working on it.
Plasma Netbook seems to work, but it needs more testing.


Involving the community:
As the development of meta-kde advanced to a point where developers
can use the layer to port KDE applications.
I'd like to invite others to test the layer, port their favorite KDE
applications and express their opinions about the current status.
Feel free to ask questions and suggest applications to be ported.

Great work! I will give it a try over the next few days and let you know how I
get on. (Sorry I know I promised to do this some weeks ago.)

meta-kde has no mailing list, so I'm looking for a list to host the
discussion, any suggestions?

Probably just the oe-devel list - if the volume of commits gets too high then
we can look at splitting off a separate one.

Do I need an official statement, and from whom can I get it in case?

Current issues with Poky:
The giflib recipe is not contained in Poky.
Is this based on a design decision, or just because no one needs it?

It's based upon nothing in OE-Core needing it. (The poky repository is just
OE-Core + bitbake + meta-yocto + yocto-docs).

As a meta-kde developer I don't want to limit the testing of meta-kde.

It should be OK to use meta-oe with Poky, and therefore meta-kde can depend
upon it. However we are aware that meta-oe overlays a bunch of recipes that
ideally it should not. We're working (albeit slowly) to address these.

An alternative in the meantime would be to add giflib to meta-kde, this will do
no significant harm if it is already available in another layer (and giflib
doesn't look like it has really changed since 2008, so I don't think it will
be much of a maintenance burden).

My assumption is that the initial request, that started this
discussion, was made with the idea in mind not to include any
"overhead" from meta-oe.
But TBH I don't know exactly.
Too bad it isn't possible to include only a subset of recipes from a layer..
But it just looks like layers don't work like that.

As an aside it would be interesting to know why KDE requires additional gif
support from giflib when gif loading is already built into Qt (and we do enable
it in our Qt recipes).

The KDE gifloader code is from 2004.
It looks like this was a possible solution and it worked, so they kept it.
But since it is KHTML depending on giflib, KDE could replace it with
Webkit in the "future" (this is really old news).

Cheers,
Paul

--

Paul Eggleton
Intel Open Source Technology Centre

--
Regards
Samuel

On 27/03/12 03:33, Ni Qingliang wrote:

who are using archlinux? I want to talk about gconf compile fail
problem.

I use Archlinux for OE/Yocto, could you post your error so we can get an idea of the problem you are having?

One note for Archlinux is that it ships Python 3 as default, to you must install Python2 from the repositories then symlink python2 to python in /usb/bin.

Regards,

--

Jack Mitchell (jack@...)
Embedded Systems Engineer
http://www.embed.me.uk

--

When using Hob in Yocto Project, I found a issue when deleting layers. I
think I ever raised this problem before.

Let me briefly introduce how layer removal works in Hob. When user
changes a layer, it will following the below steps
1) init the cooker.
2) set new layers to cooker.
3) parse configuration files.
4) get available machines, distros, SDKs, etc.

As we know, if we source oe-init-build-env in Yocto project environment,
we will have DISTRO="poky" set in local.conf by default, where the
"poky" DISTRO comes from the meta-yocto layer. If user deletes
meta-yocto in Hob, and then error will happen when bitbake parsing the
local.conf, since it could not find where the "poky" DISTRO is defined.

Even if we are able to successfully removed the meta-yocto layer by
removing the DISTRO definition in local.conf, system will report another
issue that:

Your configuration is using stamp files including the sstate hash but
your build directory was built with stamp files that do not include
this.
To continue, either rebuild or switch back to the OEBasic signature
handler with BB_SIGNATURE_HANDLER = 'OEBasic'.

This is because BB_SIGNATURE_HANDLER = "OEBasic" is also defined in
meta-yocto layer (poky.conf).


So it seems that in certain environment (e.x, Yocto Project), certain
layer (e.x, meta-yocto) should not be removed?

Or any idea on how to solve this problem?

Thanks,
Dongxiao

On Mon, 26 Mar 2012 22:45:16 +0100
Richard Purdie <richard.purdie@...> wrote:

I'm still a little surprised we don't make any system() calls though.
I just tried putting a os.system("true") call into the "breakit"
class and it doesn't trigger the warnings. Could that be down to the
lack of a popen wrapper?

I think that part could be, but this doesn't explain why adding the
popen() wrapper doesn't fix it. Oh, wait. Yes, it does. I think I am
now happy with this, although I have a loose end or two.

So, here's what I've figured out.

We start bitbake with PSEUDO_PREFIX set. This then gets stored in the
internal stash. Thus, on any call we catch, we should be restoring it.
We then unset it, because it's not part of the whitelisted environment.

Now, what this means is that when we spawn child processes, they should
be getting the environment, but the parent bitbake is running with
PSEUDO_DISABLED. Which, in turn, sets antimagic. So most calls run
through their non-wrapped form.

The problem: I wrote my popen() wrapper wrong. See, I carefully
removed the check for pseudo_disabled from the top of it. But! That
code path is not actually the only way in which pseudo_disabled affects
behavior. That's just an *OPTIMIZATION*. The pseudo_disabled flag
also means that antimagic is set, and I copied that part of the wrapper
in unmodified:

if (antimagic > 0) {
/* call the real syscall */
rc = (*real_popen)(command, mode);
} else {
/* exec*() use this to restore the sig mask */
pseudo_saved_sigmask = saved;
rc = wrap_popen(command, mode);
}

And antimagic is 1, so I call real popen. Which forks. And even
though pseudo isn't in the LD_PRELOAD environment variable, it's still
in the process's address space, but PSEUDO_PREFIX isn't set, and for
some reason, the stashed value is missing. Not sure I can explain that
part yet; maybe we do have a path where we wipe the stashed value.

But the underlying problem is that my popen() wrapper was never
actually doing the setupenv/dropenv, or just a setupenv.

And the other underlying problem is that calling os.popen() directly is
probably something we should discourage, because we really do want to
know, for each subprocess we plan to spawn, whether it is running in
the pseudo environment or not. So if you call os.popen(), you get
"whatever state bitbake is in", which may not be at all what you wanted
or intended.

If I fix the popen() patch, it may actually start working again,
although I'm still not totally sure why the prefix is getting wiped out.

So... I think...

1. We should probably whitelist PSEUDO_PREFIX because life is a heck
of a lot easier if we aren't trying to set it and unset it all the time.
2. I need to fix my popen patch.
3. Once I've fixed that, I can probably do a much better job of
articulating what's happening to pseudo_prefix that's causing us to end
up with a child process where both the internal stash and the
environment variable are unset.

The big thing I was missing was that PSEUDO_DISABLED implies that
everything will always have antimagic >= 1.

-s
--
Listen, get this. Nobody with a good compiler needs to be justified.

my sutdent.

who are using archlinux? I want to talk about gconf compile fail
problem.


--
Yi Qingliang
niqingliang@...
https://niqingliang2003.wordpress.com

Thanks, Richard. Clearer now but not entirely.

On Mon, 2012-03-26 at 12:42 -0700, Rudolf Streif wrote:

Another variable that seems to be dropped from the latest 1.1.1
revision of the Reference Manual is BBMASK. In previous versions of
the manual it was explained that this variable can be used to remove
packages from images. However, that did not work for me and it did not
surprise me either.

BBMASK removes recipes from being parsed. It does not remove them from
images although that would I guess be an indirect result since you could
no longer build them.

To include a package with an image you will have to make it a
dependency of that image. If you then hide the recipe of the package
using BBMASK then you are breaking the dependency and the Bitbake will
complain with "Nothing provides <package>" because the dependency is
still there.

I could not think of any other use case for BBMASK in the way it is
implemented. Are there any?

Its designed so that if you for example didn't care out any *gpe*
recipe, you could exclude them entirely and not even have the parse
overhead.

Its less useful now things are split into layers but nonetheless still
valid syntax.

Cheers,

Richard

Scott,

On Mon, 2012-03-26 at 12:18 -0500, Peter Seebach wrote:

On Mon, 26 Mar 2012 17:47:29 +0100
Richard Purdie <richard.purdie@...> wrote:

This is pretty much what we do at the moment, it gets unset after we
load. Pseudo is of course disabled at this point.

I guess we just got lucky to this point and avoided "Bad Things"?

I suspect so. What's weird to me is that PSEUDO_PREFIX wasn't in the
environment before, either. So I still don't quite get this. I am
still missing something which will make this all make sense.

... at this point, I am leaning towards viewing this as a bug where it
is not enough to simply correct the behavior, I will not feel confident
in it until I have understood how it could have happened, but worked in
many other cases.

This is why I'm not saying lets just set PSEUDO_PREFIX. Its bothering me
too.

What puzzles me is we get this value from envbackup[key] =
os.environ.get("PSEUDO_PREFIX") so its already not in the
environment.

So basically if we read "PSEUDO_PREFIX" from the environment we get
nothing. If we unset the value back to being "nothing", things
break.

Yes. This is, of course, obviously impossible.

Obviously :). Except the code does this and I've watched it happen. I'm
not claiming to understand it...

Hmm. Well, hmm. When we start up, we should pick up PSEUDO_PREFIX
from our environment, and during some of the initial client setup, we
should be stashing that value in our stashed values table. At this
point, so far as I can tell, nothing should ever unset that stashed
value.

On fork(), we don't change anything until we're in the client side of
the fork, but that setup should happen in the same address space, with
the values still stashed.

When we poke new values into the environment, will it corrupt the
internal stash?

Oh, nevermind, I just realized: We use antimagic as the
implementation
goo for PSEUDO_DISABLED.

So a call to os.popen() from a program which has PSEUDO_DISABLED set
is going to think it's in antimagic mode.

And suddenly, the trick is revealed:

os.popen() is bypassing all the runqueue stuff which is trying to
ensure that the environment is in a valid state. So if bitbake code
calls os.popen(), it may behave weirdly, for the same reason that any
other direct invocation of fork() or system() or whatnot would behave
weirdly -- because bitbake is running with pseudo in a strange state.

I'd be very surprised if we don't make some other system() call
somewhere in bitbake's parent context.

If this were a trigger, it could go a long way to explaining some errors
people have reported though.

So I think the thing is:

Because bitbake is running with PSEUDO_DISABLED, any child process
that
is not explicitly set to either enable or unload pseudo is going to be
running under pseudo, with PSEUDO_DISABLED. And that means we need to
ensure that PSEUDO_PREFIX stays set, because we need that even when
pseudo is disabled. (It's used during some of the initial setup
sanity checks.)

This is the answer I was expecting we'd come to.

I'm still a little surprised we don't make any system() calls though. I
just tried putting a os.system("true") call into the "breakit" class and
it doesn't trigger the warnings. Could that be down to the lack of a
popen wrapper?

Cheers,

Richard

[YOCTO #1487]

For the liveCD image, interactive bootup is needed, but psplash prevents from
booting interactively. In such case ISO image is not usable, so remove ISO image
and the corresponding link and throw error info to warn outside to enable
unionfs in kenrel.

Signed-off-by: Yang Shi <yang.shi@...>
---
meta/recipes-sato/images/core-image-sato.bb | 16 ++++++++++++++++
1 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/meta/recipes-sato/images/core-image-sato.bb b/meta/recipes-sato/images/core-image-sato.bb
index 11c3318..10e2239 100644
--- a/meta/recipes-sato/images/core-image-sato.bb
+++ b/meta/recipes-sato/images/core-image-sato.bb
@@ -9,3 +9,19 @@ IMAGE_FEATURES += "apps-console-core ${SATO_IMAGE_FEATURES}"
LICENSE = "MIT"

inherit core-image
+
+LIVE = "${@base_contains('IMAGE_FSTYPES', 'live', 'yes', 'no', d)}"
+
+do_check_unionfs() {
+ if [ "${NOISO}" = "1" ]; then
+ return
+ fi
+
+ if [ "${LIVE}" = "yes" ] && ! grep -q "CONFIG_UNION_FS=y" ${STAGING_KERNEL_DIR}/.config; then
+ rm -f ${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.iso
+ rm -f ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.iso
+ bbfatal "Building LIVE CD without UNION FS enabled in kernel"
+ fi
+}
+
+addtask check_unionfs before do_build after do_bootimg
--
1.7.5.4

[YOCTO #1487]

Use unionfs to mount rootfs and make root file system can be writen when using liveCD to boot up.
Set UNION_FS variable depending on kenrel config, so that it can work with kernel which doesn't
have unionfs feature.

Signed-off-by: Yang Shi <yang.shi@...>
---
meta/recipes-core/initrdscripts/files/init-live.sh | 21 +++++++++++++++++--
.../initrdscripts/initramfs-live-boot_1.0.bb | 9 +++++++-
2 files changed, 26 insertions(+), 4 deletions(-)

diff --git a/meta/recipes-core/initrdscripts/files/init-live.sh b/meta/recipes-core/initrdscripts/files/init-live.sh
index eb5ab5b..abaf16c 100644
--- a/meta/recipes-core/initrdscripts/files/init-live.sh
+++ b/meta/recipes-core/initrdscripts/files/init-live.sh
@@ -7,6 +7,7 @@ ROOT_IMAGE="rootfs.img"
MOUNT="/bin/mount"
UMOUNT="/bin/umount"
ISOLINUX=""
+UNIONFS="no"

early_setup() {
mkdir /proc
@@ -89,10 +90,24 @@ case $label in
mkdir $ROOT_MOUNT
mknod /dev/loop0 b 7 0 2>/dev/null

- if ! $MOUNT -o rw,loop,noatime,nodiratime /media/$i/$ISOLINUX/$ROOT_IMAGE $ROOT_MOUNT ; then
- fatal "Couldnt mount rootfs image"
+
+ if [ "$UNIONFS" = "yes" ]; then
+ mkdir /rootfs-tmp
+
+ if ! $MOUNT -o rw,loop,noatime,nodiratime /media/$i/$ISOLINUX/$ROOT_IMAGE /rootfs-tmp ; then
+ fatal "Couldnt mount rootfs image"
+ else
+ mkdir /cow
+ mount -t tmpfs -o rw,noatime,mode=755 tmpfs /cow
+ mount -t unionfs -o dirs=/cow:/rootfs-tmp=ro unionfs $ROOT_MOUNT
+ boot_live_root
+ fi
else
- boot_live_root
+ if ! $MOUNT -o rw,loop,noatime,nodiratime /media/$i/$ISOLINUX/$ROOT_IMAGE $ROOT_MOUNT ; then
+ fatal "Couldnt mount rootfs image"
+ else
+ boot_live_root
+ fi
fi
;;
install)
diff --git a/meta/recipes-core/initrdscripts/initramfs-live-boot_1.0.bb b/meta/recipes-core/initrdscripts/initramfs-live-boot_1.0.bb
index e85a0e1..f7f0c9d 100644
--- a/meta/recipes-core/initrdscripts/initramfs-live-boot_1.0.bb
+++ b/meta/recipes-core/initrdscripts/initramfs-live-boot_1.0.bb
@@ -2,10 +2,17 @@ DESCRIPTION = "A live image init script"
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
RDEPENDS = "udev"
+DEPENDS = "virtual/kernel"
SRC_URI = "file://init-live.sh"

-PR = "r7"
+PR = "r8"

+do_compile() {
+ if grep -q "CONFIG_UNION_FS=y" ${STAGING_KERNEL_DIR}/.config; then
+ sed -i 's/UNIONFS="no"/UNIONFS="yes"/g' ${WORKDIR}/init-live.sh
+ fi
+}
+
do_install() {
install -m 0755 ${WORKDIR}/init-live.sh ${D}/init
}
--
1.7.5.4

Use unionfs to mount rootfs and make root file system can be writen when using liveCD to boot up.
Set UNION_FS variable depending on kenrel config, so that it can work with kernel which doesn't
have unionfs feature.

Without UNION FS enabled in kernel, minimal liveCD image can be bootup to ignore the failure of mouting
read-only filesystem. For the sato liveCD image, interactive bootup is needed, but psplash prevents from
booting interactively. In such case ISO image is not usable, so remove ISO image and the corresponding
link and throw error info to warn outside to enable unionfs in kenrel.

We tried a lot of different ways to achieve this:

1. Check if ISO image is built in initramfs-live-boot.bb or not, then prevent from generating ISO image.
But, we can't distinguish minimal image or sato image.

2. Check if x11 feature is included in initramfs-live-boot.bb or not, then prevent from generating ISO image.
But, x11 feature is contained in minimal image as well even though the package is not built.

3. Tried to append some check code in build_iso() in core-image-sato.bb, but poky can't support append code
in build_xxx functions like what we do for do_xxx funcitons.

So, we came up with current solution. Any new suggestion is appreciated.

One more thing is that if IMAGE_FSTYPE += "live" is not set in conf/local.conf with this fix, we will get below
error when building sato image:

ERROR: Running idle function
Traceback (most recent call last):
File "/home/yshi/yocto/poky/bitbake/lib/bb/server/process.py", line
122, in ProcessServer.idle_commands(delay=0.1):
try:
> retval = function(self, data, False)
if retval is False:
File "/home/yshi/yocto/poky/bitbake/lib/bb/cooker.py", line 1130, in
buildTargetsIdle(server=<ProcessServer(ProcessServer-1, started)>,
rq=<bb.runqueue.RunQueue instance at 0x74e4638>, abort=False):
try:
> retval = rq.execute_runqueue()
except runqueue.TaskFailure as exc:
File "/home/yshi/yocto/poky/bitbake/lib/bb/runqueue.py", line 947,
in RunQueue.execute_runqueue():
self.rqexe = RunQueueExecuteDummy(self)
> if self.rqdata.prepare() == 0:
self.state = runQueueComplete
File "/home/yshi/yocto/poky/bitbake/lib/bb/runqueue.py", line 719,
in RunQueueData.prepare():

procdep.append(self.taskData.fn_index[self.runq_fnid[dep]] + "." +
self.runq_task[dep])
> self.runq_hash[task] =
bb.parse.siggen.get_taskhash(self.taskData.fn_index[self.runq_fnid[task]],
self.runq_task[task], procdep, self.dataCache)

File "/home/yshi/yocto/poky/bitbake/lib/bb/siggen.py", line 153, in
SignatureGeneratorOEBasicHash.get_taskhash(fn='/home/yshi/yocto/poky/meta/recipes-sato/images/core-image-sato.bb',
task='do_bootimg', deps=[], dataCache=<bb.cache.CacheData object at
0x2148490>):
k = fn + "." + task
> data = dataCache.basetaskhash[k]
self.runtaskdeps[k] = []
KeyError: '/home/yshi/yocto/poky/meta/recipes-sato/images/core-image-sato.bb.do_bootimg'

NOTE: Preparing runqueue

Bruce pointed out there was a large discussion about this on hte list last week, so this should be a known issue in poky.

The following changes since commit f81b0593e74a31cb2d992df0583948ff57e3ed98:

gdbm: Activate -enable-libgdbm-compat and add symlinks to headers in include/gdbm (2012-03-23 17:56:29 +0200)

are available in the git repository at:
git://git.yoctoproject.org/poky-contrib yshi/1487
http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=yshi/1487

Yang Shi (2):
initrdscripts: fix init-live.sh and use unionfs
sato: Remove questioned ISO image

meta/recipes-core/initrdscripts/files/init-live.sh | 21 +++++++++++++++++--
.../initrdscripts/initramfs-live-boot_1.0.bb | 9 +++++++-
meta/recipes-sato/images/core-image-sato.bb | 16 +++++++++++++++
3 files changed, 42 insertions(+), 4 deletions(-)

Oh, nevermind, I just realized: We use antimagic as the implementation
goo for PSEUDO_DISABLED.

So a call to os.popen() from a program which has PSEUDO_DISABLED set is
going to think it's in antimagic mode.

And suddenly, the trick is revealed:

os.popen() is bypassing all the runqueue stuff which is trying to
ensure that the environment is in a valid state. So if bitbake code
calls os.popen(), it may behave weirdly, for the same reason that any
other direct invocation of fork() or system() or whatnot would behave
weirdly -- because bitbake is running with pseudo in a strange state.

So I think the thing is:

Because bitbake is running with PSEUDO_DISABLED, any child process that
is not explicitly set to either enable or unload pseudo is going to be
running under pseudo, with PSEUDO_DISABLED. And that means we need to
ensure that PSEUDO_PREFIX stays set, because we need that even when
pseudo is disabled. (It's used during some of the initial setup
sanity checks.)

-s
--
Listen, get this. Nobody with a good compiler needs to be justified.