Date   

Your GStreamer installation is missing a plug-in

Bhupendra Singh <bhupendra.singh@...>
 

Dear All

I am trying to make a Qt application QML-GUI that will show live streaming of ip-camera. but when in run qt-application on my Embedded Device then I got

Some problem .   

 

(gst-plugin-scanner:1296): GStreamer-WARNING **: Failed to load plugin '/usr/lib/gstreamer-0.10/libgstopengl.so': /usr/lib/libgstgl-0.10.so.1: undefined symbol: gst_gl_shader_set_uniform_matrix_2x3fv

** (gst-plugin-scanner:1296): WARNING **: could not find config file '/home/root/.config/gst-openmax.conf'.. using defaults!

(gst-plugin-scanner:1296): GLib-GObject-WARNING **: cannot register existing type 'GstVorbisDec'

(gst-plugin-scanner:1296): GLib-CRITICAL **: g_once_init_leave: assertion 'result != 0' failed

(gst-plugin-scanner:1296): GStreamer-CRITICAL **: gst_element_register: assertion 'g_type_is_a (type, GST_TYPE_ELEMENT)' failed

shared memfd open() failed: Function not implemented

Warning: "No decoder available for type 'application/x-rtp, media=(string)video, payload=(int)35, clock-rate=(int)90000, encoding-name=(string)H264, packetization-mode=(string)1, profile-level-id=(string)4d0029, sprop-parameter-sets=(string)\"Z00AKZpkA8ARPy4C1AQEFAg\\=\\,aO48gA\\=\\=\", a-recvonly=(string)\"\", npt-start=(guint64)0, play-speed=(double)1, play-scale=(double)1'."

Error: "Your GStreamer installation is missing a plug-in."

 

I am using –

Embedded Device(SOC) – Colibri-T20  (NVIDIA,Toradex)

Os -    Angstrom v2017.12 – Kernel   

            Colibri-T20_Qt5-X11-Image 2.8b6 20190816

 

Which package I am missing in my os

If am running this application on my Desktop it works correctly .

 

 

Thanks & Regards

Bhupendra Singh

 


building SDK artifacts with external toolchain

Marek Belisko
 

Hi,

I have an dilema to solve. I have an SDK from vendor which contains
scripts to build u-boot + kernel + some kind of application and create
initramfs out of that and this can be flashed to NOR device and boot.
But setup and using is really horrible. Idea is to port this process
to yocto and have possibility to be used as yocto SDK for development.
Issue is that u-boot and kernel are obsolete (u-boot 2010 and kernel
3.18) and after few fixed I was able to buld and run u-boto with 7.3
arm ggc but when building kernel I got some issue with asm and I'm
kind of lost ;). So idea was to use toolchain which SDK provide but
it's again 4.9.4 (some linaro clone). Target is to use poky rocko with
this setup. I tried to build minimal image with external toolchain but
got some QA issues like:

gmp-6.1.2-r0 do_package_qa: QA Issue: libgmpxx rdepends on
external-linaro-toolchain-dbg [debug-deps]
ERROR: gmp-6.1.2-r0 do_package_qa: QA Issue:
/usr/lib/libgmpxx.so.4.5.2 contained in package libgmpxx requires
libstdc++.so.6(CXXABI_1.3), but no providers found in
RDEPENDS_libgmpxx? [file-rdeps]
ERROR: gmp-6.1.2-r0 do_package_qa: QA Issue:
/usr/lib/libgmpxx.so.4.5.2 contained in package libgmpxx requires
libstdc++.so.6(CXXABI_ARM_1.3.3), but no providers found in
RDEPENDS_libgmpxx? [file-rdeps]
ERROR: gmp-6.1.2-r0 do_package_qa: QA Issue:
/usr/lib/libgmpxx.so.4.5.2 contained in package libgmpxx requires
libstdc++.so.6(GLIBCXX_3.4), but no providers found in
RDEPENDS_libgmpxx? [file-rdeps]
ERROR: gmp-6.1.2-r0 do_package_qa: QA Issue:
/usr/lib/libgmpxx.so.4.5.2 contained in package libgmpxx requires
libstdc++.so.6(GLIBCXX_3.4.11), but no providers found in
RDEPENDS_libgmpxx? [file-rdeps]
ERROR: gmp-6.1.2-r0 do_package_qa: QA Issue:
/usr/lib/libgmpxx.so.4.5.2 contained in package libgmpxx requires
libstdc++.so.6, but no providers found in RDEPENDS_libgmpxx?
[file-rdeps]

