Date   

Re: avahi-daemon.service - how to create custom .service file with different startup parameters

Howard
 

Awesome Konrad Thanks.  That looks like it will do exactly what I need.


[meta-mingw][PATCH] libmpc: Add missing whitespace in append operator use

Khem Raj
 

Signed-off-by: Khem Raj <raj.khem@gmail.com>
---
recipes-support/libmpc/libmpc_%.bbappend | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-support/libmpc/libmpc_%.bbappend b/recipes-support/libmpc/libmpc_%.bbappend
index 0d289df..5a9ab9e 100644
--- a/recipes-support/libmpc/libmpc_%.bbappend
+++ b/recipes-support/libmpc/libmpc_%.bbappend
@@ -1 +1 @@
-EXTRA_OECONF_append_mingw32 = "--enable-static --disable-shared"
\ No newline at end of file
+EXTRA_OECONF_append_mingw32 = " --enable-static --disable-shared"
--
2.29.2


Re: avahi-daemon.service - how to create custom .service file with different startup parameters

Konrad Weihmann
 

Hi,

I would recommend that you go for a systemd drop-in file [1].
That would be something like a small snippet placed to /etc/systemd/system/avahi-daemon.service.d/override.conf

In that file place something like
[Service]
ExecStart=
ExecStart=<new command line with your custom options>

this way you don't need to alter the upstream recipe with weird sed hacks or similar.

This drop-in file could be packaged by any recipe or bbappend.

[1] https://coreos.com/os/docs/latest/using-systemd-drop-in-units.html

On 14.11.20 17:28, Howard wrote:
Hi:
I've been digging through meta/recipes-connectivity trying to figure out how I can override the avahi-daemon startup parameters.   However I am not finding where the avahi-daemon.service file gets created, or if there is a way to pass in different parameters so that it gets created with my startup parameters.
I need to start the daemon with the --no-chroot option in order for it to see a symlink to a file  /etc/avahi/services/MyAvahiService.service in a writeable partition.
Is there a clean way to do this or do I have to do the brute-force method of either killing it at runtime and restarting w/ --no-chroot, or doing a postinst step and paving over the original avahi-daemon.service file with my own?
Thanks
Howard


avahi-daemon.service - how to create custom .service file with different startup parameters

Howard
 

Hi:

I've been digging through meta/recipes-connectivity trying to figure out how I can override the avahi-daemon startup parameters.   However I am not finding where the avahi-daemon.service file gets created, or if there is a way to pass in different parameters so that it gets created with my startup parameters.

I need to start the daemon with the --no-chroot option in order for it to see a symlink to a file  /etc/avahi/services/MyAvahiService.service in a writeable partition.

Is there a clean way to do this or do I have to do the brute-force method of either killing it at runtime and restarting w/ --no-chroot, or doing a postinst step and paving over the original avahi-daemon.service file with my own?

 

Thanks

Howard

 


[meta-cgl][PATCH] layer.conf: add gatesgarth

Jeremy Puhlman
 

Signed-off-by: Jeremy A. Puhlman <jpuhlman@mvista.com>
---
meta-cgl-common/conf/layer.conf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-cgl-common/conf/layer.conf b/meta-cgl-common/conf/layer=
.conf
index 6035b4b..8100e23 100644
--- a/meta-cgl-common/conf/layer.conf
+++ b/meta-cgl-common/conf/layer.conf
@@ -11,6 +11,6 @@ BBFILE_PRIORITY_cgl-common =3D "7"
=20
LAYERDEPENDS_cgl-common =3D "core openembedded-layer networking-layer pe=
rl-layer filesystems-layer security selinux"
=20
-LAYERSERIES_COMPAT_cgl-common =3D "warrior zeus dunfell"
+LAYERSERIES_COMPAT_cgl-common =3D "warrior zeus dunfell gatesgarth"
=20
require conf/distro/include/cgl_common_security_flags.inc
--=20
2.20.1


Re: Reproducible builds and RPM packages

Richard Purdie
 

