1. yocto@lists.yoctoproject.org
  2. Messages
   Date   
Re: dunfell: pkgconfig-native build fails in existing Yocto BSP

Matthias Klein
 

Hello Richard,

Thanks for the quick help!

Best regards,
Matthias
[hardknott][yocto-autobuilder-helper][PATCH] config.json: set max load in PARALLEL_MAKE

Anuj Mittal
 

From: Trevor Gamblin <trevor.gamblin@...>

Add "-l 52" to PARALLEL_MAKE in config.json to limit Make and Ninja
builds based on the detected system load. With this option added, if
either tool has at least one job running and detects that the system
load exceeds the given value, it will wait until either the system load
average drops below that limit, or until all other jobs are finished
before starting additional jobs.

Since most autobuilder machines have 56 cores, this should help keep the
system from being overloaded during builds.

Reference: https://www.gnu.org/software/make/manual/html_node/Parallel.html

Signed-off-by: Trevor Gamblin <trevor.gamblin@...>
Signed-off-by: Richard Purdie <richard.purdie@...>
(cherry picked from commit 5c5fc7bcd221427d34bbac80c9bad315fb6de4df)
Signed-off-by: Anuj Mittal <anuj.mittal@...>
---
config.json | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/config.json b/config.json
index 33d36ad..d397365 100644
--- a/config.json
+++ b/config.json
@@ -43,7 +43,7 @@
"PREMIRRORS = ''",
"BB_GENERATE_MIRROR_TARBALLS = '1'",
"BB_NUMBER_THREADS = '16'",
- "PARALLEL_MAKE = '-j 16'",
+ "PARALLEL_MAKE = '-j 16 -l 52'",
"XZ_MEMLIMIT = '5%'",
"XZ_THREADS = '8'",
"BB_TASK_NICE_LEVEL = '5'",
--
2.31.1
Re: How to iherit class based on a conditional variable? #sysvinit #systemd

Alexander Kanavin
 

It's fine to inherit both classes and install both files without even checking DISTRO_FEATURES. There's behind the scenes magic that will do the right thing depending on what init manager is chosen in the distro config.

Alex


On Mon, 25 Oct 2021 at 14:38, Bel Hadj Salem Talel <bhstalel@...> wrote:
Hello,

I have a recipe that installs a simple bash script to run on startup.
As you all know, there is systemd and sysvinit.
I need to add support for both init managers.

I can do :
SRC_URI_append = " ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'file://script.service', 'file://script.sh', d)}"

and I can do the same in all the tasks.

The problem is, that I need to inherit either systemd or update-rc.d

Is it possible to inherit them all, or how can I inherit something conditionally ?

Thanks,
Talel
Re: bbappend usage

Alexander Kanavin
 

There is no one-size-fits-all answer to this. It helps if you provide specifics: what components and what portions of them and why.

Alex


On Mon, 25 Oct 2021 at 15:26, Monsees, Steven C (US) via lists.yoctoproject.org <steven.monsees=baesystems.com@...> wrote:

I am looking to selectively remove portions of 1or 2 components I will not be using from my running image

-----Original Message-----
From: yocto@... <yocto@...> On Behalf Of Leon Woestenberg
Sent: Monday, October 25, 2021 9:12 AM
To: Monsees, Steven C (US) <steven.monsees@...>
Cc: yocto@...
Subject: Re: [yocto] bbappend usage

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.


Hello Steve,

Is the approach where you remove the recipes from the image an option?
Is there a reason why you want to build the recipes that you do not want to appear in your image?

Regards,

Leon.


--
Leon Woestenberg
leon@...
T: +31 40 711 42 76
M: +31 6 472 30 372

Sidebranch Embedded Systems
Eindhoven, The Netherlands
http://www.sidebranch.com



On Mon, Oct 25, 2021 at 2:55 PM Monsees, Steven C (US) via lists.yoctoproject.org <steven.monsees=baesystems.com@...> wrote:
>
>
>
> Hello:
>
>
>
> If I am building an image “image-ABC”, and it is composed of a number
> recipes, and for some of these recipes I may NOT want to install their
> final components within my image…
>
>
>
> Which is the best place to modify the build with bbappend ?
>
>
>
> Would I modify a recipe’s do_install (do_install_append-recipe_xyz) ?, or would I modify the image recipe (do_install_append-image_ABC) I am leaning this way to avoid cases where the component recipes might have bbappends in place already ?
>
>
>
> Looking for the proper Yocto way…
>
>
>
> Thanks,
>
> Steve
>
>
>
>
>
>
>
>
Re: bbappend usage

