Date   

Re: "Yocto Project Linux Kernel Development Manual" is gone

Nicolas Dechesne
 

hi,

thanks for reporting, you're right.. and the Development tasks manual entry is listed twice.. We will investigate and fix that!

cheers


On Sun, Mar 22, 2020 at 11:57 PM Vasyl Vavrychuk <vvavrychuk@...> wrote:

Latest "Docs Overview" webpage https://www.yoctoproject.org/docs/ has no link to "Yocto Project Linux Kernel Development Manual".

Instead it shows link to "Yocto Project Development Tasks Manual" two times.



"Yocto Project Linux Kernel Development Manual" is gone

Vasyl Vavrychuk <vvavrychuk@...>
 

Latest "Docs Overview" webpage https://www.yoctoproject.org/docs/ has no link to "Yocto Project Linux Kernel Development Manual".

Instead it shows link to "Yocto Project Development Tasks Manual" two times.


distinction between "OEROOT" and "OE_ROOT" (used in toaster)?

Robert P. J. Day
 

messing with docs some more, and just noticed that while all else
under poky uses the variable OEROOT, the toaster executable uses
OE_ROOT. works fine, of course, given that toaster is self-contained,
just wondering if there was a reason for the subtle renaming.

rday

--

========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================


[meta-gplv2][PATCH] gettext: fix typos in PACKAGES

Yi Zhao
 

Fix typos:
${SODEV} -> ${SOLIBS}
${SOLIBDEV} -> ${SOLIBSDEV}

Also fix the indentation of SRC_URI.

Signed-off-by: Yi Zhao <yi.zhao@windriver.com>
---
recipes-core/gettext/gettext_0.16.1.bb | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/recipes-core/gettext/gettext_0.16.1.bb b/recipes-core/gettext/gettext_0.16.1.bb
index dacdfd3..9287a71 100644
--- a/recipes-core/gettext/gettext_0.16.1.bb
+++ b/recipes-core/gettext/gettext_0.16.1.bb
@@ -14,7 +14,7 @@ PROVIDES_class-native = "virtual/gettext-native"
SRC_URI = "${GNU_MIRROR}/gettext/gettext-${PV}.tar.gz \
file://gettext-vpath.patch \
file://linklib_from_0.17.patch \
- file://gettext-autoconf-lib-link-no-L.patch \
+ file://gettext-autoconf-lib-link-no-L.patch \
file://disable_java.patch \
file://fix_aclocal_version.patch \
file://fix_gnu_source_circular.patch \
@@ -78,7 +78,7 @@ FILES_gettext-runtime = "${bindir}/gettext \
${bindir}/ngettext \
${bindir}/envsubst \
${bindir}/gettext.sh \
- ${libdir}/libasprintf${SODEV} \
+ ${libdir}/libasprintf${SOLIBS} \
${libdir}/GNU.Gettext.dll \
"
FILES_gettext-runtime_append_libc-uclibc = " ${libdir}/libintl.so.* \
@@ -86,7 +86,7 @@ FILES_gettext-runtime_append_libc-uclibc = " ${libdir}/libintl.so.* \
"
FILES_gettext-runtime-staticdev += "${libdir}/libasprintf.a"
FILES_gettext-runtime-dev += "${includedir}/autosprintf.h \
- ${libdir}/libasprintf${SOLIBDEV}"
+ ${libdir}/libasprintf${SOLIBSDEV}"
FILES_gettext-runtime-dev_append_libc-uclibc = " ${libdir}/libintl.so \
${includedir}/libintl.h \
"
--
2.17.1


Re: What are the key factors for yocto build speed?

Martin Jansa
 

On 1600AF with 16G RAM and nvme drive it took ~ 38 hours, if you were running all 4 builds (as test.sh does), you can still finish the tests by running only the remaining build steps.

You can send me even partial results and I'll let you know if your times are expected or not (it should be very similar to this 1600AF, depends on how much swap you have and on how fast disks the swap and build is).

It's also possible that you didn't have enough swap and one of bitbake threads got killed by OOMK and then the rest was stuck forever.

Regards,

On Sat, Mar 21, 2020 at 7:39 PM Oliver Westermann <oliver.westermann@...> wrote:
On Wed, Mar 18, 2020 at 08:38 AM, Martin Jansa wrote:

