Hi,

I have two device tree source files, imx6ulz.dts and imx6ulz-kobs.dts,
I defined machine configure file with KERNEL_DEVICETREE = "imx6ulz.dtb
imx6ulz-kobs.dtb", I can see both imx6ulz.dtb imx6ulz-kobs.dtb in
build directory, but there is only one imx6ulz.dtb in the images
directory, missed imx6ulz-kobs.dtb, how can I package imx6ulz-kobs.dtb
to the images directory?

Thank you.

Kind regards,

- jh


--
"A man can fail many times, but he isn't a failure until he begins to
blame somebody else."
-- John Burroughs

Hi!

I had a similar issue in my backlog for ages... Finally hit it again
while updating some SDKs and found this thread from more than two
years ago. In my case, fetching during the SDK install script run was
triggered by at least one recipe which was setting SRCREV with
AUTOREV. Although using AUTOREV in generating SDKs is probably
debatable, I found your comments here a good starting point for
further investigation. Looking at the git history since then, it
reveals a recent commit [1] which is reworking (possibly with
different motivations) the way SDK install script is "cleaning" some
env variables at invocation.

I tested backporting this commit to an old pyro based project where I
was seeing SDK install failures with AUTOREV recipes and it solved the
original error.

I could find no issue in Bugzilla for this specific face of the
problem, even though the above commit descries itself as a rework of
the fix for [1]. I'm reporting to the list for the records, in case
someone else would happen to hit issues with using the ssh agent while
installing their SDKs.

Regards,

[1] https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=6d78b84029d0717354bf39e5c355fba1c14d8347
[2] https://bugzilla.yoctoproject.org/show_bug.cgi?id=8698

On Thu, Sep 6, 2018 at 12:18 PM Gabriele Favalessa
<gabriele@...> wrote:

An update (and a workaround.)

What's happening is that during the execution of the install script for the extended SDK, the env of the original shell is ignored. If your SDK refers to private git repos (on github for example) and you normally authenticate to github using ssh and ssh-agent, the SSH_AUTH_SOCK env variables needed won't be set by the time git is invoked. The workaround is configuring the authentication to github in .ssh/config and avoid the ssh-agent. (Yes, I checked and SSH_AUTH_SOCK is exported by the shell :)

But the underlying problem is that env of the shell is ignored during install, so potentially other useful variables could be ignored. Is that intentional? Is there a way to prevent it?

Gabriele

On Wed, Aug 29, 2018 at 3:55 PM Gabriele Favalessa <gabriele@...> wrote:

Hi,

I'm trying to install on ubuntu 17.04 an Extensible SDK that I have built, and it stops with an error:

