I'm just upgrading to pyro and have some issues with u-boot-fw-utils.

The error fails at do_compile stage which looks like this:

do_compile () {
oe_runmake ${UBOOT_MACHINE}
oe_runmake env
}


The error is:

Log data follows:
| DEBUG: Executing shell function do_compile
| NOTE: make -j 16 CROSS_COMPILE=arm-senic-linux-gnueabi-
CC=arm-senic-linux-gnueabi- gcc -march=armv7ve -mfpu=neon-vfpv4
-mfloat-abi=hard -mcpu=cortex-a7
--sysroot=/home/alan/senic-os-update/build/tmp-glibc/work/senic_hub_beta-senic-linux-gnueabi/u-boot-fw-utils-senic/v2017.03+gitAUTOINC+5233f17333-r0/recipe-sysroot
-O2 -pipe -g -feliminate-unused-debug-types
-fdebug-prefix-map=/home/alan/senic-os-update/build/tmp-glibc/work/senic_hub_beta-senic-linux-gnueabi/u-boot-fw-utils-senic/v2017.03+gitAUTOINC+5233f17333-r0=/usr/src/debug/u-boot-fw-utils-senic/v2017.03+gitAUTOINC+5233f17333-r0
-fdebug-prefix-map=/home/alan/senic-os-update/build/tmp-glibc/work/senic_hub_beta-senic-linux-gnueabi/u-boot-fw-utils-senic/v2017.03+gitAUTOINC+5233f17333-r0/recipe-sysroot-native=
-fdebug-prefix-map=/home/alan/senic-os-update/build/tmp-glibc/work/senic_hub_beta-senic-linux-gnueabi/u-boot-fw-utils-senic/v2017.03+gitAUTOINC+5233f17333-r0/recipe-sysroot=
-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed V=1
| ERROR: oe_runmake failed
| make -f ./Makefile silentoldconfig
| make -f ./scripts/Makefile.build obj=scripts/basic
| cc -Wp,-MD,scripts/basic/.fixdep.d -Wall -Wstrict-prototypes -O2
-fomit-frame-pointer -o scripts/basic/fixdep
scripts/basic/fixdep.c
| /bin/sh: 1: cc: not found


I would assume this is a to specific error to ask help about. It seems
that the compiler isn't being called correctly (it's called as cc,
which isn't the full compiler name).
Suggestions are welcome but that isn't the reason for my post.

Is there a way to run the above listed make command with the same
environment as it is run when the error is produced?

I have tried:

devtool modify u-boot-fw-utils

but it doesn't bring me to an environment where I can reproduce the
error by executing the make call manually.
I get different non related errors:

make: invalid option -- 'a'
make: invalid option -- 'c'
make: invalid option -- '='
make: invalid option -- 'a'
make: invalid option -- '7'
make: invalid option -- 'c'
make: invalid option -- 'u'
make: invalid option -- '='

and the make I'm using comes from /usr/bin/make instead of somewhere from yocto.

Any ideas on how to approach?

Be Well,
Alan

On 11/01/2017 06:43 PM, colin.helliwell@... wrote:

I need to build two slightly varying versions of our Yocto build – one for the production units and one for development.
They differ in only a few ways – the kernel and apps are the same. But one has Dropbear, whilst the other doesn’t; and the U-Boot configs & patches are different.
I’m wondering where to do the separation – image, distro, conf…?
Any thoughts on the cleanest way to split and/or inherit them would be appreciated.

Image, certainly. Put the common bits into an include, and specific bits into image-production|development.bb files. Poky has plenty of examples for this.


Alex

On Wed, 2017-11-01 at 15:58 +0000, Adam Lee wrote:

Thanks Fabien, I definitely don't have Xwayland in my rootfs. My manifest is missing xserver-xorg-
xwayland as well.

Which image are you using? I thought including of  "x11 wayland" was sufficient. Perhaps not..?

The image I built is a custom one but I tried core-image-weston on imx6 and rpi3 and it does the
job.

