Date   

[PATCH][autobuilder-helper][warrior 05/41] layer-config, shared-repo-unpack: Sub-repos in NEEDREPOS

Richard Purdie
 

From: Thomas Goodwin <btgoodwin@geontech.com>

The previous fixes requires the user to set "no-layer-add"
for a repo and then use ADDLAYER to insert the sub-repos
(e.g., meta-openmbedded/meta-oe) as a two-part process.
This means that you would also have to specify that flag
if a repo that is a layer with dependencies is in the
list so that it can be inserted in the correct order later
via ADDLAYER to avoid parsing problems. This fix allows
for specifying a NEEDREPOS with the subdirectory of the
target layer (e.g., meta-openembedded/meta-oe) so that
there is no need for the "no-layer-add" followed by
ADDLAYER combination. The entire meta-openembedded
repo would be moved into place, and the sublayer added
to bblayers.conf.

Signed-off-by: Thomas Goodwin <btgoodwin@geontech.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
scripts/layer-config | 24 +++++++++++++++---------
scripts/shared-repo-unpack | 4 ++--
2 files changed, 17 insertions(+), 11 deletions(-)

diff --git a/scripts/layer-config b/scripts/layer-config
index 286451a..bb1b681 100755
--- a/scripts/layer-config
+++ b/scripts/layer-config
@@ -33,21 +33,27 @@ callinit = False
repos = utils.getconfig("repo-defaults", ourconfig)

for repo in needrepos:
- checkdir = repo
- if repo in repos:
- if "call-init" in repos[repo] and repos[repo]["call-init"]:
+ repo_basename = repo.split('/')[0]
+ checkdir = repo_basename
+ if repo_basename in repos:
+ if "call-init" in repos[repo_basename] and repos[repo_basename]["call-init"]:
callinit = True
- if "checkout-dirname" in repos[repo]:
- checkdir = repos[repo]["checkout-dirname"]
- utils.mkdir(args.abworkdir + "/" + checkdir)
- for f in os.listdir(args.abworkdir + "/repos/" + repo):
- subprocess.check_call(['mv', args.abworkdir + "/repos/" + repo + "/" + f, args.abworkdir + "/" + checkdir + "/"])
+ if "checkout-dirname" in repos[repo_basename]:
+ checkdir = repos[repo_basename]["checkout-dirname"]
+
+ source = args.abworkdir + "/repos/" + repo_basename
+ destination = args.abworkdir + "/" + checkdir
+ if not os.path.isdir(destination) or callinit:
+ utils.mkdir(destination)
+ for f in os.listdir(source):
+ subprocess.check_call(['mv', source + "/" + f, destination + "/"])

if callinit:
subprocess.check_call(". ./oe-init-build-env", shell=True, cwd=args.abworkdir)

for repo in needrepos:
- if repo in repos and "no-layer-add" in repos[repo] and repos[repo]["no-layer-add"]:
+ repo_basename = repo.split('/')[0]
+ if repo_basename in repos and "no-layer-add" in repos[repo_basename] and repos[repo_basename]["no-layer-add"]:
continue
try:
bitbakecmd(args.abworkdir, "bitbake-layers add-layer %s" % (args.abworkdir + "/" + repo))
diff --git a/scripts/shared-repo-unpack b/scripts/shared-repo-unpack
index a281897..92f0ccf 100755
--- a/scripts/shared-repo-unpack
+++ b/scripts/shared-repo-unpack
@@ -46,9 +46,9 @@ with open(args.repojson) as f:
repos = json.load(f)

targetsubdir = args.abworkdir + "/repos"
-
+needrepos_baseddirs = [r.split('/')[0] for r in needrepos]
for repo in sorted(repos.keys()):
- if repo not in needrepos:
+ if repo not in needrepos_baseddirs:
continue
targetrepodir = "%s/%s" % (targetsubdir, repo)
if args.cache_dir:
--
2.25.1


[PATCH][autobuilder-helper][warrior 04/41] layer-config: fixing silent failures from always exiting '0'

Richard Purdie
 

From: Thomas Goodwin <btgoodwin@geontech.com>

The return value from bitbakecmd was not being returned when
errors occurred which allowed shared-repo-unpack to succeed
despite the failure. This fix changes to check_call and a
try-catch when attempting to add repos that fail for whatever
reason during add-layer, like a missing conf/layer.conf at
the top level or a previously-added layer breaks parsing
because of missing dependencies.

Signed-off-by: Thomas Goodwin <btgoodwin@geontech.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
scripts/layer-config | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/scripts/layer-config b/scripts/layer-config
index bfc62da..286451a 100755
--- a/scripts/layer-config
+++ b/scripts/layer-config
@@ -24,9 +24,7 @@ args = parser.parse_args()
ourconfig = utils.loadconfig()

def bitbakecmd(targetdir, cmd):
- ret = subprocess.call(". ./oe-init-build-env; %s" % cmd, shell=True, cwd=targetdir)
- if ret:
- utils.printheader("ERROR: Command %s failed with exit code %d, see errors above." % (cmd, ret))
+ subprocess.check_call(". ./oe-init-build-env; %s" % cmd, shell=True, cwd=targetdir)

needrepos = utils.getconfigvar("NEEDREPOS", ourconfig, args.target, None)

@@ -51,5 +49,8 @@ if callinit:
for repo in needrepos:
if repo in repos and "no-layer-add" in repos[repo] and repos[repo]["no-layer-add"]:
continue
- bitbakecmd(args.abworkdir, "bitbake-layers add-layer %s" % (args.abworkdir + "/" + repo))
-
+ try:
+ bitbakecmd(args.abworkdir, "bitbake-layers add-layer %s" % (args.abworkdir + "/" + repo))
+ except subprocess.CalledProcessError as e:
+ utils.printheader("ERROR: Command %s failed with exit code %d, see errors above." % (e.cmd, e.returncode))
+ sys.exit(e.returncode)
--
2.25.1


[PATCH][autobuilder-helper][warrior 03/41] README: Add pointer to the mailing list for patches

Richard Purdie
 

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
README | 5 +++++
1 file changed, 5 insertions(+)

diff --git a/README b/README
index a6c4f1d..2747510 100644
--- a/README
+++ b/README
@@ -25,3 +25,8 @@ would also allow customisation.
Authors:
Richard Purdie <richard.purdie@linuxfoundation.org>
Joshua Lock <joshua.g.lock@intel.com>
+
+Contributions:
+
+Patches for this code should be sent to the yocto@yoctoproject.org mailing list
+with [yocto-autobuilder-helper] in the subject.
--
2.25.1


[PATCH][autobuilder-helper][warrior 02/41] config.json: Hide WARNINGS we don't care about for meta-gplv2 testing

Richard Purdie
 