-------------------------------------------------------
sdk@sdk:~$ ./acme-linux-glibc-x86_64-acme-image-datalogger-cortexa7hf-neon-toolchain-ext-2.5.1.sh -D
…
+ sh -c . buildtools/environment-setup* > /home/sdk/acme-linux_sdk/preparing_build_system.log && cd /home/sdk/acme-linux_sdk/layers/poky && set /home/sdk/acme-linux_sdk && . /home/sdk/acme-linux_sdk/layers/poky/oe-init-build-env /home/sdk/acme-linux_sdk >> /home/sdk/acme-linux_sdk/preparing_build_system.log && python /home/sdk/acme-linux_sdk/ext-sdk-prepare.py /home/sdk/acme-linux_sdk/preparing_build_system.log 'acme-image-datalogger meta-extsdk-toolchain:do_populate_sysroot'
WARNING: /home/sdk/acme-linux_sdk/layers/poky/meta-myboard/recipes-kernel/linux/linux-imx_4.9.11.bb: Exception during build_dependencies for AUTOREV
WARNING: /home/sdk/acme-linux_sdk/layers/poky/meta-myboard/recipes-kernel/linux/linux-imx_4.9.11.bb: Error during finalise of /home/sdk/acme-linux_sdk/layers/poky/meta-myboard/recipes-kernel/linux/linux-imx_4.9.11.bb
ERROR: ExpansionError during parsing /home/sdk/acme-linux_sdk/layers/poky/meta-myboard/recipes-kernel/linux/linux-imx_4.9.11.bb
Traceback (most recent call last):
bb.data_smart.ExpansionError: Failure expanding variable SRCPV, expression was ${@bb.fetch2.get_srcrev(d)} which triggered exception FetchError: Fetcher failure: Fetch command export PSEUDO_DISABLED=1; export GIT_SSL_CAINFO="/home/sdk/acme-linux_sdk/buildtools/sysroots/x86_64-acmesdk-linux/etc/ssl/certs/ca-certificates.crt"; export PATH="/home/sdk/acme-linux_sdk/layers/poky/scripts:/home/sdk/acme-linux_sdk/tmp/work/myboard-acme-linux-gnueabi/linux-imx/4.9.11-r0/recipe-sysroot-native/usr/bin/arm-acme-linux-gnueabi:/home/sdk/acme-linux_sdk/tmp/work/myboard-acme-linux-gnueabi/linux-imx/4.9.11-r0/recipe-sysroot/usr/bin/crossscripts:/home/sdk/acme-linux_sdk/tmp/work/myboard-acme-linux-gnueabi/linux-imx/4.9.11-r0/recipe-sysroot-native/usr/sbin:/home/sdk/acme-linux_sdk/tmp/work/myboard-acme-linux-gnueabi/linux-imx/4.9.11-r0/recipe-sysroot-native/usr/bin:/home/sdk/acme-linux_sdk/tmp/work/myboard-acme-linux-gnueabi/linux-imx/4.9.11-r0/recipe-sysroot-native/sbin:/home/sdk/acme-linux_sdk/tmp/work/myboard-acme-linux-gnueabi/linux-imx/4.9.11-r0/recipe-sysroot-native/bin:/home/sdk/acme-linux_sdk/layers/poky/bitbake/bin:/home/sdk/acme-linux_sdk/tmp/hosttools"; export HOME="/home/sdk"; git -c core.fsyncobjectfiles=0 ls-remote ssh://git@.../Acme/linux-imx.git failed with exit code 128, output:
Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.


ERROR: SDK preparation failed: error log written to /home/sdk/acme-linux_sdk/preparing_build_system.log
-------------------------------------------------------

I tested the failing git command `git -c ls-remote ssh://git@.../Acme/linux-imx.git` directly from the command line and it succeeds without errors. I do have the ssh key in ssh-agent, so that's not surprise.

It looks like during the SDK installation the ssh key is needed but for some reason the ssh-agent is not reachable (maybe the SSH_* env variables are not propagated by the script?)

Is it unavoidable for the SDK to fetch from git during the installation? If it is unavoidable, how can I make the script fetch from a private github repo, given that the ssh-agent seems to be ignored?

Just out of curiosity, I copy&pasted the failing command in the shell, and this time it ran without errors (again confirming that the ssh key is present.)

-------------------------------------------------------
sdk@sdk:~$ sh -c . buildtools/environment-setup* > /home/sdk/acme-linux_sdk/preparing_build_system.log && cd /home/sdk/
acme-linux_sdk/layers/poky && set /home/sdk/acme-linux_sdk && . /home/sdk/acme-linux_sdk/layers/poky/oe-init-build-env
/home/sdk/acme-linux_sdk >> /home/sdk/acme-linux_sdk/preparing_build_system.log && python /home/sdk/acme-linux_sdk/ext-
sdk-prepare.py /home/sdk/acme-linux_sdk/preparing_build_system.log 'acme-image-datalogger meta-extsdk-toolchain:do_popu
late_sysroot'
Loading cache: 100% |###################################################################################| Time: 0:00:00
Parsing recipes: 100% |#################################################################################| Time: 0:01:32
Initialising tasks: 100% |##############################################################################| Time: 0:00:02
Checking sstate mirror object availability: 100% |######################################################| Time: 0:00:00
Loading cache: 100% |###################################################################################| Time: 0:00:00
Parsing recipes: 100% |#################################################################################| Time: 0:00:07
Initialising tasks: 100% |##############################################################################| Time: 0:00:00
-------------------------------------------------------