On Thu, 2020-11-12 at 15:43 -0800, Jate Sujjavanich wrote:
I have sussed out several behaviors of the image build having to do
with reproducible builds. It seems like bitbake creates the rpm with
the correct modification times per the reproducible_builds bbclass.
When do_rootfs installs the packages, the timestamps seem correct.

The function reproducible_final_image_task sets all files in rootfs
to be REPRODUCIBLE_TIMESTAMP_ROOTFS which is the last commit time in
poky by default. This occurs after package installation and before
image creation.

When the image creation code runs, it seems like each utility has
different behavior on respecting SOURCE_DATE_EPOCH in the
environment. The ext3 utility allowed mtime's beyond the default
value of 0. The squashfs utility enforced the restriction of no
mtime's being beyond 0 seconds since the epoch. Once I set this to
the build timestamp (DATETIME) in the image recipe, the squashfs
image had correct times.

So to get this working, you'd need to disable
reproducible_final_image_task, and make sure the image creation
utility is not wiping out the modification times of files created by
rpm.

I'd argue that we'd want reproducible_final_image_task to not
override all the mtime's of files. We probably have to check the
other file system type to see their behavior with SOURCE_DATE_EPOCH
as well.
Thanks for mentioning that, it does sound like that is doing something
we no longer should be doing now source_date_epoch is working in most
packages properly.

There are some files such as the rpm database and any other files not
under control of package management which would need this handling to
have the images be 100% reproducible so its not entirely
straightforward though.

Cheers,

Richard


Re: How to remove Kernel headers from SDK

Khem Raj
 