We're not interested in these warnings, the license incompatibility is
expected. By hiding these, we'll notice when warnings we do care about
appear.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
config.json | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/config.json b/config.json
index 90b78f3..43526de 100644
--- a/config.json
+++ b/config.json
@@ -553,7 +553,8 @@
"MACHINE" : "qemux86",
"BBTARGETS" : "core-image-minimal core-image-full-cmdline",
"extravars" : [
- "INCOMPATIBLE_LICENSE = '*GPLv3'"
+ "INCOMPATIBLE_LICENSE = '*GPLv3'",
+ "WARN_QA_remove = 'incompatible-license'"
],
"EXTRACMDS" : [
"../../yocto-autobuilder-helper/scripts/check-gplv3"
--
2.25.1


[PATCH][autobuilder-helper][warrior 01/41] config.json: Disable PRSERV

Richard Purdie
 

This was copied from the old autobuilder configuration without much thought.
It would only be effective if we had a common PRSERV or saved the database
but we don't. It therefore makes sense to disable it.

One problem it was causing was inconsistency in the buildhistory output as
PKGR would change "r0" to "r0.0" and vice versa. The issue depended on whether
the build has coming from sstate or not and the settings the sstate had been
built with.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
config.json | 6 ------
1 file changed, 6 deletions(-)

diff --git a/config.json b/config.json
index 573082a..90b78f3 100644
--- a/config.json
+++ b/config.json
@@ -24,7 +24,6 @@
"DISTRO" : "poky",
"SDKMACHINE" : "i686",
"PACKAGE_CLASSES" : "package_rpm package_deb package_ipk",
- "PRSERV" : "PRSERV_HOST = 'localhost:0'",
"DLDIR" : "DL_DIR = '${BASE_SHAREDDIR}/current_sources'",
"SSTATEDIR" : ["SSTATE_DIR ?= '${BASE_SHAREDDIR}/pub/sstate-warrior'"],
"SSTATEDIR_RELEASE" : ["SSTATE_MIRRORS += 'file://.* file://${BASE_SHAREDDIR}/pub/sstate/PATH'", "SSTATE_DIR ?= '${BASE_PUBLISHDIR}/sstate/@RELEASENUM@'"],
@@ -67,7 +66,6 @@
"SANITYTARGETS" : "core-image-sato:do_testsdk core-image-minimal:do_testsdkext core-image-sato:do_testsdkext"
},
"step3" : {
- "PRSERV" : false,
"BUILDHISTORY" : false,
"EXTRACMDS" : ["${SCRIPTSDIR}/checkvnc; DISPLAY=:1 oe-selftest -r runqemu meta_ide -j 15"],
"ADDLAYER" : ["${BUILDDIR}/../meta-selftest"]
@@ -124,7 +122,6 @@
"MACHINE" : "qemux86-64",
"SDKMACHINE" : "x86_64",
"PACKAGE_CLASSES" : "package_rpm",
- "PRSERV" : false,
"extravars" : [
"RPM_GPG_SIGN_CHUNK = '1'"
],
@@ -142,7 +139,6 @@
"trigger-build" : {
"SDKMACHINE" : "x86_64",
"MACHINE" : "qemux86",
- "PRSERV" : false,
"step1" : {
"BBTARGETS" : "universe -c fetch -k",
"extravars" : [
@@ -235,7 +231,6 @@
"MACHINE" : "qemux86-64",
"SDKMACHINE" : "x86_64",
"PACKAGE_CLASSES" : "package_rpm",
- "PRSERV" : false,
"extravars" : [
"RPM_GPG_SIGN_CHUNK = '1'"
],
@@ -596,7 +591,6 @@
"MACHINE" : "qemux86",
"SDKMACHINE" : "x86_64",
"BBTARGETS" : "universe:do_checkuri",
- "PRSERV" : false,
"extravars" : [
"SOURCE_MIRROR_FETCH = '1'",
"BB_NUMBER_THREADS = '1'",
--
2.25.1


Re: #sdk #yocto Appears SDK searching host for files that are only present on target side #sdk #yocto

Monsees, Steven C (US)
 


fyi...

I am using CMake with GNU, that is what is required for the build.

I do source the SDK environment script prior to attempting build.

Here is my current environment-setup-corei7-64-poky-linux script created by SDK:

# Check for LD_LIBRARY_PATH being set, which can break SDK and generally is a bad practice
# http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html#AEN80
# http://xahlee.info/UnixResource_dir/_/ldpath.html
# Only disable this check if you are absolutely know what you are doing!
if [ ! -z "$LD_LIBRARY_PATH" ]; then
    echo "Your environment is misconfigured, you probably need to 'unset LD_LIBRARY_PATH'"
    echo "but please check why this was set in the first place and that it's safe to unset."
    echo "The SDK will not operate correctly in most cases when LD_LIBRARY_PATH is set."
    echo "For more references see:"
    echo "  http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html#AEN80"
    echo "  http://xahlee.info/UnixResource_dir/_/ldpath.html"
    return 1
fi
export SYSROOTS=/ede/smonsees/yocto/testSDK/sysroots
export SDKTARGETSYSROOT=/disk0/scratch/smonsees/yocto/testSDK/sysroots/corei7-64-poky-linux
export PATH=/disk0/scratch/smonsees/yocto/testSDK/sysroots/x86_64-pokysdk-linux/usr/bin:/disk0/scratch/smonsees/yocto/testSDK/sysroots/x86_64-pokysdk-linux/usr/sbin:/disk0/scratch/smonsees/yocto/testSDK/sysroots/x86_64-pokysdk-linux/bin:/disk0/scratch/smonsees/yocto/testSDK/sysroots/x86_64-pokysdk-linux/sbin:/disk0/scratch/smonsees/yocto/testSDK/sysroots/x86_64-pokysdk-linux/usr/bin/../x86_64-pokysdk-linux/bin:/disk0/scratch/smonsees/yocto/testSDK/sysroots/x86_64-pokysdk-linux/usr/bin/x86_64-poky-linux:/disk0/scratch/smonsees/yocto/testSDK/sysroots/x86_64-pokysdk-linux/usr/bin/x86_64-poky-linux-musl:/disk0/scratch/smonsees/yocto/testSDK/sysroots/corei7-64-poky-linux/usr/lib/../lib/:/disk0/scratch/smonsees/yocto/testSDK/sysroots/corei7-64-poky-linux/usr/lib/../lib/x86_64-poky-linux/7.3.0/:$PATH
export PKG_CONFIG_SYSROOT_DIR=$SDKTARGETSYSROOT
export PKG_CONFIG_PATH=$SDKTARGETSYSROOT/usr/lib/pkgconfig:$SDKTARGETSYSROOT/usr/share/pkgconfig
export CONFIG_SITE=/disk0/scratch/smonsees/yocto/testSDK/site-config-corei7-64-poky-linux
export OECORE_NATIVE_SYSROOT="/disk0/scratch/smonsees/yocto/testSDK/sysroots/x86_64-pokysdk-linux"
export OECORE_TARGET_SYSROOT="$SDKTARGETSYSROOT"
export OECORE_ACLOCAL_OPTS="-I /disk0/scratch/smonsees/yocto/testSDK/sysroots/x86_64-pokysdk-linux/usr/share/aclocal"
unset command_not_found_handle
export CC="x86_64-poky-linux-gcc  -v -m64 -march=corei7 -mtune=corei7 -mfpmath=sse -msse4.2 --sysroot=$SDKTARGETSYSROOT"
export CXX="x86_64-poky-linux-g++  -v -m64 -march=corei7 -mtune=corei7 -mfpmath=sse -msse4.2 --sysroot=$SDKTARGETSYSROOT"
export CPP="x86_64-poky-linux-gcc -v -E  -m64 -march=corei7 -mtune=corei7 -mfpmath=sse -msse4.2 --sysroot=$SDKTARGETSYSROOT"
export AS="x86_64-poky-linux-as  "
export LD="x86_64-poky-linux-ld  --sysroot=$SDKTARGETSYSROOT"
export GDB=x86_64-poky-linux-gdb
export STRIP=x86_64-poky-linux-strip
export RANLIB=x86_64-poky-linux-ranlib
export OBJCOPY=x86_64-poky-linux-objcopy
export OBJDUMP=x86_64-poky-linux-objdump
export AR=x86_64-poky-linux-ar
export NM=x86_64-poky-linux-nm
export M4=m4
export TARGET_PREFIX=x86_64-poky-linux-
export CONFIGURE_FLAGS="--target=x86_64-poky-linux --host=x86_64-poky-linux --build=x86_64-linux --with-libtool-sysroot=$SDKTARGETSYSROOT"
export CFLAGS=" --sysroot=$SDKTARGETSYSROOT -O2 -pipe -g -feliminate-unused-debug-types"
export CXXFLAGS=" --sysroot=$SDKTARGETSYSROOT -O2 -pipe -g -feliminate-unused-debug-types"
export LDFLAGS=" -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed"
export CPPFLAGS=""
export KCFLAGS="--sysroot=$SDKTARGETSYSROOT"
export OECORE_DISTRO_VERSION="2.4.1"
export OECORE_SDK_VERSION="2.4.1"
export ARCH=x86
export CROSS_COMPILE=x86_64-poky-linux-

# Append environment subscripts
if [ -d "$OECORE_TARGET_SYSROOT/environment-setup.d" ]; then
    for envfile in $OECORE_TARGET_SYSROOT/environment-setup.d/*.sh; do
     . $envfile
    done
fi
if [ -d "$OECORE_NATIVE_SYSROOT/environment-setup.d" ]; then
    for envfile in $OECORE_NATIVE_SYSROOT/environment-setup.d/*.sh; do
     . $envfile
    done
fi
export CLANGCC="x86_64-poky-linux-clang -m64 -march=corei7 -mtune=corei7 -mfpmath=sse -msse4.2 -mlittle-endian --sysroot=$SDKTARGETSYSROOT"
export CLANGCXX="x86_64-poky-linux-clang++ -m64 -march=corei7 -mtune=corei7 -mfpmath=sse -msse4.2 -mlittle-endian --sysroot=$SDKTARGETSYSROOT"
export CLANGCPP="x86_64-poky-linux-clang -E -m64 -march=corei7 -mtune=corei7 -mfpmath=sse -msse4.2 -mlittle-endian --sysroot=$SDKTARGETSYSROOT"


 and


Re: Compiling and packaging libraries

Mike Looijmans
 

The simplest solution is to use autotools or Cmake for your project. That will automatically "do the right thing" to get the library properly installed and registered.

Even if your project is just one C file and a header, putting that in autotools or cmake is less work than getting all the nitty bits in a hand-crafted Makefile right.



Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijmans@topicproducts.com
W: www.topicproducts.com

Please consider the environment before printing this e-mail

On 06-09-2020 10:53, majid.nasiry65 via lists.yoctoproject.org wrote:
Hi
I wrote a recipe for adding a library to my image it compile correctly but I have issues in installing it and I got "-dev package contains non-symlink .so" error.
I know default method for install libraries is versioned mode and I need to make symbolic links, but I don't know how?
Another question is what is difference between -dev and -dbg output?


Re: poky dhcpcd failed build

Yocto
 

On 9/10/20 6:58 AM, Khem Raj wrote:
#include <sys/param.h>
i ran devtool modify dhcpcd and there is no "socket.c" in the source tree.


Re: #sdk #yocto Appears SDK searching host for files that are only present on target side #sdk #yocto

Khem Raj
 

On 9/9/20 8:57 AM, Monsees, Steven C (US) via lists.yoctoproject.org wrote:
 

Looking to understand why the SDK is searching the host/native
(x86_64-pokysdk-linux) side when it should be looking at the target side
(corei7-64-poky-linux) …

 

All the “crt” files are present under the target side.

 

Can someone explain what might be miss-configured ?, or better, point me
to a possible patch ?

 

I have seen some talk on-line about similar issues, but no clear
indication what the issue was, or how it was resolved…

 

I am running Yocto clang 6.0.1, cmake 3.8.2, under “rocko”, my SDK is a
standard SDK, not extensible.

 

11:31 smonsees@yix490016 ~/yocto/test/beignet-Release_v1.2/mybuild>make

Scanning dependencies of target gbeinterp

[  0%] Building CXX object
backend/src/CMakeFiles/gbeinterp.dir/gbe_bin_interpreter.cpp.o

[  0%] Linking CXX shared library libgbeinterp.so

/disk0/scratch/smonsees/yocto/testSDK/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/7.3.0/real-ld:
cannot find crti.o: No such file or directory

/disk0/scratch/smonsees/yocto/testSDK/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/7.3.0/real-ld:
cannot find crtbeginS.o: No such file or directory

/disk0/scratch/smonsees/yocto/testSDK/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/7.3.0/real-ld:
cannot find -lstdc++

/disk0/scratch/smonsees/yocto/testSDK/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/7.3.0/real-ld:
cannot find -lm

/disk0/scratch/smonsees/yocto/testSDK/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/7.3.0/real-ld:
cannot find -lgcc_s

/disk0/scratch/smonsees/yocto/testSDK/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/7.3.0/real-ld:
cannot find -lc

/disk0/scratch/smonsees/yocto/testSDK/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/7.3.0/real-ld:
cannot find -lgcc_s

/disk0/scratch/smonsees/yocto/testSDK/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/7.3.0/real-ld:
cannot find crtendS.o: No such file or directory

/disk0/scratch/smonsees/yocto/testSDK/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/7.3.0/real-ld:
cannot find crtn.o: No such file or directory

collect2: error: ld returned 1 exit status

make[2]: *** [backend/src/libgbeinterp.so] Error 1

make[1]: *** [backend/src/CMakeFiles/gbeinterp.dir/all] Error 2

make: *** [all] Error 2

11:31 smonsees@yix490016 ~/yocto/test/beignet-Release_v1.2/mybuild>

Perhaps you need to use ${CC} and ${CXX} etc. in your makefile, and also
source the SDK environment script in shell, before using it.
 

Thanks,

Steve

 

 




Re: apt segmentation fault #apt #yocto #rocko

Khem Raj
 

On 9/8/20 10:57 PM, Sourab B wrote:
Hello all, i was trying to install Google coral PCIe driver from this
site:  https://coral.ai/docs/m2/get-started
<https://coral.ai/docs/m2/get-started> on my device. But i got
segmentation fault. I've done strace as well and I have attached
the log. I'm not quite sure what the issue is. 
*
Commands :

*
echo "deb https://packages.cloud.google.com/apt
<https://packages.cloud.google.com/apt> coral-edgetpu-stable main" | tee
/etc/apt/sources.list.d/coral-edgetpu.list

curl https://packages.cloud.google.com/apt/doc/apt-key.gpg
<https://packages.cloud.google.com/apt/doc/apt-key.gpg> | apt-key add -

*ERROR:*
curl https://packages.cloud.google.com/apt/doc/apt-key.gpg
<https://packages.cloud.google.com/apt/doc/apt-key.gpg> | apt-key add -
  % Total    % Received % Xferd  Average Speed   Time    Time     Time
 Current
                                 Dload  Upload   Total   Spent    Left
 Speed
100   653  100   653    0     0   2176      0 --:--:-- --:--:-- --:--:--
 2176

gpg: signal [  174.686462] audit: type=1701 audit(1598596554.214:5):
auid=4294967295 uid=0 gid=0 ses=4294967295 pid=876 comm="gpg" exe="/usr/bi1
Segmentation fault caught ... exiting
Segmentation fault (core dumped)
Discern between source distributions and binary distributions. Yocto
project provides tools to build either of those, but it does not support
interoperability with other binary distros e.g. debian/ubuntu/fedora
etc. so while your yocto based distro might be using apt for online
package management, it does not mean it supports feeds from
debian/ubuntu or other dpkg based distros. You have to have yocto based
binary distro feeds.




Re: do_rootfs: Could not invoke dnf

Khem Raj
 

On 9/8/20 3:31 AM, majid.nasiry65@gmail.com wrote:
Hello
I trying to create an image but when I add a library (opendnp3
<https://github.com/dnp3/opendnp3>) to image I got below error.

DEBUG: Executing python function extend_recipe_sysroot
NOTE: Direct dependencies are
['virtual:native:/home/majid/myir-imx-manifest/sources/poky/meta/recipes-core/update-rc.d/update-rc.d_0.8.bb:do_populate_sysroot',
'/home/majid/myir-imx-manifest/sources/poky/meta/recipes-devtools/qemu/qemuwrapper-cross_1.0.bb:do_populate_sysroot',
'/home/majid/myir-imx-manifest/sources/poky/meta/recipes-core/glibc/ldconfig-native_2.12.1.bb:do_populate_sysroot',
'virtual:native:/home/majid/myir-imx-manifest/sources/poky/meta/recipes-extended/pbzip2/pbzip2_1.1.13.bb:do_populate_sysroot',
'virtual:native:/home/majid/myir-imx-manifest/sources/poky/meta/recipes-devtools/dnf/dnf_4.2.2.bb:do_populate_sysroot',
'/home/majid/myir-imx-manifest/sources/meta-myir/meta-bsp/recipes-security/optee-imx/optee-os_3.7.0.imx.bb:do_populate_sysroot',
'/home/majid/myir-imx-manifest/sources/meta-myir/meta-bsp/recipes-bsp/u-boot/u-boot-imx_2019.04.bb:do_populate_sysroot',
'/home/majid/myir-imx-manifest/sources/poky/meta/recipes-core/glibc/cross-localedef-native_2.30.bb:do_populate_sysroot',
'virtual:native:/home/majid/myir-imx-manifest/sources/poky/meta/recipes-devtools/opkg/opkg_0.4.1.bb:do_populate_sysroot',
'virtual:native:/home/majid/myir-imx-manifest/sources/poky/meta/recipes-devtools/createrepo-c/createrepo-c_0.15.0.bb:do_populate_sysroot',
'virtual:native:/home/majid/myir-imx-manifest/sources/poky/meta/recipes-support/bmap-tools/bmap-tools_3.5.bb:do_populate_sysroot',
'virtual:native:/home/majid/myir-imx-manifest/sources/poky/meta/recipes-extended/pigz/pigz_2.4.bb:do_populate_sysroot',
'virtual:native:/home/majid/myir-imx-manifest/sources/poky/meta/recipes-devtools/prelink/prelink_git.bb:do_populate_sysroot',
'virtual:native:/home/majid/myir-imx-manifest/sources/poky/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.45.3.bb:do_populate_sysroot',
'/home/majid/myir-imx-manifest/sources/poky/meta/recipes-kernel/kmod/depmodwrapper-cross_1.0.bb:do_populate_sysroot',
'virtual:native:/home/majid/myir-imx-manifest/sources/poky/meta/recipes-devtools/pseudo/pseudo_git.bb:do_populate_sysroot',
'virtual:native:/home/majid/myir-imx-manifest/sources/poky/meta/recipes-devtools/opkg-utils/opkg-utils_0.4.1.bb:do_populate_sysroot',
'virtual:native:/home/majid/myir-imx-manifest/sources/poky/meta/recipes-devtools/makedevs/makedevs_1.0.1.bb:do_populate_sysroot',
'/home/majid/myir-imx-manifest/sources/poky/meta/recipes-devtools/mklibs/mklibs-native_0.1.44.bb:do_populate_sysroot',
'virtual:native:/home/majid/myir-imx-manifest/sources/poky/meta/recipes-devtools/rpm/rpm_4.14.2.1.bb:do_populate_sysroot']
NOTE: Installed into sysroot: []
NOTE: Skipping as already exists in sysroot: ['update-rc.d-native',
'qemuwrapper-cross', 'ldconfig-native', 'pbzip2-native', 'dnf-native',
'optee-os', 'u-boot-imx', 'cross-localedef-native', 'opkg-native',
'createrepo-c-native', 'bmap-tools-native', 'pigz-native',
'prelink-native', 'e2fsprogs-native', 'depmodwrapper-cross',
'pseudo-native', 'opkg-utils-native', 'makedevs-native',
'mklibs-native', 'rpm-native', 'systemd-systemctl-native',
'shadow-native', 'quilt-native', 'qemu-native', 'kmod-native',
'bzip2-native', 'python3-native', 'ninja-native',
'gettext-minimal-native', 'librepo-native', 'libcomps-native',
'cmake-native', 'libdnf-native', 'python3-iniparse-native',
'gcc-runtime', 'glibc', 'libtool-native', 'autoconf-native',
'gnu-config-native', 'automake-native', 'libsolv-native',
'pkgconfig-native', 'libarchive-native', 'curl-native', 'expat-native',
'file-native', 'sqlite3-native', 'zlib-native', 'xz-native',
'glib-2.0-native', 'libxml2-native', 'libmodulemd-native',
'openssl-native', 'python3-setuptools-native', 'python3-six-native',
'binutils-native', 'elfutils-native', 'texinfo-dummy-native',
'util-linux-native', 'attr-native', 'perl-native', 'dbus-native',
'nss-native', 'popt-native', 'db-native', 'debianutils-native',
'gtk-doc-native', 'gdbm-native', 'libtirpc-native', 'libffi-native',
'libnsl2-native', 'readline-native', 're2c-native', 'gpgme-native',
'libcheck-native', 'ncurses-native', 'gobject-introspection-native',
'swig-native', 'json-c-native', 'libgcc', 'linux-libc-headers',
'm4-native', 'lzo-native', 'libpcre-native', 'gettext-native',
'meson-native', 'libyaml-native', 'unzip-native', 'flex-native',
'libcap-ng-native', 'nspr-native', 'libgpg-error-native',
'libassuan-native']
DEBUG: Python function extend_recipe_sysroot finished
DEBUG: Executing python function do_rootfs
NOTE: Initializing intercept dir for
/home/majid/myir-imx-manifest/build/tmp/work/myd_y6ull14x14-poky-linux-gnueabi/myir-image-core/1.0-r0/rootfs
DEBUG: Collected intercepts:
 
/home/majid/myir-imx-manifest/sources/poky/scripts/postinst-intercepts/delay_to_first_boot
 
/home/majid/myir-imx-manifest/sources/poky/scripts/postinst-intercepts/postinst_intercept
 
/home/majid/myir-imx-manifest/sources/poky/scripts/postinst-intercepts/update_font_cache
 
/home/majid/myir-imx-manifest/sources/poky/scripts/postinst-intercepts/update_gio_module_cache
 
/home/majid/myir-imx-manifest/sources/poky/scripts/postinst-intercepts/update_gtk_icon_cache
 
/home/majid/myir-imx-manifest/sources/poky/scripts/postinst-intercepts/update_gtk_immodules_cache
 
/home/majid/myir-imx-manifest/sources/poky/scripts/postinst-intercepts/update_pixbuf_cache
 
/home/majid/myir-imx-manifest/sources/poky/scripts/postinst-intercepts/update_udev_hwdb
 
NOTE: ###### Generate rootfs #######
NOTE: Executing
'/home/majid/myir-imx-manifest/build/tmp/work/myd_y6ull14x14-poky-linux-gnueabi/myir-image-core/1.0-r0/recipe-sysroot-native/usr/bin/createrepo_c
--update -q
/home/majid/myir-imx-manifest/build/tmp/work/myd_y6ull14x14-poky-linux-gnueabi/myir-image-core/1.0-r0/oe-rootfs-repo'
...
NOTE: Running
/home/majid/myir-imx-manifest/build/tmp/work/myd_y6ull14x14-poky-linux-gnueabi/myir-image-core/1.0-r0/recipe-sysroot-native/usr/bin/dnf
-v --rpmverbosity=info -y -c
/home/majid/myir-imx-manifest/build/tmp/work/myd_y6ull14x14-poky-linux-gnueabi/myir-image-core/1.0-r0/rootfs/etc/dnf/dnf.conf
--setopt=reposdir=/home/majid/myir-imx-manifest/build/tmp/work/myd_y6ull14x14-poky-linux-gnueabi/myir-image-core/1.0-r0/rootfs/etc/yum.repos.d
--installroot=/home/majid/myir-imx-manifest/build/tmp/work/myd_y6ull14x14-poky-linux-gnueabi/myir-image-core/1.0-r0/rootfs
--setopt=logdir=/home/majid/myir-imx-manifest/build/tmp/work/myd_y6ull14x14-poky-linux-gnueabi/myir-image-core/1.0-r0/temp
--repofrompath=oe-repo,/home/majid/myir-imx-manifest/build/tmp/work/myd_y6ull14x14-poky-linux-gnueabi/myir-image-core/1.0-r0/oe-rootfs-repo
makecache --refresh
DEBUG: DNF version: 4.2.2
cachedir:
/home/majid/myir-imx-manifest/build/tmp/work/myd_y6ull14x14-poky-linux-gnueabi/myir-image-core/1.0-r0/rootfs/var/cache/dnf
Added oe-repo repo from
/home/majid/myir-imx-manifest/build/tmp/work/myd_y6ull14x14-poky-linux-gnueabi/myir-image-core/1.0-r0/oe-rootfs-repo
Making cache files for all metadata files.
oe-repo: has expired and will be refreshed.
repo: downloading from remote: oe-repo
oe-repo                                         127 MB/s | 1.3 MB   
 00:00    
not found other for: 
not found modules for: 
not found deltainfo for: 
not found updateinfo for: 
oe-repo: using metadata from Tue 08 Sep 2020 09:48:47 AM UTC.
Last metadata expiration check: 0:00:01 ago on Tue 08 Sep 2020 09:48:47
AM UTC.
No module defaults found
Metadata cache created.
 
NOTE: Running
/home/majid/myir-imx-manifest/build/tmp/work/myd_y6ull14x14-poky-linux-gnueabi/myir-image-core/1.0-r0/recipe-sysroot-native/usr/bin/dnf
-v --rpmverbosity=info -y -c
/home/majid/myir-imx-manifest/build/tmp/work/myd_y6ull14x14-poky-linux-gnueabi/myir-image-core/1.0-r0/rootfs/etc/dnf/dnf.conf
--setopt=reposdir=/home/majid/myir-imx-manifest/build/tmp/work/myd_y6ull14x14-poky-linux-gnueabi/myir-image-core/1.0-r0/rootfs/etc/yum.repos.d
--installroot=/home/majid/myir-imx-manifest/build/tmp/work/myd_y6ull14x14-poky-linux-gnueabi/myir-image-core/1.0-r0/rootfs
--setopt=logdir=/home/majid/myir-imx-manifest/build/tmp/work/myd_y6ull14x14-poky-linux-gnueabi/myir-image-core/1.0-r0/temp
--repofrompath=oe-repo,/home/majid/myir-imx-manifest/build/tmp/work/myd_y6ull14x14-poky-linux-gnueabi/myir-image-core/1.0-r0/oe-rootfs-repo
--nogpgcheck install locale-base-en-us locale-base-en-gb psplash
start-service myir-rc-local staticip-network packagegroup-core-boot
packagegroup-base-extended ppp-quectel u-boot-imx-fw-utils opendnp3
packagegroup-core-nfs-server alsa-utils packagegroup-core-ssh-dropbear
packagegroup-fsl-optee-imx run-postinsts
ERROR: Could not invoke dnf. Command
'/home/majid/myir-imx-manifest/build/tmp/work/myd_y6ull14x14-poky-linux-gnueabi/myir-image-core/1.0-r0/recipe-sysroot-native/usr/bin/dnf
-v --rpmverbosity=info -y -c
/home/majid/myir-imx-manifest/build/tmp/work/myd_y6ull14x14-poky-linux-gnueabi/myir-image-core/1.0-r0/rootfs/etc/dnf/dnf.conf
--setopt=reposdir=/home/majid/myir-imx-manifest/build/tmp/work/myd_y6ull14x14-poky-linux-gnueabi/myir-image-core/1.0-r0/rootfs/etc/yum.repos.d
--installroot=/home/majid/myir-imx-manifest/build/tmp/work/myd_y6ull14x14-poky-linux-gnueabi/myir-image-core/1.0-r0/rootfs
--setopt=logdir=/home/majid/myir-imx-manifest/build/tmp/work/myd_y6ull14x14-poky-linux-gnueabi/myir-image-core/1.0-r0/temp
--repofrompath=oe-repo,/home/majid/myir-imx-manifest/build/tmp/work/myd_y6ull14x14-poky-linux-gnueabi/myir-image-core/1.0-r0/oe-rootfs-repo
--nogpgcheck install locale-base-en-us locale-base-en-gb psplash
start-service myir-rc-local staticip-network packagegroup-core-boot
packagegroup-base-extended ppp-quectel u-boot-imx-fw-utils opendnp3
packagegroup-core-nfs-server alsa-utils packagegroup-core-ssh-dropbear
packagegroup-fsl-optee-imx run-postinsts' returned 1:
DNF version: 4.2.2
cachedir:
/home/majid/myir-imx-manifest/build/tmp/work/myd_y6ull14x14-poky-linux-gnueabi/myir-image-core/1.0-r0/rootfs/var/cache/dnf
Added oe-repo repo from
/home/majid/myir-imx-manifest/build/tmp/work/myd_y6ull14x14-poky-linux-gnueabi/myir-image-core/1.0-r0/oe-rootfs-repo
repo: using cache for: oe-repo
not found other for: 
not found modules for: 
not found deltainfo for: 
not found updateinfo for: 
oe-repo: using metadata from Tue 08 Sep 2020 09:48:47 AM UTC.
Last metadata expiration check: 0:00:01 ago on Tue 08 Sep 2020 09:48:47
AM UTC.
No module defaults found
No match for argument: opendnp3
Error: Unable to find a match
 
DEBUG: Python function do_rootfs finished

What is the problem?
Image builder uses debian naming for shared libs, and libraries are
usually pulled in via shlibs resolver as a dependency so it would be
good for you to ensure that this library has a use in image which means
some application depends on it during runtime.


Regards



Re: poky dhcpcd failed build

Khem Raj
 

On 9/7/20 11:27 PM, Yocto wrote:

On 9/8/20 1:24 PM, Yocto wrote:
w
| collect2: error: ld returned 1 exit status
| make[1]: *** [Makefile:73: dhcpcd] Error 1
| make[1]: Leaving directory
'/var/home/dingo/overc/build/tmp/work/corei7-64-overc-linux/dhcpcd/9.1.4-r0/dhcpcd-9.1.4/src'
| make: *** [Makefile:24: all] Error 2
| WARNING:
/var/home/dingo/overc/build/tmp/work/corei7-64-overc-linux/dhcpcd/9.1.4-r0/temp/run.do_compile.3649983:190
exit 1 from 'exit 1'
| WARNING: Backtrace (BB generated script):
|     #1: bbfatal_log,
/var/home/dingo/overc/build/tmp/work/corei7-64-overc-linux/dhcpcd/9.1.4-r0/temp/run.do_compile.3649983,
line 190
|     #2: die,
/var/home/dingo/overc/build/tmp/work/corei7-64-overc-linux/dhcpcd/9.1.4-r0/temp/run.do_compile.3649983,
line 165
|     #3: oe_runmake,
/var/home/dingo/overc/build/tmp/work/corei7-64-overc-linux/dhcpcd/9.1.4-r0/temp/run.do_compile.3649983,
line 160
|     #4: autotools_do_compile,
/var/home/dingo/overc/build/tmp/work/corei7-64-overc-linux/dhcpcd/9.1.4-r0/temp/run.do_compile.3649983,
line 155
|     #5: do_compile,
/var/home/dingo/overc/build/tmp/work/corei7-64-overc-linux/dhcpcd/9.1.4-r0/temp/run.do_compile.3649983,
line 150
|     #6: main,
/var/home/dingo/overc/build/tmp/work/corei7-64-overc-linux/dhcpcd/9.1.4-r0/temp/run.do_compile.3649983,
line 194
|
| Backtrace (metadata-relative locations):
|     #1: bbfatal_log,
/var/home/dingo/overc/poky/meta/classes/logging.bbclass, line 72
|     #2: die, /var/home/dingo/overc/poky/meta/classes/base.bbclass,
line 56
|     #3: oe_runmake,
/var/home/dingo/overc/poky/meta/classes/base.bbclass, line 65
|     #4: autotools_do_compile,
/var/home/dingo/overc/poky/meta/classes/autotools.bbclass, line 243
|     #5: do_compile, autogenerated, line 2
ERROR: Task
(/var/home/dingo/overc/poky/meta/recipes-connectivity/dhcpcd/dhcpcd_9.1.4.bb:do_compile)
failed with exit code '1'
gcc/x86_64-overc-linux/10.2.0/ld: privsep-root.o: in function
`ps_root_dogetifaddrs':
| /usr/src/debug/dhcpcd/9.1.4-r0/dhcpcd-9.1.4/src/privsep-root.c:374:
undefined reference to `ALIGN'
|
/var/home/dingo/overc/build/tmp/work/corei7-64-overc-linux/dhcpcd/9.1.4-r0/recipe-sysroot-native/usr/bin/x86_64-overc-linux/../../libexec/x86_64-overc-linux/gcc/x86_64-overc-linux/10.2.0/ld:
/usr/src/debug/dhcpcd/9.1.4-r0/dhcpcd-9.1.4/src/privsep-root.c:375:
undefined reference to `ALIGN'
|
/var/home/dingo/overc/build/tmp/work/corei7-64-overc-linux/dhcpcd/9.1.4-r0/recipe-sysroot-native/usr/bin/x86_64-overc-linux/../../libexec/x86_64-overc-linux/gcc/x86_64-overc-linux/10.2.0/ld:
/usr/src/debug/dhcpcd/9.1.4-r0/dhcpcd-9.1.4/src/privsep-root.c:376:
undefined reference to `ALIGN'
|
/var/home/dingo/overc/build/tmp/work/corei7-64-overc-linux/dhcpcd/9.1.4-r0/recipe-sysroot-native/usr/bin/x86_64-overc-linux/../../libexec/x86_64-overc-linux/gcc/x86_64-overc-linux/10.2.0/ld:
/usr/src/debug/dhcpcd/9.1.4-r0/dhcpcd-9.1.4/src/privsep-root.c:378:
undefined reference to `ALIGN'
|
/var/home/dingo/overc/build/tmp/work/corei7-64-overc-linux/dhcpcd/9.1.4-r0/recipe-sysroot-native/usr/bin/x86_64-overc-linux/../../libexec/x86_64-overc-linux/gcc/x86_64-overc-linux/10.2.0/ld:
/usr/src/debug/dhcpcd/9.1.4-r0/dhcpcd-9.1.4/src/privsep-root.c:380:
undefined reference to `ALIGN'
|
/var/home/dingo/overc/build/tmp/work/corei7-64-overc-linux/dhcpcd/9.1.4-r0/recipe-sysroot-native/usr/bin/x86_64-overc-linux/../../libexec/x86_64-overc-linux/gcc/x86_64-overc-linux/10.2.0/ld:
privsep-root.o:/usr/src/debug/dhcpcd/9.1.4-r0/dhcpcd-9.1.4/src/privsep-root.c:382:
more undefined references to `ALIGN' follow
| collect2: error: ld returned 1 exit status
Can you try adding
#include <sys/param.h> into socket.c and see if that help ? if it does
then please send it as a patch






Re: Compiling and packaging libraries

Khem Raj
 

On 9/6/20 1:53 AM, majid.nasiry65@gmail.com wrote:
Hi
I wrote a recipe for adding a library to my image it compile correctly but I have issues in installing it and I got "-dev package contains non-symlink .so" error.
I know default method for install libraries is versioned mode and I need to make symbolic links, but I don't know how?
in library's build system you want to use symbol versioning during linker stage. Then you can create using ln cmd to creating symlink to lib.so and lib.so.<major_version> see [1]

Another question is what is difference between -dev and -dbg output?
dev packages contain, development headers and libraries which are useful for building packages on target

dbg packages contain debug info, which is useful if you are debugging on target.


[1] http://www.microhowto.info/howto/build_a_shared_library_using_gcc.html


Re: Outreachy internship project - license tracing enhancement

Nicolas Dechesne
 

Hey Paul,

First of all, thank you so much for doing this. It's very much appreciated, I am very happy to see our community members willing to contribute to such a great internship program. As I mentioned to you separately, I will do my best to support and help you!

On Wed, Sep 9, 2020 at 6:55 PM Paul Eggleton <Paul.Eggleton@...> wrote:
Hi Armin

I think Nicolas will need to do the re-registration as he's the named Outreachy coordinator for YP.

I don't need to re-register, I need to confirm that the YP community (which is already registered) will participate in this round, and I need to indicate how the funding is done. I will reach out privately to discuss the funding side of things (there are a couple of questions/information to provide on their form).

That said, if anyone else is willing to sponsor another internship, please let me know here or privately!


Thanks
Paul

-----Original Message-----
From: akuster808 <akuster808@...>
Sent: Thursday, 10 September 2020 2:29 am
To: Paul Eggleton <Paul.Eggleton@...>; yocto@...
Cc: Nicolas Dechesne <nicolas.dechesne@...>; Richard Purdie (richard.purdie@...) <richard.purdie@...>
Subject: Re: [yocto] Outreachy internship project - license tracing enhancement



On 9/9/20 3:51 AM, Paul Eggleton via lists.yoctoproject.org wrote:
> Hi folks
>
> I'd like to propose we put forward the following project proposal for an Outreachy internship (https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.outreachy.org%2Fcommunities%2Fcfp%2F&amp;data=02%7C01%7Cpaul.eggleton%40microsoft.com%7C3a6b0143434b454bbab708d854cca58f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637352585960663229&amp;sdata=2L0gT8udq5P5bxEcPIsrjVxHXADmt9kEDMZxwk1ul5o%3D&amp;reserved=0). I'm prepared to be the mentor for the project and Microsoft will provide funding. (Note that we haven't got our community re-registered with Outreachy or set this up as an intern project proposal yet - deadline for YP community registration is September 17th and for project submissions is September 24th). Here's the brief:

This sounds great.

Are you looking for YP to take action on  registration or are you handling this?

-armin
>
> -------------
> Yocto Project License tracing enhancement
>  
> The Yocto Project build system is typically used to build customised Linux images from source for embedded applications. Along with the image, a manifest of packages and their corresponding licenses is prepared, however the accuracy of the license information is dependent on the accuracy of the metadata we have for each package (i.e. what is in the recipe file). As part of the build, we have an internal mapping from output files to source files which is currently used to prepare source packages to aid in debugging, however with the presence of SPDX headers in source files it could also be used to allow tracing the license of sources used in building a package/image to help improve our metadata and future license manifests. A proof-of concept implementation of this has been put together [1] - during this internship a successful intern will:
> 1) take the proof-of-concept implementation and get it to a state
> where it can be merged into the poky repository
> 2) use the functionality to examine the accuracy of our license
> tagging (LICENSE fields in recipes); look for errors / noise in the
> comparison, and produce a simple report with the results
> 3) run a check over sources in a world build looking for percentage
> coverage of SPDX headers, and run it for several past releases to see
> the change over time
>  
> Bonus: assess the current state of meta-spdx-scanner; investigate what it would take to produce SPDX documents from build output (would likely require integration with Fossology).
>
> [1]
> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgit.y
> octoproject.org%2Fcgit%2Fcgit.cgi%2Fpoky-contrib%2Flog%2F%3Fh%3Drpurdi
> e%2Flicense-experiments-osls&amp;data=02%7C01%7Cpaul.eggleton%40micros
> oft.com%7C3a6b0143434b454bbab708d854cca58f%7C72f988bf86f141af91ab2d7cd
> 011db47%7C1%7C0%7C637352585960673189&amp;sdata=ZoCsEf0BYvCs5GalpYUgbv%
> 2Ff5qt1Lagho3NBML5qgUg%3D&amp;reserved=0
> -------------
>
> I'm making the assumption that we're OK with merging the PoC functionality in rather than just keeping it separate and using it for analysis - let me know if otherwise. What I'd really like to know is do people think that this is sufficient for a 3-month internship, assuming that the intern has limited to moderate familiarity with our codebase? Do we need to flesh it out further? Any modifications that you'd suggest to the work?
>
> Thanks
> Paul
>
>


#sdk #yocto Appears SDK searching host for files that are only present on target side #sdk #yocto

Monsees, Steven C (US)
 

 

Looking to understand why the SDK is searching the host/native (x86_64-pokysdk-linux) side when it should be looking at the target side (corei7-64-poky-linux) …

 

All the “crt” files are present under the target side.

 

Can someone explain what might be miss-configured ?, or better, point me to a possible patch ?

 

I have seen some talk on-line about similar issues, but no clear indication what the issue was, or how it was resolved…

 

I am running Yocto clang 6.0.1, cmake 3.8.2, under “rocko”, my SDK is a standard SDK, not extensible.

 

11:31 smonsees@yix490016 ~/yocto/test/beignet-Release_v1.2/mybuild>make

Scanning dependencies of target gbeinterp

[  0%] Building CXX object backend/src/CMakeFiles/gbeinterp.dir/gbe_bin_interpreter.cpp.o

[  0%] Linking CXX shared library libgbeinterp.so

/disk0/scratch/smonsees/yocto/testSDK/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/7.3.0/real-ld: cannot find crti.o: No such file or directory

/disk0/scratch/smonsees/yocto/testSDK/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/7.3.0/real-ld: cannot find crtbeginS.o: No such file or directory

/disk0/scratch/smonsees/yocto/testSDK/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/7.3.0/real-ld: cannot find -lstdc++

/disk0/scratch/smonsees/yocto/testSDK/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/7.3.0/real-ld: cannot find -lm

/disk0/scratch/smonsees/yocto/testSDK/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/7.3.0/real-ld: cannot find -lgcc_s

/disk0/scratch/smonsees/yocto/testSDK/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/7.3.0/real-ld: cannot find -lc

/disk0/scratch/smonsees/yocto/testSDK/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/7.3.0/real-ld: cannot find -lgcc_s

/disk0/scratch/smonsees/yocto/testSDK/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/7.3.0/real-ld: cannot find crtendS.o: No such file or directory

/disk0/scratch/smonsees/yocto/testSDK/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/7.3.0/real-ld: cannot find crtn.o: No such file or directory

collect2: error: ld returned 1 exit status

make[2]: *** [backend/src/libgbeinterp.so] Error 1

make[1]: *** [backend/src/CMakeFiles/gbeinterp.dir/all] Error 2

make: *** [all] Error 2

11:31 smonsees@yix490016 ~/yocto/test/beignet-Release_v1.2/mybuild>

 

Thanks,

Steve

 

 


Re: Outreachy internship project - license tracing enhancement

akuster
 

On 9/9/20 3:51 AM, Paul Eggleton via lists.yoctoproject.org wrote:
Hi folks

I'd like to propose we put forward the following project proposal for an Outreachy internship (https://www.outreachy.org/communities/cfp/). I'm prepared to be the mentor for the project and Microsoft will provide funding. (Note that we haven't got our community re-registered with Outreachy or set this up as an intern project proposal yet - deadline for YP community registration is September 17th and for project submissions is September 24th). Here's the brief:
This sounds great.

Are you looking for YP to take action on  registration or are you
handling this?

-armin

-------------
Yocto Project License tracing enhancement
 
The Yocto Project build system is typically used to build customised Linux images from source for embedded applications. Along with the image, a manifest of packages and their corresponding licenses is prepared, however the accuracy of the license information is dependent on the accuracy of the metadata we have for each package (i.e. what is in the recipe file). As part of the build, we have an internal mapping from output files to source files which is currently used to prepare source packages to aid in debugging, however with the presence of SPDX headers in source files it could also be used to allow tracing the license of sources used in building a package/image to help improve our metadata and future license manifests. A proof-of concept implementation of this has been put together [1] - during this internship a successful intern will:
1) take the proof-of-concept implementation and get it to a state where it can be merged into the poky repository
2) use the functionality to examine the accuracy of our license tagging (LICENSE fields in recipes); look for errors / noise in the comparison, and produce a simple report with the results
3) run a check over sources in a world build looking for percentage coverage of SPDX headers, and run it for several past releases to see the change over time
 
Bonus: assess the current state of meta-spdx-scanner; investigate what it would take to produce SPDX documents from build output (would likely require integration with Fossology).

[1] http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=rpurdie/license-experiments-osls
-------------

I'm making the assumption that we're OK with merging the PoC functionality in rather than just keeping it separate and using it for analysis - let me know if otherwise. What I'd really like to know is do people think that this is sufficient for a 3-month internship, assuming that the intern has limited to moderate familiarity with our codebase? Do we need to flesh it out further? Any modifications that you'd suggest to the work?

Thanks
Paul


Outreachy internship project - license tracing enhancement

Paul Eggleton <paul.eggleton@...>
 

Hi folks

I'd like to propose we put forward the following project proposal for an Outreachy internship (https://www.outreachy.org/communities/cfp/). I'm prepared to be the mentor for the project and Microsoft will provide funding. (Note that we haven't got our community re-registered with Outreachy or set this up as an intern project proposal yet - deadline for YP community registration is September 17th and for project submissions is September 24th). Here's the brief:

-------------
Yocto Project License tracing enhancement
 
The Yocto Project build system is typically used to build customised Linux images from source for embedded applications. Along with the image, a manifest of packages and their corresponding licenses is prepared, however the accuracy of the license information is dependent on the accuracy of the metadata we have for each package (i.e. what is in the recipe file). As part of the build, we have an internal mapping from output files to source files which is currently used to prepare source packages to aid in debugging, however with the presence of SPDX headers in source files it could also be used to allow tracing the license of sources used in building a package/image to help improve our metadata and future license manifests. A proof-of concept implementation of this has been put together [1] - during this internship a successful intern will:
1) take the proof-of-concept implementation and get it to a state where it can be merged into the poky repository
2) use the functionality to examine the accuracy of our license tagging (LICENSE fields in recipes); look for errors / noise in the comparison, and produce a simple report with the results
3) run a check over sources in a world build looking for percentage coverage of SPDX headers, and run it for several past releases to see the change over time
 
Bonus: assess the current state of meta-spdx-scanner; investigate what it would take to produce SPDX documents from build output (would likely require integration with Fossology).

[1] http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=rpurdie/license-experiments-osls
-------------

I'm making the assumption that we're OK with merging the PoC functionality in rather than just keeping it separate and using it for analysis - let me know if otherwise. What I'd really like to know is do people think that this is sufficient for a 3-month internship, assuming that the intern has limited to moderate familiarity with our codebase? Do we need to flesh it out further? Any modifications that you'd suggest to the work?

Thanks
Paul


apt segmentation fault #apt #yocto #rocko

Sourab B
 

Hello all, i was trying to install Google coral PCIe driver from this site:  https://coral.ai/docs/m2/get-started on my device. But i got segmentation fault. I've done strace as well and I have attached the log. I'm not quite sure what the issue is. 

Commands :

echo "deb https://packages.cloud.google.com/apt coral-edgetpu-stable main" | tee /etc/apt/sources.list.d/coral-edgetpu.list

curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -

ERROR:
curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   653  100   653    0     0   2176      0 --:--:-- --:--:-- --:--:--  2176

gpg: signal [  174.686462] audit: type=1701 audit(1598596554.214:5): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=876 comm="gpg" exe="/usr/bi1
Segmentation fault caught ... exiting
Segmentation fault (core dumped)


Yocto Zeus stable branch

akuster
 

Hello,

The Zeus branch was defined as a transitional branch with a 9 month
stable cycle since LTS was created. The 3.0.4 was the last Zeus dot
release. We have since added several Build stabilization changes and
last minute backports . We intend on doing on last formal build cycle
but no QA so no formal dot release. After this action is complete,  
this branch will most like transition to Community Support and we will
see where it goes from there.

regards,
Armin
( On behalf of the Yocto Project® TSC)

Yocto Project® are registered trademark of the Linux Foundation.


Warrior and Thud stable branches

akuster
 

Sorry. still have the old email address in my contacts.

re-sending.

-------- Forwarded Message --------
Subject: [yocto] Warrior and Thud stable branches
Date: Tue, 8 Sep 2020 21:39:28 -0700
From: akuster via lists.yoctoproject.org
<akuster808=gmail.com@lists.yoctoproject.org>
Reply-To: akuster808@gmail.com
To: openembedded-core@openembedded.org
<openembedded-core@openembedded.org>, yocto@yoctoproject.org
<yocto@yoctoproject.org>, OpenEmbedded Devel List
<openembedded-devel@lists.openembedded.org>,
bitbake-devel@lists.openembedded.org <bitbake-devel@lists.openembedded.org>



Hello,

A few words regarding the older stable releases, Thud and Warrior.

Thud no longer has an active Community Maintainer so this release with
be move to the  EOL state.  Warrior did have a volunteer but no activity
to date and this branch will also move to the EOL state. This will take
affect tomorrow (Wednesday PST).

regards,
Armin

2021 - 2040 of 52543