If you want to compare how terrible your current VM compares with some
other builders, you can use:
https://github.com/shr-project/test-oe-build-time
Thanks for all the replies here, had some long days so no earlier answers.
I did test this on my home rig (2600X, 16G RAM) and it took ~ 24h until I aborted. Is this expected? I did not yet try on the VM ;D

- Olli


Re: What are the key factors for yocto build speed?

Oliver Westermann
 

On Wed, Mar 18, 2020 at 08:09 AM, Mike Looijmans wrote:
Of course he's on a tight budget. He wouldn't need to ask for advice otherwise...
When has a company ever given you a card blanche for equipment? :D

There is a budget and I just need to write down a good argument to spend it on something like this, the amount depends heavily on the arguments and this thread already provides a lot of arguments ;-)

Has anyone ever ran multiple bitbake instances (but with different users!) on a system?
If so: Any precautions needed there?


Re: What are the key factors for yocto build speed?

Oliver Westermann
 

On Wed, Mar 18, 2020 at 08:38 AM, Martin Jansa wrote:

If you want to compare how terrible your current VM compares with some
other builders, you can use:
https://github.com/shr-project/test-oe-build-time
Thanks for all the replies here, had some long days so no earlier answers.
I did test this on my home rig (2600X, 16G RAM) and it took ~ 24h until I aborted. Is this expected? I did not yet try on the VM ;D

- Olli


Re: Include B in image only if A is used

Peter Kjellerstedt
 

You could do:

 

RRECOMMENDS_${PN} += "networkmanager-custom-config”

 

in networkmanager_%.bbappend, and then:

 

COMPATIBLE_MACHINE = "<your machine>"

 

In the networkmanager-custom-config recipe. That should not cause the networkmanager recipe to become machine specific, but it will still pull in your configuration for your machine.

 

//Peter

 

From: yocto@... <yocto@...> On Behalf Of Nicolas Dechesne
Sent: den 21 mars 2020 09:37
To: yocto@...
Subject: [yocto] Include B in image only if A is used

 

hi,

 

what would be the proper/best mechanism to enforce that package_B is included in an image only if package_A is also included? This is mostly a 'BSP' fixup. My current need is that for a given machine, we need a custom/specific networkmanager configuration file. So I would like from the BSP layer to ensure that if anyone builds an image with networkmanager, then my networkmanager-custom-config package is also added.

 

of course, I can do a bbappend, but that make networkmanager 'machine' specific.. is there anything else that could be done from the BSP layer? Any existing hook or event I could use?

 

thanks!


Include B in image only if A is used

Nicolas Dechesne
 

hi,

what would be the proper/best mechanism to enforce that package_B is included in an image only if package_A is also included? This is mostly a 'BSP' fixup. My current need is that for a given machine, we need a custom/specific networkmanager configuration file. So I would like from the BSP layer to ensure that if anyone builds an image with networkmanager, then my networkmanager-custom-config package is also added.

of course, I can do a bbappend, but that make networkmanager 'machine' specific.. is there anything else that could be done from the BSP layer? Any existing hook or event I could use?

thanks!


Re: yocto on tinkerbaord using meta-rockchip

Karthik Poduval
 

Hi Trevor,

Thanks for getting back, I tried with tinker-board-s machine type but same result. I also tried flashing Asus Debian image on sdcard but that too didn't work (no console logs with this image). I am suspecting it's a hardware issue at this point. Any other suggestions or insights would be appreciated.

On Thu, Mar 19, 2020, 6:58 PM Trevor Woerner <twoerner@...> wrote:
Hi Karthik,

On Thu, Mar 19, 2020 at 9:36 PM karthik poduval
<karthik.poduval@...> wrote:
> Thank you for you work on meta-rockchip layer. You were listed as the
> maintainer for meta-rockchip so I though I will send you a mail with
> an issue I was facing.
>
> I was trying to flash an image on a Asus tinker board using
> meta-rockchip. Here are the steps I followed.
>
> git clone git://git.yoctoproject.org/poky
> git clone  git://git.yoctoproject.org/meta-rockchip
> source poky/oe-init-build-env
> bitbake-layers add-layer ../../meta-rockchip/
> MACHINE=tinker-board bitbake core-image-minimal
>
> #flahsed it using the following command to sdcard (my sdcard was dev/sde)
> sudo dd if=tmp/deploy/images/tinker-board/core-image-minimal-tinker-board.wic
> of=/dev/sde
>
> after inserting sdcard and booting up I can see on the serial console
> it attempts to boot, crosses bootloader and proceeds to linux boot but
> then gets hing around dwmmc_rockchip loading.
>
> Attached the complete serial log. Your help is greatly appreciated.