On 11/13/20 5:20 AM, Bel Hadj Salem Talel wrote:
Hi All,
I need to deliver an SDK for arch64 but without Kernel headers that one can build Kernel modules with them. (/usr/include/linux/* , ...)
I only need to deliver an SDK with toolchain and minimal headers for compilation such as "stdio.h" , ...
How can I do it ?

perhaps bitbak meta-toolchain would suffice

Thanks, Talel


How to remove Kernel headers from SDK

Bel Hadj Salem Talel
 

Hi All,
I need to deliver an SDK for arch64 but without Kernel headers that one can build Kernel modules with them. (/usr/include/linux/* , ...)
I only need to deliver an SDK with toolchain and minimal headers for compilation such as "stdio.h" , ...

How can I do it ?
Thanks, Talel


Re: Trying to compile hping3 from sources #devtool

Khem Raj
 

Hey Manasa !!

Long time, happy to hear from you. I hope you are doing well,

Hi Vaijayanthi

I took a look at hping3 and its one package thats not cross-compile
friendly, So no wonder Vaijayanthi was finding all sorts of issues.
It was looking at host system for tcl and all kind of other headers
which was causing the issues you were seeing.

Just for Manasa I gave it a whirl :) and here is a version which should
work (At least it compiles), its completely untested but I hope it will
unblock you

https://github.com/YoeDistro/meta-openembedded/commit/c4a5be527f61f286cd47352f56b563390a4e3d58

You can download this

curl -O
https://github.com/YoeDistro/meta-openembedded/commit/c4a5be527f61f286cd47352f56b563390a4e3d58.patch

cd meta-openembedded

git am c4a5be527f61f286cd47352f56b563390a4e3d58.patch

then

bitbake hping3

Let me know if it is helpful

Thank you

-Khem

On 11/12/20 12:59 PM, Godavarthi, Manasa wrote:
Hi Raj,

 

Small world! Hope you are doing well. I would love to catch up sometime
with you.

 

Vaijayanthi also worked with me at Juniper. We really appreciate your
help regarding hping3. Basically, there is no recipe for hping3, looks
like. So, Vaijayanthi is trying to compile from source and include it as
part of our Yocto build and SDK so that hping3 binary is available as
part of our linux distro.

 

Regards,

--Manasa

 

*From: *Muralidharan, Vaijayanthi <vaijayanthi.muralidharan@hpe.com>
*Date: *Thursday, November 12, 2020 at 12:36 PM
*To: *raj.khem@gmail.com <raj.khem@gmail.com>
*Cc: *Vaijayanthi <vaijayanthi@silver-peak.com>, Yocto-mailing-list
<yocto@lists.yoctoproject.org>, Godavarthi, Manasa
<manasa.godavarthi@hpe.com>
*Subject: *Re: [yocto] Trying to compile hping3 from sources #devtool

Just to add more to this: I managed to build via bitbake successfully.
But "make" fails with the following error:
Problem: package packagegroup-sps-all-1.0-r0.noarch requires
packagegroup-sps-network-utils, but none of the providers can be installed
  - package packagegroup-sps-network-utils-1.0-r0.noarch requires
hping3, but none of the providers can be installed
  - conflicting requests
  - nothing provides libpcap.so.0.8()(64bit) needed by
hping3-git-r0.core2_64
  - nothing provides libtcl8.6.so()(64bit) needed by hping3-git-r0.core2_64
(try to add '--skip-broken' to skip uninstallable packages or '--nobest'
to use not only best candidate packages)

ERROR: sps-image-vxoa-1.0-r0 do_rootfs:

I have added RDENPDS for libpcap and libtcl in hping3's recipe.

On 11/9/20, 4:06 PM, "Muralidharan, Vaijayanthi"
<vaijayanthi.muralidharan@hpe.com> wrote:

    This is a recipe that was created via devtool.

    devtool add hping3 https://github.com/antirez/hping

    On 11/9/20, 10:43 AM, "Muralidharan, Vaijayanthi"
<vaijayanthi.muralidharan@hpe.com> wrote:

        hping3_git.bb

        On 11/7/20, 12:04 PM, "yocto@lists.yoctoproject.org on behalf of
Khem Raj via lists.yoctoproject.org" <yocto@lists.yoctoproject.org on
behalf of raj.khem=gmail.com@lists.yoctoproject.org> wrote:

            On Sat, Nov 7, 2020 at 11:57 AM Muralidharan, Vaijayanthi
            <vaijayanthi.muralidharan@hpe.com> wrote:
            >
            > Khem,
            >
            > Thanks for responding. I am trying to build hping3 from
sources. There is only a bb recipe for hping2.
            >

            what is your failing recipe called (exact name )

            > On 11/6/20, 9:42 PM, "Khem Raj" <raj.khem@gmail.com> wrote:
            >
            >     whats the name of your recipe ? secondly hping3
requires libtcl8.6.so
            >     seems to be troublesome because its asking
            >     for devel package not the original library, I wonder
why, can you find
            >     out the linker cmdline where ping3 is getting linked ?
            >
            >     On Fri, Nov 6, 2020 at 6:31 PM Vaijayanthi
<vaijayanthi@silver-peak.com> wrote:
            >     >
            >     > Hi, I am using devtool add hping3
https://github.com/antirez/hping to add hping3 as part of our custom
image. Here is my recipe:
            >     >
            >     > # Recipe created by recipetool
            >     >
            >     > # This is the basis of a recipe and may need further
editing in order to be fully functional.
            >     >
            >     > # (Feel free to remove these comments when editing.)
            >     >
            >     >
            >     >
            >     > # WARNING: the following LICENSE and
LIC_FILES_CHKSUM values are best guesses - it is
            >     >
            >     > # your responsibility to verify that the values are
complete and correct.
            >     >
            >     > #
            >     >
            >     > # The following license files were not able to be
identified and are
            >     >
            >     > # represented as "Unknown" below, you will need to
check them yourself:
            >     >
            >     > #   COPYING
            >     >
            >     > LICENSE = "GPLv2"
            >     >
            >     > LIC_FILES_CHKSUM =
"file://COPYING;md5=3728a6c4c9630a9e796ad4b82dacd887
<file:///COPYING;md5=3728a6c4c9630a9e796ad4b82dacd887>"
            >     >
            >     >
            >     >
            >     > SRC_URI =
"git://github.com/antirez/hping;protocol=https"
            >     >
            >     >
            >     >
            >     > # Modify these as desired
            >     >
            >     > PV = "1.0+git${SRCPV}"
            >     >
            >     > SRCREV = "3547c7691742c6eaa31f8402e0ccbb81387c1b99"
            >     >
            >     >
            >     >
            >     > S = "${WORKDIR}/git"
            >     >
            >     >
            >     >
            >     > #DEPENDS = "libpcap"
            >     >
            >     > RDEPENDS_${PN} += " libpcap tcl-lib tcl"
            >     >
            >     >
            >     >
            >     > # NOTE: no Makefile found, unable to determine what
needs to be done
            >     >
            >     >
            >     >
            >     > do_configure () {
            >     >
            >     >     # Specify any needed configure commands here
            >     >
            >     >     CONFIGOSTYPE="LINUX" ./configure
            >     >
            >     > }
            >     >
            >     >
            >     >
            >     > do_compile () {
            >     >
            >     >     # Specify compilation commands here
            >     >
            >     >     make
            >     >
            >     > }
            >     >
            >     > do_install() {
            >     >
            >     >     #install -Dm755 ${B}/libpcap.so.0.8
${D}${libdir}/libpcap.so.0.8
            >     >
            >     >     #ln -sf libpcap.so.0.8 ${D}${libdir}/libpcap.so
            >     >
            >     >     #install -Dm755 ${B}/libtcl8.6.so
${D}${libdir}/libtcl8.6.so
            >     >
            >     >     #ln -sf libtcl8.6.so ${D}${libdir}/libtcl8.6.so
            >     >
            >     >     install -m 0755 -d ${D}${sbindir} ${D}/${mandir}
${D}${docdir}/hping3
            >     >
            >     >     install -m 0755 hping3 ${D}/${sbindir}
            >     >
            >     >     install -m 0644 docs/hping3.8 ${D}/${mandir}
            >     >
            >     >     install -m 0644 docs/HPING2-HOWTO.txt
docs/HPING2-IS-OPEN \
            >     >
            >     >         docs/MORE-FUN-WITH-IPID docs/SPOOFED_SCAN.txt \
            >     >
            >     >         docs/AS-BACKDOOR docs/APD.txt
${D}${docdir}/hping3
            >     >
            >     > }
            >     >
            >     >
            >     >
            >     > #INSANE_SKIP_${PN}-dev = "ldflags"
            >     >
            >     > #INSANE_SKIP_${PN} = "ldflags"
            >     >
            >     > #INSANE_SKIP_${PN} += "file-rdeps dev-deps"
            >     >
            >     >
            >     > How do I add this to my custom bitbake layer? Also,
make is complaining about
            >     > ERROR: hping3-1.0+git999-r0 do_package_qa: QA Issue:
/usr/sbin/hping3 contained in package hping3 requires
libpcap.so.0.8()(64bit), but no providers found in RDEPENDS_hping3?
[file-rdeps]
            >     > ERROR: hping3-1.0+git999-r0 do_package_qa: QA Issue:
/usr/sbin/hping3 contained in package hping3 requires
libtcl8.6.so()(64bit), but no providers found in RDEPENDS_hping3?
[file-rdeps]
            >     > ERROR: hping3-1.0+git999-r0 do_package_qa: QA run
found fatal errors. Please consider fixing them.
            >     >
            >     > Please let me know what I should I do next to
integrate this recipe with my custom meta layer and also, address the
make failures.
            >     >
            >     >
            >     >
            >     >
            >     >
            >


Re: Reproducible builds and RPM packages

Jate Sujjavanich
 

I have sussed out several behaviors of the image build having to do with reproducible builds. It seems like bitbake creates the rpm with the correct modification times per the reproducible_builds bbclass. When do_rootfs installs the packages, the timestamps seem correct.

The function reproducible_final_image_task sets all files in rootfs to be REPRODUCIBLE_TIMESTAMP_ROOTFS which is the last commit time in poky by default. This occurs after package installation and before image creation.

When the image creation code runs, it seems like each utility has different behavior on respecting SOURCE_DATE_EPOCH in the environment. The ext3 utility allowed mtime's beyond the default value of 0. The squashfs utility enforced the restriction of no mtime's being beyond 0 seconds since the epoch. Once I set this to the build timestamp (DATETIME) in the image recipe, the squashfs image had correct times.

So to get this working, you'd need to disable reproducible_final_image_task, and make sure the image creation utility is not wiping out the modification times of files created by rpm.

I'd argue that we'd want reproducible_final_image_task to not override all the mtime's of files. We probably have to check the other file system type to see their behavior with SOURCE_DATE_EPOCH as well.

- Jate


Re: Qtwebengine recipe in yocto zeus (latest version) #yocto #zeus #qt

Khem Raj
 

On 11/12/20 8:29 AM, anthony.marchand@navocap.com wrote:
Hello.
I hope you're going well in this period.
I'm working with yocto (zeus version) with a soc i.MX6 and kernel 4.19. Actually, I meet a weird issue about the recipe "qtwebengine" in all of my projects that are using zeus version.
The compilation was working fine until there, but since approximatively two weeks, with no particular reason, whatever the project I want to compile, I'm unable to compile qtwebengine and making a rootfs image with it inside.
So I have tested:
1) bitbake qtwebengine
2) bitbake myimage
PS: myimage contain the recipe qtwebengine.
But whatever the bitbake commands 1 or 2, Bitbake shows me the same error I don't understand and this error follows:
-----------------------------------------------------------------------------------
| In file included from /usr/include/bits/errno.h:26:0,
|                  from /usr/include/errno.h:28,
|                  from /usr/include/c++/7/cerrno:42,
|                  from /usr/include/c++/7/ext/string_conversions.h:44,
|                  from /usr/include/c++/7/bits/basic_string.h:6361,
|                  from /usr/include/c++/7/string:52,
|                  from /usr/include/c++/7/stdexcept:39,
|                  from /usr/include/c++/7/array:39,
|                  from /usr/include/c++/7/tuple:39,
|                  from /usr/include/c++/7/bits/unique_ptr.h:37,
|                  from /usr/include/c++/7/memory:80,
|                  from ../../../../git/src/3rdparty/chromium/v8/src/torque/cfg.h:9,
|                  from ./../../../../git/src/3rdparty/chromium/v8/src/torque/cfg.cc:5,
|                  from v8_snapshot/gen/v8/torque_base_jumbo_1.cc:5:
| /usr/include/linux/errno.h:1:10: fatal error: asm/errno.h: No such file or directory
|  #include <asm/errno.h>
|           ^~~~~~~~~~~~~
| compilation terminated.
...
| Makefile.gn_run:340: recipe for target 'run_ninja' failed
| make[3]: *** [run_ninja] Error 1
| make[3]: Leaving directory '/home/yocto/Dev/build_zeus/tmp/work/cortexa9t2hf-neon-mx6qdl-poky-linux-gnueabi/qtwebengine/5.13.0+gitAUTOINC+5d4bac57a0_8a28c0bb19-r0/build/src/core'
| Makefile:82: recipe for target 'sub-gn_run-pro-make_first' failed
| make[2]: *** [sub-gn_run-pro-make_first] Error 2
| make[2]: Leaving directory '/home/yocto/Dev/build_zeus/tmp/work/cortexa9t2hf-neon-mx6qdl-poky-linux-gnueabi/qtwebengine/5.13.0+gitAUTOINC+5d4bac57a0_8a28c0bb19-r0/build/src/core'
| Makefile:76: recipe for target 'sub-core-make_first' failed
| make[1]: *** [sub-core-make_first] Error 2
| make[1]: Leaving directory '/home/yocto/Dev/build_zeus/tmp/work/cortexa9t2hf-neon-mx6qdl-poky-linux-gnueabi/qtwebengine/5.13.0+gitAUTOINC+5d4bac57a0_8a28c0bb19-r0/build/src'
| Makefile:48: recipe for target 'sub-src-make_first' failed
| make: *** [sub-src-make_first] Error 2
| WARNING: exit code 1 from a shell command.
|
ERROR: Task (/home/yocto/Dev/build_zeus/../meta-qt5/recipes-qt/qt5/qtwebengine_git.bb:do_compile) failed with exit code '1'
-----------------------------------------------------------------------------------
I don't understand why bitbake don't find '<asm/errno.h>', because it is present in the kernel 4.19 and in my host system ubuntu 18. Furthermore, I don't understand the problem with run_ninja.
I try to change my PC for compilation, but I have got the same error. The PC I use to compile with bitbake got 20 cores intel xeon and 32GB of ram. I think the problem is not from here. :-)
Does someone already meet this problem?
Does someone know where could be the problem?
it seems to be failing to find files on build host install and there were similar issues seen on chromium browswer long time ago which has been addressed in meta-browser. you might disable building torque perhaps to workaround it.

Thanks for all and best reguards: Anthony.


Re: Patch files before recipe is parsed

 

On Thu, 12 Nov 2020 at 17:14, Paul Adams <paul.adams@evogro.com> wrote:

There is a problem with the Yocto recipe for Python 3 in warrior. It
is missing ntpath in the list of core modules listed in
python3-manifest.json.

Since warrior is EOL, I was hoping to fix this by patching the
python3-manifest.json file but it doesn't work. I think the reason is
that the manifest file is read by an anonymous function in the recipe,
which I understand is executed during recipe parsing (which I assume
happens before the patches are applied).

I know the patch is being applied correctly because the content of
python3-manifest.json file is correct when I inspect it in the
build/tmp/work... directory.

My question is whether there is any method in bitbake to apply patches
early enough to fix this issue?
There's nothing in bitbake to support this. If you need to carry
patches against an EOL branch then you can either create a local fork
of poky or use a setup tool like kas (https://github.com/siemens/kas)
which can apply patches when checking out layers.

The better alternative would be to upgrade to a supported branch if
you can though.

Thanks,

--
Paul Barker
Konsulko Group


Re: #yocto "zeus" #yocto

Khem Raj
 

are you using nfsvers= in /etc/fstab

On Thu, Nov 12, 2020 at 10:44 AM Monsees, Steven C (US) via
lists.yoctoproject.org
<steven.monsees=baesystems.com@lists.yoctoproject.org> wrote:



All things being equal, would you know why I might see

"NFS: bad mount option value specified: minorversion=1"

when running app under "zeus" but not under "rocko" ?

-----Original Message-----
From: Khem Raj [mailto:raj.khem@gmail.com]
Sent: Thursday, November 12, 2020 1:40 PM
To: Monsees, Steven C (US) <steven.monsees@baesystems.com>; yocto@lists.yoctoproject.org
Subject: Re: [yocto] #yocto "zeus"

*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.



On 11/12/20 4:03 AM, Monsees, Steven C (US) via lists.yoctoproject.org
wrote:
This is probably a simple question, but since I am new to yocto there
is a lot to learn...

How do I establish kernel access permissions for the "zeus" kernel so
that when my application is up and running, (or an application startup
script), can create read/write files for access/updating in the "/etc"
and "/dev" directories ?

In the few cases I do this I am seeing unable to open errors...

Note the same code appears to work correctly under "rocko"...
you have to provide more context to help you more, but usually /dev is populated with devtmpfs during kernel boot. and similarly /etc is mounted early on. So access permissions could be mounting issues perhaps.


Thanks,

Steve







Re: #yocto "zeus" #yocto

Monsees, Steven C (US)
 

All things being equal, would you know why I might see

"NFS: bad mount option value specified: minorversion=1"

when running app under "zeus" but not under "rocko" ?

-----Original Message-----
From: Khem Raj [mailto:raj.khem@gmail.com]
Sent: Thursday, November 12, 2020 1:40 PM
To: Monsees, Steven C (US) <steven.monsees@baesystems.com>; yocto@lists.yoctoproject.org
Subject: Re: [yocto] #yocto "zeus"

*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.



On 11/12/20 4:03 AM, Monsees, Steven C (US) via lists.yoctoproject.org
wrote:
This is probably a simple question, but since I am new to yocto there
is a lot to learn...

How do I establish kernel access permissions for the "zeus" kernel so
that when my application is up and running, (or an application startup
script), can create read/write files for access/updating in the "/etc"
and "/dev" directories ?

In the few cases I do this I am seeing unable to open errors...

Note the same code appears to work correctly under "rocko"...
you have to provide more context to help you more, but usually /dev is populated with devtmpfs during kernel boot. and similarly /etc is mounted early on. So access permissions could be mounting issues perhaps.


Thanks,

Steve





Re: #yocto "zeus" #yocto

Khem Raj
 

On 11/12/20 4:03 AM, Monsees, Steven C (US) via lists.yoctoproject.org wrote:
This is probably a simple question, but since I am new to yocto there is a lot to learn…
How do I establish kernel access permissions for the “zeus” kernel so that when my application is up and running, (or an application startup script), can create read/write files for access/updating in the ”/etc” and “/dev” directories ?
In the few cases I do this I am seeing unable to open errors…
Note the same code appears to work correctly under “rocko”…
you have to provide more context to help you more, but usually /dev is populated with devtmpfs during kernel boot. and similarly /etc is mounted early on. So access permissions could be mounting issues perhaps.

Thanks,
Steve


Patch files before recipe is parsed

Paul Adams
 

There is a problem with the Yocto recipe for Python 3 in warrior. It
is missing ntpath in the list of core modules listed in
python3-manifest.json.

Since warrior is EOL, I was hoping to fix this by patching the
python3-manifest.json file but it doesn't work. I think the reason is
that the manifest file is read by an anonymous function in the recipe,
which I understand is executed during recipe parsing (which I assume
happens before the patches are applied).

I know the patch is being applied correctly because the content of
python3-manifest.json file is correct when I inspect it in the
build/tmp/work... directory.

My question is whether there is any method in bitbake to apply patches
early enough to fix this issue?


Qtwebengine recipe in yocto zeus (latest version) #yocto #zeus #qt

anthony.marchand@...
 

Hello.
I hope you're going well in this period.
I'm working with yocto (zeus version) with a soc i.MX6 and kernel 4.19. Actually, I meet a weird issue about the recipe "qtwebengine" in all of my projects that are using zeus version.
The compilation was working fine until there, but since approximatively two weeks, with no particular reason, whatever the project I want to compile, I'm unable to compile qtwebengine and making a rootfs image with it inside.

So I have tested:

1) bitbake qtwebengine
2) bitbake myimage

PS: myimage contain the recipe qtwebengine.

But whatever the bitbake commands 1 or 2, Bitbake shows me the same error I don't understand and this error follows:

-----------------------------------------------------------------------------------
| In file included from /usr/include/bits/errno.h:26:0,
|                  from /usr/include/errno.h:28,
|                  from /usr/include/c++/7/cerrno:42,
|                  from /usr/include/c++/7/ext/string_conversions.h:44,
|                  from /usr/include/c++/7/bits/basic_string.h:6361,
|                  from /usr/include/c++/7/string:52,
|                  from /usr/include/c++/7/stdexcept:39,
|                  from /usr/include/c++/7/array:39,
|                  from /usr/include/c++/7/tuple:39,
|                  from /usr/include/c++/7/bits/unique_ptr.h:37,
|                  from /usr/include/c++/7/memory:80,
|                  from ../../../../git/src/3rdparty/chromium/v8/src/torque/cfg.h:9,
|                  from ./../../../../git/src/3rdparty/chromium/v8/src/torque/cfg.cc:5,
|                  from v8_snapshot/gen/v8/torque_base_jumbo_1.cc:5:
| /usr/include/linux/errno.h:1:10: fatal error: asm/errno.h: No such file or directory
|  #include <asm/errno.h>
|           ^~~~~~~~~~~~~
| compilation terminated.
...
| Makefile.gn_run:340: recipe for target 'run_ninja' failed
| make[3]: *** [run_ninja] Error 1
| make[3]: Leaving directory '/home/yocto/Dev/build_zeus/tmp/work/cortexa9t2hf-neon-mx6qdl-poky-linux-gnueabi/qtwebengine/5.13.0+gitAUTOINC+5d4bac57a0_8a28c0bb19-r0/build/src/core'
| Makefile:82: recipe for target 'sub-gn_run-pro-make_first' failed
| make[2]: *** [sub-gn_run-pro-make_first] Error 2
| make[2]: Leaving directory '/home/yocto/Dev/build_zeus/tmp/work/cortexa9t2hf-neon-mx6qdl-poky-linux-gnueabi/qtwebengine/5.13.0+gitAUTOINC+5d4bac57a0_8a28c0bb19-r0/build/src/core'
| Makefile:76: recipe for target 'sub-core-make_first' failed
| make[1]: *** [sub-core-make_first] Error 2
| make[1]: Leaving directory '/home/yocto/Dev/build_zeus/tmp/work/cortexa9t2hf-neon-mx6qdl-poky-linux-gnueabi/qtwebengine/5.13.0+gitAUTOINC+5d4bac57a0_8a28c0bb19-r0/build/src'
| Makefile:48: recipe for target 'sub-src-make_first' failed
| make: *** [sub-src-make_first] Error 2
| WARNING: exit code 1 from a shell command.
|
ERROR: Task (/home/yocto/Dev/build_zeus/../meta-qt5/recipes-qt/qt5/qtwebengine_git.bb:do_compile) failed with exit code '1'
-----------------------------------------------------------------------------------

I don't understand why bitbake don't find '<asm/errno.h>', because it is present in the kernel 4.19 and in my host system ubuntu 18. Furthermore, I don't understand the problem with run_ninja.

I try to change my PC for compilation, but I have got the same error. The PC I use to compile with bitbake got 20 cores intel xeon and 32GB of ram. I think the problem is not from here. :-)

Does someone already meet this problem?

Does someone know where could be the problem?

Thanks for all and best reguards: Anthony.


#yocto "zeus" #yocto

Monsees, Steven C (US)
 

 

This is probably a simple question, but since I am new to yocto there is a lot to learn…

 

How do I establish kernel access permissions for the “zeus” kernel so that when my application is up and running, (or an application startup script), can create read/write files for access/updating in the ”/etc” and “/dev” directories ?

 

In the few cases I do this I am seeing unable to open errors…

Note the same code appears to work correctly under “rocko”…

 

Thanks,

Steve


Re: Emulator tool for imx8m #linux #devtool #yocto

Amrun Nisha.R
 

Thanks Andy,

I tried to boot the linux kernel using TFTP/NFS, i got this below error

BOOTP broadcast 1
DHCP client bound to address 10.78.216.7 (12 ms)
Using ethernet@30be0000 device
TFTP from server 199.63.127.45; our IP address is 10.78.216.7; sending through gateway 10.79.108.1
Filename 'boot\x86\wdsnbp.com'.
Load address: 0x42000000
Loading: *
ARP Retry count exceeded; starting again
Error: Bad gzipped data
fdt_file=fsl-imx8mq-var-dart.dtb
BOOTP broadcast 1
DHCP client bound to address 10.78.216.7 (17 ms)
Using ethernet@30be0000 device
TFTP from server 199.63.127.45; our IP address is 10.78.216.7; sending through gateway 10.79.108.1
Filename 'boot\x86\wdsnbp.com'.
Load address: 0x43000000
Loading: *
ARP Retry count exceeded; starting again
WARN: Cannot load the DT

is there any way to fix this issue?


Issue related to .wic image

NIKHIL PATIL
 

Hi ,
    We are compiling a core-image-sato-sdk.wic  image  using bitbake  that time i am not able to copy anything into /lib/firmware  folder. 
     but when i am compiling core-image-sato-sdk.hddimg   that time its work fine .     
    for wic image getting following error .
  
root@intel-corei7-64:~# cp tests/Firmware/* /lib/firmware/
cp: cannot create regular file '/lib/firmware/RS9113_AP_BT_DUAL_MODE.rps': Read-only file system
cp: cannot create regular file '/lib/firmware/RS9113_WC_BL.rps': Read-only file system

4101 - 4120 of 55458