However the resulting SDK installation seems to be broken anyway (probably there are other steps after the one I re-run manually that where not executed because the toplevel script stopped with an error):

-------------------------------------------------------
sdk@sdk:~/acme-linux_sdk$ source environment-setup-cortexa7hf-neon-acme-linux-gnueabi
SDK environment now set up; additionally you may now run devtool to perform development tasks.
Run devtool --help for further details.
ERROR: this SDK was not fully installed and needs reinstalling
-------------------------------------------------------

Thanks

Gabriele

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

On 30-04-2020 20:23, Khem Raj via lists.yoctoproject.org wrote:

On 4/30/20 11:16 AM, Marek Belisko wrote:

Hi Rudolf,

On Thu, Apr 30, 2020 at 7:39 PM Rudolf J Streif
<rudolf.streif@...> wrote:

I was looking for a way in a wks file to have wic grow the last
partition to fill up the remainder of the disk. Of course wic does not
know how large the disk is but that could be a parameter.

The alternative way is to use fixed-size and do the math manually but
that would not allow wic to grow a partition based on content.

You can use https://manpages.debian.org/testing/systemd/systemd-growfs.8.en.html
which grow partition to the end.

can it grow a mounted partition ? since that will be the case when growing rootfs partition.

Yes, a mounted ext4 partition can be resized. Some tools will try to keep you from doing that though, had to patch parted to stop whining about mounted partitions in "scripted" mode that to make it work though.

https://github.com/topic-embedded-products/topic-platform/tree/zeus/meta-topic-platform/recipes-extended/parted

Here's the recipe that re-partitions the SD or eMMC on first boot after programming a (small) wic image:

https://github.com/topic-embedded-products/topic-platform/tree/zeus/meta-topic-platform/recipes-topic/expand-wic-partition

Hello All,

Intel and WR YP QA is planning for QA execution for YP build yocto-3.0.3.rc2. We are planning to execute following tests for this cycle:

OEQA-manual tests for following module:
1. OE-Core
2. BSP-hw

Runtime auto test for following platforms:
1. MinnowTurbot 32-bit
2. Coffee Lake
3. NUC 7
4. NUC 6
5. Edgerouter
6. MPC8315e-rdb
7. Beaglebone

ETA for completion is next Thursday, May 21.

Thanks,
Sangeeta

This allows automating its setup and execution on all autobuilder worker machines;
previously there was a static setup on a dedicated machine, which wasn't
great from maintenance perspective.

To use:

scripts/setup-auh target_dir
scripts/run-auh target_dir

(run-auh can be run several times in a directory that
was previously set up)

Signed-off-by: Alexander Kanavin <alex.kanavin@...>
---
scripts/auh-config/local.conf.append | 3 +++
scripts/auh-config/upgrade-helper.conf | 33 ++++++++++++++++++++++++++
scripts/run-auh | 32 +++++++++++++++++++++++++
scripts/setup-auh | 26 ++++++++++++++++++++
4 files changed, 94 insertions(+)
create mode 100644 scripts/auh-config/local.conf.append
create mode 100644 scripts/auh-config/upgrade-helper.conf
create mode 100755 scripts/run-auh
create mode 100755 scripts/setup-auh

