On 14/08/2021 00:28, Manuel Wagesreither wrote:

Hello all,
I updated the layers of my project to the current dunfell branch tips. See here: https://gitlab.com/manuel_wagesreither/bora-proj/-/commit/de631634d7556987d2551d0cedca8f67530bc78d
Since then, the build is failing with the following message:
```
ERROR: ParseError at /home/manuel/bora-proj/meta-openembedded/meta-oe/conf/layer.conf:104: unparsed line: 'DEFAULT_TEST_SUITES:pn-meta-oe-ptest-image = " ${PTESTTESTSUITE}"'
```

There was an OVERRIDE syntax change and this is what are seeing.
Some layers, like meta-openembedded incorporated this change into their master branch. So either you need to update all your layers as well, or you need to use meta-openembedded with a branch/commit before the change.

Regards,

Robert

Signed-off-by: Alexander Kanavin <alex.kanavin@...>
---
scripts/auh-config/local.conf.append | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/auh-config/local.conf.append b/scripts/auh-config/local.conf.append
index 417d228..25c062b 100644
--- a/scripts/auh-config/local.conf.append
+++ b/scripts/auh-config/local.conf.append
@@ -1,5 +1,5 @@

INHERIT += "buildhistory"
LICENSE_FLAGS_WHITELIST = "commercial"
-DISTRO_FEATURES_append_libc-glibc = ' systemd'
-DISTRO_FEATURES_append = ' pam'
+DISTRO_FEATURES:append:libc-glibc = ' systemd'
+DISTRO_FEATURES:append = ' pam'
--
2.31.1

It is not guaranteed to build or work otherwise, and causes
update failures in unrelated recipes when building for musl for instance.

Signed-off-by: Alexander Kanavin <alex.kanavin@...>
---
scripts/auh-config/local.conf.append | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/scripts/auh-config/local.conf.append b/scripts/auh-config/local.conf.append
index b18590f..417d228 100644
--- a/scripts/auh-config/local.conf.append
+++ b/scripts/auh-config/local.conf.append
@@ -1,4 +1,5 @@

INHERIT += "buildhistory"
LICENSE_FLAGS_WHITELIST = "commercial"
-DISTRO_FEATURES_append = ' systemd pam'
+DISTRO_FEATURES_append_libc-glibc = ' systemd'
+DISTRO_FEATURES_append = ' pam'
--
2.31.1

On Fri, Aug 13, 2021 at 11:29 AM Manuel Wagesreither <ManWag@...> wrote:

Hello all,

I updated the layers of my project to the current dunfell branch tips. See here: https://gitlab.com/manuel_wagesreither/bora-proj/-/commit/de631634d7556987d2551d0cedca8f67530bc78d

Since then, the build is failing with the following message:
```
ERROR: ParseError at /home/manuel/bora-proj/meta-openembedded/meta-oe/conf/layer.conf:104: unparsed line: 'DEFAULT_TEST_SUITES:pn-meta-oe-ptest-image = " ${PTESTTESTSUITE}"'
```

Indeed this line, and even more the one after look strange.
https://github.com/openembedded/meta-openembedded/blob/master/meta-oe/conf/layer.conf#L104

Note that you are using the master branch of meta-oe ^^^^^^^^

If you use the dunfell branch you won't have this issue.

Steve

```
DEFAULT_TEST_SUITES:pn-meta-oe-ptest-image = " ${PTESTTESTSUITE}"

NON_MULTILIB_RECIPES:append = " crash"
```

When I replace the : with _, things seem to work. I can't make sense of that. Did the syntax change? If so, why doesn't bitbake understand the new syntax? I thought bitbake is included in one of the layers.

Thanks, Regards,
Manuel

Hello all,

I updated the layers of my project to the current dunfell branch tips. See here: https://gitlab.com/manuel_wagesreither/bora-proj/-/commit/de631634d7556987d2551d0cedca8f67530bc78d

Since then, the build is failing with the following message:
```
ERROR: ParseError at /home/manuel/bora-proj/meta-openembedded/meta-oe/conf/layer.conf:104: unparsed line: 'DEFAULT_TEST_SUITES:pn-meta-oe-ptest-image = " ${PTESTTESTSUITE}"'
```

Indeed this line, and even more the one after look strange.
https://github.com/openembedded/meta-openembedded/blob/master/meta-oe/conf/layer.conf#L104
```
DEFAULT_TEST_SUITES:pn-meta-oe-ptest-image = " ${PTESTTESTSUITE}"

NON_MULTILIB_RECIPES:append = " crash"
```

