|
Re: "Yocto Project Linux Kernel Development Manual" is gone
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:
|
|
|
|
"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".
|
|
|
|
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:
|
|
|
|
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:
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
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,
|
|
|
|
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:
...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
|
|
|
|
Re: Patching submodules
Emily
Hi Nicolas -
toggle quoted messageShow quoted text
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:
|
|
|
|
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:
|
|
|
|
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 :)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
|
|
|
|
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:...This is a bug: 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 -
toggle quoted messageShow quoted text
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:
|
|
|
|
Re: Patching submodules
On Fri, 20 Mar 2020 at 04:10, Emily <easmith5555@gmail.com> wrote:
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 -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 resetYou 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'mI 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,
|
|
|