Date   

[meta-security][PATCH] smack: add runtime dependency on python3-core

Martin Jansa
 

* fixes:
ERROR: QA Issue: /usr/share/smack/smack_rules_gen contained in package smack requires /usr/bin/python3, but no providers found in RDEPENDS_smack? [file-rdeps]

Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
---
recipes-mac/smack/smack_1.3.1.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-mac/smack/smack_1.3.1.bb b/recipes-mac/smack/smack_1.3.1.bb
index 246562a..f32d91b 100644
--- a/recipes-mac/smack/smack_1.3.1.bb
+++ b/recipes-mac/smack/smack_1.3.1.bb
@@ -48,7 +48,7 @@ INITSCRIPT_PARAMS = "start 16 2 3 4 5 . stop 35 0 1 6 ."
FILES_${PN} += "${sysconfdir}/init.d/smack"
FILES_${PN}-ptest += "generator"

-RDEPENDS_${PN} += "coreutils"
+RDEPENDS_${PN} += "coreutils python3-core"
RDEPENDS_${PN}-ptest += "make bash bc"

BBCLASSEXTEND = "native"
--
2.17.1


Re: Trouble using initramfs

Moritz Porst <moritz.porst@...>
 


On 16.08.19 01:17, Mittal, Anuj wrote:
On Thu, 2019-08-15 at 19:12 -0300, Antonio Teixeira wrote:
Hello.

I've been having trouble with loading initramfs on boot when the
initramfs is bundled with the kernel image.
I've been using the following options in local.conf:
INITRAMFS_IMAGE = "core-image-minimal-initramfs"
INITRAMFS_IMAGE_BUNDLE = "1"

I'm using the linux-intel kernel from the meta-intel layer, however,
when booting, the kernel simply doesn't load the initramfs.
When I build a bundled kernel image I have a normal bzImage (~10mb) and a bzImage-initramfs(~30mb) in my build directory. Check the kernel image on your device, for me always the unbundled one gets deployed with the image, so I copy the bundled image via "scp. You may have to increase size of the boot partition in case you use an additional boot partition. In wic you can use the --size <size in mb> command.

If I set INITRAMFS_IMAGE_BUNDLE to "0", copy the generated initramfs
image to the boot partition, and then point grub to the external
initramfs.cpio.gz image using the initrd option in the boot entry
config, the kernel loads it fine and everything works.
Which branch are you using? Can you try the latest master with wic?
There was a fix to wic to allow copying the kernel image with bundled
initramfs to boot partition instead of the one without when
INITRAMFS_IMAGE_BUNDLE is 1.
I didn't ask the original question but have the same problem. I have the thud branch checked out, but I couldn't find that fix on google. Can you elaborate on this ?

Thanks,

Anuj
Best regards
Moritz


Re: LF Community Bridge Mentorship

Nicolas Dechesne
 

hi there.
just a reminder!
cheers

On Tue, Jul 30, 2019 at 4:46 PM Nicolas Dechesne
<nicolas.dechesne@linaro.org> wrote:

Dear all,

The Community Bridge platform was launched earlier this year by the
Linux Foundation. It’s a set of services available to LF projects to
help them build stronger ecosystems, and foster developers
relationship within their respective communities. See [1] and [2]. The
Yocto Project has joined the Community Bridge Funding and Mentorship
programs.

If you have any specific questions about these programs, please do not
hesitate to reach out to me.

Today, we would like to talk more about the mentorship program. We
have tried several initiatives in the past about interns and
mentorship, and we would like to do that again using the new LF
platform. A mentorship program for the Yocto Project is a good
opportunity for our overall community to reach out to new developers,
improve our developers diversity. It will help increase the pool of
available developers with appropriate skills about the Yocto Project
and Open Embedded technologies and as a consequence create a more
sustainable ecosystem around the Yocto Project. It also offers
existing senior developers the chance to become mentors, and share
their knowledge!

We would like to request feedback about how to best define the Yocto
Project Mentorship program.

The structure of the mentorship is flexible and we can adjust as
needed. Our initial thought is to set 12-week project, which is what
the Linux Kernel Mentorship program is using, see [4]. The overall
process involves:

1. Finding / defining work items for potential mentees.
2. Get appropriate funding for mentees’ stipends
3. Recruit mentors within our community
4. Review and select mentees’ applications

There has already been some work on the potential work items in the
form of the newcomer bugs, some of which could be turned into work
suitable for a mentorship programme.

=== Call for ACTION ===

* We need your help for any of the items above, and especially #1 to
get started. Whether you are a long time contributor to the project or
you recently joined our mailing list, your feedback will be greatly
appreciated.
* If you are interested to participate as a mentor, please let me know!
* You don’t need to be a project expert to be a mentor, you need to
know how the project works and be willing to help guide someone
through their task.

There is no specific timeline set yet, it will most likely depend on
how much feedback we receive about this initiative, but most likely
the internships will have to be tied to the Yocto Project release
timeline.

If you have any questions or any suggestions, please reach out to me!
cheers,
Nico

[1] https://www.linuxfoundation.org/press-release/2019/03/the-linux-foundation-launches-new-communitybridge-platform-to-help-sustain-open-source-communities/
[2] https://communitybridge.org/
[3] https://people.communitybridge.org/
[4] https://wiki.linuxfoundation.org/lkmp


Re: Segmentation fault | bitbake machine-image.bb | core dumped

Jaymin Dabhi
 

Hi Randy,

Thanks for your information regarding Yocto Jethro branch.

Yes, this core dumped issue is reproducible.
When I add python3-pip package in local.conf file and build complete image, this core dumped is happening.

Randy, it would be much helpful if you explain me how to adjust core file limits using ulimit, and how get the backtrace?

I have added python3-pip package in local.conf file, this is the one change only I did in local.conf.
Yes, I am able to generate the image successfully after reverting this one change.

Please let me know if more information require.