According to the log, your board is a "tinker-board-s", please try
using that for your MACHINE instead of "tinker-board".

Thanks and best regards,
    Trevor


Re: What are the key factors for yocto build speed?

Adrian Bunk
 

On Fri, Mar 20, 2020 at 03:58:35PM +0100, Mike Looijmans wrote:
...
(because octave is virtually impossible to cross-compile).
...
The recipe in meta-openembedded cross-compiles without problem.

cu
Adrian


Re: <EXT> Re: [yocto] What are the key factors for yocto build speed?

Philip Balister
 

On 3/18/20 11:47 AM, David Stewart wrote:
4 hours seems extremely long to me for a 8 core system, but I have not tried this in a while. Were you removing all the sources and re-downloading them for every build?
Depends on the image Dave, I build images with QT5 and gnuradio and they
take a while :) core-image-minimal is much faster.

Philip



From: <yocto@lists.yoctoproject.org> on behalf of Srini <rsrinivasan@abiomed.com>
Date: Wednesday, March 18, 2020 at 10:13 AM
To: "mikko.rapeli@bmw.de" <mikko.rapeli@bmw.de>, "mike.looijmans@topic.nl" <mike.looijmans@topic.nl>
Cc: "yocto@lists.yoctoproject.org" <yocto@lists.yoctoproject.org>
Subject: Re: <EXT> Re: [yocto] What are the key factors for yocto build speed?

My own experience (pardon me if already discussed)

Fought the build times for several months - ending up eventually at 8 cores (but specifying 16 threads in poky builds). Best times for my build about 4 hours. Clearly impractical during engineering.

Generated an sdk and used it for app development. Each build is now a minute or 2.

Using a homegrown utility, updated the image file with applications in a jiffy - to produce burnable sdcard image.

Complete build required only for the final release -- or made major changes like python2 to python3!

YMMV.

srini

-----Original Message-----
From: yocto@lists.yoctoproject.org<mailto:yocto@lists.yoctoproject.org> <yocto@lists.yoctoproject.org> On Behalf Of Mikko Rapeli via Lists.Yoctoproject.Org
Sent: Wednesday, March 18, 2020 11:52 AM
To: mike.looijmans@topic.nl<mailto:mike.looijmans@topic.nl>
Cc: yocto@lists.yoctoproject.org<mailto:yocto@lists.yoctoproject.org>
Subject: <EXT> Re: [yocto] What are the key factors for yocto build speed?

On Wed, Mar 18, 2020 at 04:09:39PM +0100, Mike Looijmans wrote:
On 18-03-2020 15:49, Adrian Bunk via Lists.Yoctoproject.Org wrote:
On Wed, Mar 18, 2020 at 10:12:26AM -0400, Jean-Marie Lemetayer wrote:
...
For example one of our build servers is using:
- AMD Ryzen 9 3900X
...
- 32Go DDR4 3200 MHZ CL14
...
It is a really good price / build time ratio configuration.
Depends on what you are building.

Building non-trivial C++ code (e.g. webkitgtk) with 24 cores but
only 32 GB RAM will not work, for such code you need more than 2
GB/core.
Seems a bit excessive to buy hardware just to handle a particular
corner case. Most of OE/Yocto code is plain C, not even C++.

My rig only has 8GB but doesn't run into memory issues during big GUI
builds. The only thing that made it swap was the populate_sdk task
that created a 1.1GB fiel and needed 20GB of RAM to compress that.
Took a few minutes more due to swapping.
I submitted a patch today to fix that in OE.

Your mileage may vary. But RAM is easy to add.
Well, I can't build with under 2 gigs per core or I run out of physical memory and kernel oom-killer kicks in to kill the build. Also can't run with yocto default parallel settings which only take into account the number of cores and thus have a custom script which does caps the threads so that 2 gigs of RAM for each are available.

Though I'm sure plain C and plain poky projects have less requirements for RAM.

-Mikko

________________________________

CONFIDENTIALITY NOTICE: This email message and any attachments are confidential and may be privileged and are meant to be read by the intended recipient only. If you are not the intended recipient, please notify sender immediately and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you




