[yocto-announce] [ANNOUNCEMENT] Milestone 1 for Yocto Project 3.1 (yocto-3.1_M1) now available

Hello, We are pleased to announce the first milestone release for Yocto Project 3.1 (yocto-3.1_M1) is now available for download. Download: http://downloads.yoctoproject.org/releases/yocto/milestones/yocto-3.1_M1 bitbake: 99d46107ccfcec576238d32cfe7903440857038d meta-gplv2:

[yocto] [ANNOUNCEMENT] Milestone 1 for Yocto Project 3.1 (yocto-3.1_M1) now available

Hello, We are pleased to announce the first milestone release for Yocto Project 3.1 (yocto-3.1_M1) is now available for download. Download: http://downloads.yoctoproject.org/releases/yocto/milestones/yocto-3.1_M1 bitbake: 99d46107ccfcec576238d32cfe7903440857038d meta-gplv2:

Re: [yocto] Raspberry pi 4 recipe and layer issues.

Hi All, This is the error, that I was getting with meta-yosys-tools/recipes-yosys/yosys/yosys_0.1.bb,found at github.com/develone. The strip command fails, both on raspberrypi4-64 target and during the "bitbake yosys" build.During the do_install which returns an error.strip: Unable to recognise

Re: [yocto] apparmor setup #yocto

On 12/19/19 8:36 AM, hu.schlie...@codewrights.de wrote: > Hi, > > i'm new here and not really shure this is the right place for this issue. > First you need to enable the distro feature DISTRO_FEATURES_append = " apparmor" otherwise the kernel fragments wont be included > I try to get apparmor

[yocto] [layerindex-web][PATCH] requirements.txt: bump Django version to fix CVE-2019-19844

Fixes a vulnerability in the password reset process due to insufficiently stringent validation of unicode email addresses. https://www.djangoproject.com/weblog/2019/dec/18/security-releases/ https://nvd.nist.gov/vuln/detail/CVE-2019-19844 (The existing version specification would have selected

Re: [yocto] [meta-selinux][PATCH 18/19] setools: upgrade 4.1.1 -> 4.2.2

Hi Yi, I've merged the rest of this series, but this one fails to apply. It looks like your tree didn't contain: commit 5fd3c5b71edb99659aeb5cb5903088d84517382e (relabel, master) Author: Christophe PRIOUZEAU Date: Tue Nov 5 14:47:09 2019 + autorelabel: only selinux-autorelabel need

Re: [yocto] Skipping network-required recipes automatically?

On Thu, 2019-12-19 at 10:03 -0500, Joel A Cohen wrote: > Hi all, > > My layer has a bunch of "development" recipes that contain something > like: > > PV = "1.1.2+git${SRCPV}" > SRCREV = "${AUTOREV}" > DEFAULT_PREFERENCE = "-1" > > > In these cases, my recipes have a "known good" version that

[yocto] apparmor setup #yocto

Hi, i'm new here and not really shure this is the right place for this issue. I try to get apparmor working using yocto. I tried using thud and zeus with the same result on apparmor_status: apparmor module is not loaded Checking the kernel flags manually with bitbake -c menuconfig

Re: [yocto] variable and task/function timing

As a user, I much prefer having one MESON_BUILD_TYPE variable that I can modify using the pn-operator, even if the acceptable values are a little less pretty. The alternative is a variable that I have to guess that name of and what valid values are per-recipe. Sure it's just MESA_BUILD_TYPE now,

[yocto] Skipping network-required recipes automatically?

Hi all, My layer has a bunch of "development" recipes that contain something like: PV = "1.1.2+git${SRCPV}" SRCREV = "${AUTOREV}" DEFAULT_PREFERENCE = "-1" In these cases, my recipes have a "known good" version that has a specific known-good version number (recipe_1.1.2.bb), and then the

Re: [yocto] mc fails to start with readonly rootfs

On Thu, Dec 19, 2019 at 2:04 PM Marek Belisko via Lists.Yoctoproject.Org wrote: > > Hi, > > when enable readonly rootfs mc fails to start because cannot write to > directory: /home/root/.config/mc > > I've created volatile-bindd to this directory (to be able to write > something) and extend mc

[yocto] mc fails to start with readonly rootfs

Hi, when enable readonly rootfs mc fails to start because cannot write to directory: /home/root/.config/mc I've created volatile-bindd to this directory (to be able to write something) and extend mc using below bbappend: do_install_append () { install -d ${D}/home/root/.config/mc }

Re: [yocto] SSTATE_MIRRORS with ssh/sftp fetchers #yocto

On 19/12/2019 11:16, Richard Purdie wrote: Do you have any idea on how to use these fetchers (or other SSH keys- based secure fetcher) to share sstate cache ? I think this is a "not implemented" problem. If you look at bitbake/lib/bb/fetch2/ssh.py or sftp.py, they don't have a checkstatus()

Re: [yocto] SSTATE_MIRRORS with ssh/sftp fetchers #yocto

On Thu, 2019-12-19 at 02:37 -0800, angeal1...@gmail.com wrote: > Hi everyone, > > Recently, I tried to use the SSTATE_MIRRORS variable to get back > sstate cache from a build machine shared amongst developers. > When I tried with the simple FILE fetcher, it worked great and > resumed the work

Re: [yocto] QA Cycle report for build (yocto-3.1_M1.rc8)

On Wed, 2019-12-18 at 07:38 -0800, akuster808 wrote: > > On 12/18/19 2:46 AM, Richard Purdie wrote: > > On Wed, 2019-12-18 at 03:32 +, Jain, Sangeeta wrote: > > > Hello all, > > > > > > This is the full report for 3.1_M1.rc8: > > >

[yocto] SSTATE_MIRRORS with ssh/sftp fetchers #yocto

Hi everyone, Recently, I tried to use the SSTATE_MIRRORS variable to get back sstate cache from a build machine shared amongst developers. When I tried with the simple FILE fetcher, it worked great and resumed the work where the build machine stopped. But when I tried to replace it with SSH

[linux-yocto][yocto-kernel-cache yocto-5.0 yocto-5.2 master][PATCH] qemuarma15: Enable high memory to support more physical memory

From: He Zhe Signed-off-by: He Zhe --- bsp/qemuarma15/qemuarma15.cfg | 1 + 1 file changed, 1 insertion(+) diff --git a/bsp/qemuarma15/qemuarma15.cfg b/bsp/qemuarma15/qemuarma15.cfg index 3bc219a..c7bb50a 100644 --- a/bsp/qemuarma15/qemuarma15.cfg +++ b/bsp/qemuarma15/qemuarma15.cfg @@ -30,3