On 15-08-2019 07:30 AM, Randy MacLeod wrote:
On 8/12/19 10:42 AM, jaymin.dabhi@vivaldi.net wrote:
Hello All,
Facing segmentation fault (core dumped) while doing bitbake.
I am using Yocto Jethro branch.
Jethro isn't officially supported by the Yocto Project.
The support cycle is ~ 1 year.
https://wiki.yoctoproject.org/wiki/Releases
Can you reproduce the issue on master or a newer supported branch?
If so you could file a bug in:
https://wiki.yoctoproject.org/wiki/Releases
Also, see below for some tips.

When I added python3-pip recipe (in local.conf) and started building image, segmentation fault occurred.
Although, I am able to bitbake python3-pip individually (i.e. bitbake python3-pip).
As per log my assumption is, core dumped is occurring at make_ext4fs execution.
Following are the error logs:
ERROR: Function failed: do_makesystem (log file is located at poky/build/tmp-glibc/work/apq8053-oe-linux/machine-image/1.0-r0/temp/log.do_makesystem.15059) ERROR: Logfile of failure stored in: poky/build/tmp-glibc/work/apq8053-oe-linux/machine-image/1.0-r0/temp/log.do_makesystem.15059 Log data follows:
| DEBUG: Executing shell function do_makesystem
| poky/build/tmp-glibc/work/apq8053-oe-linux/machine-image/1.0-r0/temp/run.do_makesystem.15059: line 105: 15073 Segmentation fault      (core dumped) make_ext4fs -J -b 1024 -s -a / -S
Odd, I've never see that happen before.
Is it reproducible?
Can you adjust the core file limits using 'ulimit',
generate a core file and get a backtrace?

poky/build/tmp-glibc/work/apq8053-oe-linux/machine-image/1.0-r0/rootfs/etc/selinux/mls/contexts/files/file_contexts -l 768000000 poky/build/tmp-glibc/deploy/images/apq8053-perf/apq8053-sysfs.ext4 poky/build/tmp-glibc/work/apq8053-oe-linux/machine-image/1.0-r0/rootfs
| WARNING: poky/build/tmp-glibc/work/apq8053-oe-linux/machine-image/1.0-r0/temp/run.do_makesystem.15059:1 exit 139 from
|   make_ext4fs -J -b 1024 -s -a / -S poky/build/tmp-glibc/work/apq8053-oe-linux/machine-image/1.0-r0/rootfs/etc/selinux/mls/contexts/files/file_contexts -l 768000000 poky/build/tmp-glibc/deploy/images/apq8053-perf/apq8053-sysfs.ext4 poky/build/tmp-glibc/work/apq8053-oe-linux/machine-image/1.0-r0/rootfs
| ERROR: Function failed: do_makesystem (log file is located at poky/build/tmp-glibc/work/apq8053-oe-linux/machine-image/1.0-r0/temp/log.do_makesystem.15059) ERROR: Task 11 ( poky/meta-qti-bsp/recipes-products/images/machine-image.bb, do_makesystem) failed with exit code '1'
Whether python3-pip recipe is creating an issue or something else? (attached the python3-pip recipe file)
What did you change in your conf/local.conf file?
If you revert that change, then you are able to generate the image
again?
../Randy

Please let me know.
Any suggestions are welcome.
Regards,
Jaymin
--
# Randy MacLeod
# Wind River Linux


[meta-security][PATCH] openscap: fix scap-security-guide build error

Yi Zhao
 

It would fail to build scap-security-guide when use openscap-native
sstate cache.

Steps to reproduce:
Create a new build project:
$ bitbake openscap-native
$ bitbake openscap-native -c clean
$ bitbake scap-security-guide

Error message:
OpenSCAP Error: Schema file 'xccdf/1.1/xccdf-schema.xsd' not found in path
'/buildarea/build/tmp/work-shared/openscap/oscap-build-artifacts/usr/share/openscap/schemas'
when trying to validate
'/buildarea/build/tmp/work/core2-64-poky-linux/scap-security-guide/0.1.44+gitAUTOINC+5fdfdcb2e9-r0/git/build/chromium/xccdf-unlinked-resolved.xml'
[/buildarea/build/tmp/work/x86_64-linux/openscap-native/1.3.1+gitAUTOINC+4bbdb46ff6-r0/git/src/source/validate.c:104]
Invalid XCCDF Checklist (1.1) content in
/buildarea/build/tmp/work/core2-64-poky-linux/scap-security-guide/0.1.44+gitAUTOINC+5fdfdcb2e9-r0/git/build/chromium/xccdf-unlinked-resolved.xml.
[/buildarea/build/tmp/work/x86_64-linux/openscap-native/1.3.1+gitAUTOINC+4bbdb46ff6-r0/git/src/source/oscap_source.c:346]
chromium/CMakeFiles/generate-internal-chromium-xccdf-unlinked-resolved.xml.dir/build.make:63: recipe for target 'chromium/xccdf-unlinked-resolved.xml' failed

When using sstate cache, the openscap-native doesn't install the
artifacts to work-shared/openscap/oscap-build-artifacts when prepare
recipe sysroot for scap-security-guide.

Set do_install[nostamp] to 1 to ensure the openscap-native artifacts
are installed to work-shared/openscap/oscap-build-artifacts even if
using sstate cache.

Signed-off-by: Yi Zhao <yi.zhao@windriver.com>
---
meta-security-compliance/recipes-openscap/openscap/openscap.inc | 1 +
1 file changed, 1 insertion(+)

diff --git a/meta-security-compliance/recipes-openscap/openscap/openscap.inc b/meta-security-compliance/recipes-openscap/openscap/openscap.inc
index 53309e8..07d9700 100644
--- a/meta-security-compliance/recipes-openscap/openscap/openscap.inc
+++ b/meta-security-compliance/recipes-openscap/openscap/openscap.inc
@@ -41,6 +41,7 @@ do_configure_append_class-native () {
}