Re: Patching submodules

Emily
 

Hi Nicolas -

The recipe is already in a custom layer entirely, I just don’t have full control over the source. So I don’t think I need a .bbappend as I can just put it in the main recipe file.

Thanks,
Emily

On Mar 20, 2020, at 10:06 AM, Nicolas Jeker <n.jeker@delisys.ch> wrote:

On Thu, 2020-03-19 at 23:10 -0500, Emily wrote:
Hi all -

I have a recipe that I'd like to patch - the source is in a repo
which has a submodule, and the patch occurs in the submodule. Is
there a way I can apply this patch without getting an error? I do
kind of understand why it's a problem - the patch is changing the
pointer of the submodule to a commit which doesn't actually exist. Do
I need to build the submodule as a separate recipe and patch it
separately maybe?
Is there a reason why you don't use a bbappend file with your patch in
it in a custom layer?

Something like this:

package_ver.bbappend
--------------------
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
SRC_URI += "file://abc.patch"


With this directory structure:

meta-custom-layer
├── package_ver.bbappend
└── package
└── abc.patch

Replace "package" and "ver" with the correct values (if you don't want
to set the version you can use "%" as a wildcard).

Maybe I missed something about your submodule situation and my advice
is completely wrong, if so, just disregard it.

I used devtool for the patch and if I don't run the devtool reset
command, then everything builds, but I think this is just because the
workspace created by devtool was added as a layer, which probably
isn't a good long term solution.
You should be able to get the above structure by using 'devtool finish
recipe meta-custom-layer'. If that doesn't work you can do it manually
as described above.

The error I get (pasted below) says I can "enforce with -f" but I'm
not sure where that option goes exactly. Thanks for the help!

Emily

Error on build:
ERROR: opc-ua-server-gfex-1.0+gitAUTOINC+921c563309-r0 do_patch:
Command Error: 'quilt --quiltrc
/local/d6/easmith5/rocko_bitbake/poky/build/tmp/work/aarch64-poky-
linux/opc-ua-server-gfex/1.0+gitAUTOINC+921c563309-r0/recipe-sysroot-
native/etc/quiltrc push' exited with 0 Output:
Applying patch 0001-Update-Poverty-to-point-to-boost-python3.patch
File Poverty is not a regular file -- refusing to patch
1 out of 1 hunk ignored -- rejects in file
Patch 0001-Update-Poverty-to-point-to-boost-python3.patch does not
apply (enforce with -f)
ERROR: opc-ua-server-gfex-1.0+gitAUTOINC+921c563309-r0 do_patch:
Function failed: patch_do_patch
I don't know why this error occurs, maybe someone else knows more.


Re: Patching submodules

Yann Dirson
 

Hi Emily,

I'm not sure how the patch is generated, and (not using devtool myself) I may understood your problem wrongly
(showing the relevant part of your diff could help), but you could try to generate it yourself with
"git show --submodule=diff", that could be more palatable to quilt.


Le ven. 20 mars 2020 à 16:09, Paul Barker <pbarker@...> a écrit :
On Fri, 20 Mar 2020 at 04:10, Emily <easmith5555@...> wrote:
>
> Hi all -
>
> I have a recipe that I'd like to patch - the source is in a repo which has a submodule, and the patch occurs in the submodule. Is there a way I can apply this patch without getting an error? I do kind of understand why it's a problem - the patch is changing the pointer of the submodule to a commit which doesn't actually exist. Do I need to build the submodule as a separate recipe and patch it separately maybe?
>
> I used devtool for the patch and if I don't run the devtool reset command, then everything builds, but I think this is just because the workspace created by devtool was added as a layer, which probably isn't a good long term solution.
>
> The error I get (pasted below) says I can "enforce with -f" but I'm not sure where that option goes exactly. Thanks for the help!
>
> Emily
>
> Error on build:
> ERROR: opc-ua-server-gfex-1.0+gitAUTOINC+921c563309-r0 do_patch: Command Error: 'quilt --quiltrc /local/d6/easmith5/rocko_bitbake/poky/build/tmp/work/aarch64-poky-linux/opc-ua-server-gfex/1.0+gitAUTOINC+921c563309-r0/recipe-sysroot-native/etc/quiltrc push' exited with 0  Output:
> Applying patch 0001-Update-Poverty-to-point-to-boost-python3.patch
> File Poverty is not a regular file -- refusing to patch
> 1 out of 1 hunk ignored -- rejects in file
> Patch 0001-Update-Poverty-to-point-to-boost-python3.patch does not apply (enforce with -f)
> ERROR: opc-ua-server-gfex-1.0+gitAUTOINC+921c563309-r0 do_patch: Function failed: patch_do_patch

