Re: [yocto] Problem with YOCTO Dunfell and host Fedora 33

Hello Joel, Thank you for the tips. Really helpful, appreciated very much. I spent some time this morning investigating this issue, and to find the culprit. Here are my findings, which resulted in a cannelloni.bb recipe change (according to what you wrote). The fix submitted is in recipe: https

[yocto] [meta-zephyr][PATCH] qemu-x86: set new -machine value for QEMU

-machine type=pc-1.3 is deprecated with QEMU 5.1.0 Error: machine runqemu - ERROR - Failed to run qemu: qemu-system-i386: unsupported machine type Signed-off-by: Naveen Saini --- conf/machine/qemu-x86.conf | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/conf/machine/qemu-x86

[yocto] [meta-security][PATCH] tpm2-tss: fix usrmerge udev install path

Update ${base_prefix}/lib to ${nonarch_base_libdir} to fix a package QA issue when usrmerge is enabled in DISTRO_FEATURES. QA Issue: tpm2-tss package is not obeying usrmerge distro feature. /lib should be relocated to /usr. [usrmerge] Signed-off-by: Ricardo Salveti --- meta-tpm/recipes-tpm2/tpm

Re: [yocto] Statically linked libraries and license manifest

On Thu, May 20, 2021 at 9:18 AM Jasper Orschulko wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > OK, maybe I did not make the issue clear enough: > > I have a package A which statically links package B at compile time > (using DEPENDS). > As a result the package A is "tainted" wit

Re: [yocto] Statically linked libraries and license manifest

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OK, maybe I did not make the issue clear enough: I have a package A which statically links package B at compile time (using DEPENDS). As a result the package A is "tainted" with source code from package B. However, as package B is only in the DEPEND

Re: [yocto] Statically linked libraries and license manifest

On Thu, May 20, 2021 at 9:00 AM Jasper Orschulko wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Hi Khem, > > thanks for your reply. As far as I understand, the "proper" way is to > use dynamic linked libraries whenever possible? I have done some more > thinking on the matter, and