do_clean[cleandirs] += "${STAGING_OSCAP_BUILDDIR}"
+do_install[nostamp] = "1"

do_install_append_class-native () {
oscapdir=${STAGING_OSCAP_BUILDDIR}/${datadir_native}
--
2.7.4


Re: Trouble using initramfs

Anuj Mittal
 

On Thu, 2019-08-15 at 19:12 -0300, Antonio Teixeira wrote:
Hello.

I've been having trouble with loading initramfs on boot when the
initramfs is bundled with the kernel image.
I've been using the following options in local.conf:
INITRAMFS_IMAGE = "core-image-minimal-initramfs"
INITRAMFS_IMAGE_BUNDLE = "1"

I'm using the linux-intel kernel from the meta-intel layer, however,
when booting, the kernel simply doesn't load the initramfs.

If I set INITRAMFS_IMAGE_BUNDLE to "0", copy the generated initramfs
image to the boot partition, and then point grub to the external
initramfs.cpio.gz image using the initrd option in the boot entry
config, the kernel loads it fine and everything works.
Which branch are you using? Can you try the latest master with wic?
There was a fix to wic to allow copying the kernel image with bundled
initramfs to boot partition instead of the one without when
INITRAMFS_IMAGE_BUNDLE is 1.

Thanks,

Anuj


Trouble using initramfs

Antonio Teixeira
 

Hello.

I've been having trouble with loading initramfs on boot when the initramfs is bundled with the kernel image.
I've been using the following options in local.conf:
INITRAMFS_IMAGE = "core-image-minimal-initramfs"
INITRAMFS_IMAGE_BUNDLE = "1"

I'm using the linux-intel kernel from the meta-intel layer, however, when booting, the kernel simply doesn't load the initramfs.

If I set INITRAMFS_IMAGE_BUNDLE to "0", copy the generated initramfs image to the boot partition, and then point grub to the external initramfs.cpio.gz image using the initrd option in the boot entry config, the kernel loads it fine and everything works.

I'm booting in a x86_64 computer (not an embedded device) using these instructions:

https://wiki.yoctoproject.org/wiki/How_do_I#Q:_How_do_I_put_Yocto_on_a_hard_drive.3F

Am I missing something? Do I need to set some other kernel parameters? Is there any way I can check if the resulting kernel image indeed has an initramfs bundled with it?


Re: please help on compiling my kernel

Randy MacLeod
 

On 8/13/19 5:59 AM, Tg, Harish wrote:
Hi Guys,
                 I am facing a strange issue which was working/compiling earlier. I did a clean and retried. Now I am getting this error with the command “bitbake -c compile -f linux-ti-staging”:
WARNING: linux-ti-staging-4.4.45+gitAUTOINC+89944627d5-r1a.arago5 do_fetch: Failed to fetch URL git://git.omapzoom.org/kernel/omap;protocol=git;branch=p-ti-lsk-linux-4.4.y-next, attempting MIRRORS if available
ERROR: linux-ti-staging-4.4.45+gitAUTOINC+89944627d5-r1a.arago5 do_fetch: Fetcher failure: Fetch command failed with exit code 128, output:
fatal: Not a git repository (or any parent up to mount point /mnt/yocto)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
ERROR: linux-ti-staging-4.4.45+gitAUTOINC+89944627d5-r1a.arago5 do_fetch: Function failed: Fetcher failure for URL: 'git://git.omapzoom.org/kernel/omap;protocol=git;branch=p-ti-lsk-linux-4.4.y-next'. Unable to fetch URL from any source.
ERROR: Logfile of failure stored in: /mnt/yocto/yocto_repo/build/arago-tmp-external-linaro-toolchain/work/delphi_jlr_isp_proto-linux-gnueabi/linux-ti-staging/4.4.45+gitAUTOINC+89944627d5-r1a.arago5/temp/log.do_fetch.102021
ERROR: Task 2 (/mnt/yocto/yocto_repo/sources/meta-ti/recipes-kernel/linux/linux-ti-staging_4.4.bb, do_fetch) failed with exit code '1'
Kindly help with this. Thanks.

Likely the server was just down for a while.

Both the web site:
http://git.omapzoom.org/?p=kernel/omap.git;a=summary
and:
$ git clone -b p-ti-lsk-linux-4.4.y-next git://git.omapzoom.org/kernel/omap.git omap.git
Cloning into 'omap.git'...
remote: Counting objects: 6410683, done.
remote: Compressing objects: 100% (1028266/1028266), done.
Receiving objects: 100% (6410683/6410683), 1.54 GiB | 2.62 MiB/s, done.
remote: Total 6410683 (delta 5337468), reused 6409647 (delta 5336439)
Resolving deltas: 100% (5337468/5337468), done.
Checking out files: 100% (52679/52679), done.
rmacleod@ala-lpggp2$echo $?
0

work for me now.

Do you have a firewall blocking your internet access?
I don't have this problems thankfully but if you do, it looks
like there are some good recommendations here:

https://stackoverflow.com/questions/4891527/git-protocol-blocked-by-company-how-can-i-get-around-that

Of course you should abide by your corporate download policies.
Oh and some vendors provide full copies of all source when you install
their Yocto-based products.

../Randy

Regards,
Harish.

--
# Randy MacLeod
# Wind River Linux


Re: wic create - bad ownership of directories inside image

Randy MacLeod
 

On 8/12/19 5:11 AM, Behnke, Jochen wrote:
Hello,
I am using poky 2.6.1 (thud) and create images using the wic utility.
Recently I noticed that all directories contained in the created image are owned by UID 1000 and not by root. The files inside the image however are owned by root.
The UID 1000 refers to my unprivileged user on the host system.
Here is the command I use to create the image
“wic create mkefidisk –e core-image-minimal”
The images created by bitbake directly (.tar.bz2, .hddimg) are correct so this seems to be a wic related problem.
Does anybody have a solution for this?
Hi Jochen,

No and I've never seen this particular extreme symptom.

There is a known, generally rare bug:
Bug 12434 - pseudo: Incorrect UID/GID in packaged files
https://bugzilla.yoctoproject.org/show_bug.cgi?id=12434
but that usually shows up when building.

You could check you build logs for the generic stings from:

glibc-locale-2.26: glibc-locale:
/glibc-binary-localedata-en-gb/usr/lib/locale/en_GB/LC_MEASUREMENT
is owned by uid 3004, which is the same as the user running bitbake.
This may be due to host contamination [host-user-contaminated]


Is your issue 100% reproducible?

../Randy


Many thanks in advance, any hint is appreciated.
Regards
Jochen
<gfidisc.SID=010500000000000515000000993c4a7a4675257c8b2de024250d0000>
__________________________________
*SCHMIDT Technology GmbH*
Feldbergstrasse 1
78112 St. Georgen/Germany
Telefon +49 (0) 77 24 / 89 90
Fax +49 (0) 77 24 / 89 91 01
info@schmidttechnology.de <mailto:info@schmidttechnology.de>
http://www.schmidttechnology.de
USt-Id Nr. DE 811725105 · Registergericht Freiburg HRB 600 755
Geschaeftsfuehrung: Oliver Schmidt, Stephan Schmidt
<gfidisc.SID=010500000000000515000000993c4a7a4675257c8b2de024250d0000>

--
# Randy MacLeod
# Wind River Linux


Re: Segmentation fault | bitbake machine-image.bb | core dumped

Randy MacLeod
 

On 8/12/19 10:42 AM, jaymin.dabhi@vivaldi.net wrote:
Hello All,
Facing segmentation fault (core dumped) while doing bitbake.
I am using Yocto Jethro branch.
Jethro isn't officially supported by the Yocto Project.
The support cycle is ~ 1 year.

https://wiki.yoctoproject.org/wiki/Releases

Can you reproduce the issue on master or a newer supported branch?
If so you could file a bug in:
https://wiki.yoctoproject.org/wiki/Releases

Also, see below for some tips.

When I added python3-pip recipe (in local.conf) and started building image, segmentation fault occurred.
Although, I am able to bitbake python3-pip individually (i.e. bitbake python3-pip).
As per log my assumption is, core dumped is occurring at make_ext4fs execution.
Following are the error logs:
ERROR: Function failed: do_makesystem (log file is located at poky/build/tmp-glibc/work/apq8053-oe-linux/machine-image/1.0-r0/temp/log.do_makesystem.15059) ERROR: Logfile of failure stored in: poky/build/tmp-glibc/work/apq8053-oe-linux/machine-image/1.0-r0/temp/log.do_makesystem.15059 Log data follows:
| DEBUG: Executing shell function do_makesystem
| poky/build/tmp-glibc/work/apq8053-oe-linux/machine-image/1.0-r0/temp/run.do_makesystem.15059: line 105: 15073 Segmentation fault      (core dumped) make_ext4fs -J -b 1024 -s -a / -S
Odd, I've never see that happen before.
Is it reproducible?

Can you adjust the core file limits using 'ulimit',
generate a core file and get a backtrace?

poky/build/tmp-glibc/work/apq8053-oe-linux/machine-image/1.0-r0/rootfs/etc/selinux/mls/contexts/files/file_contexts -l 768000000 poky/build/tmp-glibc/deploy/images/apq8053-perf/apq8053-sysfs.ext4 poky/build/tmp-glibc/work/apq8053-oe-linux/machine-image/1.0-r0/rootfs
| WARNING: poky/build/tmp-glibc/work/apq8053-oe-linux/machine-image/1.0-r0/temp/run.do_makesystem.15059:1 exit 139 from
|   make_ext4fs -J -b 1024 -s -a / -S poky/build/tmp-glibc/work/apq8053-oe-linux/machine-image/1.0-r0/rootfs/etc/selinux/mls/contexts/files/file_contexts -l 768000000 poky/build/tmp-glibc/deploy/images/apq8053-perf/apq8053-sysfs.ext4 poky/build/tmp-glibc/work/apq8053-oe-linux/machine-image/1.0-r0/rootfs
| ERROR: Function failed: do_makesystem (log file is located at poky/build/tmp-glibc/work/apq8053-oe-linux/machine-image/1.0-r0/temp/log.do_makesystem.15059) ERROR: Task 11 ( poky/meta-qti-bsp/recipes-products/images/machine-image.bb, do_makesystem) failed with exit code '1'
Whether python3-pip recipe is creating an issue or something else? (attached the python3-pip recipe file)
What did you change in your conf/local.conf file?
If you revert that change, then you are able to generate the image
again?

../Randy

Please let me know.
Any suggestions are welcome.
Regards,
Jaymin

--
# Randy MacLeod
# Wind River Linux


Re: Init stops working on second boot cycle

Randy MacLeod
 

On 8/13/19 6:21 AM, Andy Pont wrote:
I’ve got a strange issue and I don’t know whether it is a Yocto related issue, a kernel issue or something else completely…
I have an image that is built with thud (2.6.2) using meta-atmel for the SAMA5D2-Xplained reference board.  I deploy the resulting .wic file to an SD card and boot the reference board and all is OK.  I can log into the terminal, upload files, etc. and again all seems to be well.
If I press the reset button on the hardware platform, on the next boot cycle it always stops with the following being last messages being displayed:
Freeing unused kernel memory: 1024K
Run /sbin/init as init process
INIT: version 2.88 booting
The system hasn’t completely hung as the occasional kernel message appears but the user space init process (sysvinit) doesn’t seem to be
What sort of occasional kernel message and do they eventually stop?

working at all.  If I put the SD card into a Linux desktop machine the file system on it is still valid and the changes that I have made are still present.
Anyone got any ideas as to what is screwing it up?
No but here are some generic debugging tips.
In no particular order, have you tried:

1) setting kernel boot options such as:
init=/bin/bash