Monsees, Steven C (US)
 

I am looking to selectively remove portions of 1or 2 components I will not be using from my running image

-----Original Message-----
From: yocto@... <yocto@...> On Behalf Of Leon Woestenberg
Sent: Monday, October 25, 2021 9:12 AM
To: Monsees, Steven C (US) <steven.monsees@...>
Cc: yocto@...
Subject: Re: [yocto] bbappend usage

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.


Hello Steve,

Is the approach where you remove the recipes from the image an option?
Is there a reason why you want to build the recipes that you do not want to appear in your image?

Regards,

Leon.


--
Leon Woestenberg
leon@...
T: +31 40 711 42 76
M: +31 6 472 30 372

Sidebranch Embedded Systems
Eindhoven, The Netherlands
http://www.sidebranch.com



On Mon, Oct 25, 2021 at 2:55 PM Monsees, Steven C (US) via lists.yoctoproject.org <steven.monsees=baesystems.com@...> wrote:



Hello:



If I am building an image “image-ABC”, and it is composed of a number
recipes, and for some of these recipes I may NOT want to install their
final components within my image…



Which is the best place to modify the build with bbappend ?



Would I modify a recipe’s do_install (do_install_append-recipe_xyz) ?, or would I modify the image recipe (do_install_append-image_ABC) I am leaning this way to avoid cases where the component recipes might have bbappends in place already ?



Looking for the proper Yocto way…



Thanks,

Steve
Re: bbappend usage

Monsees, Steven C (US)
 

No, you got it wromg... I have a buildable image which has all the components necessary, I want to remove some overhead installed by some components that I will not be within my running application...

-----Original Message-----
From: yocto@... <yocto@...> On Behalf Of Robert P. J. Day
Sent: Monday, October 25, 2021 9:10 AM
To: Monsees, Steven C (US) <steven.monsees@...>
Cc: yocto@...
Subject: Re: [yocto] bbappend usage

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.


On Mon, 25 Oct 2021, Monsees, Steven C (US) via lists.yoctoproject.org wrote:

If I am building an image “image-ABC”, and it is composed of a number
recipes, and for some of these recipes I may NOT want to install their
final components within my image…

Which is the best place to modify the build with bbappend ?

Would I modify a recipe’s do_install (do_install_append-recipe_xyz) ?,
or would I modify the image recipe (do_install_append-image_ABC) I am
leaning this way to avoid cases where the component recipes might have
bbappends in place already ?
i would think start with defining a minimal image, then define other images based on that one which add more recipes. this has nothing to do with redefining the recipes, it just means defining more than one image.

rday
Re: bbappend usage

Konrad Weihmann <kweihmann@...>
 

The super yoctoish way would be to alter the packaging of the recipe to your needs.

Let's assume recipe-a consists of the files

foo
bar

and it would package both files into recipe-a pkg.

In the actual image you only install packages into a file system, so if you don't want bar to be installed into your final image, it'd be best to package bar into a separate package.

PACKAGES_BEFORE_PN = "${PN}-bar"
FILES:${PN}-bar = "bar"

in this case the recipe would produce

recipe-a (containing just foo)
recipe-a-bar (containing just bar)

You could install now (via IMAGE_INSTALL in your image recipe) just add recipe-a and only foo would be put into the final image.

While a potential other image (IMAGE_INSTALL += "recipe-a-bar recipe-a")
would contain both.

But if you'd go down that road you have to make sure that runtime dependencies between the packages are met (using REDEPENDS:* statements), as otherwise it could turn into very hard to debug issues.
So I would propose to **not** do that via bbappends, but forks of the recipes you want to repackage.

Another option (as likely mentioned already) is to use

rem_stuff() {
rm ${IMAGE_ROOTFS}/<file you want to delete>
}

ROOTFS_POSTPROCESS_COMMAND += "rem_stuff;"

in your image recipe

On 25.10.21 14:55, Monsees, Steven C (US) via lists.yoctoproject.org wrote:
Hello:
If I am building an image “image-ABC”, and it is composed of a number recipes, and for some of these recipes I may NOT want to install their final components within my image…
Which is the best place to modify the build with bbappend ?
Would I modify a recipe’s do_install (do_install_append-recipe_xyz) ?, or would I modify the image recipe (do_install_append-image_ABC) I am leaning this way to avoid cases where the component recipes might have bbappends in place already ?
Looking for the proper Yocto way…
Thanks,
Steve
Re: bbappend usage