Re: [yocto] Statically linked libraries and license manifest

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Khem, thanks for your reply. As far as I understand, the "proper" way is to use dynamic linked libraries whenever possible? I have done some more thinking on the matter, and at least in our case the packages in question are empty (the base packag

[yocto] [yocto-autobuilder-helper][dunfell] config.json: Set XZ limits to more reasonable values on autobuilder

From: Richard Purdie The autobuilders have 128GB memory, we don't want them using 50% which is the default, 5% should be enough. Also limit the number of threads down from 48 to something reasonable. This may be partly causing some of our performance issues? Signed-off-by: Richard Purdie (cherr

Re: [yocto] Problem with YOCTO Dunfell and host Fedora 33

Hi Zoran, Your cannelloni recipe is set to autorev, meaning it's not locked to a commit. So when something changes upstream you have to manage it. Chances are Canelloni introduced a CMake change which is overwriting (opposed to appending) one or more variables required for cross compiling. Perha

[yocto] Problem with YOCTO Dunfell and host Fedora 33

Hello Yocto developers, I have few problems running the following self proprietary script from one of my public git repos: https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/yocto-setup.sh I recall that last time I used the script (I used then Fedora 31), the ./yocto setup dunfell worked

[yocto] [meta-zephyr][PATCH v2 0/4] Fix efi generation and add x86 MACHINE confs (cover letter)

(1) zephyr-kernel-src: fix efi generation failure for x86 boards With zephyr v2.5.0, EFI binary generation support has been added for x86 board (64-bit mode). To achieve this, an python tool[1] has been added to convert zephyr EFL file into an EFI appliable. But unfortunately at current this does

[yocto] [meta-zephyr][PATCH v2 4/4] acrn.conf: drop acrn machine configuration

zephyr can be build for 'acrn' with following configuration: MACHINE = "intel-x86-64" ZEPHYR_BOARD = "acrn" Signed-off-by: Naveen Saini --- conf/machine/acrn.conf | 9 - 1 file changed, 9 deletions(-) delete mode 100644 conf/machine/acrn.conf diff --git a/conf/machine/acrn.conf b/conf

[yocto] [meta-zephyr][PATCH v2 3/4] intel-x86-32.conf: add common MACHINE for x86 (32-bit) BOARDS

User need to specify board value to ZEPHYR_BOARD in local.conf ZEPHYR_BOARD = "minnowboard" By default it set to MinnowBoard Max 'minnowboard' Currently 32-bit supported boards: * up_squared_32 * minnowboard Ref: https://docs.zephyrproject.org/latest/boards/x86/index.html Signed-off-by: Naveen

[yocto] [meta-zephyr][PATCH v2 1/4] zephyr-kernel-src: fix efi generation failure for x86 boards

With zephyr v2.5.0, EFI binary support has been added for x86 board (64-bit mode). To achieve this, an python tool[1] has been added to convert zephyr ELF file into an EFI appliable. But currently this does not work with Yocto cross-compilation env. This patch fix this issue and allow to build ze

[yocto] [meta-zephyr][PATCH v2 2/4] intel-x86-64.conf: add common MACHINE for x86 (64-bit) BOARDS

User need to specify board value to ZEPHYR_BOARD in local.conf ZEPHYR_BOARD = "ehl_crb" By default it set to Elkhart Lake CRB 'ehl_crb' Currently 64-bit supported boards: * up_squared * ehl_crb_sbl * ehl_crb * acrn * acrn_ehl_crb Ref: https://docs.zephyrproject.org/latest/boards/x86/index.html

Re: [yocto] hostile freenode takeover

On 5/20/21 4:32 AM, Nicolas Dechesne wrote: > On Thu, May 20, 2021 at 10:16 AM Quentin Schulz < > quentin.sch...@streamunlimited.com> wrote: > >> Hi Khem, all, >> >> On Wed, May 19, 2021 at 10:09:12AM -0700, Khem Raj wrote: >>> On Wed, May 19, 2021 at 9:56 AM Nicolas Dechesne >>> wrote:

Re: [yocto] hostile freenode takeover

On 5/20/21 3:32 PM, Nicolas Dechesne wrote: On Thu, May 20, 2021 at 10:16 AM Quentin Schulz > wrote: Hi Khem, all, On Wed, May 19, 2021 at 10:09:12AM -0700, Khem Raj wrote: > On Wed, May 19, 2021 at 9:56 AM Nicolas Dechesne > mailt

Re: [yocto] [qa-build-notification] QA notification for completed autobuilder build (yocto-3.3.1.rc1)

Hello All, This is the full report for yocto-3.3.1.rc1: https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults === Summary No high milestone defects. No new issue found. Thanks, Sangeeta > -Original Message- > From: qa-build-n

Re: [yocto] hostile freenode takeover

On Thu, May 20, 2021 at 10:16 AM Quentin Schulz < quentin.sch...@streamunlimited.com> wrote: > Hi Khem, all, > > On Wed, May 19, 2021 at 10:09:12AM -0700, Khem Raj wrote: > > On Wed, May 19, 2021 at 9:56 AM Nicolas Dechesne > > wrote: > > > > > > > > > > > > On Wed, May 19, 2021 at 6:49 PM Jasper

Re: [yocto] hostile freenode takeover

Hi Khem, all, On Wed, May 19, 2021 at 10:09:12AM -0700, Khem Raj wrote: > On Wed, May 19, 2021 at 9:56 AM Nicolas Dechesne > wrote: > > > > > > > > On Wed, May 19, 2021 at 6:49 PM Jasper Orschulko > > wrote: > >> > >> -BEGIN PGP SIGNED MESSAGE- > >> Hash: SHA256 > >> > >> Dear all, > >>

Re: [yocto] [meta-zephyr][PATCH] qemuzephyrrunner.py: use existing qemu conf file

Hi Jon, > -Original Message- > From: yocto@lists.yoctoproject.org On > Behalf Of Jon Mason > Sent: Tuesday, May 18, 2021 11:10 PM > To: yocto@lists.yoctoproject.org > Subject: [yocto] [meta-zephyr][PATCH] qemuzephyrrunner.py: use existing > qemu conf file > > Read the generated QEMU conf

[yocto] [meta-dpdk][PATCH] dpdk: fix build with GCC 11

From: Mingli Yu Fixes: | In function 'memset', | inlined from 'test_table_stub' at test_table_tables.c:151:4: | /buildarea/tmp/work/intel_x86_64-wrs-linux/dpdk/19.11.5-r0/recipe-sysroot/usr/include/bits/string_fortified.h:59:10: error: '__builtin_memset' offset [0, 31] is out of the boun