Does that reboot consistently when you press reset?

2) getting sysvinit to start an emergency shell?
https://manpages.debian.org/testing/sysvinit-core/init.8.en.html
I don't know how you'd do that for your board but is
should be possible.

3) single user mode:
https://wiki.gentoo.org/wiki/Sysvinit#Single_user_mode

4) Does the problem happen if you run 'shutdown -r now'
rather than pressing the reset button?

Good luck,

--
# Randy MacLeod
# Wind River Linux


Re: Bitbake local.conf variable been override by weak assignment

Rick Liu
 

oops~
After I purged build/tmp and build/cache,
it just works,
so it's probably just cache issue.

# $BRCM_NXT-RELEASE-216_BRANCH [2 operations]
# set /home/rl891036/scrach/DHELPDESK-3176/poky/build/conf/local.conf:60
# "SIT_int_nxt_v216.1.15.0"
# set? /home/rl891036/scrach/DHELPDESK-3176/poky/build/../meta-brcm/meta-datacenter/recipes-kernel/nxt-l2-drv/brcm-nxt-l2-drv_nxtrelease.bb:10
# "RICK"
# pre-expansion value:
# "SIT_int_nxt_v216.1.15.0"
BRCM_NXT-RELEASE-216_BRANCH="SIT_int_nxt_v216.1.15.0"