Leon Woestenberg
 

Hello Steve,

Is the approach where you remove the recipes from the image an option?
Is there a reason why you want to build the recipes that you do not
want to appear in your image?

Regards,

Leon.


--
Leon Woestenberg
leon@...
T: +31 40 711 42 76
M: +31 6 472 30 372

Sidebranch Embedded Systems
Eindhoven, The Netherlands
http://www.sidebranch.com



On Mon, Oct 25, 2021 at 2:55 PM Monsees, Steven C (US) via
lists.yoctoproject.org
<steven.monsees=baesystems.com@...> wrote:




Hello:



If I am building an image “image-ABC”, and it is composed of a number recipes, and for some of these recipes I may NOT want to install their final components within my image…



Which is the best place to modify the build with bbappend ?



Would I modify a recipe’s do_install (do_install_append-recipe_xyz) ?, or would I modify the image recipe (do_install_append-image_ABC) I am leaning this way to avoid cases where the component recipes might have bbappends in place already ?



Looking for the proper Yocto way…



Thanks,

Steve
Re: bbappend usage

Robert P. J. Day
 

On Mon, 25 Oct 2021, Monsees, Steven C (US) via lists.yoctoproject.org wrote:

If I am building an image “image-ABC”, and it is composed of a
number recipes, and for some of these recipes I may NOT want to
install their final components within my image…

Which is the best place to modify the build with bbappend ?

Would I modify a recipe’s do_install (do_install_append-recipe_xyz)
?, or would I modify the image recipe (do_install_append-image_ABC)
I am leaning this way to avoid cases where the component recipes
might have bbappends in place already ?
i would think start with defining a minimal image, then define other
images based on that one which add more recipes. this has nothing to
do with redefining the recipes, it just means defining more than one
image.

rday
bbappend usage

Monsees, Steven C (US)
 

 

Hello:

 

If I am building an image “image-ABC”, and it is composed of a number recipes, and for some of these recipes I may NOT want to install their final components within my image…

 

Which is the best place to modify the build with bbappend ?

 

Would I modify a recipe’s do_install (do_install_append-recipe_xyz) ?, or would I modify the image recipe (do_install_append-image_ABC) I am leaning this way to avoid cases where the component recipes might have bbappends in place already ?

 

Looking for the proper Yocto way…

 

Thanks,

Steve

 

 
How to iherit class based on a conditional variable? #sysvinit #systemd

Bel Hadj Salem Talel <bhstalel@...>
 

Hello,

I have a recipe that installs a simple bash script to run on startup.
As you all know, there is systemd and sysvinit.
I need to add support for both init managers.

I can do :
SRC_URI_append = " ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'file://script.service', 'file://script.sh', d)}"

and I can do the same in all the tasks.

The problem is, that I need to inherit either systemd or update-rc.d

Is it possible to inherit them all, or how can I inherit something conditionally ?

Thanks,
Talel
Re: dunfell: pkgconfig-native build fails in existing Yocto BSP

Richard Purdie
 

On Mon, 2021-10-25 at 06:50 +0000, Matthias Klein wrote:
Hello,

our dunfell based yocto no longer builds in the pkgconfig-native section. I tried it in an Ubuntu 18.04 and Debian 10 Docker container.
The build always aborts as follows:

checking thread related cflags... -D_REENTRANT
checking for pthread_create/pthread_join... no
checking for pthread_create/pthread_join in -lpthread... no
checking for pthread_create/pthread_join in -lpthread32... no
checking for pthread_create/pthread_join in -lpthreads... no
checking for pthread_create/pthread_join in -lthread... no
configure: error: I can't find the libraries for the thread implementation
posix. Please choose another thread implementation or
provide information on your thread implementation.
configure: error: ../../git/glib/configure failed for glib
NOTE: The following config.log files may provide further information.
NOTE: /work/yocto-optimeas/build/tmp/work/x86_64-linux/pkgconfig-native/0.29.2+gitAUTOINC+edf8e6f0ea-r0/build/glib/config.log /work/yocto-optimeas/build/tmp/work/x86_64-linux/pkgconfig-native/0.29.2+gitAUTOINC+edf8e6f0ea-r0/build/config.log
ERROR: configure failed
WARNING: /work/yocto-optimeas/build/tmp/work/x86_64-linux/pkgconfig-native/0.29.2+gitAUTOINC+edf8e6f0ea-r0/temp/run.do_configure.243679:1 exit 1 from 'exit 1'
ERROR: Execution of '/work/yocto-optimeas/build/tmp/work/x86_64-linux/pkgconfig-native/0.29.2+gitAUTOINC+edf8e6f0ea-r0/temp/run.do_configure.243679' failed with exit code 1
ERROR: Task (virtual:native:/work/yocto-optimeas/yocto/poky/meta/recipes-devtools/pkgconfig/pkgconfig_git.bb:do_configure) failed with exit code '1'
ERROR: ninja-native-1.10.0-r0 do_compile: Execution of '/work/yocto-optimeas/build/tmp/work/x86_64-linux/ninja-native/1.10.0-r0/temp/run.do_compile.319277' failed with exit code 1
ERROR: Logfile of failure stored in: /work/yocto-optimeas/build/tmp/work/x86_64-linux/ninja-native/1.10.0-r0/temp/log.do_compile.319277
Log data follows:
DEBUG: Executing shell function do_compile
ninja: fatal: posix_spawn: Operation not permitted
bootstrapping ninja...
wrote build.ninja.
bootstrap complete. rebuilding...
Traceback (most recent call last):
File "./configure.py", line 709, in <module>
subprocess.check_call(rebuild_args)
File "/usr/lib/python3.7/subprocess.py", line 347, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['./ninja']' returned non-zero exit status 1.
WARNING: /work/yocto-optimeas/build/tmp/work/x86_64-linux/ninja-native/1.10.0-r0/temp/run.do_compile.319277:1 exit 1 from 'python3 ./configure.py --bootstrap'
ERROR: Execution of '/work/yocto-optimeas/build/tmp/work/x86_64-linux/ninja-native/1.10.0-r0/temp/run.do_compile.319277' failed with exit code 1
ERROR: Task (virtual:native:/work/yocto-optimeas/yocto/poky/meta/recipes-devtools/ninja/ninja_1.10.0.bb:do_compile) failed with exit code '1'


I also tried using the commits from dunfell-next in the poky repo as a test. But then the build doesn't even start and I get the following error:

ERROR: ParseError at /work/yocto-optimeas/yocto/meta-openembedded/meta-oe/recipes-extended/libimobiledevice/libplist_2.1.0.bb:9: Could not inherit file classes/python3targetconfig.bbclass | ETA: --:--:--


Does anyone have any idea what is causing this? does anyone have the same behavior?
I just backported a uninative upgrade to dunfell which should address this
issue.

Cheers,

Richard
Re: dunfell: pkgconfig-native build fails in existing Yocto BSP

Ahmed Hossam
 

Hello,

We also have the same issue with similar in-docker builds, a workaround for the issue is mentioned here: https://bugzilla.yoctoproject.org/show_bug.cgi?id=14519 until the fix is backported to dunfell.

Best Regards,
Ahmed Hossam
Re: Build Ubuntu Distro #ubuntu #distro

Konrad Weihmann <kweihmann@...>
 

No there isn't - with the yocto project you can build your own distribution not mimic other already available distributions.

If you want to build Ubuntu you have to ask canonical.

On 25.10.21 09:41, keyurthumar0402@... wrote:
I want to build ubuntu distro using yocto.
Is there a way for that ?
Build Ubuntu Distro #ubuntu #distro

keyurthumar0402@...
 

I want to build ubuntu distro using yocto.

Is there a way for that ?
Re: How to enable graphics acceleration on qemux86-64?

Alexander Kanavin
 

On Sun, 24 Oct 2021 at 23:29, Manuel Wagesreither <ManWag@...> wrote:
Hi all,
hi Alexander,

I solved my problems. Things work fine now. Below I'm summing things up as documentation for myself and also others in case this pops up in someones search query.

Cheers :) you should also try this on bleeding edge master, it should work the same as hardknott, but if there are issues, you can make and send patches to fix them.

Alex
dunfell: pkgconfig-native build fails in existing Yocto BSP

Matthias Klein
 

Hello,

our dunfell based yocto no longer builds in the pkgconfig-native section. I tried it in an Ubuntu 18.04 and Debian 10 Docker container.
The build always aborts as follows:

checking thread related cflags... -D_REENTRANT
| checking for pthread_create/pthread_join... no
| checking for pthread_create/pthread_join in -lpthread... no
| checking for pthread_create/pthread_join in -lpthread32... no
| checking for pthread_create/pthread_join in -lpthreads... no
| checking for pthread_create/pthread_join in -lthread... no
| configure: error: I can't find the libraries for the thread implementation
| posix. Please choose another thread implementation or
| provide information on your thread implementation.
| configure: error: ../../git/glib/configure failed for glib
| NOTE: The following config.log files may provide further information.
| NOTE: /work/yocto-optimeas/build/tmp/work/x86_64-linux/pkgconfig-native/0.29.2+gitAUTOINC+edf8e6f0ea-r0/build/glib/config.log /work/yocto-optimeas/build/tmp/work/x86_64-linux/pkgconfig-native/0.29.2+gitAUTOINC+edf8e6f0ea-r0/build/config.log
| ERROR: configure failed
| WARNING: /work/yocto-optimeas/build/tmp/work/x86_64-linux/pkgconfig-native/0.29.2+gitAUTOINC+edf8e6f0ea-r0/temp/run.do_configure.243679:1 exit 1 from 'exit 1'
| ERROR: Execution of '/work/yocto-optimeas/build/tmp/work/x86_64-linux/pkgconfig-native/0.29.2+gitAUTOINC+edf8e6f0ea-r0/temp/run.do_configure.243679' failed with exit code 1
ERROR: Task (virtual:native:/work/yocto-optimeas/yocto/poky/meta/recipes-devtools/pkgconfig/pkgconfig_git.bb:do_configure) failed with exit code '1'
ERROR: ninja-native-1.10.0-r0 do_compile: Execution of '/work/yocto-optimeas/build/tmp/work/x86_64-linux/ninja-native/1.10.0-r0/temp/run.do_compile.319277' failed with exit code 1
ERROR: Logfile of failure stored in: /work/yocto-optimeas/build/tmp/work/x86_64-linux/ninja-native/1.10.0-r0/temp/log.do_compile.319277
Log data follows:
| DEBUG: Executing shell function do_compile
| ninja: fatal: posix_spawn: Operation not permitted
| bootstrapping ninja...
| wrote build.ninja.
| bootstrap complete. rebuilding...
| Traceback (most recent call last):
| File "./configure.py", line 709, in <module>
| subprocess.check_call(rebuild_args)
| File "/usr/lib/python3.7/subprocess.py", line 347, in check_call
| raise CalledProcessError(retcode, cmd)
| subprocess.CalledProcessError: Command '['./ninja']' returned non-zero exit status 1.
| WARNING: /work/yocto-optimeas/build/tmp/work/x86_64-linux/ninja-native/1.10.0-r0/temp/run.do_compile.319277:1 exit 1 from 'python3 ./configure.py --bootstrap'
| ERROR: Execution of '/work/yocto-optimeas/build/tmp/work/x86_64-linux/ninja-native/1.10.0-r0/temp/run.do_compile.319277' failed with exit code 1
ERROR: Task (virtual:native:/work/yocto-optimeas/yocto/poky/meta/recipes-devtools/ninja/ninja_1.10.0.bb:do_compile) failed with exit code '1'


I also tried using the commits from dunfell-next in the poky repo as a test. But then the build doesn't even start and I get the following error:

ERROR: ParseError at /work/yocto-optimeas/yocto/meta-openembedded/meta-oe/recipes-extended/libimobiledevice/libplist_2.1.0.bb:9: Could not inherit file classes/python3targetconfig.bbclass | ETA: --:--:--


Does anyone have any idea what is causing this? does anyone have the same behavior?

Many greetings,
Matthias
Re: How to enable graphics acceleration on qemux86-64?

Manuel Wagesreither
 

Hi all,
hi Alexander,

I solved my problems. Things work fine now. Below I'm summing things up as documentation for myself and also others in case this pops up in someones search query.

Am So, 17. Okt 2021, um 13:32, schrieb Alexander Kanavin:
On Sat, 16 Oct 2021 at 14:08, Manuel Wagesreither <ManWag@...> wrote:

Here are some updates:

Building core-image-weston on hardknott succeeded. Couldn't `runqmu kvm slirp sdl core-image-weston` first because I got an error message about 'dri.pc' being missing. Debian package search told me it's part of 'mesa-commond-dev', so I installed it on my host machine and indeed, that runqemu command above got working again. Not just that, now even OpenGL acceleration with `runqmu kvm slirp sdl gl core-image-weston` worked, altough I didn't change anything OpenGL-wise. core-image-weston feels really snappy now. Great!