The issue appears to be that patches are applied using quilt which
doesn't understand a patch like this. I don't know of a good solution
to this other than making a new commit in the top level repository and
updating SRCREV.

Perhaps it's better to carry the diff within the submodule as a patch
- so you leave the submodule commit pointer where it is and instead
include all the necessary changes to the submodule in the patch. Would
that work for you?



--
Yann Dirson <yann@...>
Blade / Shadow -- http://shadow.tech


Re: yocto on tinkerbaord using meta-rockchip

Philip Balister
 

On 3/20/20 3:10 AM, Yann Dirson wrote:
Wow, I'm suprised to discover this meta-rockchip :)

Rockchip engineers also publish a meta-rockchip on Github (
https://github.com/rockchip-linux/meta-rockchip), although
nowadays it's mainly Jeffy Chen publishing on
https://github.com/JeffyCN/meta-rockchip/

Those two repos seem quite complementary, Jeffy being focussed on kernel
4.4, and Trevor on mainline.
Wouldn't it make sense to merge all this work in a single place ?
Yes :) But you observe the key issue, Trevor is correctly focused on the
upstream kernel and the vendor layer on an old vendor kernel. The vendor
kernels rapidly turn into maintenance nightmares over a product lifetime.

Philip


Le ven. 20 mars 2020 à 02:59, Trevor Woerner <twoerner@gmail.com> a écrit :

Hi Karthik,

On Thu, Mar 19, 2020 at 9:36 PM karthik poduval
<karthik.poduval@gmail.com> wrote:
Thank you for you work on meta-rockchip layer. You were listed as the
maintainer for meta-rockchip so I though I will send you a mail with
an issue I was facing.

I was trying to flash an image on a Asus tinker board using
meta-rockchip. Here are the steps I followed.

git clone git://git.yoctoproject.org/poky
git clone git://git.yoctoproject.org/meta-rockchip
source poky/oe-init-build-env
bitbake-layers add-layer ../../meta-rockchip/
MACHINE=tinker-board bitbake core-image-minimal

#flahsed it using the following command to sdcard (my sdcard was dev/sde)
sudo dd
if=tmp/deploy/images/tinker-board/core-image-minimal-tinker-board.wic
of=/dev/sde

after inserting sdcard and booting up I can see on the serial console
it attempts to boot, crosses bootloader and proceeds to linux boot but
then gets hing around dwmmc_rockchip loading.

Attached the complete serial log. Your help is greatly appreciated.
According to the log, your board is a "tinker-board-s", please try
using that for your MACHINE instead of "tinker-board".

Thanks and best regards,
Trevor





Re: What are the key factors for yocto build speed?

Mike Looijmans
 

On 19-03-2020 18:21, Adrian Bunk wrote:
On Thu, Mar 19, 2020 at 05:07:17PM +0100, Mike Looijmans wrote:
...
With both parallelization options
to "16", I might end up with 16 compile tasks running 16 compile threads
each, i.e. 256 running processes.
...
This is a bug:
http://bugzilla.yoctoproject.org/show_bug.cgi?id=13306
I sometimes wonder whether something basic like "no more than one
compile task at a time" would be sufficient in practice to avoid
overloading all cores.
It would also help with RAM usage, there are some combinations of
recipes where the build gets aborted by the oom killer on my laptop
(8 cores, 32 GB RAM) when bitbake runs the compile tasks in parallel.

I tried compiling octave on an ARM board with 1GB of RAM (because octave is virtually impossible to cross-compile). There was one C++ in there that triggered a huge memory load of about 1GB, thus failing to run fully in RAM. Had to create an extra 1GB swap on the SD card to get the build to succeed. The actual swap usage wasn't much, and I could finish the build with two threads even (a dual core ARM yay).

So the memory usage is dependent on what's in the C++ file. Especially heavy template programming can put a huge load on memory. There's no way to predict that beforehand.


--
Mike Looijmans


Re: Patching submodules

Emily
 

Hi Paul -