On Wed, Aug 14, 2019 at 1:18 PM Rick Liu <rick.liu@broadcom.com> wrote:

I have defined a global default value BRCM_NXT-RELEASE-216_BRANCH in local.conf,
and setup a weak assignment (?=) in my recipe,
but somehow the weak assignment override the local.conf global default value.
Does anyone have any idea?

build/conf/local.conf:
BRCM_NXT-RELEASE-216_BRANCH = "SIT_int_nxt_v216.1.15.0"
PREFERRED_VERSION_brcm-nxt-l2-drv = "nxtrelease%"

meta-brcm/meta-datacenter/recipes-kernel/nxt-l2-drv/brcm-nxt-l2drv_nxtrelese.bb:
BRCM_NXT-RELEASE-216_BRANCH ?= "RICK"

$ bitbake -e brcm-nxt-l2-drv
# $BRCM_NXT-RELEASE-216_BRANCH [2 operations]
# set /home/rl891036/scrach/DHELPDESK-3176/poky/build/conf/local.conf:60
# [_defaultval] "SIT_int_nxt_v216.1.15.0"
# set? /home/rl891036/scrach/DHELPDESK-3176/poky/build/../meta-brcm/meta-datacenter/recipes-kernel/nxt-l2-drv/brcm-nxt-l2-drv_nxtrelease.bb:10
# "RICK"
# pre-expansion value:
# "RICK"
BRCM_NXT-RELEASE-216_BRANCH="RICK"


Bitbake local.conf variable been override by weak assignment

Rick Liu
 

I have defined a global default value BRCM_NXT-RELEASE-216_BRANCH in local.conf,
and setup a weak assignment (?=) in my recipe,
but somehow the weak assignment override the local.conf global default value.
Does anyone have any idea?

build/conf/local.conf:
BRCM_NXT-RELEASE-216_BRANCH = "SIT_int_nxt_v216.1.15.0"
PREFERRED_VERSION_brcm-nxt-l2-drv = "nxtrelease%"

meta-brcm/meta-datacenter/recipes-kernel/nxt-l2-drv/brcm-nxt-l2drv_nxtrelese.bb:
BRCM_NXT-RELEASE-216_BRANCH ?= "RICK"

$ bitbake -e brcm-nxt-l2-drv
# $BRCM_NXT-RELEASE-216_BRANCH [2 operations]
# set /home/rl891036/scrach/DHELPDESK-3176/poky/build/conf/local.conf:60
# [_defaultval] "SIT_int_nxt_v216.1.15.0"
# set? /home/rl891036/scrach/DHELPDESK-3176/poky/build/../meta-brcm/meta-datacenter/recipes-kernel/nxt-l2-drv/brcm-nxt-l2-drv_nxtrelease.bb:10
# "RICK"
# pre-expansion value:
# "RICK"
BRCM_NXT-RELEASE-216_BRANCH="RICK"


Unable to build Yocto meta-freescale layer for NXP

Sayan Sinha <sayan.sinha@...>
 

Hello everyone,

  I was trying to build Yocto for my NXP. I tried building the Meta Freescale layer (meta-freescale - Layer containing NXP hardware support metadata). As mentioned in the Yocto Project Quick Build page, I added the Meta Freescale layer to bitbake using `bitbake-layers add-layer ../meta-freescale-2.2`. Unfortunately, when I run `bitbake meta-freescale-2.2`, I get an error message

```
ERROR: ParseError at ~/poky/meta/classes/image.bbclass:18: Could not inherit file classes/image_types_uboot.bbclass | ETA: 0:00:06

Summary: There were 3 WARNING messages shown.
Summary: There was 1 ERROR message shown, returning a non-zero exit code.
```
Any insights on this would be constructive. I would also like to mention that my final aim is to build Yocto (with RTOS support, preferably using Litmus RT) for NXP SBC-S32V234.

Thanks a lot in advance!


[meta-raspberrypi] Issues building bcm2835_bootfiles in Thud

Phillip Marks <pmarks@...>
 

We are building Thud for a raspberry-pi0+wifi and we've noticed that the recipe bcm2835_bootfiles under meta-raspberrypi/recipes-bsp/bootfiles is not pulling in the proprietary *.dtb modules from the firmware repository. This is causing linux-raspberrypi to fail as it tries to build those modules and fails on "no target found for bcm2708-rpi-0-w.dtb". How does bcm2835_bootfiles pull in the Broadcom firmware modules and where in build does it store them? We don't see them in tmp/work. 

- Phillip Marks


Re: [patchtest][PATCH V2] patchtest: fix linux-yocto version

Changqing Li
 

Hi, Richard

This patchset need to be merged.

patchtest: fix linux-yocto version