I got curious and reverted back to dunfell to check if the now-installed dri.pc made a difference, but no, it didn't. `runqemu` with `sdl` started (like it did before), and with `sdl gl` it still said "OpenGL support is disabled".

You need to replicate the settings from oe-selftest (link provided previously). I think on dunfell it's not enabled out of the box, and needs to be configured explicitly.

You were are right. In hindsight, your initial post contained everything necessary. The 'PACKAGECONFIG_append_pn-<package-name>' variables tell everything necessary. I couldn't make sense of what I was reading at the beginning.

DUNFELL:
=========
Summing things up, here's what I need on Dunfell for `runqemu kvm slirp sdl gl`.

* DISTRO_FEATURES opengl
* 'weston-xwayland' in IMAGE_INSTALL.
* 'PACKAGECONFIG:append:pn-qemu-system-native = " sdl gtk+ virglrenderer glx"'. (Having opengl in DISTRO_FEATURES puts opengl in libsdl2-native PACKAGECONFIG automatically.)

It's interesting the gtk+ part was necessary even for `runqemu kvm slirp sdl gl`. Thought gtk+ and sdl are different solutions for the same problem. Without gtk+, it would fail with
```
qemu-system-x86_64: ../libepoxy-1.5.4/src/dispatch_common.c:863: epoxy_get_proc_address: Assertion `0 && "Couldn't find current GLX or EGL context.\n"'
```
Can't make sense of that and won't investigate any further.

HARDKNOTT:
============
Here's what I need on Hardknott:

As Alexander wrote, with Hardknott explicit configuration is no longer necessary if DISTRO_FEATURES has opengl. Think it's due to following patch: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=7561eb32a01f7990ad4a4606ac97ebe2a659e029

Hence I need:
* DISTRO_FEATURES opengl
* 'PACKAGECONFIG:append:pn-qemu-system-native = " sdl".
* 'weston-xwayland' in IMAGE_INSTALL.
* /etc/systemd/system/default.target is a symlink to multi-user.target and shadows /lib/systemd/system/default.target which is a symlink to graphical.target. Hence, one must start graphical.target manually.
* Need to adapt weston.service to start weston with --modules=xwayland.so.

Perhaps this helps anyone.

Thanks again for your help, Alexander.

Manuel
Re: [meta-qt4]

Paul Barker
 

On Sat, 23 Oct 2021, at 00:30, Khem Raj wrote:
Hi Jared

On 10/22/21 2:40 PM, jared_terry@... wrote:
How do I get meta-qt4 patches applied?  I tried to contact the
maintainer listed and the email comes back undeliverable.  I have the
needed patch but now way to deliver it.

Please see [1] usually sending to the right mailing list and CCing the
maintainers is the usual way to send patches

[1] https://git.yoctoproject.org/cgit/cgit.cgi/meta-qt4/tree/README
Cc'd Paul Eggleton's current email. Perhaps the readme file in meta-qt4 needs updating.

Thanks,

--
Paul Barker
https://pbarker.dev/
Re: rebuilding perf fails after cleanall

chuck kamas
 

Bruce,


I am running a 8 month old version of poky Dunfell, commit e32d854e. I can see the code in perf.bb where it copies over the kernel code to its directory, so I think that I have the patch you mentioned. I have been trying for the past few hours to reproduce the issue in the x86 poky build, and have not come up with the magic method.  I'll keep on trying to simplify the issue to be replaceable in the version I am using and the latest dunfell.


Chuck


On 10/22/21 10:57 AM, Bruce Ashfield wrote:
On Fri, Oct 22, 2021 at 1:23 PM chuck kamas via lists.yoctoproject.org
<chuckkamas=yahoo.com@...> wrote:

Hi all,


I am trying to model a new recipe off of perf.bb to compile the usbip
helper kernel code. I have been having issues with the
work-shared/../kernel-source directory being empty, so I went back to
the perf recipie and tried:

bitbake perf -c cleanall

bitbake perf


What release are you using ? We did have some issues with this in the
past, but they should all be accounted for now.

I can bitbake perf, bitbake -c cleanall perf; bitbake perf

perf makes a copy of the kernel-sharel tools directory (it didn't in
the past), so
it should be safe for any combinations like that.

Bruce


I get the same error about path does not exist and the work-shared
kernel-source directory being empty.


Is perf.bb only executable in the context of a global rebuild?


Chuck









--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

2681 - 2700 of 57789