I’m not sure what you mean by “include all the necessary changes to the submodule in the patch”, because anytime I change something in the submodule then the git diff for the main repo just shows a change to the submodule as a whole, not a specific file inside the submodule.

I don’t have complete control over the source but maybe I’ll see if I can make a change to the submodule itself, that seems to be the easiest.

Thanks,
Emily

On Mar 20, 2020, at 6:18 AM, Paul Barker <pbarker@konsulko.com> wrote:

On Fri, 20 Mar 2020 at 04:10, Emily <easmith5555@gmail.com> wrote:

Hi all -

I have a recipe that I'd like to patch - the source is in a repo which has a submodule, and the patch occurs in the submodule. Is there a way I can apply this patch without getting an error? I do kind of understand why it's a problem - the patch is changing the pointer of the submodule to a commit which doesn't actually exist. Do I need to build the submodule as a separate recipe and patch it separately maybe?

I used devtool for the patch and if I don't run the devtool reset command, then everything builds, but I think this is just because the workspace created by devtool was added as a layer, which probably isn't a good long term solution.

The error I get (pasted below) says I can "enforce with -f" but I'm not sure where that option goes exactly. Thanks for the help!

Emily

Error on build:
ERROR: opc-ua-server-gfex-1.0+gitAUTOINC+921c563309-r0 do_patch: Command Error: 'quilt --quiltrc /local/d6/easmith5/rocko_bitbake/poky/build/tmp/work/aarch64-poky-linux/opc-ua-server-gfex/1.0+gitAUTOINC+921c563309-r0/recipe-sysroot-native/etc/quiltrc push' exited with 0 Output:
Applying patch 0001-Update-Poverty-to-point-to-boost-python3.patch
File Poverty is not a regular file -- refusing to patch
1 out of 1 hunk ignored -- rejects in file
Patch 0001-Update-Poverty-to-point-to-boost-python3.patch does not apply (enforce with -f)
ERROR: opc-ua-server-gfex-1.0+gitAUTOINC+921c563309-r0 do_patch: Function failed: patch_do_patch
The issue appears to be that patches are applied using quilt which
doesn't understand a patch like this. I don't know of a good solution
to this other than making a new commit in the top level repository and
updating SRCREV.

Perhaps it's better to carry the diff within the submodule as a patch
- so you leave the submodule commit pointer where it is and instead
include all the necessary changes to the submodule in the patch. Would
that work for you?


Re: Patching submodules

 

On Fri, 20 Mar 2020 at 04:10, Emily <easmith5555@gmail.com> wrote:

Hi all -

I have a recipe that I'd like to patch - the source is in a repo which has a submodule, and the patch occurs in the submodule. Is there a way I can apply this patch without getting an error? I do kind of understand why it's a problem - the patch is changing the pointer of the submodule to a commit which doesn't actually exist. Do I need to build the submodule as a separate recipe and patch it separately maybe?

I used devtool for the patch and if I don't run the devtool reset command, then everything builds, but I think this is just because the workspace created by devtool was added as a layer, which probably isn't a good long term solution.

The error I get (pasted below) says I can "enforce with -f" but I'm not sure where that option goes exactly. Thanks for the help!

Emily

Error on build:
ERROR: opc-ua-server-gfex-1.0+gitAUTOINC+921c563309-r0 do_patch: Command Error: 'quilt --quiltrc /local/d6/easmith5/rocko_bitbake/poky/build/tmp/work/aarch64-poky-linux/opc-ua-server-gfex/1.0+gitAUTOINC+921c563309-r0/recipe-sysroot-native/etc/quiltrc push' exited with 0 Output:
Applying patch 0001-Update-Poverty-to-point-to-boost-python3.patch
File Poverty is not a regular file -- refusing to patch
1 out of 1 hunk ignored -- rejects in file
Patch 0001-Update-Poverty-to-point-to-boost-python3.patch does not apply (enforce with -f)
ERROR: opc-ua-server-gfex-1.0+gitAUTOINC+921c563309-r0 do_patch: Function failed: patch_do_patch
The issue appears to be that patches are applied using quilt which
doesn't understand a patch like this. I don't know of a good solution
to this other than making a new commit in the top level repository and
updating SRCREV.

Perhaps it's better to carry the diff within the submodule as a patch
- so you leave the submodule commit pointer where it is and instead
include all the necessary changes to the submodule in the patch. Would
that work for you?


Re: Patching submodules