When I replace the : with _, things seem to work. I can't make sense of that. Did the syntax change? If so, why doesn't bitbake understand the new syntax? I thought bitbake is included in one of the layers.

Thanks, Regards,
Manuel

Both repos have been added to check-layer-nightly so we need to make
sure the dunfell branches of the repos are being used

Signed-off-by: Steve Sakoman <steve@...>
---
schedulers.py | 2 ++
1 file changed, 2 insertions(+)

diff --git a/schedulers.py b/schedulers.py
index 8f6f343..a6e9fd6 100644
--- a/schedulers.py
+++ b/schedulers.py
@@ -70,9 +70,11 @@ branchdefaults = {
'branch_poky': 'dunfell',
'branch_bitbake': '1.46',
'branch_meta-arm': 'dunfell',
+ 'branch_meta-aws': 'dunfell',
'branch_meta-gplv2': 'dunfell',
'branch_meta-intel': 'dunfell',
'branch_meta-mingw': 'dunfell',
+ 'branch_meta-openembedded': 'dunfell',
'branch_oecore': 'dunfell',
},
'zeus': {
--
2.25.1

Hi Daniel,

On August 12, 2021 6:27:50 PM UTC, daniel_herrmann22@... wrote:

Hello,

I'm stucking a little bit by compiling a cmake application which has dependencies
on libs from another recipe.

*1)*
The recipe which provided my libs is a normal debian package which I installed in yocto like this:

SRC_URI = "file://${BP}.deb"
S = "${WORKDIR}"

inherit bin_package pkgconfig

do_install() {
install -d ${D}/opt/package-name/include/
install -d ${D}/opt/package-name/lib
install -d ${D}/opt/package-name/lib/cmake
}

Those commands only add directories, you still need to copy your files to one of those directories. Use for example:

install ${S}/path/to/lib.so.x.y ${D}${libdir}

FILES_${PN} = "/opt/package-name/lib/folder"
FILES_${PN} += "/opt/package-name/include/folder"

Any specific reason for not putting your libs in ${libdir} instead of /opt/package-name/lib/folder?

Also, if you can compile from scratch the software instead of including the Deb package, it'd be a better idea 😉

*2)*
The libs from 1) I want to use in the cmake-application

*2.1)*
*CmakeLists.txt is like this:*

cmake_minimum_required(VERSION 2.8)
project(test)
set(package_DIR /opt/package-name/lib/cmake)   #path to cmake package -> Config.cmake
find_package(package)
add_executable(test main.cpp)
target_link_libraries(test package::lib)

*-> I dont know how to set the right path to the Config.cmake. At the moment it points to the host location.*
*I have tried like this ${STAGING_DIR}/opt/... which should point to the sysroot, but no success.*

*2.2)*
*Recipe for the cmake-application in short*

DEPENDS += "package-name"   # package from 1)
inherit cmake
SRC_URI="git://....
SRCREV = "...."

S = "${WORKDIR}/git"

do_install(){
install -d ${D}/${bindir}
install -m0755 test ${D}/${bindir}
}

FILES_${PN} = "/usr/bin/test"

RDEPENDS_${PN} += "package-name"

When I make a sysroot from the hole image with bitbake -c populate_sdk  and I point directly to path where the Config.cmake is stored, everythings works..
Is there any way to make it work in the yocto build process, without making a explicit sysroot ?

I don't think your library package is correctly configured for starters. I would recommend installing your libs in ${D}${libdir} that's where most of the libs are and some variables default are set for those so it's all automagic.