and patchtest: fix virtio-9p-pci is not a valid device


Thanks

On 6/13/19 5:16 PM, changqing.li@windriver.com wrote:
From: Changqing Li <changqing.li@windriver.com>

4.9 is not avaiable currently, so remove version from bbappend
and remove PREFERRED_VERSION.

Signed-off-by: Changqing Li <changqing.li@windriver.com>
---
.../linux/{linux-yocto_4.%.bbappend => linux-yocto_%.bbappend} | 0
scripts/create-guest-machine | 5 -----
2 files changed, 5 deletions(-)
rename meta-patchtest/recipes-kernel/linux/{linux-yocto_4.%.bbappend => linux-yocto_%.bbappend} (100%)

diff --git a/meta-patchtest/recipes-kernel/linux/linux-yocto_4.%.bbappend b/meta-patchtest/recipes-kernel/linux/linux-yocto_%.bbappend
similarity index 100%
rename from meta-patchtest/recipes-kernel/linux/linux-yocto_4.%.bbappend
rename to meta-patchtest/recipes-kernel/linux/linux-yocto_%.bbappend
diff --git a/scripts/create-guest-machine b/scripts/create-guest-machine
index 8dd6a2e..8381ef8 100755
--- a/scripts/create-guest-machine
+++ b/scripts/create-guest-machine
@@ -145,11 +145,6 @@ cat >> $POKY/build/conf/auto.conf << EOF
$PTSMARK
MACHINE = "$MACHINE"
-# The preferred kernel version in poky (4.10%, master) returns an error whilst
-# executing patchtest on guest. Changing the preferred version to 4.9% as it
-# is more suitable and does not present any errors.
-PREFERRED_VERSION_linux-yocto_qemux86-64 = "4.9%"
-
PACKAGE_CLASSES = "package_ipk"
IMAGE_FSTYPES = "ext4"
SSTATE_MIRRORS ?= "file://.* http://sstate.yoctoproject.org/dev/PATH"
--
BRs

Sandy(Li Changqing)


Re: [PATCH][thud] meta-yocto-bsp: Bump to the latest stable kernel for the BSPs

Armin Kuster
 



On 8/12/19 8:48 PM, Kevin Hao wrote:
On Fri, Apr 19, 2019 at 01:23:35PM +0800, Kevin Hao wrote:
In order to fix a systemtap bug [1] on arm board, we backport a kernel
patch from v5.0 kernel to v4.14 & v4.18 kernel, then need to bump the
kernel version to include this patch. Even this is only an arm specific
bug, we would like to bump the kernel version for the BSPs at the same
time. Boot test for all the boards.