Nicolas Jeker
 

On Thu, 2020-03-19 at 23:10 -0500, Emily wrote:
Hi all -

I have a recipe that I'd like to patch - the source is in a repo
which has a submodule, and the patch occurs in the submodule. Is
there a way I can apply this patch without getting an error? I do
kind of understand why it's a problem - the patch is changing the
pointer of the submodule to a commit which doesn't actually exist. Do
I need to build the submodule as a separate recipe and patch it
separately maybe?
Is there a reason why you don't use a bbappend file with your patch in
it in a custom layer?

Something like this:

package_ver.bbappend
--------------------
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
SRC_URI += "file://abc.patch"


With this directory structure:

meta-custom-layer
├── package_ver.bbappend
└── package
└── abc.patch

Replace "package" and "ver" with the correct values (if you don't want
to set the version you can use "%" as a wildcard).

Maybe I missed something about your submodule situation and my advice
is completely wrong, if so, just disregard it.

I used devtool for the patch and if I don't run the devtool reset
command, then everything builds, but I think this is just because the
workspace created by devtool was added as a layer, which probably
isn't a good long term solution.
You should be able to get the above structure by using 'devtool finish
recipe meta-custom-layer'. If that doesn't work you can do it manually
as described above.

The error I get (pasted below) says I can "enforce with -f" but I'm
not sure where that option goes exactly. Thanks for the help!

Emily

Error on build:
ERROR: opc-ua-server-gfex-1.0+gitAUTOINC+921c563309-r0 do_patch:
Command Error: 'quilt --quiltrc
/local/d6/easmith5/rocko_bitbake/poky/build/tmp/work/aarch64-poky-
linux/opc-ua-server-gfex/1.0+gitAUTOINC+921c563309-r0/recipe-sysroot-
native/etc/quiltrc push' exited with 0 Output:
Applying patch 0001-Update-Poverty-to-point-to-boost-python3.patch
File Poverty is not a regular file -- refusing to patch
1 out of 1 hunk ignored -- rejects in file
Patch 0001-Update-Poverty-to-point-to-boost-python3.patch does not
apply (enforce with -f)
ERROR: opc-ua-server-gfex-1.0+gitAUTOINC+921c563309-r0 do_patch:
Function failed: patch_do_patch
I don't know why this error occurs, maybe someone else knows more.


Re: yocto on tinkerbaord using meta-rockchip

Yann Dirson
 

Wow, I'm suprised to discover this meta-rockchip :)

Rockchip engineers also publish a meta-rockchip on Github (https://github.com/rockchip-linux/meta-rockchip), although
nowadays it's mainly Jeffy Chen publishing on https://github.com/JeffyCN/meta-rockchip/

Those two repos seem quite complementary, Jeffy being focussed on kernel 4.4, and Trevor on mainline.
Wouldn't it make sense to merge all this work in a single place ?


Le ven. 20 mars 2020 à 02:59, Trevor Woerner <twoerner@...> a écrit :
Hi Karthik,

On Thu, Mar 19, 2020 at 9:36 PM karthik poduval
<karthik.poduval@...> wrote:
> Thank you for you work on meta-rockchip layer. You were listed as the
> maintainer for meta-rockchip so I though I will send you a mail with
> an issue I was facing.
>
> I was trying to flash an image on a Asus tinker board using
> meta-rockchip. Here are the steps I followed.
>
> git clone git://git.yoctoproject.org/poky
> git clone  git://git.yoctoproject.org/meta-rockchip
> source poky/oe-init-build-env
> bitbake-layers add-layer ../../meta-rockchip/
> MACHINE=tinker-board bitbake core-image-minimal
>
> #flahsed it using the following command to sdcard (my sdcard was dev/sde)
> sudo dd if=tmp/deploy/images/tinker-board/core-image-minimal-tinker-board.wic
> of=/dev/sde
>
> after inserting sdcard and booting up I can see on the serial console
> it attempts to boot, crosses bootloader and proceeds to linux boot but
> then gets hing around dwmmc_rockchip loading.
>
> Attached the complete serial log. Your help is greatly appreciated.

According to the log, your board is a "tinker-board-s", please try
using that for your MACHINE instead of "tinker-board".

Thanks and best regards,
    Trevor



--
Yann Dirson <yann@...>
Blade / Shadow -- http://shadow.tech

8221 - 8240 of 57104