Date   

Re: Cannot build yocto anymore after updating all layers to current dunfell branch tips

Robert Berger
 

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


[PATCH yocto-autobuilder-helper 2/2] auh-config: adjust to new override syntax

Alexander Kanavin
 

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


[PATCH yocto-autobuilder-helper 1/2] auh-config: enable systemd only for glibc

Alexander Kanavin
 

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


Re: Cannot build yocto anymore after updating all layers to current dunfell branch tips

Steve Sakoman
 

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



best way to get feature of systemd v248 in yocto-hardknott (systemd v247)?

Bill Plunkett
 

I'd like to use a systemd DHCP client feature that became available in v248 in my yocto-hardknott system.  Is there any hope of using the complete v249.1 recipe from the oe master branch?

Bill


Cannot build yocto anymore after updating all layers to current dunfell branch tips

Manuel Wagesreither
 

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


[yocto-autobuilder2] schedulers.py: add dunfell branchdefaults for meta-aws and meta-openembedded

Steve Sakoman
 

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


Re: Dependencies between recipes

Quentin Schulz
 

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.


[PATCH][yocto-autobuilder2] schedulers: change default value for SWAT monitoring

Alexandre Belloni
 

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


Re: [meta-mingw] [PATCH] binutils: Package static libdep linker plugins

Joshua Watt
 


On 8/13/21 2:05 AM, Samuli Piippo wrote:
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





Re: Unable to add gdbserver to the Yocto build #yocto

Alexander Kanavin
 

Thud has not been supported for a very long time actually. To really find out what is happening, it would help if you make an archive of tmp/work/../gdb/ and put it somewhere for inspection.

Alex


On Fri, 13 Aug 2021 at 13:32, Ashutosh Naik <ashutosh.naik@...> wrote:


On Fri, Aug 13, 2021 at 2:16 AM Khem Raj <raj.khem@...> wrote:


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


Hi Alexander and KhemRaj,

I am using the Yocto "thud" version which has long term support.

The architecture used is aarch64-oe-linux

The gdb directory or executables were not created in tmp/work/.../gdb/deploy-*/ (the gdb WORKDIR), nor in tmp/deploy/... (packages deploy dir), and neither in tmp/work/..../machine-image/ (image-specific package repo), although the compilation went through successfully.

Could it be that the architecture "aarch64-oe-linux" is not supported for gdbserver in Yocto "thud" ?

Regards
Ash

 




Re: Unable to add gdbserver to the Yocto build #yocto

Ashutosh Naik
 



On Fri, Aug 13, 2021 at 2:16 AM Khem Raj <raj.khem@...> wrote:


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


Hi Alexander and KhemRaj,

I am using the Yocto "thud" version which has long term support.

The architecture used is aarch64-oe-linux

The gdb directory or executables were not created in tmp/work/.../gdb/deploy-*/ (the gdb WORKDIR), nor in tmp/deploy/... (packages deploy dir), and neither in tmp/work/..../machine-image/ (image-specific package repo), although the compilation went through successfully.

Could it be that the architecture "aarch64-oe-linux" is not supported for gdbserver in Yocto "thud" ?

Regards
Ash

 


execute a python code in raspberrypi #python

yasminebenghozzi6@...
 

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 .


Re: [meta-mingw] [PATCH] binutils: Package static libdep linker plugins

Samuli Piippo
 

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.

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





Re: Unable to add gdbserver to the Yocto build #yocto

Khem Raj
 

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


Dependencies between recipes

daniel_herrmann22@...
 

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


Re: #yocto debbuging option under zeus #yocto

Khem Raj
 

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


Re: Unable to add gdbserver to the Yocto build #yocto

Alexander Kanavin
 

Can you check whether the gdbserver package is in tmp/work/.../gdb/deploy-*/ (the gdb WORKDIR), and whether it is in tmp/deploy/... (packages deploy dir), and then whether it is in tmp/work/..../machine-image/ (image-specific package repo)? Seems like it gets lost at some point.

Alex


On Thu, 12 Aug 2021 at 17:24, Ashutosh Naik <ashutosh.naik@...> wrote:
HI Alexander,

Thanks for your email.

The  'bitbake gdb' runs through successfully. However, I still get the error for gdbserver when running 'bitbake machine-image'

Thanks
Ash

On Thu, Aug 12, 2021 at 3:54 PM Alexander Kanavin <alex.kanavin@...> wrote:
What happens when you 'bitbake gdb'?

Alex

On Thu, 12 Aug 2021 at 16:28, <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
 
Thanks
Ash




Re: Unable to add gdbserver to the Yocto build #yocto

Ashutosh Naik
 

HI Alexander,

Thanks for your email.

The  'bitbake gdb' runs through successfully. However, I still get the error for gdbserver when running 'bitbake machine-image'

Thanks
Ash

On Thu, Aug 12, 2021 at 3:54 PM Alexander Kanavin <alex.kanavin@...> wrote:
What happens when you 'bitbake gdb'?

Alex

On Thu, 12 Aug 2021 at 16:28, <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
 
Thanks
Ash




Minutes: Yocto Project Weekly Triage Meeting 8/12/2021

Randy MacLeod
 

*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)

3021 - 3040 of 57384