diff --git a/scripts/auh-config/local.conf.append b/scripts/auh-config/local.conf.append
new file mode 100644
index 0000000..9628737
--- /dev/null
+++ b/scripts/auh-config/local.conf.append
@@ -0,0 +1,3 @@
+
+INHERIT += "buildhistory"
+LICENSE_FLAGS_WHITELIST = "commercial"
diff --git a/scripts/auh-config/upgrade-helper.conf b/scripts/auh-config/upgrade-helper.conf
new file mode 100644
index 0000000..fbf5d8a
--- /dev/null
+++ b/scripts/auh-config/upgrade-helper.conf
@@ -0,0 +1,33 @@
+[maintainer_override]
+# mails for recipe upgrades will go to john.doe instead of jane.doe, etc
+#ross.burton@...=anibal.limon@...
+
+[settings]
+# recipes in blacklist will be skipped
+blacklist=linux-libc-headers linux-yocto alsa-utils-scripts build-appliance-image
+#blacklist=python python3 glibc gcc linux-libc-headers linux-yocto-rt linux-yocto linux-yocto-dev linux-yocto-tiny qt4-x11-free qt4-embedded qt4-x11-free qt4e-demo-image gnome-common gnome-desktop3 gnome-desktop-testing adt-installer build-appliance-image
+# only recipes belonging to maintainers in whitelist will be attempted
+#maintainers_whitelist=anibal.limon@...
+# SMTP server
+smtp=smtp1.yoctoproject.org:25
+# from whom should the mails arrive
+from=auh@...
+# who should get the status mail with statistics, at the end
+status_recipients=openembedded-core@...
+# clean sstate directory before upgrading
+#clean_sstate=yes
+# clean tmp directory before upgrading
+#clean_tmp=yes
+# machines to test build with
+#machines=qemux86 qemux86-64 qemuarm qemumips qemuppc
+#machines=qemux86
+
+buildhistory=yes
+#testimage=yes
+#testimage_name=core-image-minimal
+
+#workdir=/home/auh/work/
+#publish_work_url=https://logs.yoctoproject.org/auh/
+
+commit_revert_policy=all
+
diff --git a/scripts/run-auh b/scripts/run-auh
new file mode 100755
index 0000000..29a8044
--- /dev/null
+++ b/scripts/run-auh
@@ -0,0 +1,32 @@
+#!/bin/bash
+# Run Auto Upgrade Helper in a directory set up by setup_auh.
+#
+# Called with $1 - the directory where the setup was created
+
+if [ -z $1 ]; then
+ echo "Use: $0 auh_setup_dir"
+ exit 1
+fi
+
+full_dir=$(readlink -e $1)
+
+auh_dir=$full_dir/auto-upgrade-helper
+poky_dir=$full_dir/poky
+build_dir=$full_dir/build
+sstate_dir=$full_dir/build/sstate-cache
+
+pushd $poky_dir
+
+# Base the upgrades on poky master
+git fetch origin
+git checkout -B tmp-auh-upgrades origin/master
+
+source $poky_dir/oe-init-build-env $build_dir
+$auh_dir/upgradehelper.py -e all
+
+# clean up to avoid the disk filling up
+rm -rf $build_dir/tmp/
+rm -rf $build_dir/workspace/sources/*
+find $sstate_dir -atime +10 -delete
+
+popd
diff --git a/scripts/setup-auh b/scripts/setup-auh
new file mode 100755
index 0000000..23f3d44
--- /dev/null
+++ b/scripts/setup-auh
@@ -0,0 +1,26 @@
+#!/bin/bash
+# Initialize Auto Upgrade Helper in a directory.
+#
+# Called with $1 - the directory to place the setup
+CONFIG_DIR=`dirname $0`/auh-config
+
+if [ -z $1 ]; then
+ echo "Use: $0 target_dir"
+ exit 1
+fi
+
+mkdir -p $1
+pushd $1
+
+git clone git://git.yoctoproject.org/poky
+pushd poky
+git config user.email auh@...
+git config user.name "Auto Upgrade Helper"
+popd
+git clone git://git.yoctoproject.org/auto-upgrade-helper
+source poky/oe-init-build-env build
+mkdir -p upgrade-helper
+popd
+
+cp $CONFIG_DIR/upgrade-helper.conf $1/build/upgrade-helper
+cat $CONFIG_DIR/local.conf.append >> $1/build/conf/local.conf
--
2.26.2

Thanks folks, IMAGE_GEN_DEBUGFS was exactly what I was looking for.

--wpd

in aid of docs, currently poring over python-based recipes to
document how one builds python recipe files, and noticed that numerous
recipe files contain an assignment of the form:

python3-smbus2_0.3.0.bb:PYPI_PACKAGE = "smbus2"

which seems superfluous given that pypi.bbclass contains:

def pypi_package(d):
bpn = d.getVar('BPN')
if bpn.startswith('python-'):
return bpn[7:]
elif bpn.startswith('python3-'):
return bpn[8:]
return bpn

PYPI_PACKAGE ?= "${@pypi_package(d)}"

clearly harmless but, in the above example, unnecessary, no?

there are, of course, numerous recipes that require an assignment of
that form as the actual PyPI package name is some annoying variation,
such as:

python3-sqlalchemy_1.3.12.bb:PYPI_PACKAGE = "SQLAlchemy"
python3-websocket-client_0.56.0.bb:PYPI_PACKAGE = "websocket_client"
python-django-south.inc:PYPI_PACKAGE = "South"

and so on, i just want to be able to write that as long as the recipe
file name *exactly* matches the PyPI package name, that assignment is
unnecessary. (i'm a minimalist.)

rday

p.s. on that note, i was curious about the recipe file
python3-twitter_3.8.0.bb, which contained the line:

PYPI_PACKAGE = "tweepy"

under the circumstances, why not have just named the recipe file
python3-tweepy...?

On Sat, May 16, 2020 at 7:12 AM Matthias Schoepfer
<matthias.schoepfer@...> wrote:

Hi Khem!

On 5/15/20 4:46 PM, Khem Raj wrote:

On 5/15/20 2:32 AM, Matthias Schoepfer via lists.yoctoproject.org wrote:

Hi!

I am trying to migrate to dunfell. Out customer does not want GPLv3
or anything like that on the firmware.

So - same as in zeus - we have a line:

INCOMPATIBLE_LICENSE = "GPLv3 LGPLv3 GPLv3+ LGPLv3+ GPL-3.0 LGPL-3.0
AGPL-3.0"

during do_rootfs, the process fails with:

do_rootfs: Package libgcc-lic cannot be installed into the image
because it has incompatible license(s): GPL-3.0

The package basically consists of the license information for libgcc,
libgcc is allowed due to the linking exception.

Even, when I try to allow this package with something like this:

INCOMPATIBLE_LICENSE_pn-libgcc-lic = ""
INCOMPATIBLE_LICENSE_pn-libgcc = ""

which has worked in the past to have an in house debug image with the
gdbserver on it, it still fails.

Am I the first to experience this? Am I doing something wrong?

We do

COPY_LIC_MANIFEST = "1"
COPY_LIC_DIRS = "1"
LICENSE_CREATE_PACKAGE = "1"

as well, if that info is needed.

Any help would be appreciated.

Can you try adding

LICENSE_${PN}-lic = "GPL-3.0-with-GCC-exception"

in meta/recipes-devtools/gcc/libgcc.inc

and see if it helps ?

It did help, thank you very much! I needed to repeat this for libgcrypt
and libidn2. It does look like a bug though, does it not?

if it happens on master too then send the patch to openembedded-core
mailing list

Regards,


Matthias

Hello!

I'm totally new to yocto and mainly new to linux development as a whole. Thus, please excuse me if my concerns that I raise here are inadequate.

== Context ==
We are developing a quite simple kernel driver that will make use of the GPIO. For a better reproducibility of the development infrastructure, we would like to be able to build this module against an SDK that is provided by the yocto build.

== Setup ==
While the yocto documentation provides a way to build the kernel module during the yocto build, according to this documentation: https://www.yoctoproject.org/docs/latest/kernel-dev/kernel-dev.html#incorporating-out-of-tree-modules, we were thinking to make use of the SDK to decouple the development phase of the module from the yocto build. In order to achieve this, the SDK requires the kernel to be configured according to the machine configuration. We expected to be able to have yocto export in the SDK the kernel headers already compiled according to the target environment. However, we couldn't achieve this objective (maybe we're missing something!!). The farthest we could go is to have yocto export the kernel sources into the SDK (according to this SO post https://stackoverflow.com/a/31261404/676344), but then, configuring it was not documented.

== Conclusion ==
We would like to know what is the best practice, from a development and continuous integration perspective, to be able to develop a kernel module.

Your advice is highly appreciated.

Thank you,
Alexandru

Hi Khem!

On 5/15/20 4:46 PM, Khem Raj wrote:

On 5/15/20 2:32 AM, Matthias Schoepfer via lists.yoctoproject.org wrote:

Hi!

I am trying to migrate to dunfell. Out customer does not want GPLv3 or anything like that on the firmware.

So - same as in zeus - we have a line:

INCOMPATIBLE_LICENSE = "GPLv3 LGPLv3 GPLv3+ LGPLv3+ GPL-3.0 LGPL-3.0 AGPL-3.0"

during do_rootfs, the process fails with:

do_rootfs: Package libgcc-lic cannot be installed into the image because it has incompatible license(s): GPL-3.0

The package basically consists of the license information for libgcc, libgcc is allowed due to the linking exception.

Even, when I try to allow this package with something like this:

INCOMPATIBLE_LICENSE_pn-libgcc-lic = ""
INCOMPATIBLE_LICENSE_pn-libgcc = ""

which has worked in the past to have an in house debug image with the gdbserver on it, it still fails.

Am I the first to experience this? Am I doing something wrong?

We do

COPY_LIC_MANIFEST = "1"
COPY_LIC_DIRS = "1"
LICENSE_CREATE_PACKAGE = "1"

as well, if that info is needed.

Any help would be appreciated.

Can you try adding

LICENSE_${PN}-lic = "GPL-3.0-with-GCC-exception"

in meta/recipes-devtools/gcc/libgcc.inc

and see if it helps ?

It did help, thank you very much! I needed to repeat this for libgcrypt and libidn2. It does look like a bug though, does it not?


Regards,


  Matthias

Hello!

On Fri, 15 May 2020 at 10:56, Philip Balister <philip@...> wrote:

I've made a wiki page to track these:
https://www.openembedded.org/wiki/Happy_Hours
Then next one is scheduled for 2100 UTC on May 27.

Ah, just in time to watch live SpaceX's launch:
https://blogs.nasa.gov/commercialcrew/

Greetings!

Daniel Díaz
daniel.diaz@...

I've made a wiki page to track these:

https://www.openembedded.org/wiki/Happy_Hours

Then next one is scheduled for 2100 UTC on May 27. This is late evening
for Europe and morning for New Zealand, so hopefully we see some
different faces. The meeting info is on the wiki page.

There is no set agenda, so bring some projects to talk about with the
community.


Philip

On Fri, May 15, 2020 at 5:36 PM Khem Raj <raj.khem@...> wrote:

On 5/15/20 8:25 AM, Patrick Doyle wrote:

I know I can do

$ bitbake base-image -cpopulate_sdk

and distribute the resulting SDK to developers (myself included).

But suppose I've just built and deployed an image and want to debug a
core file generated by one of the applications.

I don't see .debug directories anywhere in $TMP, so when I try to tell
gdb to use the sysroot from the application, that works, but I don't
get debugging symbols libc, nor do I get stack traces (on my MIPS
target).
(I guess it's possible that I would have found the .debug directories
if I had performed a complete build from scratch without the benefit
of the sstate-cache, but I rely upon the sstate-cache and routinely
start with a blank $TMP)

So, I can populate the sdk, and end up with a pile of .debug directories:

$ find . -name .debug -type d
./tmp/work/sundial-poky-linux-musl/base-image/1.0-r0/sdk/image/opt/irobot-mt/0.2/sysroots/mips32r2-24kec-nf-poky-linux-musl/usr/lib/.debug
./tmp/work/x86_64-nativesdk-pokysdk-linux/gcc-cross-canadian-mipsel/8.3.0-r0/packages-split/gcc-cross-canadian-mipsel-dbg/opt/irobot-mt/0.2/sysroots/x86_64-pokysdk-linux/usr/bin/mipsel-poky-linux/.debug
./tmp/work/x86_64-nativesdk-pokysdk-linux/gcc-cross-canadian-mipsel/8.3.0-r0/packages-split/gcc-cross-canadian-mipsel-dbg/opt/irobot-mt/0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/mipsel-poky-linux/gcc/mipsel-poky-linux/8.3.0/.debug
./tmp/work/x86_64-nativesdk-pokysdk-linux/gcc-cross-canadian-mipsel/8.3.0-r0/packages-split/gcc-cross-canadian-mipsel-dbg/opt/irobot-mt/0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/mipsel-poky-linux/gcc/mipsel-poky-linux/8.3.0/plugin/.debug
./tmp/work/x86_64-nativesdk-pokysdk-linux/gcc-cross-canadian-mipsel/8.3.0-r0/package/opt/irobot-mt/0.2/sysroots/x86_64-pokysdk-linux/usr/bin/mipsel-poky-linux/.debug
./tmp/work/x86_64-nativesdk-pokysdk-linux/gcc-cross-canadian-mipsel/8.3.0-r0/package/opt/irobot-mt/0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/mipsel-poky-linux/gcc/mipsel-poky-linux/8.3.0/.debug
./tmp/work/x86_64-nativesdk-pokysdk-linux/gcc-cross-canadian-mipsel/8.3.0-r0/package/opt/irobot-mt/0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/mipsel-poky-linux/gcc/mipsel-poky-linux/8.3.0/plugin/.debug
./tmp/work/mips32r2-24kec-nf-poky-linux-musl/musl-utils/20170421-r0/packages-split/musl-utils-dbg/usr/bin/.debug
./tmp/work/mips32r2-24kec-nf-poky-linux-musl/musl-utils/20170421-r0/package/usr/bin/.debug

Which sysroot directory is the best one at which I can point gdb for
getting debug symbols?

If I build this with an autobuilder and want to archive the sysroot
for use by gdb later, which one should I archive?

I could archive the generated SDK, but that will require that I (or
others) install the SDK just to debug a core file, which seems a
little heavy to me. But I can do that, if that's "the Yocto way".

I wonder if there is a lighter weight mechanism for accessing the
debugging symbols during development, and for archiving said symbols
for post-development support.

Any ideas? Best practices? Recommended approaches?

I would think of using IMAGE_GEN_DEBUGFS set to 1 which should generate
a debug archive of image

see following for detailed steps

https://docs.windriver.com/bundle/Wind_River_Linux_Platform_Developers_Guide_9_1/page/fvn1520619692704.html

https://developer.ridgerun.com/wiki/index.php?title=Preparing_Yocto_Development_Environment_for_Debugging

Thanks

--wpd

I created [1] in meta-mortsgna. It is not recommended (bit of a hack /
nobody but me and my colleagues use it) but it

* works on the fly: Once enabled building the recipe you want to debug
is good enough
* not bound to SDK or image which tends to last
* no manual copying necessary

[1] https://github.com/schnitzeltony/meta-mortsgna/blob/master/classes/instant-sysroot-target.bbclass

Andreas