Adam

On Wed, Nov 1, 2017 at 10:28 AM Fabien Lahoudere <fabien.lahoudere@...> wrote:

On Wed, 2017-11-01 at 14:10 +0000, Adam Lee wrote:

Hello, how do I tell if I successfully built xwayland into my image?

I looked for "xwayland" binary but to no avail.

I have this /usr/bin/Xwayland in my rootfs.

Check you manifest. It should contain xserver-xorg-xwayland.

Adam

--
Fabien
--
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto

--
Fabien

On 11/1/2017 12:11 AM, Andre McCurdy wrote:

The fetcher explicitly tries to avoid that by retrying each file only
once. See retry logic in:
http://git.openembedded.org/bitbake/commit/?id=54b1961551511948e0cbd2ac39f19b39b9cee568
However, there is a later commit which may also be related:
http://git.openembedded.org/bitbake/commit/?id=6fa07752bbd3ac345cd8617da49a70e0b2dd565f

I didnt have this patch, presently i am on morty branch. I will check with master branch

Thanks for the info
Vineeth

Does the version of bitbake which you are using contain both commits?

On Wed, 2017-11-01 at 14:10 +0000, Adam Lee wrote:

Hello, how do I tell if I successfully built xwayland into my image?

I looked for "xwayland" binary but to no avail.

I have this /usr/bin/Xwayland in my rootfs.

Check you manifest. It should contain xserver-xorg-xwayland.

Adam

--
Fabien

On 11/1/17 8:49 AM, Mark Hatle wrote:

On 11/1/17 4:17 AM, Pavlina Varekova wrote:

Hi,
thank you very much. It sounds good. So I tried replace fakechroot with pseudo.
I read man pages and replace:

FAKECHROOT_BASE="${DIR1}" fakechroot  command

with:

%{PATH/TO/PSEUDO/}bin/pseudo  -r "${DIR1}" -P %{PATH/TO/PSEUDO/} command

But it does not work good. Probably some variable is set differently.
Please is the replacement correct?

Pavlina

I always run pseudo, then once the shell opens then run 'chroot <path>' within
pseudo.

The system will still execute commands outside of the 'chroot', but any
application looking at the file filesystem will appear to be constrained.

I just realized, it -may- still execute commands outside of the chroot. pseudo
(like fakechroot) can not protect everything like a real chroot.

Below is my typical use:

$ ./bin/pseudo /bin/bash
# chroot /usr
# cd /
# ls
bash: ls: command not found
# bin/ls
bin etc games include lib lib64 libexec local sbin share src tmp

So it's working here.


But using the -r option, appears to work as well:

$ ./bin/pseudo -r /usr /bin/bash
bash-4.2# cd /
bash-4.2# ls
bash: ls: command not found
bash-4.2# bin/ls
bin etc games include lib lib64 libexec local sbin share src tmp
bash-4.2#

--Mark

--Mark

On 11/1/17 4:17 AM, Pavlina Varekova wrote:

Hi,
thank you very much. It sounds good. So I tried replace fakechroot with pseudo.
I read man pages and replace:

FAKECHROOT_BASE="${DIR1}" fakechroot  command

with:

%{PATH/TO/PSEUDO/}bin/pseudo  -r "${DIR1}" -P %{PATH/TO/PSEUDO/} command

But it does not work good. Probably some variable is set differently.
Please is the replacement correct?

Pavlina

I always run pseudo, then once the shell opens then run 'chroot <path>' within
pseudo.

The system will still execute commands outside of the 'chroot', but any
application looking at the file filesystem will appear to be constrained.

--Mark

From: André Draszik <adraszik@...>

It is currently impossible to override localstatedir,
mandir and sysconfdir during ./configure, because they
are being overriden unconditionally.

With this patch it is now possible to set above
locations as needed.