Otherwise, the issue is that the files from your library package aren't made available to other recipes. First because you're not installing your libs. Second, by default only a portion of files installed are made available to other recipes via their sysroot. The portions are listed in SYSROOT_DIRS (https://docs.yoctoproject.org/ref-manual/variables.html#term-SYSROOT_DIRS). If you want to keep using /opt/whatever directory for your libs, you'll need to add this directory to SYSROOT_DIRS. And probably will need to tweak a few other paths to point to ${RECIPE_SYSROOT}/opt for library lookup for the linker for example.

If you install in ${D}${libdir} instead, everything is handled for you automagically ☺️

Easier to maintain that way, highly recommend 😉

Cheers,
Quentin

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

meta-oe and auh are not for SWAT, change the default to be false

Signed-off-by: Alexandre Belloni <alexandre.belloni@...>
---
schedulers.py | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/schedulers.py b/schedulers.py
index 8f6f34323a75..6b711d65766f 100644
--- a/schedulers.py
+++ b/schedulers.py
@@ -206,11 +206,15 @@ def props_for_builder(builder):
scheduler
"""

+ swat_default = True
+ if builder in ['auh', 'meta-oe']:
+ swat_default = False
+
props = []
props.append(util.BooleanParameter(
name="swat_monitor",
label="Should SWAT monitor this build?",
- default=True))
+ default=swat_default))
if builder == 'build-appliance':
props.append(buildappsrcrev_param())
if builder in ['build-appliance', 'buildtools', 'eclipse-plugin-neon', 'eclipse-plugin-oxygen']:
--
2.31.1

ping.

I'm still seeing problem with this on hardknott, at least when building for qemux86 target:

agent:2021/08/13 06:00:50 build.go:391: ERROR: binutils-cross-canadian-i686-2.36.1-r0 do_package_qa: QA Issue: non -staticdev package contains static .a library: binutils-cross-canadian-i686 path '/opt/poky/3.3.2/sysroots/x86_64-w64-mingw32/usr/lib/i686-poky-linux/bfd-plugins/libdep.dll.a'
agent:2021/08/13 06:00:50 build.go:391: non -staticdev package contains static .a library: binutils-cross-canadian-i686 path '/opt/poky/3.3.2/sysroots/x86_64-w64-mingw32/usr/lib/i686-poky-linux/bfd-plugins/libdep.dll.a' [staticdev]
agent:2021/08/13 06:00:50 build.go:391: ERROR: binutils-cross-canadian-i686-2.36.1-r0 do_package_qa: QA run found fatal errors. Please consider fixing them.

Hmm, I'm not sure why I missed this. However, why is the MinGW build producing the .a files and not all the builds? It seems like this could go in the oe-core version of the recipe (w/o the override) instead of the bbappend?

On Tue, 16 Feb 2021 at 11:07, Samuli Piippo via lists.yoctoproject.org <samuli.piippo=gmail.com@...> wrote:

this is new plugin added in binutils 2.36

Signed-off-by: Samuli Piippo <samuli.piippo@...>
---
 recipes-devtools/binutils/binutils-cross-canadian_2.%.bbappend | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/recipes-devtools/binutils/binutils-cross-canadian_2.%.bbappend b/recipes-devtools/binutils/binutils-cross-canadian_2.%.bbappend
index 5845fe0..0d376bb 100644
--- a/recipes-devtools/binutils/binutils-cross-canadian_2.%.bbappend
+++ b/recipes-devtools/binutils/binutils-cross-canadian_2.%.bbappend
@@ -3,3 +3,5 @@ LDFLAGS_append_sdkmingw32 = " -Wl,-static"

 DEPENDS_remove_sdkmingw32 = "nativesdk-gettext"
 DEPENDS_remove_sdkmingw32 = "nativesdk-flex"
+
+FILES_${PN}-staticdev_append_sdkmingw32 = " ${libdir}/bfd-plugins/lib*.a"
--
2.17.1

Hello beautiful people, 

I successfully executed helloworld.py on the raspberrypi by making a layer. BUt now i need to add a whole python code with classes etc, which exists in different files like the picture, I wanna know please how to add them to be able to run the code on the raspberrypi. THey re all related together and i need to run the main-SF.py so the code will be executed.

THank you .

On 8/12/21 7:28 AM, ashutosh.naik@... wrote:

I added the following to EXTRA_IMAGE_FEATURES inside my local.conf,
EXTRA_IMAGE_FEATURES = "debug-tweaks tools-debug"
PACKAGECONFIG_remove_pn-gdb = "readline"
I also tried to add the gdbserver package explicitly by adding this to conf/local.conf:
IMAGE_INSTALL_append = " gdbserver"
However, the build failed with the following error:
Collected errors:
 * Solver encountered 1 problem(s):
 * Problem 1/1:
 *   - nothing provides gdbserver needed by
packagegroup-core-tools-debug-1.0-r3.all
 *
 * Solution 1:
 *   - do not ask to install a package providing
packagegroup-core-tools-debug
Would appreciate any help, as I am struggling with this issue for over a day

whats your target architecture ? sometimes gdbserver port may not be available for a given arch.

Thanks
Ash

Hello, 

I'm stucking a little bit by compiling a cmake application which has dependencies
on libs from another recipe.

1)
The recipe which provided my libs is a normal debian package which I installed in yocto like this:

SRC_URI = "file://${BP}.deb"
S = "${WORKDIR}"

inherit bin_package pkgconfig

do_install() {
    install -d ${D}/opt/package-name/include/ 
    install -d ${D}/opt/package-name/lib
    install -d ${D}/opt/package-name/lib/cmake   
}

FILES_${PN} = "/opt/package-name/lib/folder"
FILES_${PN} += "/opt/package-name/include/folder"


2)
The libs from 1) I want to use in the cmake-application

2.1)
CmakeLists.txt is like this:

cmake_minimum_required(VERSION 2.8)
project(test)
set(package_DIR /opt/package-name/lib/cmake)   #path to cmake package -> Config.cmake
find_package(package)
add_executable(test main.cpp)
target_link_libraries(test package::lib)

-> I dont know how to set the right path to the Config.cmake. At the moment it points to the host location.
I have tried like this ${STAGING_DIR}/opt/... which should point to the sysroot, but no success.


2.2)
Recipe for the cmake-application in short

DEPENDS += "package-name"   # package from 1)
inherit cmake
SRC_URI="git://....
SRCREV = "...."

S = "${WORKDIR}/git"

do_install(){
    install -d ${D}/${bindir}
    install -m0755 test ${D}/${bindir}   
}

FILES_${PN} = "/usr/bin/test"

RDEPENDS_${PN} += "package-name"


When I make a sysroot from the hole image with bitbake -c populate_sdk  and I point directly to path where the Config.cmake is stored, everythings works..
Is there any way to make it work in the yocto build process, without making a explicit sysroot ?

Thanks

On 8/11/21 3:53 AM, Monsees, Steven C (US) via lists.yoctoproject.org wrote:

Is it documented anywhere on how one might manually load debug info an for image with the binaries stripped ?

what you are looking for is perhaps achieved better by setting a feedserver on your buildmachine and then let your target download/update packages much like other distributions

in local.conf set

PACKAGE_FEED_URIS = "http://10.0.0.10:8000"

this would encode the feedserver address into you online package manager config in image

then run

bitbake package-index

which would update the feed metadata index

Run a http-server on the feed directory on buildserver

a poor man's way is

cd build/tmp/deploy/ipk/
python -m http.server

then you can go to your target and do normal opkg operations


opkg update && opkg install busybox-dbg

another advantage of this approach is that it will automatically download/install the dependecies.

Thanks,
Steve
*From:* yocto@... <yocto@...> *On Behalf Of *Monsees, Steven C (US) via lists.yoctoproject.org
*Sent:* Tuesday, August 10, 2021 1:48 PM
*To:* yocto@...
*Subject:* [yocto] #yocto debbuging option under zeus
*_External Email Alert_*
*This email has been sent from an account outside of the BAE Systems network.*
Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros.  For further information on how to spot phishing, access “Cybersecurity OneSpace Page” and report phishing by clicking the button “Report Phishing” on the Outlook toolbar.
I ran across the following under the Yocto Project Profiling and Tracing Manual, and after checking my ipk data files/layout, I was wondering if someone could tell me, if ipk is capable of performing a similar set of operations to install my debug data ?, and if so, what would be the correct command sequence ?
“ The debug packages once built can be found in build/tmp/deploy/rpm/* on the host system. Find the busybox-dbg-...rpm file and copy it to the target. For example:
[trz@empanada core2]$ scp /home/trz/yocto/crownbay-tracing-dbg/build/tmp/deploy/rpm/core2_32/busybox-dbg-1.20.2r2.core2_32.rpm root@....31 <mailto:root@....31>:
root@....31's <mailto:root@....31's> password:
     busybox-dbg-1.20.2-r2.core2_32.rpm                     100% 1826KB   1.8MB/s   00:01
Now install the debug rpm on the target:
     root@crownbay:~# *rpm -i busybox-dbg-1.20.2-r2.core2_32.rpm*
“
Thanks,
Steve

*Wiki: *https://wiki.yoctoproject.org/wiki/Bug_Triage

*Attendees:* Alex, Diane, Joshua, MichaelO, Randy, Saul, Stephen, Steve, Tim, Tony, Ross

*ARs:*

Deal with old milestones:
https://wiki.yoctoproject.org/wiki/Bug_Triage#Old_Milestone

1. Ross
2. Bruce

FYI: AR = Action Required according to Google's top hit:

http://www.nathanzeldes.com/wp-content/uploads/2014/01/Effective-Action-Culture.pdf



*Notes:*
*
*
- (carried over) Steve encountered build failures such as the one in https://errors.yoctoproject.org/Errors/Details/593109/ when attempting to run dunfell builds with the PARALLEL_MAKE load averaging added. WR is testing/investigating on internal Autobuilder instance

- No Future/3.99 bugs to triage this week (wow!)

*Medium+ 3.4 Unassigned Enhancements/Bugs: *80* (No change)

*Medium+ 3.99 Unassigned Enhancements/Bugs: *30* (Last week 30)

*AB-INT Bugs: *46* (No change)