[1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=13273
Hi Armin,

Could you help merge this patch to thud branch?
yes. It is now on my list.

Thanks,
Armin

Thanks,
Kevin

Signed-off-by: Kevin Hao <kexin.hao@...>
---
 .../recipes-kernel/linux/linux-yocto_4.14.bbappend   | 20 ++++++++++----------
 .../recipes-kernel/linux/linux-yocto_4.18.bbappend   | 20 ++++++++++----------
 2 files changed, 20 insertions(+), 20 deletions(-)

diff --git a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.14.bbappend b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.14.bbappend
index 502485a94b15..426757e48c9e 100644
--- a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.14.bbappend
+++ b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.14.bbappend
@@ -8,11 +8,11 @@ KMACHINE_genericx86 ?= "common-pc"
 KMACHINE_genericx86-64 ?= "common-pc-64"
 KMACHINE_beaglebone-yocto ?= "beaglebone"
 
-SRCREV_machine_genericx86    ?= "2c5caa7e84311f2a0097974a697ac1f59030530e"
-SRCREV_machine_genericx86-64 ?= "2c5caa7e84311f2a0097974a697ac1f59030530e"
-SRCREV_machine_edgerouter ?= "e06bfa18c727bd0e6e10cf26d9f161e4c791f52b"
-SRCREV_machine_beaglebone-yocto ?= "b8805de77dcf8f59d8368fee4921c146c1300a6a"
-SRCREV_machine_mpc8315e-rdb ?= "f88e87360b10f8fbd853a7d412982e6620f3f96d"
+SRCREV_machine_genericx86    ?= "5252513a39b4b3773debab1f77071d7c430ecb10"
+SRCREV_machine_genericx86-64 ?= "5252513a39b4b3773debab1f77071d7c430ecb10"
+SRCREV_machine_edgerouter ?= "d8fb40cd0e99325715c70aed6f361a8318097829"
+SRCREV_machine_beaglebone-yocto ?= "c67809688bd22cb4cb909bcf1a1045e6337c3229"
+SRCREV_machine_mpc8315e-rdb ?= "258ee8228e0a512c6dbe2a0dadcd9f030ba45964"
 
 COMPATIBLE_MACHINE_genericx86 = "genericx86"
 COMPATIBLE_MACHINE_genericx86-64 = "genericx86-64"
@@ -20,8 +20,8 @@ COMPATIBLE_MACHINE_edgerouter = "edgerouter"
 COMPATIBLE_MACHINE_beaglebone-yocto = "beaglebone-yocto"
 COMPATIBLE_MACHINE_mpc8315e-rdb = "mpc8315e-rdb"
 
-LINUX_VERSION_genericx86 = "4.14.76"
-LINUX_VERSION_genericx86-64 = "4.14.76"
-LINUX_VERSION_edgerouter = "4.14.71"
-LINUX_VERSION_beaglebone-yocto = "4.14.71"
-LINUX_VERSION_mpc8315e-rdb = "4.14.71"
+LINUX_VERSION_genericx86 = "4.14.98"
+LINUX_VERSION_genericx86-64 = "4.14.98"
+LINUX_VERSION_edgerouter = "4.14.98"
+LINUX_VERSION_beaglebone-yocto = "4.14.98"
+LINUX_VERSION_mpc8315e-rdb = "4.14.98"
diff --git a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.18.bbappend b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.18.bbappend
index 7f15843f3a90..11b35cc1c2f8 100644
--- a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.18.bbappend
+++ b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.18.bbappend
@@ -8,11 +8,11 @@ KMACHINE_genericx86 ?= "common-pc"
 KMACHINE_genericx86-64 ?= "common-pc-64"
 KMACHINE_beaglebone-yocto ?= "beaglebone"
 
-SRCREV_machine_genericx86    ?= "db2d813869a0501782469ecdb17e277a501c9f57"
-SRCREV_machine_genericx86-64 ?= "db2d813869a0501782469ecdb17e277a501c9f57"
-SRCREV_machine_edgerouter ?= "28e7781d57a59227bf1c08c7f3dbdfee16aa0dc2"
-SRCREV_machine_beaglebone-yocto ?= "28e7781d57a59227bf1c08c7f3dbdfee16aa0dc2"
-SRCREV_machine_mpc8315e-rdb ?= "99071a599d8650b069fb8135866fca203f375350"
+SRCREV_machine_genericx86    ?= "b24d9d2146d4ce4ef3ad7251b936f35c69dcf0c4"
+SRCREV_machine_genericx86-64 ?= "b24d9d2146d4ce4ef3ad7251b936f35c69dcf0c4"
+SRCREV_machine_edgerouter ?= "b24d9d2146d4ce4ef3ad7251b936f35c69dcf0c4"
+SRCREV_machine_beaglebone-yocto ?= "b24d9d2146d4ce4ef3ad7251b936f35c69dcf0c4"
+SRCREV_machine_mpc8315e-rdb ?= "0802dc980cbc8bdb156d6fe305e7b88e6b602634"
 
 COMPATIBLE_MACHINE_genericx86 = "genericx86"
 COMPATIBLE_MACHINE_genericx86-64 = "genericx86-64"
@@ -20,8 +20,8 @@ COMPATIBLE_MACHINE_edgerouter = "edgerouter"
 COMPATIBLE_MACHINE_beaglebone-yocto = "beaglebone-yocto"
 COMPATIBLE_MACHINE_mpc8315e-rdb = "mpc8315e-rdb"
 
-LINUX_VERSION_genericx86 = "4.18.22"
-LINUX_VERSION_genericx86-64 = "4.18.22"
-LINUX_VERSION_edgerouter = "4.18.25"
-LINUX_VERSION_beaglebone-yocto = "4.18.25"
-LINUX_VERSION_mpc8315e-rdb = "4.18.25"
+LINUX_VERSION_genericx86 = "4.18.35"
+LINUX_VERSION_genericx86-64 = "4.18.35"
+LINUX_VERSION_edgerouter = "4.18.35"
+LINUX_VERSION_beaglebone-yocto = "4.18.35"
+LINUX_VERSION_mpc8315e-rdb = "4.18.35"
-- 
2.14.4




[meta-security][PATCH 2/2] linux-yocto-dev: update to use kernel cache

Armin Kuster
 

Signed-off-by: Armin Kuster <akuster808@gmail.com>
---
recipes-kernel/linux/linux-yocto-dev.bbappend | 13 ++-----------
1 file changed, 2 insertions(+), 11 deletions(-)

diff --git a/recipes-kernel/linux/linux-yocto-dev.bbappend b/recipes-kernel/linux/linux-yocto-dev.bbappend
index 68b2b8b..239e30e 100644
--- a/recipes-kernel/linux/linux-yocto-dev.bbappend
+++ b/recipes-kernel/linux/linux-yocto-dev.bbappend
@@ -1,11 +1,2 @@
-FILESEXTRAPATHS_prepend := "${THISDIR}/linux-yocto-5.0:"
-
-SRC_URI += "\
- ${@bb.utils.contains('DISTRO_FEATURES', 'apparmor', ' file://apparmor.cfg', '', d)} \
- ${@bb.utils.contains('DISTRO_FEATURES', 'apparmor', ' file://apparmor_on_boot.cfg', '', d)} \
-"
-
-SRC_URI += "\
- ${@bb.utils.contains('DISTRO_FEATURES', 'smack', ' file://smack.cfg', '', d)} \
- ${@bb.utils.contains('DISTRO_FEATURES', 'smack', ' file://smack-default-lsm.cfg', '', d)} \
-"
+KERNEL_FEATURES_append = " ${@bb.utils.contains("DISTRO_FEATURES", "apparmor", " features/apparmor/apparmor.scc", "" ,d)}"
++KERNEL_FEATURES_append = " ${@bb.utils.contains("DISTRO_FEATURES", "smack", " features/smack/smack.scc", "" ,d)}"
--
2.17.1


[meta-security][PATCH 1/2] linux-yocto: use 4.19 kernel cache now

Armin Kuster
 

remove kernel fragments now that they are in the
kernel-cache for 4.19

update bbappend accordingly.

Signed-off-by: Armin Kuster <akuster808@gmail.com>
---
recipes-kernel/linux/linux-yocto/apparmor.cfg | 15 ---------------
.../linux/linux-yocto/apparmor_on_boot.cfg | 1 -
.../linux/linux-yocto/smack-default-lsm.cfg | 2 --
recipes-kernel/linux/linux-yocto/smack.cfg | 8 --------
recipes-kernel/linux/linux-yocto/yama.cfg | 1 -
recipes-kernel/linux/linux-yocto_4.%.bbappend | 13 ++-----------
6 files changed, 2 insertions(+), 38 deletions(-)
delete mode 100644 recipes-kernel/linux/linux-yocto/apparmor.cfg
delete mode 100644 recipes-kernel/linux/linux-yocto/apparmor_on_boot.cfg
delete mode 100644 recipes-kernel/linux/linux-yocto/smack-default-lsm.cfg
delete mode 100644 recipes-kernel/linux/linux-yocto/smack.cfg
delete mode 100644 recipes-kernel/linux/linux-yocto/yama.cfg

diff --git a/recipes-kernel/linux/linux-yocto/apparmor.cfg b/recipes-kernel/linux/linux-yocto/apparmor.cfg
deleted file mode 100644
index b5f9bb2..0000000
--- a/recipes-kernel/linux/linux-yocto/apparmor.cfg
+++ /dev/null
@@ -1,15 +0,0 @@
-CONFIG_AUDIT=y
-# CONFIG_NETFILTER_XT_TARGET_AUDIT is not set
-CONFIG_SECURITY_NETWORK=y
-# CONFIG_SECURITY_NETWORK_XFRM is not set
-CONFIG_SECURITY_PATH=y
-# CONFIG_SECURITY_SELINUX is not set
-CONFIG_SECURITY_APPARMOR=y
-CONFIG_SECURITY_APPARMOR_HASH=y
-CONFIG_SECURITY_APPARMOR_HASH_DEFAULT=y
-# CONFIG_SECURITY_APPARMOR_DEBUG is not set
-CONFIG_INTEGRITY_AUDIT=y
-CONFIG_DEFAULT_SECURITY_APPARMOR=y
-# CONFIG_DEFAULT_SECURITY_DAC is not set
-CONFIG_DEFAULT_SECURITY="apparmor"
-CONFIG_AUDIT_GENERIC=y
diff --git a/recipes-kernel/linux/linux-yocto/apparmor_on_boot.cfg b/recipes-kernel/linux/linux-yocto/apparmor_on_boot.cfg
deleted file mode 100644
index fc35740..0000000
--- a/recipes-kernel/linux/linux-yocto/apparmor_on_boot.cfg
+++ /dev/null
@@ -1 +0,0 @@
-CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE=1
diff --git a/recipes-kernel/linux/linux-yocto/smack-default-lsm.cfg b/recipes-kernel/linux/linux-yocto/smack-default-lsm.cfg
deleted file mode 100644
index b5c4845..0000000
--- a/recipes-kernel/linux/linux-yocto/smack-default-lsm.cfg
+++ /dev/null
@@ -1,2 +0,0 @@
-CONFIG_DEFAULT_SECURITY="smack"
-CONFIG_DEFAULT_SECURITY_SMACK=y
diff --git a/recipes-kernel/linux/linux-yocto/smack.cfg b/recipes-kernel/linux/linux-yocto/smack.cfg
deleted file mode 100644
index 62f465a..0000000
--- a/recipes-kernel/linux/linux-yocto/smack.cfg
+++ /dev/null
@@ -1,8 +0,0 @@
-CONFIG_IP_NF_SECURITY=m
-CONFIG_IP6_NF_SECURITY=m
-CONFIG_EXT2_FS_SECURITY=y
-CONFIG_EXT3_FS_SECURITY=y
-CONFIG_EXT4_FS_SECURITY=y
-CONFIG_SECURITY=y
-CONFIG_SECURITY_SMACK=y
-CONFIG_TMPFS_XATTR=y
diff --git a/recipes-kernel/linux/linux-yocto/yama.cfg b/recipes-kernel/linux/linux-yocto/yama.cfg
deleted file mode 100644
index 3b55731..0000000
--- a/recipes-kernel/linux/linux-yocto/yama.cfg
+++ /dev/null
@@ -1 +0,0 @@
-CONFIG_SECURITY_YAMA=y
diff --git a/recipes-kernel/linux/linux-yocto_4.%.bbappend b/recipes-kernel/linux/linux-yocto_4.%.bbappend
index 321392c..39d4e6f 100644
--- a/recipes-kernel/linux/linux-yocto_4.%.bbappend
+++ b/recipes-kernel/linux/linux-yocto_4.%.bbappend
@@ -1,11 +1,2 @@
-FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
-
-SRC_URI += "\
- ${@bb.utils.contains('DISTRO_FEATURES', 'apparmor', ' file://apparmor.cfg', '', d)} \
- ${@bb.utils.contains('DISTRO_FEATURES', 'apparmor', ' file://apparmor_on_boot.cfg', '', d)} \
-"
-
-SRC_URI += "\
- ${@bb.utils.contains('DISTRO_FEATURES', 'smack', ' file://smack.cfg', '', d)} \
- ${@bb.utils.contains('DISTRO_FEATURES', 'smack', ' file://smack-default-lsm.cfg', '', d)} \
-"
+KERNEL_FEATURES_append = " ${@bb.utils.contains("DISTRO_FEATURES", "apparmor", " features/apparmor/apparmor.scc", "" ,d)}"
+KERNEL_FEATURES_append = " ${@bb.utils.contains("DISTRO_FEATURES", "smack", " features/smack/smack.scc", "" ,d)}"
--
2.17.1


[meta-security][PATCH 3/3] linux-stable/5.2: add stable bbappend

Armin Kuster
 

Signed-off-by: Armin Kuster <akuster808@gmail.com>
---
recipes-kernel/linux/linux-stable_5.2.bbappend | 4 ++++
1 file changed, 4 insertions(+)
create mode 100644 recipes-kernel/linux/linux-stable_5.2.bbappend

diff --git a/recipes-kernel/linux/linux-stable_5.2.bbappend b/recipes-kernel/linux/linux-stable_5.2.bbappend
new file mode 100644
index 0000000..76b5df5
--- /dev/null
+++ b/recipes-kernel/linux/linux-stable_5.2.bbappend
@@ -0,0 +1,4 @@
+KERNEL_FEATURES_append = " ${@bb.utils.contains("DISTRO_FEATURES", "apparmor", " features/apparmor/apparmor.scc", "" ,d)}"
+KERNEL_FEATURES_append = " ${@bb.utils.contains("DISTRO_FEATURES", "smack", " features/smack/smack.scc", "" ,d)}"
+KERNEL_FEATURES_append = " ${@bb.utils.contains("DISTRO_FEATURES", "yama", " features/yama/yama.scc", "" ,d)}"
+
--
2.17.1

7561 - 7580 of 53871