Signed-off-by: André Draszik <adraszik@...>
---
...-override-localstatedir-mandir-sysconfdir.patch | 68 ++++++++++++++++++++++
meta-tpm/recipes-tpm/trousers/trousers_git.bb | 1 +
2 files changed, 69 insertions(+)
create mode 100644 meta-tpm/recipes-tpm/trousers/files/0001-build-don-t-override-localstatedir-mandir-sysconfdir.patch

diff --git a/meta-tpm/recipes-tpm/trousers/files/0001-build-don-t-override-localstatedir-mandir-sysconfdir.patch b/meta-tpm/recipes-tpm/trousers/files/0001-build-don-t-override-localstatedir-mandir-sysconfdir.patch
new file mode 100644
index 0000000..7b3cc77
--- /dev/null
+++ b/meta-tpm/recipes-tpm/trousers/files/0001-build-don-t-override-localstatedir-mandir-sysconfdir.patch
@@ -0,0 +1,68 @@
+From 3396fc7a184293c23135161f034802062f7f3816 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Andr=C3=A9=20Draszik?= <adraszik@...>
+Date: Wed, 1 Nov 2017 11:41:48 +0000
+Subject: [PATCH] build: don't override --localstatedir --mandir --sysconfdir
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+It is currently impossible to override localstatedir,
+mandir and sysconfdir during ./configure, because they
+are being overriden unconditionally because of they
+way trousers is built using rpmbuild.
+
+If they need massaging for rpmbuild, the values should
+be specified inside the spec file, not in ./configure
+and thereby overriding user-requested values.
+
+With this patch it is now possible to set above
+locations as needed. The .spec file is being modified
+as well so as to restore previous behaviour.
+
+Signed-off-by: André Draszik <adraszik@...>
+---
+Upstream-Status: Submitted [https://sourceforge.net/p/trousers/mailman/message/36099290/]
+Signed-off-by: André Draszik <adraszik@...>
+ configure.ac | 11 ++---------
+ dist/trousers.spec.in | 2 +-
+ 2 files changed, 3 insertions(+), 10 deletions(-)
+
+diff --git a/configure.ac b/configure.ac
+index b9626af..7fe5f8e 100644
+--- a/configure.ac
++++ b/configure.ac
+@@ -376,16 +376,9 @@ CFLAGS="$CFLAGS -I../include \
+ KERNEL_VERSION=`uname -r`
+ AC_SUBST(CFLAGS)
+
+-# When we build the rpms, prefix will be /usr. This'll do some things that make sense,
+-# like put our sbin stuff in /usr/sbin and our library in /usr/lib. It'll do some other
+-# things that don't make sense like put our config file in /usr/etc. So, I'll just hack
+-# it here. If the --prefix option isn't specified during configure, let it all go to
++# If the --prefix option isn't specified during configure, let it all go to
+ # /usr/local, even /usr/local/etc. :-P
+-if test x"${prefix}" = x"/usr"; then
+- sysconfdir="/etc"
+- localstatedir="/var"
+- mandir="/usr/share/man"
+-elif test x"${prefix}" = x"NONE"; then
++if test x"${prefix}" = x"NONE"; then
+ localstatedir="/usr/local/var"
+ fi
+
+diff --git a/dist/trousers.spec.in b/dist/trousers.spec.in
+index b298b0e..10ef178 100644
+--- a/dist/trousers.spec.in
++++ b/dist/trousers.spec.in
+@@ -45,7 +45,7 @@ applications.
+
+ %build
+ %{?arch64:export PKG_CONFIG_PATH=%{pkgconfig_path}:$PKG_CONFIG_PATH}
+-./configure --prefix=/usr --libdir=%{_libdir}
++./configure --prefix=/usr --libdir=%{_libdir} --sysconfdir=/etc --localstatedir=/var --mandir=/usr/share/man
+ make
+
+ %clean
+--
+2.15.0.rc1
+
diff --git a/meta-tpm/recipes-tpm/trousers/trousers_git.bb b/meta-tpm/recipes-tpm/trousers/trousers_git.bb
index 352374c..e9f838e 100644
--- a/meta-tpm/recipes-tpm/trousers/trousers_git.bb
+++ b/meta-tpm/recipes-tpm/trousers/trousers_git.bb
@@ -15,6 +15,7 @@ SRC_URI = " \
file://trousers-udev.rules \
file://tcsd.service \
file://get-user-ps-path-use-POSIX-getpwent-instead-of-getpwe.patch \
+ file://0001-build-don-t-override-localstatedir-mandir-sysconfdir.patch \
"

S = "${WORKDIR}/git"
--
2.15.0.rc1

From: André Draszik <adraszik@...>

The combination of using start-stop-daemon and pidof is
not working reliably in all cases. Sometimes, the
tcsd daemon isn't running yet at the time pidof is being
invoked.

This results in an empty /var/run/tcsd.pid, making it
impossible to stop tcsd using the init script.

To solve this, one could either add a delay before calling
pidof, or alternatively use start-stop-daemon's built-in
functionality to achieve the same.

Let's do the latter.

Signed-off-by: André Draszik <adraszik@...>
---
meta-tpm/recipes-tpm/trousers/files/trousers.init.sh | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/meta-tpm/recipes-tpm/trousers/files/trousers.init.sh b/meta-tpm/recipes-tpm/trousers/files/trousers.init.sh
index 0ecf7cc..d0d6cb3 100644
--- a/meta-tpm/recipes-tpm/trousers/files/trousers.init.sh
+++ b/meta-tpm/recipes-tpm/trousers/files/trousers.init.sh
@@ -33,10 +33,12 @@ case "${1}" in
exit 0
fi

- start-stop-daemon --start --quiet --oknodo --pidfile /var/run/${NAME}.pid --user ${USER} --chuid ${USER} --exec ${DAEMON} -- ${DAEMON_OPTS}
+ start-stop-daemon --start --quiet --oknodo \
+ --pidfile /var/run/${NAME}.pid --make-pidfile --background \
+ --user ${USER} --chuid ${USER} \
+ --exec ${DAEMON} -- ${DAEMON_OPTS} --foreground
RETVAL="$?"
echo "$NAME."
- [ "$RETVAL" = 0 ] && pidof $DAEMON > /var/run/${NAME}.pid
exit $RETVAL
;;

--
2.15.0.rc1

This message contains information that may be privileged or confidential and is the property of the KPIT Technologies Ltd. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. KPIT Technologies Ltd. does not accept any liability for virus infected mails.

Hi,
thank you very much. It sounds good. So I tried replace fakechroot with pseudo.
I read man pages and replace:

FAKECHROOT_BASE="${DIR1}" fakechroot  command

with:

%{PATH/TO/PSEUDO/}bin/pseudo  -r "${DIR1}" -P %{PATH/TO/PSEUDO/} command

But it does not work good. Probably some variable is set differently.
Please is the replacement correct?

Pavlina

On 11/1/2017 12:11 AM, Andre McCurdy wrote:

It looks like the logic in the wget fetcher retries once, so if it's getting stuck
then that seems like a genuine bug.

Vineeth, are you sure it's really continuously retrying?

Yes, I see continuous retry of wget of same sstate files.

The fetcher explicitly tries to avoid that by retrying each file only
once. See retry logic in:

http://git.openembedded.org/bitbake/commit/?id=54b1961551511948e0cbd2ac39f19b39b9cee568

However, there is a later commit which may also be related:

http://git.openembedded.org/bitbake/commit/?id=6fa07752bbd3ac345cd8617da49a70e0b2dd565f

Does the version of bitbake which you are using contain both commits?

Thanks Andre
I am not having later patch. I will check the issue with master branch

Ross,

That works great.

Thanks,

-Dave

Hey,

I am trying to add a single ptest to my image without adding all ptests from all other packages in my distro.

https://wiki.yoctoproject.org/wiki/Ptest only has instructions to add ptest-pkgs, but this is too large for my embedded platform.

How can I install ptest-runner plus the single ptest from a specific recipe?


Thanks,

-Dave