I can workaround those but to me it looks like it's somehow not
compatible or so (was using 4.9.4 linaro toolchain). My idea was to
maybe use older poky (when 4.9 toolchain was used) but I'm not sure I
like this approach. Other ideas? Thanks.

BR,

marek

--
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com


Qemu on windows sdk

franksinankaya <franksinankaya@...>
 

I noticed last week that qemu packaged into mingw windows sdk is broken while the qemu in linux sdk works fine using thud-next branch. 

Qemu crashes very early while launching the kernel boot. 

This used to work fine on sumo.

Does anybody see this problem too?



Re: LF Community Bridge Mentorship

Armin Kuster
 

On 8/16/19 12:37 AM, Nicolas Dechesne wrote:
hi there.
just a reminder!
cheers
Maybe mention this during the BoF in next week's ELC?

- armin

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: How to patch a recipe .inc file

Greg Wilson-Lindberg
 

Hi Jonas,
I have added extra kernel config through a .bbappend and a do_configure_append() function. The issue that I was asking about is that the for the initramfs changes that are suggested in the meta-raspberrypi documentation, section 3.14, they need to be inserted in the middle of one of the functions in the linux-raspberrypi.inc file, they can't be added in a prepend() or append() function. This either requires that I change the linux-raspberrypi.inc file or find some way to patch it during the build, I would prefer to patch it.

Regards,
Greg Wilson-Lindberg

-----Original Message-----
From: Gmail [mailto:jonaskgandersson@gmail.com]
Sent: Wednesday, August 07, 2019 10:38 PM
To: Greg Wilson-Lindberg <GWilson@sakuraus.com>
Cc: Yocto list discussion <yocto@yoctoproject.org>
Subject: Re: [yocto] How to patch a recipe .inc file

Hi,

To add some kernel config I have created an extra .cfg file in:
my_recipe/recipes-kernel/linux/linux-raspberrypi/
and add an bb_append file:

recipes-kernel/linux/linux-raspberrypi_%25.bbappend
__________________________________________________________
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"

SRC_URI += "file://your_conf.cfg"
__________________________________________________________

BR
Jonas

8 aug. 2019 kl. 01:02 skrev Greg Wilson-Lindberg <GWilson@sakuraus.com>:

I'm working with a Yocto Sumo build provided with Qt's boot2qt system. I'm trying
to enable using initramfs as a step in trying to enable OSTree updates.

In the meta-raspberrypi documentation, section 3.14, it says to add some kernel
config to the linux-raspberrypi.inc file. I would prefer to keep my changes to Yocto
layer files in my own tree so I'm trying to figure out how to patch the existing file.
I've got bitbake finding my patch file, but it can't find the file to patch.

Can somebody help me to specify that the file that I'm patching is part of the
meta-raspberrypi linux recipe?

I'm going to be gone for a week, but I wanted to ask this now so maybe I'll have
some information when I get back.

Regards,
Greg Wilson-Lindberg

--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: Trouble using initramfs

Anuj Mittal
 

On Fri, 2019-08-16 at 10:26 +0200, Moritz Porst wrote:
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 ?


Please see:

https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=b697aba61e55b93aa1ebf59a369d182c7a14c313

Thanks,

Anuj


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

Randy MacLeod
 

On 8/16/19 12:40 AM, jaymin.dabhi@vivaldi.net wrote:
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?
Via google:
https://jvns.ca/blog/2018/04/28/debugging-a-segfault-on-linux/

../Randy

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

--
# Randy MacLeod
# Wind River Linux


[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"

7201 - 7220 of 53518