Re: [yocto] patches to upgrade meta-jupyter layer packages

[Khem Raj]

On Mon, Nov 18, 2019 at 4:30 PM Chandana Kalluri  wrote:
>
>
> > -Original Message-
> > From: Khem Raj 
> > Sent: Monday, November 18, 2019 4:21 PM
> > To: Chandana Kalluri 
> > Cc: yocto@yoctoproject.org
> > Subject: Re: [yocto] patches to upgrade meta-jupyter layer packages
> >
> > On Mon, Nov 18, 2019 at 4:17 PM Chandana Kalluri 
> > wrote:
> > >
> > > Hello all,
> > >
> > > I have upgraded python packages from meta-jupyter layer to work with the
> > zeus branch.
> > > I am planning to send out the patches to this yocto project mailing list
> > yocto@yoctoproject.org Please let me know if this is alright or if I need to
> > send them to a different mailing list.
> >
> > have you upgraded the recipes in meta-jupyter ? if so then it should be
> > reviewed as per that layers policy, if you are looking for migrating the 
> > recipes
> > from above layer into other layers which use yocto ml for patch submission
> > then its ok
> >
> [CKalluri] Ive upgraded recipes in meta-jupyter layer. There is no mailing 
> list specific to meta-jupyter layer hence the question where to send the 
> patches for upgrade.

perhaps you should contact the manitainers, and if its on github then
github pull requests are usually accepted but
its better to find out. Its good to look at README files e.g.

https://github.com/Xilinx/meta-jupyter/blob/master/README.md

Lists that it accepts github pulls

> > >
> > > Thanks,
> > > Chandana
> > >
> > > --
> > > ___
> > > yocto mailing list
> > > yocto@yoctoproject.org
> > > https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] patches to upgrade meta-jupyter layer packages

[Khem Raj]

On Mon, Nov 18, 2019 at 4:17 PM Chandana Kalluri  wrote:
>
> Hello all,
>
> I have upgraded python packages from meta-jupyter layer to work with the zeus 
> branch.
> I am planning to send out the patches to this yocto project mailing list 
> yocto@yoctoproject.org Please let me know if this is alright or if I need to 
> send them to a different mailing list.

have you upgraded the recipes in meta-jupyter ? if so then it should
be reviewed as per that layers policy, if you are looking
for migrating the recipes from above layer into other layers which use
yocto ml for patch submission then its ok

>
> Thanks,
> Chandana
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [qemu] can't find qemu-native recipe

[Khem Raj]

On Mon, Nov 18, 2019 at 4:10 PM Greg Wilson-Lindberg
 wrote:
>
> Hi Khem,
>
> I found the BBCLASSEXTEND in the qemu.inc file, I also found a line in the 
> .bb file:
>
> SRC_URI_append_class-native = " \
>
>
> so I changed my SRC_URI to that and I stopped getting the 'can't find file to 
> patch' error, but the file (syscall.c) is not modified.
>
>
> Here is my qemu_3.0.0.bbappend file, 
> meta-sakura/recipes-devtools/qemu/qemu_3.0.0.bbappend:
>
> FILESEXTRAPATHS_prepend := "${FILE_DIRNAME}/${PN}:"
>
> SRC_URII_append_class-native = 
> "file://syscall.c-add_missing_sockios_header_include.patch"
   ^^
If you pasted exactly what you have then there is a typo above it
should be SRC_URI_append_class-native ...

> And here is the patch file 
> .../qemu/syscall.c-add_missing_sockios_header_include.patch:
> --- a/linux-user/syscall.c2019-11-18 09:42:39.0 -0800
> +++ b/linux-user/syscall.c2019-11-18 09:23:23.0 -0800
> @@ -34,6 +34,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
>
> I am not getting the:
>
> ...tmp/work/x86_64-linux/qemu-native/3.0.0-r0/qemu-3.0.0/linux-user/syscall.c
>
> modified.
>
>
> I'm obviously missing something. Any help would be greatly appreciated.
>
>
> Regards,
>
> Greg
>
>
> 
> From: Khem Raj 
> Sent: Monday, November 18, 2019 3:30:27 PM
> To: Greg Wilson-Lindberg
> Cc: Yocto list discussion
> Subject: Re: [yocto] [qemu] can't find qemu-native recipe
>
> On Mon, Nov 18, 2019 at 3:27 PM Greg Wilson-Lindberg
>  wrote:
> >
> > I'm building thud for the raspberry pi3 for boot2qt on Ubuntu 18.04.
> > I've got a patch that I need to apply to to fix an include file problem and 
> > I can't find the qemu-native recipe. I can find a number of recipes that 
> > depend in one way or another on 'qemu-native', but I can't find a recipe, 
> > class for it or anything that provides it. I can see it being built, and I 
> > get an error that indicates that the patch that I have needs to be applied. 
> > I can find tmp/work/x86_64-linux/qemu-native/.
> >
> > In the cooker log I see:
> > task qemu_3.0.0
> > recipe qemu-native-3.0.0
> >
> > But I can't find a qemu-native.bb file,or bbclass.
> >
> > I'm rather confused at this point, can someone shed a bit of light on what 
> > I'm missing?
> >
>
> there must be BBCLASSEXTEND = "native" in qemu recipe which
> essentially automatically extends the recipe for native case
>
> see
> https://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#var-BBCLASSEXTEND
>
> > Regards,
> > Greg Wilson-Lindberg
> >
> > --
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [qemu] can't find qemu-native recipe

[Khem Raj]

On Mon, Nov 18, 2019 at 3:27 PM Greg Wilson-Lindberg
 wrote:
>
> I'm building thud for the raspberry pi3 for boot2qt on Ubuntu 18.04.
> I've got a patch that I need to apply to to fix an include file problem and I 
> can't find the qemu-native recipe. I can find a number of recipes that depend 
> in one way or another on 'qemu-native', but I can't find a recipe, class for 
> it or anything that provides it. I can see it being built, and I get an error 
> that indicates that the patch that I have needs to be applied. I can find 
> tmp/work/x86_64-linux/qemu-native/.
>
> In the cooker log I see:
> task qemu_3.0.0
> recipe qemu-native-3.0.0
>
> But I can't find a qemu-native.bb file,or bbclass.
>
> I'm rather confused at this point, can someone shed a bit of light on what 
> I'm missing?
>

there must be BBCLASSEXTEND = "native" in qemu recipe which
essentially automatically extends the recipe for native case

see
https://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#var-BBCLASSEXTEND

> Regards,
> Greg Wilson-Lindberg
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] QA notification for completed autobuilder build (yocto-2.7.2.rc1)

[Khem Raj]

looks good to me.

On Sun, Nov 17, 2019 at 11:00 PM Jain, Sangeeta  wrote:
>
> Hello all,
>
> This is the full report for 2.7.2 RC1:
> https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults
>
> === Summary 
> No high milestone defects.
> No new defect found in this cycle.
>
>
> Thanks & Regards,
> Sangeeta Jain
>
> >-Original Message-
> >From: Pokybuild User 
> >Sent: Thursday, October 31, 2019 1:23 AM
> >To: yocto@yoctoproject.org
> >Cc: ota...@ossystems.com.br; yi.z...@windriver.com; Sangal, Apoorv
> >; Yeoh, Ee Peng ; Chan,
> >Aaron Chun Yew ; Ang, Chin Huat
> >; richard.pur...@linuxfoundation.org;
> >akuster...@gmail.com; sjolley.yp...@gmail.com; Jain, Sangeeta
> >
> >Subject: QA notification for completed autobuilder build (yocto-2.7.2.rc1)
> >
> >
> >A build flagged for QA (yocto-2.7.2.rc1) was completed on the autobuilder 
> >and is
> >available at:
> >
> >
> >https://autobuilder.yocto.io/pub/releases/yocto-2.7.2.rc1
> >
> >
> >Build hash information:
> >
> >bitbake: 75d6648f232a06b99c54a1e33324a7fc1cd15b38
> >meta-gplv2: d5d9fc9a4bbd365d6cd6fe4d6a8558f7115c17da
> >meta-intel: ca26bed652722167b2dbe0042cfc2406029e9c6c
> >meta-mingw: 10695afe8cd406844e0d0dd868c11677e07557d4
> >oecore: 726c3b92298981f5aa2f2449ceeec7b4bf84ed29
> >poky: d0f73121551dc98f6924cd77952bf9ebf5ef3dd7
> >
> >
> >
> >This is an automated message from the Yocto Project Autobuilder
> >Git: git://git.yoctoproject.org/yocto-autobuilder2
> >Email: richard.pur...@linuxfoundation.org
> >
> >
> >
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Adding a custom environment variable

[Khem Raj]

On Fri, 2019-11-15 at 12:29 +0100, Deepika Teriar wrote:
> Hi,
> 
> I have a module called unit-tests.
> I want to create an environment variable so that at compile time I
> can select whether to add or remove the module from build.
> 

perhaps look into ptest distro feature.

> Thanks
> Deepika

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

Re: [yocto] [meta-raspberrypi][PATCH] wic: add swap partition and set /root and /swap size

[Khem Raj]

On Thu, 2019-11-14 at 06:04 +, Hongxu Jia wrote:
> - Add swap partition to workaround memory limitation
> 
> - Support to set /root and /swap size, 4G /root and 1G /swap by
> default
> 
> Signed-off-by: Hongxu Jia 
> ---
>  conf/machine/include/rpi-base.inc   | 5
> -
>  wic/{sdimage-raspberrypi.wks => sdimage-raspberrypi.wks.in} | 3 ++-
>  2 files changed, 6 insertions(+), 2 deletions(-)
>  rename wic/{sdimage-raspberrypi.wks => sdimage-raspberrypi.wks.in}
> (75%)
> 
> diff --git a/conf/machine/include/rpi-base.inc
> b/conf/machine/include/rpi-base.inc
> index 36a8daf..de2f366 100644
> --- a/conf/machine/include/rpi-base.inc
> +++ b/conf/machine/include/rpi-base.inc
> @@ -6,7 +6,10 @@ SOC_FAMILY = "rpi"
>  include conf/machine/include/soc-family.inc
>  
>  IMAGE_FSTYPES ?= "tar.bz2 ext3 rpi-sdimg"
> -WKS_FILE ?= "sdimage-raspberrypi.wks"
> +
> +PI_WKS_ROOT_SIZE ?= "--size=4096M --overhead-factor 1"

this means we need minimum 4G cards.

> +PI_WKS_SWAP_SIZE ?= "--size=1024M --overhead-factor 1"

I think these options should be not set here. if someone wants they
should be injected by local config.

> +WKS_FILE ?= "sdimage-raspberrypi.wks.in"
>  
>  XSERVER = " \
>  xserver-xorg \
> diff --git a/wic/sdimage-raspberrypi.wks b/wic/sdimage-
> raspberrypi.wks.in
> similarity index 75%
> rename from wic/sdimage-raspberrypi.wks
> rename to wic/sdimage-raspberrypi.wks.in
> index 01fbaea..81707c7 100644
> --- a/wic/sdimage-raspberrypi.wks
> +++ b/wic/sdimage-raspberrypi.wks.in
> @@ -3,4 +3,5 @@
>  # Raspberry Pi. Boot files are located in the first vfat partition.
>  
>  part /boot --source bootimg-partition --ondisk mmcblk0 --fstype=vfat 
> --label boot --active --align 4096 --size 20
> -part / --source rootfs --ondisk mmcblk0 --fstype=ext4 --label root
> --align 4096
> +part / --source rootfs --ondisk mmcblk0 --fstype=ext4 --label root
> --align 4096 ${PI_WKS_ROOT_SIZE}
> +part swap --ondisk mmcblk0 --size 44 --label swap --fstype=swap
> ${PI_WKS_SWAP_SIZE}

its using --size 44, perhaps thats default if its not set via
PI_WKS_SWAP_SIZE

> -- 
> 2.17.1
> 

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

Re: [yocto] Collaboration on Testing GCC/LLVM Toolchains

[Khem Raj]

On Wed, Nov 13, 2019 at 4:02 PM Nicholas Krause  wrote:
>
> Greetings All,
>
> I'm a student working on multi-threading GCC and researching it. Seems
> that it my
>
> time doing it and other things with the project it would be great to
> start collaborating
>
> on testing gcc/llvm upstream with Yocto. Granted there is a testsuite
> for both but it
>
> would be great to also test it against a build system that builds real
> world software.
>
> Furthermore I'm aware that this is done for Yocto toolchain selection
> internally but it
>
> would be great if we can start collaborating on testing upstream
> toolchains if
>
> possible.

I think its a good idea. Currently, we test released versions mostly,
however, there is
a class to switch to git versions and primarily be able to use tip of
master for a given
recipe, this would be something I wish we had but so far we have not
fully completed it
I know Ross had started this work and created initial skeleton, So
step one would be to
complete that class so we can easily switch recipes to use dev
versions of packages
this will go beyond GCC but certainly will be a tremendous achievement.

>
>
> Not sure if that's done already so sorry for the noise if it is,
>
> Nick
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] puzzle: simple recipe gets image dependencies

[Khem Raj]

On Wed, Nov 13, 2019 at 3:42 PM Vladimir Molokov 
wrote:

> thank you for your answer!
>
> when I comment out DEPENDS = "attr" line in "example" recipe
> then there is no "bad-example" dependency:
> https://gitlab.com/morokov/build/raw/master/task-depends-without-attr.dot
>
> > Alright, so you have initramfs enabled it seems. Which means kernel
> > will first try to build designated
> > initramfs image which in your case is
> >
> > "linux-yocto.do_bundle_initramfs" ->
> "core-image-minimal.do_image_complete"
> >
> > and then core-image-minimal includes bad-example
> >
> > "core-image-minimal.do_image_complete" ->
> "bad-example.do_populate_sysroot"
> >
> > and example does ask kernel to be deployed
> >
> > "example.do_build" -> "linux-yocto.do_deploy"
> >
> >
> > so that completes the chain.
>
> "example" is just a simple recipe, it doesn't inherit image class
> it doesn't even belong to any image, just standalone recipe.
> I don't quite get the logic around initramfs


Initramfs is an image that is bundled into kernel binary so you are
essentially building an image before you can create kernel binary
thereafter you build full image and your build is choking on this small
image which infact is a regular image and will respect image depends

>
> why does it add those dependencies to "example" recipe?
> it doesn't if "attr" is commented out.


Possible that attr dependencies traverse down to kernel

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

Re: [yocto] puzzle: simple recipe gets image dependencies

[Khem Raj]

On Wed, Nov 13, 2019 at 12:45 PM Vladimir Molokov
 wrote:
>
> > can you share this dot file ?
> sure:
> http://gitlab.com/morokov/build/raw/master/task-depends.dot
>

Alright, so you have initramfs enabled it seems. Which means kernel
will first try to build designated
initramfs image which in your case is

"linux-yocto.do_bundle_initramfs" -> "core-image-minimal.do_image_complete"

and then core-image-minimal includes bad-example

"core-image-minimal.do_image_complete" -> "bad-example.do_populate_sysroot"

and example does ask kernel to be deployed

"example.do_build" -> "linux-yocto.do_deploy"


so that completes the chain.

Hope that helps.


> also here are more files from the build directory, just in case:
> https://gitlab.com/morokov/build/
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] pkg-config not found

[Khem Raj]

On Wed, 2019-11-13 at 11:43 -0600, Mark Hawthorne wrote:
> I figured out the problem. The call to AX_PTHREAD() was breaking
> PKG_PROG_PKG_CONFIG. I don't understand why, but it works once I
> remove that line.

Swap the order, let PKG_PROG_PKG_CONFIG appear before AX_PTHREAD

> 
> On Tue, Nov 12, 2019 at 8:24 PM Mark Hawthorne <
> markhawthorne...@gmail.com> wrote:
> > I added the lines you suggested and it indicates that PKG_CONFIG is
> > not set. What would cause this to fail in the bitbake environment?
> > It works for other packages such as pixman.
> > 
> > On Tue, Nov 12, 2019 at 6:38 PM Khem Raj 
> > wrote:
> > > On Tue, Nov 12, 2019 at 4:29 PM Mark Hawthorne
> > >  wrote:
> > > >
> > > > Khem,
> > > >
> > > > I found a recipe that you made a few years ago where you
> > > addressed this problem:
> > > >
> > > > 
> > > http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-extended/boinc/boinc-client_7.12.bb
> > > >
> > > > You solved it by exporting PKG_CONFIG
> > > >
> > > > export PKG_CONFIG = "${STAGING_BINDIR_NATIVE}/pkg-config"
> > > >
> > > > This seems like it may be the incorrect way to do it and there
> > > needs to be an update in the configure.ac file instead?
> > > 
> > > in configure.ac you can add something like this
> > > 
> > > PKG_PROG_PKG_CONFIG
> > > if test -z "$PKG_CONFIG"; then
> > >   AC_MSG_WARN([Cannot find pkg-config, make sure it is installed
> > > in your PATH])
> > > fi
> > > 
> > > >
> > > > On Tue, Nov 12, 2019 at 4:44 PM Mark Hawthorne <
> > > markhawthorne...@gmail.com> wrote:
> > > >>
> > > >> No, it did not help
> > > >>
> > > >> It appears from the config.log file that the PKG_CONFIG
> > > variable never gets set. I'm sorting through the bbclass files to
> > > figure out why this is not getting set...
> > > >>
> > > >> PKG_CONFIG=''
> > > >> PKG_CONFIG_LIBDIR='/home/mark/Documents/tisdk/build/arago-tmp-
> > > external-arm-toolchain/work/armv7at2hf-neon-linux-
> > > gnueabi/myprogram/1.0-r0/recipe-sysroot/usr/lib/pkgconfig'
> > > >> PKG_CONFIG_PATH='/home/mark/Documents/tisdk/build/arago-tmp-
> > > external-arm-toolchain/work/armv7at2hf-neon-linux-
> > > gnueabi/myprogram/1.0-r0/recipe-
> > > sysroot/usr/lib/pkgconfig:/home/mark/Documents/tisdk/build/arago-
> > > tmp-external-arm-toolchain/work/armv7at2hf-neon-linux-
> > > gnueabi/myprogram/1.0-r0/recipe-sysroot/usr/share/pkgconfig'
> > > >>
> > > >> On Tue, Nov 12, 2019 at 4:22 PM Khem Raj 
> > > wrote:
> > > >>>
> > > >>> On Tue, Nov 12, 2019 at 2:00 PM Mark Hawthorne
> > > >>>  wrote:
> > > >>> >
> > > >>> > Thank you. I have fixed this issue but the original pkg-
> > > config error still persists.
> > > >>> >
> > > >>>
> > > >>> do a clean build after above change
> > > >>>
> > > >>> bitbake -ccleanall 
> > > >>> bitbake 
> > > >>>
> > > >>> does that help ?
> > > >>>
> > > >>> > On Tue, Nov 12, 2019 at 3:41 PM Adrian Bunk  > > > wrote:
> > > >>> >>
> > > >>> >> On Tue, Nov 12, 2019 at 03:06:25PM -0600, Mark Hawthorne
> > > wrote:
> > > >>> >> >...
> > > >>> >> > DEPENDS_${PN} = "libpng freetype glm libegl libgles2
> > > libspatialite"
> > > >>> >> >...
> > > >>> >>
> > > >>> >> DEPENDS, not DEPENDS_${PN}
> > > >>> >>
> > > >>> >> cu
> > > >>> >> Adrian
> > > >>> >>
> > > >>> >> --
> > > >>> >>
> > > >>> >>"Is there not promise of rain?" Ling Tan asked
> > > suddenly out
> > > >>> >> of the darkness. There had been need of rain for
> > > many days.
> > > >>> >>"Only a promise," Lao Er said.
> > > >>> >>Pearl S. Buck -
> > > Dragon Seed
> > > >>> >>
> > > >>> > --
> > > >>> > ___
> > > >>> > yocto mailing list
> > > >>> > yocto@yoctoproject.org
> > > >>> > https://lists.yoctoproject.org/listinfo/yocto
> > > >
> > > > --
> > > > ___
> > > > yocto mailing list
> > > > yocto@yoctoproject.org
> > > > https://lists.yoctoproject.org/listinfo/yocto

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

Re: [yocto] bitbake -c populate_sdk generates locale error

[Khem Raj]

On Wed, 2019-11-13 at 16:12 +, Matt Schepers wrote:
> Hi,
> 
> When I run 'bitbake  -c populate_sdk' I get an error about the
> locale not being found. I have tried setting the locale in local.conf
> but that didn't seem to help. The odd thing is that 'bitbake '
> works just fine.
> 
> Respectfully,
> Matt Schepers
> 
> ERROR: telspan-dh3-1.0-r0 do_populate_sdk: Error executing a python
> function in exec_python_func() autogenerated:
> 
> The stack trace of python calls that resulted in this
> exception/failure was:
> File: 'exec_python_func() autogenerated', lineno: 2, function:
> 
>  0001:
>  *** 0002:do_populate_sdk(d)
>  0003:
> File:
> '/home/mschepers/dh3_yocto/yocto/build/../meta/poky/meta/classes/popu
> late_sdk_base.bbclass', lineno: 152, function: do_populate_sdk
>  0148:
>  0149:populate_sdk(d)
>  0150:
>  0151:fakeroot python do_populate_sdk() {
>  *** 0152:populate_sdk_common(d)
>  0153:}
>  0154:SSTATETASKS += "do_populate_sdk"
>  0155:SSTATE_SKIP_CREATION_task-populate-sdk = '1'
>  0156:do_populate_sdk[cleandirs] = "${SDKDEPLOYDIR}"
>  
>  
>  
> File:
> '/home/mschepers/dh3_yocto/yocto/build/../meta/poky/meta/lib/oe/sdk.p
> y', lineno: 45, function: generate_locale_archive
>  0041:# Need to set this so cross-localedef knows where the
> archive is
>  0042:env = dict(os.environ)
>  0043:env["LOCALEARCHIVE"] = oe.path.join(localedir, "locale-
> archive")
>  0044:
>  *** 0045:for name in os.listdir(localedir):
>  0046:path = os.path.join(localedir, name)
>  0047:if os.path.isdir(path):
>  0048:try:
>  0049:cmd = ["cross-localedef", "--verbose"]
> Exception: FileNotFoundError: [Errno 2] No such file or directory:
> '/home/mschepers/dh3_yocto/yocto/build/tmp/work/dh3a10-poky-linux-
> gnueabi/telspan-dh3/1.0-r0/sdk/image/opt/poky/2.5.2/sysroots/x86_64-
> telspan-linux/usr/lib/locale'
> 

this means the locales on sdk host are not installed properly, so
perhaps just renstalling locales on SDK host might help. since you seem
to be on 2.5 release check if you have nativesdk-glibc recipe
available, if you do then perhaps adding something like 

SDK_DEPENDS += "nativesdk-glibc-locale"

in local.conf or preferably meta/classes/populate_sdk_base.bbclass
might help. But I must also note that a bit of work has gone into SDK
host locale issue since 2.5 release so you might have to do a bit of
digging to see needed patches to get it going on 2.5

> ERROR: telspan-dh3-1.0-r0 do_populate_sdk: Function failed:
> do_populate_sdk
> ERROR: Logfile of failure stored in:
> /home/mschepers/dh3_yocto/yocto/build/tmp/work/dh3a10-poky-linux-
> gnueabi/telspan-dh3/1.0-r0/temp/log.do_populate_sdk.27826
> ERROR: Task (/home/mschepers/dh3_yocto/yocto/build/../meta/meta-
> telspan/recipes-core/images/telspan-dh3.bb:do_populate_sdk) failed
> with exit code '1'

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

Re: [yocto] No Package Provides /bin/awk

[Khem Raj]

On Wed, 2019-11-13 at 10:33 +0200, Adrian Bunk wrote:
> On Tue, Nov 12, 2019 at 04:08:48PM -0600, Wayne Li wrote:
> > Dear Yocto Developers,
> > 
> > I'm trying to to build a Yocto kernel for a T4240 RDB.  When I run
> > "bitbake
> > fsl-image-full" to build the entire linux image, I get an error
> > that says
> > "Can't install kernel-devsrc-1.0-r0@t4240rdb_64b: no package
> > provides
> > /bin/awk".  Here's the entire error print that I see:
> > 
> > https://gist.github.com/WayneZhenLi/e35f65081092cf1f24df29ec369c701c
> > 
> > Anyway I'm confused about this error because /bin/awk does
> > exist.  Like if
> > I run "/bin/awk" in the console I see help info come up describing
> > how to
> > use a program called "gawk".  Why can't bitbake find /bin/awk
> > then?  Or am
> > I misunderstanding what this error is trying to say?  I mean I'm
> > assuming
> > it's just not able to find /bin/awk but maybe the error means
> > something
> > else?  Or maybe /bin/awk is actually relative to some path?  Let me
> > know
> > your thoughts.
> 
> /bin/awk is missing on your target image that will run on the T4240
> RDB.
> 
> The smallest implementation is to enable CONFIG_AWK in your busybox
> config.
> 

import something like below patch into your kernel will help too

https://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto/commit/?id=8af11c1cdd8fa08217e702b57cf96e9030db52b2

> > -Thanks!, Wayne Li
> 
> cu
> Adrian
> 
> -- 
> 
>"Is there not promise of rain?" Ling Tan asked suddenly out
> of the darkness. There had been need of rain for many days.
>"Only a promise," Lao Er said.
>Pearl S. Buck - Dragon Seed
> 

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

Re: [yocto] puzzle: simple recipe gets image dependencies

[Khem Raj]

On Wed, 2019-11-13 at 12:33 +0100, Vladimir Molokov wrote:
> Hi all,
> 
> 
> 
> Here is a strange dependency puzzle:
> 
> simple recipe which doesn't inherit image class
> 
> gets EXTRA-IMAGEDENDS, kernel, initramfs and so on.
> 
> 
> 
> It's reproducible on latest poky,
> 
> I've made a minimal example, all lines are important,
> 
> if you remove something, like systemd or attr
> 
> it drops all the dependencies
> 
> though I didn't find anything wrong in systemd nor in attr recipes.
> 
> 
> 
> Steps to reproduce:
> 
> 
> 
> 1. mkdir puzzle && cd puzzle
> 
> 1. git clone git://git.yoctoproject.org/poky
> 
> 2. source poky/oe-init-build-env
> 
> 3. bitbake-layers create-layer meta-puzzle
> 
> 4. bitbake-layers add-layer meta-puzzle
> 
> 5. cp meta-puzzle/recipes-example/example/example_0.1.bb \
> 
>meta-puzzle/recipes-example/example/bad-example_0.1.bb
> 
> 
> 
> 6. mkdir -p meta-puzzle/conf/distro
> 
> 
> 
> 7. printf "require conf/distro/poky.conf\n\n\
> 
> DISTRO = \"extra-img-dep-test\" \n\
> 
> DISTRO_NAME = \"Extra image dependency test\"\n\
> 
> DISTRO_VERSION = \"0.1\"\n\n\
> 
> DISTRO_FEATURES_append = \"systemd\"\n"\
> 
> > meta-puzzle/conf/distro/extra-img-dep-test.conf
> 
> 
> 
> 7. printf "MACHINE ?= \"qemux86\"\n\
> 
> DISTRO ?= \"extra-img-dep-test\"\n\n\
> 
> EXTRA_IMAGEDEPENDS += \"bad-example\"\n\n\
> 
> INITRAMFS_IMAGE = \"core-image-minimal\"\n"\
> 
> > conf/local.conf
> 
> 
> 
> 8. echo 'DEPENDS = "attr"' >> \
> 
>meta-puzzle/recipes-example/example/example_0.1.bb
> 
> 
> 
> 9. bitbake -g example && grep bad-example task-depends.dot

can you share this dot file ?
> 
> 10. see dependencies on 'bad-example'..
> 
> 
> 
> Will be very grateful if anybody point out
> 
> what is wrong with this setup.
> 
> 
> 
> I've talked with people struggling with similar problem
> 
> and nobody was able to solve it so far
> 
> and I myself stumbled in it in a couple of projects.
> 
> 
> 
> BR,
> 
> Vladimir.
> 
> 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] pkg-config not found

[Khem Raj]

On Tue, Nov 12, 2019 at 4:29 PM Mark Hawthorne
 wrote:
>
> Khem,
>
> I found a recipe that you made a few years ago where you addressed this 
> problem:
>
> http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-extended/boinc/boinc-client_7.12.bb
>
> You solved it by exporting PKG_CONFIG
>
> export PKG_CONFIG = "${STAGING_BINDIR_NATIVE}/pkg-config"
>
> This seems like it may be the incorrect way to do it and there needs to be an 
> update in the configure.ac file instead?

in configure.ac you can add something like this

PKG_PROG_PKG_CONFIG
if test -z "$PKG_CONFIG"; then
  AC_MSG_WARN([Cannot find pkg-config, make sure it is installed in your PATH])
fi

>
> On Tue, Nov 12, 2019 at 4:44 PM Mark Hawthorne  
> wrote:
>>
>> No, it did not help
>>
>> It appears from the config.log file that the PKG_CONFIG variable never gets 
>> set. I'm sorting through the bbclass files to figure out why this is not 
>> getting set...
>>
>> PKG_CONFIG=''
>> PKG_CONFIG_LIBDIR='/home/mark/Documents/tisdk/build/arago-tmp-external-arm-toolchain/work/armv7at2hf-neon-linux-gnueabi/myprogram/1.0-r0/recipe-sysroot/usr/lib/pkgconfig'
>> PKG_CONFIG_PATH='/home/mark/Documents/tisdk/build/arago-tmp-external-arm-toolchain/work/armv7at2hf-neon-linux-gnueabi/myprogram/1.0-r0/recipe-sysroot/usr/lib/pkgconfig:/home/mark/Documents/tisdk/build/arago-tmp-external-arm-toolchain/work/armv7at2hf-neon-linux-gnueabi/myprogram/1.0-r0/recipe-sysroot/usr/share/pkgconfig'
>>
>> On Tue, Nov 12, 2019 at 4:22 PM Khem Raj  wrote:
>>>
>>> On Tue, Nov 12, 2019 at 2:00 PM Mark Hawthorne
>>>  wrote:
>>> >
>>> > Thank you. I have fixed this issue but the original pkg-config error 
>>> > still persists.
>>> >
>>>
>>> do a clean build after above change
>>>
>>> bitbake -ccleanall 
>>> bitbake 
>>>
>>> does that help ?
>>>
>>> > On Tue, Nov 12, 2019 at 3:41 PM Adrian Bunk  wrote:
>>> >>
>>> >> On Tue, Nov 12, 2019 at 03:06:25PM -0600, Mark Hawthorne wrote:
>>> >> >...
>>> >> > DEPENDS_${PN} = "libpng freetype glm libegl libgles2 libspatialite"
>>> >> >...
>>> >>
>>> >> DEPENDS, not DEPENDS_${PN}
>>> >>
>>> >> cu
>>> >> Adrian
>>> >>
>>> >> --
>>> >>
>>> >>"Is there not promise of rain?" Ling Tan asked suddenly out
>>> >> of the darkness. There had been need of rain for many days.
>>> >>"Only a promise," Lao Er said.
>>> >>Pearl S. Buck - Dragon Seed
>>> >>
>>> > --
>>> > ___
>>> > yocto mailing list
>>> > yocto@yoctoproject.org
>>> > https://lists.yoctoproject.org/listinfo/yocto
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] pkg-config not found

[Khem Raj]

On Tue, Nov 12, 2019 at 2:00 PM Mark Hawthorne
 wrote:
>
> Thank you. I have fixed this issue but the original pkg-config error still 
> persists.
>

do a clean build after above change

bitbake -ccleanall 
bitbake 

does that help ?

> On Tue, Nov 12, 2019 at 3:41 PM Adrian Bunk  wrote:
>>
>> On Tue, Nov 12, 2019 at 03:06:25PM -0600, Mark Hawthorne wrote:
>> >...
>> > DEPENDS_${PN} = "libpng freetype glm libegl libgles2 libspatialite"
>> >...
>>
>> DEPENDS, not DEPENDS_${PN}
>>
>> cu
>> Adrian
>>
>> --
>>
>>"Is there not promise of rain?" Ling Tan asked suddenly out
>> of the darkness. There had been need of rain for many days.
>>"Only a promise," Lao Er said.
>>Pearl S. Buck - Dragon Seed
>>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Error Building Valgrind_3.15 for yocto

[Khem Raj]

On Tue, Nov 12, 2019 at 5:26 AM Sheraz Ali  wrote:
>
> Hi Sir,
>
> I want to add valgrind to my yocto i am using valgrind version 
> (3.15.0-r0 ) i have attached the valgrind source and error log for your 
> reference.
>
> This is the Build Configuration for which i am trying to build valgrind
>
> Build Configuration:
> BB_VERSION= "1.22.0"
> BUILD_SYS = "x86_64-linux"
> NATIVELSBSTRING   = "Ubuntu-14.04"
> TARGET_SYS= "arm-poky-linux-gnueabi"
> MACHINE   = "iwg22m"
> DISTRO= "poky"
> DISTRO_VERSION= "1.6.1"
> TUNE_FEATURES = "armv7a vfp neon callconvention-hard cortexa7"
> TARGET_FPU= "vfp-neon"
> meta
> meta-yocto
> meta-yocto-bsp= "tmp:c4f1f0f491f988901bfd6965f7d10f60cb94a76f"
> meta-renesas
> meta-rzg1 = "tmp:19bf1ed97d04009722bb88a780268822ee60ff83"
> meta-oe
> meta-multimedia   = "tmp:dca466c074c9a35bc0133e7e0d65cca0731e2acf"
> meta-linaro-toolchain = "tmp:8a0601723c06fdb75e62aa0f0cf15fc9d7d90167"
> meta-networking   = "tmp:dca466c074c9a35bc0133e7e0d65cca0731e2acf"
>
> I am getting the following error can you suggest me what to do
>
> arm-poky-linux-gnueabi-gcc: error: unrecognized argument in option 
> '-march=armv7ve'
> arm-poky-linux-gnueabi-gcc: note: valid arguments to '-march=' are: armv2 
> armv2a armv3 armv3m armv4 armv4t armv5 armv5e armv5t armv5te armv6 armv6-m 
> armv6j armv6k armv6s-m armv6t2 armv6z armv6zk armv7 armv7-a armv7-m armv7-r 
> armv7e-m armv8-a armv8-a+crc iwmmxt iwmmxt2 native
> make[5]: *** [intdiv-intdiv.o] Error 1
> make[5]: Leaving directory 
> `/home/sarjoodeen/Project/2018/Nippon/YOCTO/iwG22M-release-bsp/build/tmp/work/cortexa7hf-vfp-neon-poky-linux-gnueabi/valgrind/3.15.0-r0/build/none/tests/arm'
> make[4]: *** [check-am] Error 2
> make[4]: Leaving directory 
> `/home/sarjoodeen/Project/2018/Nippon/YOCTO/iwG22M-release-bsp/build/tmp/work/cortexa7hf-vfp-neon-poky-linux-gnueabi/valgrind/3.15.0-r0/build/none/tests/arm'
> make[3]: *** [check-recursive] Error 1
> make[3]: Leaving directory 
> `/home/sarjoodeen/Project/2018/Nippon/YOCTO/iwG22M-release-bsp/build/tmp/work/cortexa7hf-vfp-neon-poky-linux-gnueabi/valgrind/3.15.0-r0/build/none/tests'
> make[2]: *** [check-recursive] Error 1
> make[2]: Leaving directory 
> `/home/sarjoodeen/Project/2018/Nippon/YOCTO/iwG22M-release-bsp/build/tmp/work/cortexa7hf-vfp-neon-poky-linux-gnueabi/valgrind/3.15.0-r0/build/none'
> make[1]: *** [check-recursive] Error 1
> make[1]: Leaving directory 
> `/home/sarjoodeen/Project/2018/Nippon/YOCTO/iwG22M-release-bsp/build/tmp/work/cortexa7hf-vfp-neon-poky-linux-gnueabi/valgrind/3.15.0-r0/build'
> make: *** [check] Error 2
> make: Leaving directory 
> `/home/sarjoodeen/Project/2018/Nippon/YOCTO/iwG22M-release-bsp/build/tmp/work/cortexa7hf-vfp-neon-poky-linux-gnueabi/valgrind/3.15.0-r0/build'
> ERROR: oe_runmake failed
> WARNING: exit code 1 from a shell command.
> ERROR: Function failed: do_compile_ptest_base (log file is located at 
> /home/sarjoodeen/Project/2018/Nippon/YOCTO/iwG22M-release-bsp/build/tmp/work/cortexa7hf-vfp-neon-poky-linux-gnueabi/valgrind/3.15.0-r0/temp/log.do_compile_ptest_base.29480)
>

somewhere, its messing up compiler flags -march=armv7ve
-mcpu=cortex-a15 -mthumb is being added can you check if you have
bbapends or other places modifying it

> Thanks and Regards
> Sheraz Ali Shah
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-gplv2][PATCH v2] dosfstools: fix out of bound writes

[Khem Raj]

On Mon, 2019-11-11 at 10:32 +, aj.bagw...@gmail.com wrote:
> From: AJ Bagwell 
> 
> Fix write issues where sprintf writes across both name and ext fields
> and drops the final null ternimator outside the struct
> 
> Signed-off-by: AJ Bagwell 
> ---
>  .../fixing-out-of-bound-writes.patch  | 54
> +++
>  .../dosfstools/dosfstools_2.11.bb |  1 +
>  2 files changed, 55 insertions(+)
>  create mode 100644 recipes-devtools/dosfstools/dosfstools/fixing-
> out-of-bound-writes.patch
> 
> diff --git a/recipes-devtools/dosfstools/dosfstools/fixing-out-of-
> bound-writes.patch b/recipes-devtools/dosfstools/dosfstools/fixing-
> out-of-bound-writes.patch
> new file mode 100644
> index 000..f80f5ab
> --- /dev/null
> +++ b/recipes-devtools/dosfstools/dosfstools/fixing-out-of-bound-
> writes.patch
> @@ -0,0 +1,54 @@
> +Fix out of bound write issues where sprintf writes across both
> +name and ext fields and drops the final null ternimator outside the
> struct
> +
> +Upstream-Status: Inappropriate [licensing]
> +We're tracking an old release of dosfstools due to licensing issues.
> +

patch is fine, I wonder if the latest version in OE-Core is also
affected by this issue ?


> +diff --git a/dosfsck/check.c b/dosfsck/check.c
> +index e8c13bb..91177d3 100644
> +--- a/dosfsck/check.c
>  b/dosfsck/check.c
> +@@ -58,6 +58,13 @@ static DOS_FILE *root;
> + }   
>   \
> +   } while(0)
> + 
> ++static void de_printf(DIR_ENT *de, const char *pattern, int
> curr_num)
> ++{
> ++char buffer[12];
> ++sprintf(buffer, pattern, curr_num);
> ++memcpy(de->name, buffer, 8);
> ++memcpy(de->ext, buffer + 8, 3);
> ++}
> + 
> + loff_t alloc_rootdir_entry(DOS_FS *fs, DIR_ENT *de, const char
> *pattern)
> + {
> +@@ -110,7 +117,8 @@ loff_t alloc_rootdir_entry(DOS_FS *fs, DIR_ENT
> *de, const char *pattern)
> + }
> + memset(de,0,sizeof(DIR_ENT));
> + while (1) {
> +-sprintf(de->name,pattern,curr_num);
> ++de_printf(de, pattern, curr_num);
> ++
> + clu_num = fs->root_cluster;
> + i = 0;
> + offset2 = cluster_start(fs,clu_num);
> +@@ -150,7 +158,7 @@ loff_t alloc_rootdir_entry(DOS_FS *fs, DIR_ENT
> *de, const char *pattern)
> + offset = fs->root_start+next_free*sizeof(DIR_ENT);
> + memset(de,0,sizeof(DIR_ENT));
> + while (1) {
> +-sprintf(de->name,pattern,curr_num);
> ++de_printf(de, pattern, curr_num);
> + for (scan = 0; scan < fs->root_entries; scan++)
> + if (scan != next_free &&
> + !strncmp(root[scan].name,de->name,MSDOS_NAME))
> +@@ -311,8 +319,8 @@ static void auto_rename(DOS_FILE *file)
> + first = file->parent ? file->parent->first : root;
> + number = 0;
> + while (1) {
> +-sprintf(file->dir_ent.name,"FSCK%04d",number);
> +-strncpy(file->dir_ent.ext,"REN",3);
> ++de_printf(>dir_ent, "FSCK%04dREN", number);
> ++
> + for (walk = first; walk; walk = walk->next)
> + if (walk != file && !strncmp(walk->dir_ent.name,file-
> >dir_ent.
> +   name,MSDOS_NAME)) break;
> diff --git a/recipes-devtools/dosfstools/dosfstools_2.11.bb
> b/recipes-devtools/dosfstools/dosfstools_2.11.bb
> index dd543b1..37c2181 100644
> --- a/recipes-devtools/dosfstools/dosfstools_2.11.bb
> +++ b/recipes-devtools/dosfstools/dosfstools_2.11.bb
> @@ -19,6 +19,7 @@ SRC_URI = "
> http://pkgs.fedoraproject.org/repo/pkgs/${BPN}/${BP}.src.tar.gz/407d4
> file://nofat32_autoselect.patch \
> file://fix_populated_dosfs_creation.patch \
> file://0001-Include-fcntl.h-for-getting-loff_t-
> definition.patch \
> +file://fixing-out-of-bound-writes.patch \
>  "
>  
>  SRC_URI[md5sum] = "407d405ade410f7597d364ab5dc8c9f6"
> -- 
> 2.17.1
> 

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

Re: [yocto] [meta-raspberrypi] poky linux build fails if ARM erratum mfix linker switch is specified

[Khem Raj]

On Thu, Nov 7, 2019 at 10:42 AM Steve Pavao  wrote:

> > On Nov 4, 2019, at 4:26 PM, Steve Pavao  wrote:
> >
> >> On Nov 4, 2019, at 11:32 AM, Steve Pavao  wrote:
> >>>
> >>> On Nov 4, 2019, at 11:16 AM, Steve Pavao  wrote:
> >>>>
> >>>> On Nov 4, 2019, at 11:11 AM, Adrian Bunk  wrote:
> >>>>
> >>>> On Mon, Nov 04, 2019 at 10:48:57AM -0500, Steve Pavao wrote:
> >>>>>
> >>>>>> On Nov 3, 2019, at 1:25 PM, Adrian Bunk  wrote:
> >>>>>>
> >>>>>> On Sun, Nov 03, 2019 at 05:56:45PM +, Andrei Gherzan wrote:
> >>>>>>> On 3 November 2019 13:18:53 GMT, Khem Raj 
> wrote:
> >>>>>>>> On Sun, Nov 3, 2019 at 2:46 AM Andrei Gherzan 
> >>>>>>>> wrote:
> >>>>>>>>> I was thinking about this. The erratum seems to show that this
> >>>>>>>> applies
> >>>>>>>>> to all revisions of a53. So it sounds like we should add it in
> >>>>>>>>> `tune-cortexa53.inc`.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> Up to r0b4 only so maybe not all a53 implementations are impacted
> >>>>>>>>
> >>>>>>>
> >>>>>>> As far as I know that is the latest revision. Do you mean that
> newer revision might come up with this fixed?
> >>>>>>
> >>>>>> It is fixed in some r0p4 implementations, indicated in REVIDR[8].
> >>>>>
> >>>>> I am closer to understanding why I experience an error when building
> with the ARM errata switches.
> >>>>>
> >>>>> I believe it is related to 32-bit app support in my poky Linux
> 64-bit build (I add this to support vcgencmd and vcdbg 32-bit apps.)
> >>>>>
> >>>>> When I remove the 32-bit support, the build completes OK.  As of
> now, adding the following seems to work fine to acheive this:
> >>>>>
> >>>>> TARGET_CC_ARCH_append += " -mfix-cortex-a53-843419
> -mfix-cortex-a53-835769”
> >>>>>
> >>>>> Something in the following block seems to be the culprit.:
> >>>>>
> >>>>> # for vcgencmd and vcdbg 32-bit executable support in the OS image
> (comment out for -c populate_sdk)
> >>>>> require conf/multilib.conf
> >>>>> MULTILIBS = "multilib:lib32"
> >>>>> DEFAULTTUNE_virtclass-multilib-lib32 = "armv7a"
> >>>>> IMAGE_INSTALL_append += " vcgencmd lib32-glibc lib32-libgcc
> lib32-libstdc++ vcdbg rpi-setup \
> >>>>> “
> >>>>>
> >>>>> I will post again when I have localized the build problem further.
> Maybe there’s some 64-bit vs. 32-bit build confusion going on, and the
> armv7a default tune switch for 32-bits is colliding with the errata
> switches.
> >>>>
> >>>> The errata switches are only valid for aarch64, not for armv7a.
> >>>> There is likely some kind of "invalid option" earlier in your build.
> >>>
> >>> To conitnue to be able to use the 32-bit app support, perhaps I must
> do this:
> >>>
> >>> DEFAULTTUNE_virtclass-multilib-lib32 = “armv7a
> -mno-fix-cortex-a53-843419 -mno-fix-cortex-a53-835769”
> >>
> >> This doesn’t work.
> >>
> >> If I wish to keep the 32-bit app support in my build, I’ll need to
> devise a way to make sure those ARM errata flags are only applied to the
> aarch64 portion of the compile/link for the target, not to the multilib
> 32-bit app support portion.
> >
> > Andrei and/or Khem,
> >
> > Could you advise an approach that allows to use the ARM errata switches
> for the aarch64 portion of the build for the target, but which will NOT
> specify the ARM errata switches for our supplementary 32-bit portion of the
> build for the target?  (This supplementary 32-bit portion of the build is
> to support the 32-bit vcgencmd app, and contains multilib and some
> additional 32-bit libraires.  Please see earlier post for the syntax we use
> in our local.conf.)
>
>
> I've been able to rebuild 64-bit Linux code with the ARM errata switches,
> by adding the following line to the end of
> /meta/conf/machine/include/arm/arch-arm64.inc,
>
> TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "aarch64", "
> -mfix-cortex-a53-843419 -mfix-cortex-a53-835769", "" ,d)}”


This should be in tune-cortexa53.inc

>
>
> Please let me know if you have any thoughts about this approach.
>
> Steve Pavao
> Korg R
>
>
>
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Running systemd service including boot time

[Khem Raj]

On Wed, Nov 6, 2019 at 12:17 PM JH  wrote:
>
> Hi,
>
> I built Yocto image to include a systemd service and it's timer, the
> timer calls the service repeated every 30 minutes, it runs well, but I
> need it also run it first time in the boot, not wait 30 minutes. I
> tried to add OnBootSec=2, it does not run in boot, any tips how can I
> force it run immediately in boot?
>
> OnBootSec=2

I wonder if 2s is too less of an elapsed time. Could you test setting
it to say 30s

> OnActiveSec=30min
>
> Thank you.
>
> Kind regards,
>
> - jh
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi] poky linux build fails if ARM erratum mfix linker switch is specified

[Khem Raj]

On Sun, Nov 3, 2019 at 9:56 AM Andrei Gherzan  wrote:

>
>
> On 3 November 2019 13:18:53 GMT, Khem Raj  wrote:
> >On Sun, Nov 3, 2019 at 2:46 AM Andrei Gherzan 
> >wrote:
> >
> >> On 01/11/2019 17:18, Khem Raj wrote:
> >> > On Fri, Nov 1, 2019 at 1:28 AM Andrei Gherzan 
> >wrote:
> >> >>
> >> >> Hi Steve,
> >> >>
> >> >> On 01/11/2019 05:32, Steve Pavao wrote:
> >> >>> poky linux build fails when ARM erratum mfix linker switch is
> >specified
> >> >>> in local.conf:
> >> >>>
> >> >>> TARGET_LD_ARCH_append += " -mfix-cortex-a53-843419”
> >> >>>
> >> >>> causes build failure.
> >> >>>
> >> >>> Please advise how to use this switch successfully.  I am synced
> >current
> >> >>> in master branch in all layers as of today.  The switch causes
> >libtool
> >> >>> link to fail due to missing libbz2.so.  If I don’t specify the
> >switch,
> >> >>> the build completes without errors.
> >> >>>
> >> >>> It is important to be able to build poky linux with this switch
> >to
> >> avoid
> >> >>> certain crash conditions as described in the ARM errata document.
> >> >>
> >> >> I haven't tried this erratum fix. It is indeed implemented at the
> >> >> linker's lever. It's curious though to see the bz2 dependency. Can
> >you
> >> >> share the specific error? I assume you are doing this on RPi3.
> >> >>
> >> >
> >> > this will impact rpi3 in 64bit mode, don't think 32bit needs this.
> >I
> >> > think its best to
> >> > add this option in raspberrypi3-64.conf perhaps via TUNE_CCARGS
> >>
> >> I was thinking about this. The erratum seems to show that this
> >applies
> >> to all revisions of a53. So it sounds like we should add it in
> >> `tune-cortexa53.inc`.
> >>
> >
> >Up to r0b4 only so maybe not all a53 implementations are impacted
> >
>
> As far as I know that is the latest revision. Do you mean that newer
> revision might come up with this fixed?
>

Rpi3 is one of many cortex a53 implementations

>
> --
> Andrei Gherzan
> gpg: rsa4096/D4D94F67AD0E9640 | t: @agherzan
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi] poky linux build fails if ARM erratum mfix linker switch is specified

[Khem Raj]

On Sun, Nov 3, 2019 at 2:46 AM Andrei Gherzan  wrote:

> On 01/11/2019 17:18, Khem Raj wrote:
> > On Fri, Nov 1, 2019 at 1:28 AM Andrei Gherzan  wrote:
> >>
> >> Hi Steve,
> >>
> >> On 01/11/2019 05:32, Steve Pavao wrote:
> >>> poky linux build fails when ARM erratum mfix linker switch is specified
> >>> in local.conf:
> >>>
> >>> TARGET_LD_ARCH_append += " -mfix-cortex-a53-843419”
> >>>
> >>> causes build failure.
> >>>
> >>> Please advise how to use this switch successfully.  I am synced current
> >>> in master branch in all layers as of today.  The switch causes libtool
> >>> link to fail due to missing libbz2.so.  If I don’t specify the switch,
> >>> the build completes without errors.
> >>>
> >>> It is important to be able to build poky linux with this switch to
> avoid
> >>> certain crash conditions as described in the ARM errata document.
> >>
> >> I haven't tried this erratum fix. It is indeed implemented at the
> >> linker's lever. It's curious though to see the bz2 dependency. Can you
> >> share the specific error? I assume you are doing this on RPi3.
> >>
> >
> > this will impact rpi3 in 64bit mode, don't think 32bit needs this. I
> > think its best to
> > add this option in raspberrypi3-64.conf perhaps via TUNE_CCARGS
>
> I was thinking about this. The erratum seems to show that this applies
> to all revisions of a53. So it sounds like we should add it in
> `tune-cortexa53.inc`.
>

Up to r0b4 only so maybe not all a53 implementations are impacted

>
> --
> Andrei Gherzan
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] poky thud: qtscript fails to build with undefined reference to `cti_vm_throw'

[Khem Raj]

On Fri, Nov 1, 2019 at 2:12 AM  wrote:
>
> Hello,
>
> I tried to build a poky SDK with QT5 support (I am using poky thud).
> Unfortunately this failed while bitbaking qtscript.
> When executing "bitbake qtscript" directly I get the same error.
>
> Here are the IMHO relevant lines of the huge log.do_compile file.
> I have replaced the long paths by <...> for clarity.
>
> -- multiple warnings ---
> ...  warning: 'template class std::auto_ptr' is deprecated 
> [-Wdeprecated-declarations]
> ---
>
> -- warning ---
> In member function 'allocatePropertyStorageInline',
> inlined from 'allocatePropertyStorage' at 
> <...>/git/src/3rdparty/javascriptcore/JavaScriptCore/runtime/JSObject.cpp:546:34:
> <...>/git/src/3rdparty/javascriptcore/JavaScriptCore/runtime/JSObject.h:679:68:
>  warning: argument 1 value '4294967295' exceeds maximum object size 
> 2147483647 [-Walloc-size-larger-than=]
>  PropertyStorage newPropertyStorage = new EncodedJSValue[newSize];
> ^
> <...>/git/src/3rdparty/javascriptcore/JavaScriptCore/runtime/JSObject.h: In 
> member function 'allocatePropertyStorage':
> <...>/recipe-sysroot/usr/include/c++/8.2.0/new:122:7: note: in a call to 
> allocation function 'operator new []' declared here
>  void* operator new[](std::size_t) _GLIBCXX_THROW (std::bad_alloc)
> ---
>
> --- error ---
> <...>/recipe-sysroot-native/usr/bin/i686-poky-linux/../../libexec/i686-poky-linux/gcc/i686-poky-linux/8.2.0/ld:
>  
> <...>/recipe-sysroot-native/usr/bin/i686-poky-linux/../../libexec/i686-poky-linux/gcc/i686-poky-linux/8.2.0/ld:
>  DWARF error: invalid abstract instance DIE ref
> /tmp/ccSwzRoN.ltrans0.ltrans.o: in function `ctiVMThrowTrampoline':
> :(.text+0x1f): undefined reference to `cti_vm_throw'
> collect2: error: ld returned 1 exit status
> Makefile:666: recipe for target '../../lib/libQt5Script.so.5.12.2' failed
> ---
>
> Has anyone an idea what could be the problem?
>

perhaps we need to patch binutils/ld with

https://patches-gcc.linaro.org/patch/9614/

see
https://sourceware.org/bugzilla/show_bug.cgi?id=23425

if you could try it out and report back that would be awesome

> Thanks
> Jochen
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi] poky linux build fails if ARM erratum mfix linker switch is specified

[Khem Raj]

On Fri, Nov 1, 2019 at 1:28 AM Andrei Gherzan  wrote:
>
> Hi Steve,
>
> On 01/11/2019 05:32, Steve Pavao wrote:
> > poky linux build fails when ARM erratum mfix linker switch is specified
> > in local.conf:
> >
> > TARGET_LD_ARCH_append += " -mfix-cortex-a53-843419”
> >
> > causes build failure.
> >
> > Please advise how to use this switch successfully.  I am synced current
> > in master branch in all layers as of today.  The switch causes libtool
> > link to fail due to missing libbz2.so.  If I don’t specify the switch,
> > the build completes without errors.
> >
> > It is important to be able to build poky linux with this switch to avoid
> > certain crash conditions as described in the ARM errata document.
>
> I haven't tried this erratum fix. It is indeed implemented at the
> linker's lever. It's curious though to see the bz2 dependency. Can you
> share the specific error? I assume you are doing this on RPi3.
>

this will impact rpi3 in 64bit mode, don't think 32bit needs this. I
think its best to
add this option in raspberrypi3-64.conf perhaps via TUNE_CCARGS

> --
> Andrei Gherzan
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] visual studio code packages or building instructions?

[Khem Raj]

On Fri, Nov 1, 2019 at 9:37 AM Aaron Solochek  wrote:
>
> I would like to get visual studio code on my NXP i.MX8. If someone is
> aware of a aarch64 rpm of it, that would be the easiest. Alternatively,
> if anyone knows how to build it using bitbake, I can build it myself.
>

I dont think we have recipe for it yet but you might want to look into
https://code.headmelted.com/

> Thank you.
>
> -Aaron
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-qt5] How to contribute patches for qtwebengine in meta-qt5?

[Khem Raj]

On Fri, Nov 1, 2019 at 3:02 AM Tanu Kaskinen  wrote:

> Hi all!
>
> The meta-qt5 readme says that contributions should be made by forking
> the meta-qt5 repository on GitHub, but when I look at the qtwebengine
> recipe, it looks like patches are pulled from
> https://github.com/meta-qt5/qtwebengine-chromium, and that repository
> looks like the patches are kept in a particular order so adding a patch
> at the top is perhaps not what I should do.
>


Like you would do for any other layer is fine
Better if you can maintain the patch ordering

>
> It's not clear to me how I should submit a patch in this case. The
> patch in question would be a simple backport of this upstream commit:
>
> https://codereview.qt-project.org/gitweb?p=qt/qtwebengine-chromium.git;a=commitdiff;h=b84e8682b312fb16b16ffb9591415067ceae69f8
>
> It's needed for not breaking qtwebengine when upgrading PulseAudio to
> 13.0.
>
> --
> Tanu
>
> https://www.patreon.com/tanuk
> https://liberapay.com/tanuk
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Reducing the size of the image by optimizing python

[Khem Raj]

On Fri, Oct 18, 2019 at 1:21 PM Abhi Arora  wrote:

> Hello,
> I am having an embedded system. We have bsp with python 3.5 but we want to
> reduce its size further. I am planning to have only oyc files but not sure
> how it can be achieved in recipes. Also, I want to know if there is a other
> way to reduce the footprint.
>

Please start by eliminating modules first so find which modules are
required for your workloads and remove all other modules from image by
adding them to BAD_RECOMMENDATIONS from IMAGE_INSTALL

>
>
> Please help.
>
> Get Outlook for Android 
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] python3 pygame under Pyro

[Khem Raj]

On Wed, Oct 2, 2019 at 3:32 PM Mauro Ziliani  wrote:
>
> Adding libsdl2 to DEPENDS i get sdl2-config under the folder
>
> tmp/work/armv7at2hf-neon-fslc-linux-gnueabi/python3-pygame/1.9.6-r0/recipe-sysroot/usr/bin/crossscripts/sdl2-config
>

yes and you should be able to use it.

> Il 03/10/19 00:01, Khem Raj ha scritto:
> > On Wed, Oct 2, 2019 at 2:46 PM Mauro Ziliani  wrote:
> >> Hi all.
> >>
> >> I'm trying to build python3-pygame for and imx6dl board in Pyro.
> >>
> >> Pygame needs SDL, but I don't know how to tell to bitbake for compile
> >> sdl before pygame.
> >>
> >>
> >> I put libsdl-native into DEPENDS but doesn't work.
> >>
> >>
> >> bitbake try to run sdl-config but it cannot find the file.
> >>
> >>
> >> Any idea?
> >>
> > Does, DEPENDS += "libsdl2" help ?
> >> Best regards,
> >>
> >> MZ
> >>
> >>
> >> --
> >> ___
> >> yocto mailing list
> >> yocto@yoctoproject.org
> >> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] python3 pygame under Pyro

[Khem Raj]

On Wed, Oct 2, 2019 at 2:46 PM Mauro Ziliani  wrote:
>
> Hi all.
>
> I'm trying to build python3-pygame for and imx6dl board in Pyro.
>
> Pygame needs SDL, but I don't know how to tell to bitbake for compile
> sdl before pygame.
>
>
> I put libsdl-native into DEPENDS but doesn't work.
>
>
> bitbake try to run sdl-config but it cannot find the file.
>
>
> Any idea?
>

Does, DEPENDS += "libsdl2" help ?
>
> Best regards,
>
>MZ
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Cannot use "LICENSE_CREATE_PACKAGE = 1" when building the image with mdns

[Khem Raj]

On 9/30/19 8:17 AM, Stefano Cappa wrote:
> I saw your last patch to upgrade mdns, so I'm sending this email also to
> you to try to get help.
> 
> mdns is working correctly, however, when I try to build my image with
> "LICENSE_CREATE_PACKAGE = "1"" in my local.conf as described
> here 
> https://www.yoctoproject.org/docs/2.8/dev-manual/dev-manual.html#providing-license-text
>  I
> get this error message:
> 
> ERROR: mydevice-image-1.0-r0 do_rootfs: Postinstall scriptlets of
> ['mdns'] have failed. If the intention is to defer them to first boot,
> then please place them into pkg_postinst_ontarget_${PN} ().
> Deferring to first boot via 'exit 1' is no longer supported.
> Details of the failure are in
> /home/user/git/poky/build/tmp/work/mydevice1-image-poky-linux-gnueabi/mydevice-image/1.0-r0/temp/log.do_rootfs.
> ERROR: mydevice-image-1.0-r0 do_rootfs: Function failed: do_rootfs
> ERROR: Logfile of failure stored in:
> /home/user/git/poky/build/tmp/work/mydevice1-poky-linux-gnueabi/mydevice-image/1.0-r0/temp/log.do_rootfs.14586
> ERROR: Task (MY CUSTOM LAYER
> PATH/recipes-core/images/mydevice-image.bb:do_rootfs) failed with exit
> code '1'
> NOTE: Tasks Summary: Attempted 4871 tasks of which 4654 didn't need to
> be rerun and 1 failed.
> 
> Do you have a solution? Why is it happening? 
> 

see mdns recipe especially

pkg_postinst_${PN} (), that function is not able to execute offline
during build. It could be that nsswitch.conf does not exist in your
image rootfs

> thank u.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] incohenrence between defconf, .config and /proc/config.gz

[Khem Raj]

On Tue, Sep 10, 2019 at 2:45 AM María del Mar Velasco AERTEC Solutions –
Aerospace & Aviation  wrote:

> Hello all,
>
>
>
> I have found that if I write the image using the created *.wic file,
> kernel config is correctly updated (/proc/config.gz and .config are
> coherent). However if I use the created *.ext4 file to write a rootfs
> partition of target, previous kernel config still remains (kernel config
> used when target was written for first time using *.wic file still remains).
>
>
>
> Any idea about how to keep kernel config updates in *.ext4 file?
>
>
>

Ext4 is just rootfs without new kernel I think that’s why you see old
.config since it’s bundled into kernel  binary

With wic you write full disk along with new kernel

> Thanks in advance
>
>
>
> *De:* María del Mar Velasco AERTEC Solutions – Aerospace & Aviation
> *Enviado el:* viernes, 6 de septiembre de 2019 10:50
> *Para:* 'yocto@yoctoproject.org' 
> *Asunto:* incohenrence between defconf, .config and /proc/config.gz
>
>
>
> Dear all,
>
>
>
> I have built an image after doing changes in kernel config by adding a
> layer that adds lines in .config file. This changes lead me to an undesired
> configuration, so I decided to undo the last kernel config. When I remove
> the layer that adds lines in .config file, I ensure that kernel is clean by
> doing bitbake -c cleanall linux-xxx. Then I build again the image. I can
> see .config file is exactly equal than defconf kernel file. However, when I
> write image into the target, /proc/config.gz file is inconsistent with
> .config file and it preserves some lines that are missing in .config file.
>
>
>
> Could somebody give me an advice about this issue? Why /proc/config.gz is
> not equal than .config file?
>
>
>
> Thanks in advance
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] in-tree module dependency

[Khem Raj]

On Wed, Sep 4, 2019 at 7:10 AM Matteo Facchinetti <
matteo.facchine...@sirius-es.it> wrote:

>
>
> Il giorno mer 4 set 2019 alle ore 15:54 Khem Raj  ha
> scritto:
>
>>
>>
>> On Wed, Sep 4, 2019 at 2:58 AM Matteo Facchinetti <
>> matteo.facchine...@sirius-es.it> wrote:
>>
>>> Hi,
>>>
>>> I have a problem with a custom kernel module's recipe that depends to an
>>> other module (in-tree).
>>> My kernel module recipes built seems OK, but I have a problem when doing
>>> the rootfs image stage.
>>>
>>> Error:
>>>  Problem: package packagegroup-console-sirlinux-1.0-r0.0.noarch requires
>>> canopen-sync, but none of the providers can be installed
>>>   - package canopen-sync-git-r0.2.neo_sirius requires
>>> kernel-module-canopen-sync-4.9.51-yocto-standard, but none of the providers
>>> can be installed
>>>   - conflicting requests
>>>   - nothing provides kernel-module-xeno-can-4.9.51-yocto-standard needed
>>> by kernel-module-canopen-sync-4.9.51-yocto-standard-git-r0.2.neo_sirius
>>>
>>
>> It seems this modules is not built can you check if that’s the case ? You
>> might look for ipk or rpm in deploy area with this name
>>
>
> I have checked and module is built.
> In build/tmp/deploy/rpm/neo_sirius there's this file:
>
> kernel-module-xeno-can-4.9.51+ipipe+git0+0774eacea2_089d772038-r0.1.neo_sirius.rpm
>

This has different version than what dep is asking for

>
>
>
>>
>>> ERROR: sirlinux4-image-qt4e-1.0-r0 do_rootfs: Function failed: do_rootfs
>>> ERROR: Logfile of failure stored in:
>>> /workspace/neo-sirius_sirlinux4/build/tmp/work/neo_sirius-poky-linux-gnueabi/sirlinux4-image-qt4e/1.0-r0/temp/log.do_rootfs.9126
>>> ERROR: Task
>>> (/workspace/neo-sirius_sirlinux4/meta-sirlinux/recipes-qt4/images/sirlinux4-image-qt4e.bb:do_rootfs)
>>> failed with exit code '1'
>>>
>>>
>>> I don't understand how exactly the modules dependencies works...
>>> Initially, I suppose that PROVIDES variable was updated automatically
>>> with the correct modules names when compiled like module from kernel but
>>> now, I don't know if I have to specify it manually or is there any other
>>> way?
>>>
>>> Regards,
>>> Matteo
>>>
>>> --
>>> ___
>>> yocto mailing list
>>> yocto@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/yocto
>>>
>>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] in-tree module dependency

[Khem Raj]

On Wed, Sep 4, 2019 at 2:58 AM Matteo Facchinetti <
matteo.facchine...@sirius-es.it> wrote:

> Hi,
>
> I have a problem with a custom kernel module's recipe that depends to an
> other module (in-tree).
> My kernel module recipes built seems OK, but I have a problem when doing
> the rootfs image stage.
>
> Error:
>  Problem: package packagegroup-console-sirlinux-1.0-r0.0.noarch requires
> canopen-sync, but none of the providers can be installed
>   - package canopen-sync-git-r0.2.neo_sirius requires
> kernel-module-canopen-sync-4.9.51-yocto-standard, but none of the providers
> can be installed
>   - conflicting requests
>   - nothing provides kernel-module-xeno-can-4.9.51-yocto-standard needed
> by kernel-module-canopen-sync-4.9.51-yocto-standard-git-r0.2.neo_sirius
>

It seems this modules is not built can you check if that’s the case ? You
might look for ipk or rpm in deploy area with this name

>
> ERROR: sirlinux4-image-qt4e-1.0-r0 do_rootfs: Function failed: do_rootfs
> ERROR: Logfile of failure stored in:
> /workspace/neo-sirius_sirlinux4/build/tmp/work/neo_sirius-poky-linux-gnueabi/sirlinux4-image-qt4e/1.0-r0/temp/log.do_rootfs.9126
> ERROR: Task
> (/workspace/neo-sirius_sirlinux4/meta-sirlinux/recipes-qt4/images/sirlinux4-image-qt4e.bb:do_rootfs)
> failed with exit code '1'
>
>
> I don't understand how exactly the modules dependencies works...
> Initially, I suppose that PROVIDES variable was updated automatically with
> the correct modules names when compiled like module from kernel but now, I
> don't know if I have to specify it manually or is there any other way?
>
> Regards,
> Matteo
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Build break in the latest openbmc tree.

[Khem Raj]

On 9/3/19 5:36 PM, Brad Bishop wrote:
> at 5:16 PM, Jae Hyun Yoo  wrote:
> 
>> On 8/27/2019 5:00 PM, Brad Bishop wrote:
>>> On Sun, 2019-08-25 at 10:49 -0700, akuster808 wrote:
 the meta-security layer should be fix now.

 please update and let me know if not.
>>> Thanks Armin!
>>> Jae, I've pulled this into OpenBMC.  Can you give it a try?
>>
>> Thanks Armin, Brad!
>>
>> I tried it using the latest tree and checked that the build breakage has
>> gone, but a new issue happened while it's building 'qemu-native'.
>>
>> | ERROR: Execution of
>> '/home/yoojae/workspace/openbmc/build/tmp/work/x86_64-linux/qemu-native/4.1.0-r0/temp/run.do_configure.2396'
>> failed with exit code 1:
>> | ERROR: unknown option --disable-libssh
>>
>> So I made a patch to fix the new issue.
>>
>> --- a/poky/meta/recipes-devtools/qemu/qemu.inc
>> +++ b/poky/meta/recipes-devtools/qemu/qemu.inc
>> @@ -137,7 +137,7 @@ PACKAGECONFIG[curses] =
>> "--enable-curses,--disable-curses,ncurses,"
>>  PACKAGECONFIG[gtk+] = "--enable-gtk,--disable-gtk,gtk+3 gettext-native"
>>  PACKAGECONFIG[vte] = "--enable-vte,--disable-vte,vte gettext-native"
>>  PACKAGECONFIG[libcap-ng] = "--enable-cap-ng,--disable-cap-ng,libcap-ng,"
>> -PACKAGECONFIG[ssh] = "--enable-libssh,--disable-libssh,libssh,"
>> +PACKAGECONFIG[ssh] = "--enable-libssh2,--disable-libssh2,libssh2,"
>>  PACKAGECONFIG[gcrypt] = "--enable-gcrypt,--disable-gcrypt,libgcrypt,"
>>  PACKAGECONFIG[nettle] = "--enable-nettle,--disable-nettle,nettle"
>>  PACKAGECONFIG[libusb] = "--enable-libusb,--disable-libusb,libusb1"
>>
>> Brad,
>> Please apply this change into the qemu recipe.
> 

this was intentionally introduced in [1] although commit message did not
mention about it so it could be unintended change, so I wonder if there
is something more going on, is this packageconfig edited by some other
bbappends from other layers in your setup


> Hi Jae
> 
> Please send your patch to OE-Core.
> 
> FWIW I am able to build qemu-native without issue with OpenBMC
> 93ee980ed9 although I am not using meta-security.
> 
> thx - brad

[1]
https://git.openembedded.org/openembedded-core/commit/?id=50a7dec95618080962e56fd347f505e691b7ad6f


pEpkey.asc
Description: application/pgp-keys
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Error at extensible sdk installation

[Khem Raj]

On Tue, Sep 3, 2019 at 12:05 AM Markus Volk  wrote:
>
>
> Hello,
>
> i built myself an extensible sdk from current master branch. After successful 
> build i tried to install and got the following error:
>
> /home/builder/tuxbox_sdk/tmp/sysroots/x86_64/usr/bin/postinst-docbook-xsl-stylesheets-native-xmlcatalog:
>  line 5: xmlcatalog: command not found
>
> and was able to fix it wby adding "xmlcatalog" to HOSTTOOLS, but i guess 
> thats not the propper way to fix it
>

infact that might be right soluition. Can you submit a patch
> --
> Markus Volk 
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Python3 scan packages

[Khem Raj]

Python3-modules is a meta package you can depend on iirc

On Sat, Aug 24, 2019 at 2:20 PM Mauro Ziliani  wrote:

> Hi all.
>
> Do you know some class or recipe which can detect the modules used by a
> python application?
>
> Now I have to RDEPENDS every package the application need
>
>
> MZ
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Different package versions between host SDK and target image

[Khem Raj]

On Fri, Aug 23, 2019 at 7:35 AM Benjamin Crawford
 wrote:
>
> Hi,
>
> I've been happily building images for the Renesas R-Car platform using the 
> Yocto project until recently. After clearing the sstate-cache and rebuilding, 
> I'm now suddenly encountering an issue where the version of OpenCV being 
> installed into the host SDK and the one being installed into the target 
> rootfs are different (OpenCV 3.3.x vs 3.4.x). Obviously, I now can't develop 
> applications as the binaries try to link to the wrong version of the library. 
> Can anyone tell what might have happened?

what operations did you do on your workspace? which release are you on?
basically, SDKs are image specific, so when you rebuild an image
especially cleaning everything up and updating layers, its better to
respin SDK as well
having said this, we do not upgrade versions on release branches, so
would like to know more on which branch of the meta-openembedded repo
are you on

>
> Kind regards,
> Ben
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] quilt-native-0.64-r0 do_install: oe_runmake failed

[Khem Raj]

error return code 126 means  Command invoked cannot execute so my
guess is the script is not marked executable. so may be try something
like

do_install_prepend() {
  chmod +x config/install-sh
}

On Mon, Aug 19, 2019 at 2:37 AM Pushpendra singh
 wrote:
>
> Hi,
>
> I am using Ubantu - 16.04 as an host machine
>
> Xilinx SDK Version : 2017.3
>
> Command : bitbake petalinux-image-minimal
>
> Getting below error
>
> Parsing recipes: 100% 
> |###|
>  Time: 0:09:00
> Parsing of 2463 .bb files complete (0 cached, 2463 parsed). 3256 targets, 229 
> skipped, 0 masked, 0 errors.
> NOTE: Resolving any missing task queue dependencies
>
> Build Configuration:
> BB_VERSION = "1.32.0"
> BUILD_SYS = "x86_64-linux"
> NATIVELSBSTRING = "universal"
> TARGET_SYS = "aarch64-poky-linux"
> MACHINE = "zcu102-zynqmp"
> DISTRO = "poky"
> DISTRO_VERSION = "2.2.2"
> TUNE_FEATURES = "aarch64"
> TARGET_FPU = ""
> meta
> meta-poky = "rel-v2017.3:8506cec55de8950e89a4d3e786860f1086782587"
> meta-perl
> meta-systemd
> meta-gpe
> meta-python
> meta-efl
> meta-ruby
> meta-filesystems
> meta-gnome
> meta-multimedia
> meta-networking
> meta-webserver
> meta-xfce
> meta-initramfs
> meta-oe = "rel-v2017.3:a9887ac249b81fcac3007244d0c807c71b73acef"
> meta-linaro-toolchain = "rel-v2017.3:39860f6c7af0858981cc004bbe4f4c421f6be607"
> meta-qt5 = "rel-v2017.3:eec778bfb9a0b5494d593a2d7bb02c027b641835"
> meta-xilinx = "rel-v2017.3:04a45809e0bc42b35c88f8a08305d82fd25e97cf"
> meta-xilinx-tools = "rel-v2017.3:37eff634934efac72d3e2eabb7c4f8d0c8a36fbb"
> meta-petalinux = "rel-v2017.3:d74ceaef26e606c2761edfc3446d0ad3c3cc8b8e"
> meta-virtualization = "rel-v2017.3:cbfd4376d5e9d229f857151ffdfb57fbc6c0c40d"
> meta-openamp = "rel-v2017.3:cfeca8988418e4967f0d6df828d23a1540ae25a0"
>
> Initialising tasks: 100% 
> ||
>  Time: 0:00:21
> NOTE: Executing SetScene Tasks
> NOTE: Executing RunQueue Tasks
> ERROR: quilt-native-0.64-r0 do_install: oe_runmake failed
> ERROR: quilt-native-0.64-r0 do_install: Function failed: do_install (log file 
> is located at 
> /home/pre-si-user/Desktop/Pushpendra/Xilix_Zync/Yocto_Code/build/tmp/work/x86_64-linux/quilt-native/0.64-r0/temp/log.do_install.15836)
> ERROR: Logfile of failure stored in: 
> /home/pre-si-user/Desktop/Pushpendra/Xilix_Zync/Yocto_Code/build/tmp/work/x86_64-linux/quilt-native/0.64-r0/temp/log.do_install.15836
> Log data follows:
> | DEBUG: Executing shell function do_install
> | NOTE: make -j 2 
> BUILD_ROOT=/home/pre-si-user/Desktop/Pushpendra/Xilix_Zync/Yocto_Code/build/tmp/work/x86_64-linux/quilt-native/0.64-r0/image
>  install
> | ERROR: oe_runmake failed
> | config/install-sh -c -d 
> /home/pre-si-user/Desktop/Pushpendra/Xilix_Zync/Yocto_Code/build/tmp/work/x86_64-linux/quilt-native/0.64-r0/image/home/pre-si-user/Desktop/Pushpendra/Xilix_Zync/Yocto_Code/build/tmp/sysroots/x86_64-linux/usr/bin
> | rm -rf 
> /home/pre-si-user/Desktop/Pushpendra/Xilix_Zync/Yocto_Code/build/tmp/work/x86_64-linux/quilt-native/0.64-r0/image/home/pre-si-user/Desktop/Pushpendra/Xilix_Zync/Yocto_Code/build/tmp/sysroots/x86_64-linux/usr/share/quilt/compat
> | /bin/bash: config/install-sh: Permission denied
> | Makefile:305: recipe for target 'install-main' failed
> | make: *** [install-main] Error 126
> | make: *** Waiting for unfinished jobs
> | config/install-sh -c -d 
> /home/pre-si-user/Desktop/Pushpendra/Xilix_Zync/Yocto_Code/build/tmp/work/x86_64-linux/quilt-native/0.64-r0/image/home/pre-si-user/Desktop/Pushpendra/Xilix_Zync/Yocto_Code/build/tmp/sysroots/x86_64-linux/usr/share/quilt/compat
> | /bin/bash: config/install-sh: Permission denied
> | Makefile:346: recipe for target 'install-compat1' failed
> | make: *** [install-compat1] Error 126
> | WARNING: 
> /home/pre-si-user/Desktop/Pushpendra/Xilix_Zync/Yocto_Code/build/tmp/work/x86_64-linux/quilt-native/0.64-r0/temp/run.do_install.15836:1
>  exit 1 from 'exit 1'
> | ERROR: Function failed: do_install (log file is located at 
> /home/pre-si-user/Desktop/Pushpendra/Xilix_Zync/Yocto_Code/build/tmp/work/x86_64-linux/quilt-native/0.64-r0/temp/log.do_install.15836)
> ERROR: Task 
> (/home/pre-si-user/Desktop/Pushpendra/Xilix_Zync/Yocto_Code/sources/core/meta/recipes-devtools/quilt/quilt-native_0.64.bb:do_install)
>  failed with exit code '1'
> NOTE: Tasks Summary: Attempted 15 tasks of which 13 didn't need to be rerun 
> and 1 failed.
>
> Summary: 1 task failed:
> /home/pre-si-user/Desktop/Pushpendra/Xilix_Zync/Yocto_Code/sources/core/meta/recipes-devtools/quilt/quilt-native_0.64.bb:do_install
> Summary: There were 2 ERROR messages shown, returning a non-zero exit code.
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> 

Re: [yocto] Your GStreamer installation is missing a plug-in

[Khem Raj]

might be you need to install gstreamer1.0-omx on target.

On Mon, Aug 19, 2019 at 12:48 AM Bhupendra Singh
 wrote:
>
> 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)9, 
> 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
>
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Yocto repos for NXP referent platform MCIMXABASEV1 also called SABRE platform?

[Khem Raj]

On Thu, Aug 8, 2019 at 11:20 PM Zoran Stojsavljevic
 wrote:
>
> Hello to all,
>
> I am trying to find out some recent yocto repo, which contains YOCTO
> reference repo for the following NXP board:
> MCIMXABASEV1 also called SABRE platform.
>
> Here is one repo I found reading this document... But this is too outdated!
>
> http://events17.linuxfoundation.org/sites/events/files/slides/AGLAMM_How%20we%20Run%20AGL%20on%20i.MX%20processors_tkobayashi_25FEB16%20rev.D.pdf
>
> Does anybody have some other repos/suggestions in mind for such a
> board? Please, come forward if yes...
>

I would say look at

http://layers.openembedded.org/layerindex/branch/master/machines/?q=sabre=1

> Thank you,
> Zoran
> ___
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] meta-rpi vs meta-raspberrypi. Which one?

[Khem Raj]

Meta-raspberrypi

On Thu, Aug 8, 2019 at 12:57 PM Mauro Ziliani  wrote:

> Hi all.
>
> I'm working on a RPi3B with pyro and qt5/qml
>
> Which layer between rpi and raspberrypi?
>
>
> MZ
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] installed-vs-shipped

[Khem Raj]

Add

FILES_${PN} += "/usr/local/bin"

in recipe. but it would be nicer if it was installed into /usr/bin by
qmake/make files itself

On Fri, Aug 2, 2019 at 11:59 AM Mauro Ziliani  wrote:
>
> Hi all.
>
> This is my problem.
>
> I have my terminal.pro project (qmake5) with target "terminal".
>
> The default destination folder for the binary is /usr/local/bin
>
> With this setup I get installed-vs-shipped error.
>
>
> Why?
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Patching /lib/systemd/system/systemd-networkd-wait-online.service

[Khem Raj]

you should be patching ./units/systemd-networkd-wait-online.service.in file

On Thu, Aug 1, 2019 at 8:14 AM Edward Tyrrell  
wrote:
>
> Hi,
>
>
> I'm trying to add a patch to the systemd layer to amend 
> systemd-networkd-wait-online.service. Within the service I simply want to add 
> --any as a parameter.
>
>
> The problem is my is bitbake fails with:
>
> Applying patch 0020-systemd-networkd-wait-online-service.patch
> can't find file to patch at input line 3
> Perhaps you used the wrong -p or --strip option?
> The text leading up to this was:
> --
> |--- a/units/systemd-networkd-wait-online.service 2019-05-23 
> 13:38:23.0 +0100
> |+++ b/units/systemd-networkd-wait-online.service 2019-07-31 
> 08:30:40.823968051 +0100
> --
> No file to patch.  Skipping patch.
> 1 out of 1 hunk ignored
> Patch 0020-systemd-networkd-wait-online-service.patch does not apply (enforce 
> with -f)
>
>
>
> My ./sources/poky/meta/recipes-core/systemd/systemd_234.bbappend consists 
> of:
>
>
> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
> SRC_URI += "file://0020-systemd-networkd-wait-online-service.patch"
>
> My patch file:
>
> --- a/units/systemd-networkd-wait-online.service 2019-05-23 
> 13:38:23.0 +0100
> +++ b/units/systemd-networkd-wait-online.service 2019-07-31 
> 08:30:40.823968051 +0100
> @@ -16,7 +16,7 @@
>
>  [Service]
>  Type=oneshot
> -ExecStart=/lib/systemd/systemd-networkd-wait-online
> +ExecStart=/lib/systemd/systemd-networkd-wait-online --any
>  RemainAfterExit=yes
>
>  [Install]
>
> ---
>
>
> So it finds the patch but struggles locating the service file to patch within 
> the build. Any ideas where I'm going wrong?
>
> Is ./sources/poky/meta/recipes-core/systemd/systemd_234.bb the proper 
> place to patch this service file?
>
>
>
> Regards,
>
>
> Edward
>
>
>
>
> This message and any attachment are confidential and may be privileged or 
> otherwise protected from disclosure. If you are not the intended recipient, 
> please telephone or email the sender and delete this message and any 
> attachment from your system. If you are not the intended recipient you must 
> not copy this message or attachment or disclose the contents to any other 
> person.
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [yocto-docs][PATCH] ref-manual: Remove documentation for the removed gnome class

[Khem Raj]

On Wed, Jul 31, 2019 at 6:30 AM Adrian Bunk  wrote:
>
> When removed all it did was
>   inherit gnomebase gtk-icon-cache gconf mime
> which would also be the most trivial replacement.
>
> Most of the time not all of these classes were needed,
> and it is recommended to use only the ones actually required.
>

This should go to oe-core ml as well.

> Signed-off-by: Adrian Bunk 
> ---
>  documentation/ref-manual/ref-classes.xml | 15 ---
>  1 file changed, 15 deletions(-)
>
> diff --git a/documentation/ref-manual/ref-classes.xml 
> b/documentation/ref-manual/ref-classes.xml
> index 37619e382d..5403f20b6f 100644
> --- a/documentation/ref-manual/ref-classes.xml
> +++ b/documentation/ref-manual/ref-classes.xml
> @@ -920,21 +920,6 @@
>  
>  
>
> -
> -gnome.bbclass
> -
> -
> -The gnome class supports recipes that
> -build software from the GNOME stack.
> -This class inherits the
> - linkend='ref-classes-gnomebase'>gnomebase,
> - linkend='ref-classes-gtk-icon-cache'>gtk-icon-cache,
> -gconf 
> and
> -mime 
> classes.
> -The class also disables GObject introspection where applicable.
> -
> -
> -

do we need to enhance the documentation for gnomebase bbclass to
mention about disabling  gobject introspection
or is it handled differently now.

>  
>  gnomebase.bbclass
>
> --
> 2.17.1
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Warrior, extended SDK

[Khem Raj]

On Sat, Jun 22, 2019 at 1:37 PM Peter Balazovic
 wrote:
>
> Hello guys
>
> I'm trying to generate extended SDK under Yocto-Warrior and getting error 
> such as
>
> ERROR: image-qt5-1.0-r0 do_sdk_depends: The file 
> /usr/include/tensorflow/contrib/lite/string_util.h is installed by both 
> tensorflow and tensorflow-lite, aborting
> ERROR: image-qt5-1.0-r0 do_sdk_depends:
> ERROR: image-qt5-1.0-r0 do_sdk_depends: Function failed: extend_recipe_sysroot
>
> can you help me identify an issue on this fail?
>

you are including two packages which are providing same file. Only one
of those should be providing the file, either delete it or rename it
in other recipe if both packages
are to be installed side by side

> Thanks.
> Peter
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Meta-raspberrypi

[Khem Raj]

On Mon, Jul 29, 2019 at 2:15 AM Shravan Singh  wrote:
>
> Hello All,
>
> I am trying to create a base image for raspberry-pi cm3(compute module 3)
>
> I am using warrior-21.0.1
> I downloaded meta-raspberry-pi from  
> https://git.yoctoproject.org/git/meta-raspberrypi
> I added the layer in bblayer.conf and I have changed the machine variable in 
> local.conf
> to raspberrypi-cm3
> I am using oe-init-build script to generate the base files
>
> Now when I run the command
> bitbake core-image-base
>
> I get the below mentioned error
> Error: No recipes available for:
> /home/blue/yacto/meta-raspberrypi/recipes-bsp/u-boot/u-boot_2019.07.bbappend
> /home/blue/yacto/meta-raspberrypi/recipes-multimedia/gstreamer/gstreamer1.0-omx_1.16%.bbappend
>
>
> Any help with this?

always post the Build Configuration printed by bitbake on top, When
you add layers ensure that the branches
match to core layer e.g. if you are using warrior release for
core/poky then use same branch checkout for
meta-raspberrypi as well.

>
>
> Regards,
> Shravan Singh
> (239) 243-0838
>
> Blue Sparq, Inc.
> 928 NE 24th Lane unit 4 and 5.
> Cape Coral, FL 33993
>
> IMPORTANT: The contents of this email and any attachments are confidential. 
> They are intended for the named recipient(s) only. If you have received this 
> email by mistake, please notify the sender immediately and do not disclose 
> the contents to anyone or make copies thereof.
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Shared area conflict

[Khem Raj]

On 7/28/19 1:05 AM, Andy Pont wrote:

Khem wrote...


there are two recipes building/installing same files. You have to
avoid conflicts via either removing them from one recipe or not
installing them
I’ve fixed this issue by creating a .bbappend file in my custom 
meta-layer that tells mesa not to install these two packages.


Only one major issue left to resolve which is described in [1] albeit 
that I have gone back to thud but I get the same results as I did with 
warrior. I have borrowed the recipes for v1.14 of the PowerVR drivers 
from [2] and fixed a couple of kernel compile issues for kernel >= 
4.1.15 and will try those once I have the device tree entries for my 
LCD cape incorporated.
this looks more recipe level problem to me. Probably you need table to 
do the right arch mapping based on calling convention on arm


-Andy.

1. https://lists.yoctoproject.org/pipermail/yocto/2019-July/046165.html
2. https://git.phytec.de/meta-phytec

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

Re: [yocto] Shared area conflict

[Khem Raj]

On Fri, Jul 26, 2019 at 3:48 AM Andy Pont  wrote:
>
> Hello,
>
> When I try to bitbake core-image-minimal it is giving up with the following 
> error:
>
> ERROR: mesa-gl-2_18.1.9-r0 do_packagedata: The recipe mesa-gl is trying to 
> install files into a shared area when those files already exist. Those files 
> and their manifest location are:
>   /home/me/Yocto/BeagleBoneBlack/tmp/pkgdata/beaglebone/runtime/libgbm
> (matched in manifest-beaglebone-libgbm.packagedata)
>   /home/me/Yocto/BeagleBoneBlack/tmp/pkgdata/beaglebone/runtime/libgbm-dev
> (matched in manifest-beaglebone-libgbm.packagedata)
> Please verify which recipe should provide the above files.
>
> I’ve tried one of the suggestions that it gives in the rather verbose message 
> that follows and nuked the “tmp” directory and rebuilt but with no further 
> success.  My local.conf contains:
>
> PREFERRED_PROVIDER_libgbm = “libgbm”
> PREFERRED_PROVIDER_libgbm-dev = "libgbm-dev”
>
> How do I get it to stop complaining?
>

there are two recipes building/installing same files. You have to
avoid conflicts via either removing them from one recipe or not
installing
them

> -Andy.
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] RDEPENDS in a containerized world

[Khem Raj]

On Fri, Jul 26, 2019 at 10:36 AM Aaron Cohen  wrote:
>
> I'm not sure if this is the proper venue, but I'll send it here hoping for 
> any insight.
>
> I'm developing a containerized system. Ideally the host will be somewhat 
> minimal, and most of the functionality of the system will run inside docker 
> containers.
>
> I have most of this working to some extent now, but am beginning to run into 
> an issue.
>
> How do I handle runtime dependencies that I "know" are provided by the host?
>
> For example, I have one particular application that requires gpsd at runtime.
>
> I know that gpsd is installed on the host, so would prefer that it not be 
> installed again in the docker container for this application.
>
> Do I have to edit the recipe for the application and remove the 
> RDEPENDS="gpsd" line, or is there some more clever way that I can specify 
> that the RDEPENDS has been fulfilled for the container that is being built?
>

The build-system is constructing a platform image and therefore it
thinks as if it will run on bare-metal, rdeps are for ensuring that it
does not have those dependencies missing. In your case
the images is contained so you have to teach that to the build system.
Maybe via a bbappend remove the runtime dependency and lower the QA
guards to ignore it for given recipe.

> Thanks,
> Aaron
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Recipes for gcc-native

[Khem Raj]

On Mon, Jul 22, 2019 at 1:14 PM Taborski, Krzysztof (Nokia - PL/Wroclaw) <
krzysztof.tabor...@nokia.com> wrote:

> Hello,
> I am wondering, if there is any reason, that yocto project does not
> delivers recipes for gcc-native ( in similar way as python-native for
> example)?
>
> It would allow to build native recipes with different/higher version of
> gcc, than this, which user has on my build servers.
>


This would not solve the problem fully and yet create more maintainer
burden since the supporting libraries are still coming from distribution
underneath and this would create yet another combination for variable

I think container approach would solve this for us in a nicer way

Most supported distribution do support newer compiler packages and that’s a
better option since they would have tested it on that distribution to some
extent

>
> Best regards,
>
> Krzysztof Taborski
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Create an image from deployed files

[Khem Raj]

On Wed, Jul 3, 2019 at 12:43 PM Stefan Herbrechtsmeier
 wrote:
>
> Hi,
>
> what would be the best solution to create an image from deployed files?
>
> The wic bootimg-partition plugin copy over files listed in
> IMAGE_BOOT_FILES and create a partition inside the wic image. The
> image.bbclass creates an image from individual packages.
>
> I want to create an image like the image.bbclass but from deployed files
> like the wic bootimg-partition plugin.
>
> I have add an image_types_vfat.bbclass to create vfat images, move the
> common parts from image.bbclass into image-common.bbclass and add a
> boot-image.bbclass. This class duplicates some code from the wic
> bootimg-partition plugin inside the do_rootfs function and add some
> dummy tasks to minimize the changes in the common code.
>
> I wonder if this is the right direction or if another solution exists.
>

I would think you can add a wic kickstart image to generate your desired image

> Best regards
>Stefan
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Looking for a recommendation for the right Yocto dev board that supports MIPI CSI-2...

[Khem Raj]

On Wed, Jul 3, 2019 at 4:32 PM Bob Cochran  wrote:
>
> On 6/20/19 11:24 PM, Bob Cochran wrote:
> > Hi,
> >
> > I'm doing some work with MIPI cameras, and I need a development board
> > with stable Yocto and MIPI CSI-2 support.   At this point, I'm
> > thinking i.MX, but I'm open to any suggestion.
>
> It looks like we're going to purchase an NXP MCIMX8M-EVK dev board (at
> least one to get started).   Can someone please confirm that the
> imx8mqevk.conf machine file is for this board?
>
> Is this board Yocto Project stable?  I need to be able to build the
> master branch for this board (or should I be using next?). Any comments
> or feedback will be great appreciated.
>
> https://www.nxp.com/support/developer-resources/evaluation-and-development-boards/i.mx-evaluation-and-development-boards/evaluation-kit-for-the-i.mx-8m-applications-processor:MCIMX8M-EVK
>

seems it is in meta-freescale.
https://git.yoctoproject.org/cgit/cgit.cgi/meta-freescale/tree/conf/machine/imx8mqevk.conf?h=master

> Thanks
>
> Bob
>
>
> >
> > I'm not sure what type of access I'll have to the D-PHY data streams.
> > Do they always terminate into a GPU?   However, I would like a board
> > that gives me the most capability to control / route the data with
> > open source drivers.
> >
> > I suppose I want CSI-2 in and HDMI out.
> >
> > Thank you,
> >
> > Bob
> >
> >
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] ERROR: Actual rootfs size is larger than allowed

[Khem Raj]

On 7/19/19 4:27 AM, María del Mar Velasco AERTEC Solutions – Aerospace & 
Aviation wrote:


Dear all,

I am new at Yocto Project and I have a simple question. I have cloned 
poky (rocko branch), sourced the environment and bitbaked the 
core-minimal-image-dev without problems. I can write the image in a SD 
Card and I am able to boot the system.


However, when I add IMAGE_INSTALL_append to local.conf with some 
packages recipes (IMAGE_INSTALL_append = “nodejs” for example), I get 
the following error:


  * ERROR: Function failed: do_image_wic
  * ERROR: Actual rootfs size (284260 KB) is larger than allowed size
262144 KB.

My question is: where could I find that 262144 KB default size value? 
I would like to change it and make it bigger. I have tried to add 
 IMAGE_ROOTFS_SIZE = “500” to local.conf file but it still fails.


you might want to check the kickstart ( .wks ) file and adjust the 
--fixed-size values for partition sizes




I attach the log.do_image_wic file.

Thanks you in advance,

MM


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

Re: [yocto] [Meta-Qt5] "Unknown Module: declarative" Error While Creating Toolchain

[Khem Raj]

On Mon, Jul 15, 2019 at 1:06 AM Onur Eser  wrote:
>
> Hi Khem,
> Thank you for your answer. I have built a toolchain as exactly as you said, 
> days ago.
> But it was giving error Unknown Modules: widgets when I try to compile. Me 
> and my
> BSP found that this is a know Qt layer issue that will not be solved til an 
> update is pushed to meta-qt5 layer.

What is complete error here and which recipe is it coming from ?
it looks like that package needs QtWidgets

> Thank you anyway, I am trying to native compile over Debian.
> Have a great week!
> Onur
>
> Khem Raj , 15 Tem 2019 Pzt, 03:55 tarihinde şunu yazdı:
>>
>> On Mon, Jul 8, 2019 at 10:59 PM Onur Eser  wrote:
>> >
>> > Hello All,
>> >
>> > I have talked to my BSP provider and they have solved the conflict files 
>> > issue with an update. Now I am able to create and boot a Yocto Image with 
>> > Meta-Qt5 recipes and 'dev_pkgs' in it. But still cannot create a 
>> > toolchain. Nor with I guess it is trying to compile something before 
>> > qtdeclarative, but these 'something' depends on qtdeclarative.
>> >
>> > My image is core image is Weston. I added the line 'inherit 
>> > populate_sdk_qt5' to my core-image-weston.bb file. And tried both commands 
>> > 'bitbake meta-toolchain-qt5' and 'bitbake -c populate_sdk 
>> > core-image-weston'. The result is the same.
>> >
>> > I cut just the error part of my output:
>> >
>> > | cd qdeclarativefolderlistmodel/ && ( test -e Makefile || 
>> > /home/closx/poky/build/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/qtquick1/5.10.1+gitAUTOINC+b2476dcd53-r0/recipe-sysroot-native/usr/bin/qt5/qmake
>> >  -o Makefile 
>> > /home/closx/poky/build/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/qtquick1/5.10.1+gitAUTOINC+b2476dcd53-r0/git/tests/auto/declarative/qdeclarativefolderlistmodel/qdeclarativefolderlistmodel.pro
>> >  ) && make -f Makefile
>> > | Project ERROR: Unknown module(s) in QT: declarative widgets
>> > | Makefile:88: recipe for target 'sub-qdeclarativecomponent-make_first' 
>> > failed
>> > | make[2]: *** [sub-qdeclarativecomponent-make_first] Error 3
>> > | make[2]: *** Waiting for unfinished jobs
>> > | Project ERROR: Unknown module(s) in QT: declarative
>> > | Project ERROR: Unknown module(s) in QT: declarative
>> > | Makefile:113: recipe for target 'sub-qdeclarativecontext-make_first' 
>> > failed
>> > | make[2]: *** [sub-qdeclarativecontext-make_first] Error 3
>> > | Project ERROR: Unknown module(s) in QT: declarative
>> > | Makefile:138: recipe for target 'sub-qdeclarativeengine-make_first' 
>> > failed
>> > | make[2]: *** [sub-qdeclarativeengine-make_first] Error 3
>> > | Makefile:63: recipe for target 'sub-parserstress-make_first' failed
>> > | make[2]: *** [sub-parserstress-make_first] Error 3
>> > | make[2]: Entering directory 
>> > '/home/closx/poky/build/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/qtquick1/5.10.1+gitAUTOINC+b2476dcd53-r0/build/tests/manual/declarative'
>> > | make[2]: Nothing to be done for 'first'.
>> > | make[2]: Leaving directory 
>> > '/home/closx/poky/build/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/qtquick1/5.10.1+gitAUTOINC+b2476dcd53-r0/build/tests/manual/declarative'
>> > | make[1]: Leaving directory 
>> > '/home/closx/poky/build/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/qtquick1/5.10.1+gitAUTOINC+b2476dcd53-r0/build/tests/manual'
>> > | Project ERROR: Unknown module(s) in QT: declarative
>> > | Makefile:163: recipe for target 'sub-qdeclarativeerror-make_first' failed
>> > | make[2]: *** [sub-qdeclarativeerror-make_first] Error 3
>> > | Project ERROR: Unknown module(s) in QT: declarative
>> > | Makefile:188: recipe for target 
>> > 'sub-qdeclarativefolderlistmodel-make_first' failed
>> > | make[2]: *** [sub-qdeclarativefolderlistmodel-make_first] Error 3
>> > | make[2]: Leaving directory 
>> > '/home/closx/poky/build/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/qtquick1/5.10.1+gitAUTOINC+b2476dcd53-r0/build/tests/auto/declarative'
>> > | Makefile:45: recipe for target 'sub-declarative-make_first' failed
>> > | make[1]: *** [sub-declarative-make_first] Error 2
>> > | make[1]: Leaving directory 
>> > '/home/closx/poky/build/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/qtquick1/5.10.1+gitAUTOINC+b2476dcd53-r0/build/tests/auto'
>> > | Makefile:45: recipe for target 'sub-auto-make_first' failed
>> > | make: *** [sub-auto-make_first] Error 2
>> > | ERROR: oe_runm

Re: [yocto] [Meta-Qt5] "Unknown Module: declarative" Error While Creating Toolchain

[Khem Raj]

On Mon, Jul 8, 2019 at 10:59 PM Onur Eser  wrote:
>
> Hello All,
>
> I have talked to my BSP provider and they have solved the conflict files 
> issue with an update. Now I am able to create and boot a Yocto Image with 
> Meta-Qt5 recipes and 'dev_pkgs' in it. But still cannot create a toolchain. 
> Nor with I guess it is trying to compile something before qtdeclarative, but 
> these 'something' depends on qtdeclarative.
>
> My image is core image is Weston. I added the line 'inherit populate_sdk_qt5' 
> to my core-image-weston.bb file. And tried both commands 'bitbake 
> meta-toolchain-qt5' and 'bitbake -c populate_sdk core-image-weston'. The 
> result is the same.
>
> I cut just the error part of my output:
>
> | cd qdeclarativefolderlistmodel/ && ( test -e Makefile || 
> /home/closx/poky/build/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/qtquick1/5.10.1+gitAUTOINC+b2476dcd53-r0/recipe-sysroot-native/usr/bin/qt5/qmake
>  -o Makefile 
> /home/closx/poky/build/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/qtquick1/5.10.1+gitAUTOINC+b2476dcd53-r0/git/tests/auto/declarative/qdeclarativefolderlistmodel/qdeclarativefolderlistmodel.pro
>  ) && make -f Makefile
> | Project ERROR: Unknown module(s) in QT: declarative widgets
> | Makefile:88: recipe for target 'sub-qdeclarativecomponent-make_first' failed
> | make[2]: *** [sub-qdeclarativecomponent-make_first] Error 3
> | make[2]: *** Waiting for unfinished jobs
> | Project ERROR: Unknown module(s) in QT: declarative
> | Project ERROR: Unknown module(s) in QT: declarative
> | Makefile:113: recipe for target 'sub-qdeclarativecontext-make_first' failed
> | make[2]: *** [sub-qdeclarativecontext-make_first] Error 3
> | Project ERROR: Unknown module(s) in QT: declarative
> | Makefile:138: recipe for target 'sub-qdeclarativeengine-make_first' failed
> | make[2]: *** [sub-qdeclarativeengine-make_first] Error 3
> | Makefile:63: recipe for target 'sub-parserstress-make_first' failed
> | make[2]: *** [sub-parserstress-make_first] Error 3
> | make[2]: Entering directory 
> '/home/closx/poky/build/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/qtquick1/5.10.1+gitAUTOINC+b2476dcd53-r0/build/tests/manual/declarative'
> | make[2]: Nothing to be done for 'first'.
> | make[2]: Leaving directory 
> '/home/closx/poky/build/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/qtquick1/5.10.1+gitAUTOINC+b2476dcd53-r0/build/tests/manual/declarative'
> | make[1]: Leaving directory 
> '/home/closx/poky/build/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/qtquick1/5.10.1+gitAUTOINC+b2476dcd53-r0/build/tests/manual'
> | Project ERROR: Unknown module(s) in QT: declarative
> | Makefile:163: recipe for target 'sub-qdeclarativeerror-make_first' failed
> | make[2]: *** [sub-qdeclarativeerror-make_first] Error 3
> | Project ERROR: Unknown module(s) in QT: declarative
> | Makefile:188: recipe for target 
> 'sub-qdeclarativefolderlistmodel-make_first' failed
> | make[2]: *** [sub-qdeclarativefolderlistmodel-make_first] Error 3
> | make[2]: Leaving directory 
> '/home/closx/poky/build/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/qtquick1/5.10.1+gitAUTOINC+b2476dcd53-r0/build/tests/auto/declarative'
> | Makefile:45: recipe for target 'sub-declarative-make_first' failed
> | make[1]: *** [sub-declarative-make_first] Error 2
> | make[1]: Leaving directory 
> '/home/closx/poky/build/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/qtquick1/5.10.1+gitAUTOINC+b2476dcd53-r0/build/tests/auto'
> | Makefile:45: recipe for target 'sub-auto-make_first' failed
> | make: *** [sub-auto-make_first] Error 2
> | ERROR: oe_runmake failed
> | WARNING: exit code 1 from a shell command.
> | ERROR: Function failed: do_compile_ptest_base (log file is located at 
> /home/closx/poky/build/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/qtquick1/5.10.1+gitAUTOINC+b2476dcd53-r0/temp/log.do_compile_ptest_base.29566)
> ERROR: Task 
> (/home/closx/poky/meta-qt5/recipes-qt/qt5/qtquick1_git.bb:do_compile_ptest_base)
>  failed with exit code '1'
>
> What do you guys think the reason of this issue may be? Any solution offers?
>
> My full output:
> https://paste.ee/p/PupWr#Epvqnw9FoasgQEBhIXqQ8hH7veMcRybX
>
> Another source issue again?
> Have a lovely day!

qtquick1 has been removed but I am guessting you are on an older
release. Can you try adding DEPENDS += "qtdeclarative"  to qtquick1
recipe and see if that helps ?
secondly you can stop build ptest for this package since thats where
its failing, that might be a workaround.

> Onur
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Cross compilation sysroot doesn't include libusb

[Khem Raj]

On Fri, Jul 12, 2019 at 1:02 PM Srinivasan, Usha
 wrote:
>
> I will start with the caveat: this is my first time trying to cross compile 
> for a target running a yocto bitbaked image. So I am surely not doing the 
> right thing.
>
>
>
> I have generated both a core-image-sato & core-image-sato-dev.  I am 
> developing an application to run on my target machine.  My application uses 
> libraries that in turn need libusb.so which doesn’t exist in under the 
> sysroot setup for cross compilation.  I have these in my local.conf and I do 
> see
>
>
>
> EXTRA_IMAGE_FEATURES ?= "debug-tweaks tools-testapps tools-sdk dev-pkgs"
>
> CORE_IMAGE_EXTRA_INSTALL += "openssh glib-2.0 glibc glib-networking 
> libusb-compat"
>
>
>
> I do see that libusb-compat was generated:
>
> ./corei7-64-poky-linux/libusb-compat/1_0.1.5-r0/deploy-rpms/corei7_64/libusb-0.1-4-0.1.5-r0.corei7_64.rpm
>
> ./corei7-64-poky-linux/libusb-compat/1_0.1.5-r0/deploy-rpms/corei7_64/libusb-0.1-src-0.1.5-r0.corei7_64.rpm
>
> ./corei7-64-poky-linux/libusb-compat/1_0.1.5-r0/deploy-rpms/corei7_64/libusb-0.1-dev-0.1.5-r0.corei7_64.rpm
>
> ./corei7-64-poky-linux/libusb-compat/1_0.1.5-r0/deploy-rpms/corei7_64/libusb-0.1-dbg-0.1.5-r0.corei7_64.rpm
>
>
>
> I tried bitbake meta-ide-support and used 
> tmp/environment-setup-corei7-64-poky-linux to setup my build environment, but 
> there is no libusb.so in the sysroot lib directory.
>
>
>
> I tried bitbake meta-toolchain and installed the tool chain and used its  
> /opt/poky/2.7/environment-setup-corei7-64-poky-linux, but again the 
> opt/poky/2.7 sysroot directory  also does not include libusb.so.

you should generate image specific SDK with bitbake -cpopulate_sdk
core-image-sato
and also add libusb to CORE_IMAGE_EXTRA_INSTALL if its not being
pulled in autromatically
as a dependency by some package in sato image.

>
>
>
> What step am I missing?
>
>
>
> Thanks in advance,
>
> Usha
>
>
>
> 
> Intel Corporation
>
> 1110 American Parkway NE
>
> Suite F-100, AMP1 10C-166b
> Allentown, PA 18109-9151
>
> 484-245-9498
>
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How to load into u-boot binary (srec) file

[Khem Raj]

On Mon, Jul 8, 2019 at 9:27 AM Szabolcs Báder  wrote:

> Hello,
>
> I created this code:
>
> ```
> # u-boot standalone hello-world.c test image
> require recipes-core/images/core-image-base.bb
>
> COMPATIBLE_MACHINE = "^rpi$"
>
> ENABLE_UART="1"
> RPI_USE_U_BOOT="1"
>
> # maybe works??
> CONFIG_STANDALONE_LOAD_ADDR="0x1000"
>
> DEPENDS = "u-boot-mkimage-native"
>
> SUMMARY="Helloworld"
> DESCRIPTION="Helloworld"
> LICENSE="CLOSED"
> # LIC_FILES_CHCKSUM = "file://COPYING;md5=1fec1f350300594d23a1d03379c0c989"
>
> SRC_URI += "file://hello_world.c"
> HELLO ?= "hello_world.c"
> do_compile() {
> mkimage -A arm -O linux -T standalone -C none -a ${LOAD_ADDR} -e 0 \
> -n "standalone example script" \
> -d ${WORKDIR}/${HELLO} ${B}/helloworld.srec
> }
>
> inherit deploy
>
> do_deploy() {
> install -d ${DEPLOYDIR}
> install -m 0644 ${B}/helloworld.srec ${DEPLOYDIR}/
> }
>
> addtask do_deploy after do_compile before do_build
> ```
>
> I get errors, because I think.. the mkimage part.. isn't working..
> somebody could help me, how to solve this?
>
>
if you post error messages that you see. It might provide more context



> Regards,
> Szabolcs
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How to load into u-boot binary (srec) file

[Khem Raj]

On Mon, Jul 8, 2019 at 9:27 AM Szabolcs Báder  wrote:

> Hello,
>
> I created this code:
>
> ```
> # u-boot standalone hello-world.c test image
> require recipes-core/images/core-image-base.bb
>
> COMPATIBLE_MACHINE = "^rpi$"
>
> ENABLE_UART="1"
> RPI_USE_U_BOOT="1"
>
> # maybe works??
> CONFIG_STANDALONE_LOAD_ADDR="0x1000"
>
> DEPENDS = "u-boot-mkimage-native"
>
> SUMMARY="Helloworld"
> DESCRIPTION="Helloworld"
> LICENSE="CLOSED"
> # LIC_FILES_CHCKSUM = "file://COPYING;md5=1fec1f350300594d23a1d03379c0c989"
>
> SRC_URI += "file://hello_world.c"
> HELLO ?= "hello_world.c"
> do_compile() {
> mkimage -A arm -O linux -T standalone -C none -a ${LOAD_ADDR} -e 0 \
> -n "standalone example script" \
> -d ${WORKDIR}/${HELLO} ${B}/helloworld.srec
> }
>
> inherit deploy
>
> do_deploy() {
> install -d ${DEPLOYDIR}
> install -m 0644 ${B}/helloworld.srec ${DEPLOYDIR}/
> }
>
> addtask do_deploy after do_compile before do_build
> ```
>
> I get errors, because I think.. the mkimage part.. isn't working..
> somebody could help me, how to solve this?
>
> Regards,
> Szabolcs
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Can't build SDK while shrinking shadow tools

[Khem Raj]

On Fri, Jun 14, 2019 at 2:16 AM Jérémy Singy  wrote:

> Hi,
>
> I'm facing a problem by trying to shrink the size of our root filesystem.
> To avoid installing some unneeded tools such as adduser, groupadd,
> nologin, etc. I just created as usual a shadow_%.bbappend in our layer
> which removes the content using do_install_append:
>
> # do not install alternatives
> ALTERNATIVE_${PN} = ""
> ALTERNATIVE_${PN}-base = ""


This is most probably the reason for your issue
You may want to remove the alternatives which you are deleting but not
everything

>
>
> # remove unwanted files on target
> do_install_append_class-target () {
>   rm -r ${D}${base_bindir}
>   rm -r ${D}${base_sbindir}
>   rm -r ${D}${bindir}
>   rm -r ${D}${sbindir}
> }
>
> Building an image with this works well and I got rid of the unwanted
> tools but I get an error whenever I try to build the SDK for this image
> with do_populate_sdk:
>
> WARNING: ceres-image-1.0-r0 do_populate_sdk:
> nativesdk-util-linux.postinst returned 1, marking as unpacked only,
> configuration required on target.
> ERROR: ceres-image-1.0-r0 do_populate_sdk: Postinstall scriptlets
> of ['nativesdk-util-linux'] have failed. If the intention is to defer
> them to first boot,
> then please place them into pkg_postinst_ontarget_${PN} ().
> Deferring to first boot via 'exit 1' is no longer supported.
> Details of the failure are in
>
> /home/chsingj/yocto-thud/tmp/work/ceres_con-oe-linux-gnueabi/ceres-image/1.0-r0/temp/log.do_populate_sdk.
> ERROR: ceres-image-1.0-r0 do_populate_sdk: Function failed:
> do_populate_sdk
> ERROR: Logfile of failure stored in:
>
> /home/chsingj/yocto-thud/tmp/work/ceres_con-oe-linux-gnueabi/ceres-image/1.0-r0/temp/log.do_populate_sdk.28331
> ERROR: Task
> (/home/chsingj/meta-delta/recipes-core/images/ceres-image.bb:
> do_populate_sdk)
> failed with exit code '1'
> NOTE: Tasks Summary: Attempted 2730 tasks of which 2729 didn't
> need to be rerun and 1 failed.
>
> The log file shows an error with update-alternatives (probably a
> failing ln call):
>
> update-alternatives: Error: not linking
>
> [BUILDPATH]/tmp/work/ceres_con-oe-linux-gnueabi/ceres-image/1.0-r0/sdk/image/opt/ceres/sdk-2019.05-r1/sysroots/x86_64-delta-linux/sbin/nologin
> to
> /opt/ceres/sdk-2019.05-r1/sysroots/x86_64-delta-linux/sbin/nologin.util-linux
> since
> [BUILDPATH]/tmp/work/ceres_con-oe-linux-gnueabi/ceres-image/1.0-r0/sdk/image/opt/ceres/sdk-2019.05-r1/sysroots/x86_64-delta-linux/sbin/nologin
> exists and is not a link
>
> If I remove the bbappend, the SDK builds fine but of course my image
> contains the unwanted files. I tried many other recipe tweaks but I
> can't get over some build errors. I'd like to avoid a solution using
> ROOTFS_POSTPROCESS_COMMAND in the image recipe as I would have to
> explicitely list all shadow tools and it would blow up my recipe. Is
> there any solution here? Is it maybe a bug that can be fixed? Thanks!
>
> Regards,
> Jeremy
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] cortexa9t2hf instead of cortexa9hf

[Khem Raj]

On Mon, Jun 17, 2019 at 10:48 AM Arno Steffens  wrote:
>
> Thanks for explaining this.
> I take some time to read about thumb/thumb2. The feedback is mixed. It seems 
> to generate more compact code, but some say it speeds up, others it slows 
> down because of reduced function set - and it can cause strange effects.
> And mixing this causes time to switch processor mode. So, as I am not an 
> expert in this and can't decide what ist best on per function base and speed 
> is of highest priority, I think I better should use not thumb(2).
>
> So, do I get it right that with this cortexa9t2hf I just have the option to 
> compile it for thumb2? But without using a dedicated compiler option it 
> generates same "standard" arm code and the difference is just to adapt all 
> the Makefiles for this suffix.
>
> According to Martin I can get the previous setting by just set 
> ARM_INSTRUCTION_SET to "arm" instead of "armv7a". Mh - I just afraid that I 
> lose other kinds of optimisation. (I am just a user not an expert in arm 
> architecture).
> On the other hand for those like me it is better go the standard way. Once I 
> am sure compiler results will not become worse (see above) I go for the pain 
> and renaming my toolchain/makefiles/stuff.
>
> Thanks for you taking the time.

While the gains/losses from using thumb2 ISA depends upon type of
loads you have and nature of code, in general this is most commonly
used ISA in linux distros, so most of the apps would have
been used compiled with this and probably optimized for as well. I
would advise that you do some bench-marking for your loads and then
decide if using thumb2 ISA is right choice for you or not.

if you want to drop thumb2 you can set appropriate default tune in
your machine config and that will do it

DEFAULTTUNE = "cortexa9hf-neon"


> Arno
>
> > Hello Arno,
> >
> > Let me try to explain my point of view. Since here (my best guess) we
> > have some asynchronous bitbake code which went South upon introducing
> > T2 HW extension.
> >
> > Point [1]: as far as I understand arm, cortexa9t2hf is is just a
> > superset of previous cortexa9hf (HW wise). NEON HW extension (NEON
> > media coprocessor) exists in both of them. In other words:
> > cortexa9t2hf = cortexa9hf HW + T2 HW extension.
> >
> > Point [2]:
> > > bitbake gives me in 2.5:
> > > TUNE_FEATURES= "arm armv7a vfp thumb neon callconvention-hard 
> > > cortexa9"
> > > TARGET_FPU   = "hard"
> > >
> > > and in 2.7:
> > > TUNE_FEATURES= "arm vfp cortexa9 neon thumb callconvention-hard"
> > > TARGET_FPU   = "hard"
> >
> > These two lines are the same: you are able to use 32b arm mode, 16bit
> > thumb mode, using armv7 HW with neon HW extension, and using HW FP
> > extension as well. The Cortex in both cases is A9.
> >
> > I expect that somebody somewhere in bitbake version 1.42 - 100% sure
> > (since 2.5/Sumo uses bitbake 1.38) dropped "armv7a" as TUNE FEATURE,
> > and I have no idea if this is done intentionally or not.
> >
> > Because of that I copied Alex and Ross to CC: into email, so they
> > should unveil this mystery (I would prefer "armv7" to stay in bitbake
> > 1.42, since A8 and A9 belongs to armv7, A15 belongs to armv8 (IIRC).
> >
> > Bottom line: nothing to be done by you, Arno, seems that bitbake 1.42
> > should return "armv7" as TUNE FEATURE.
> >
> > Best Regards,
> > Zoran
> > ___
> >
> >
> > On Mon, Jun 17, 2019 at 3:00 PM Arno Steffens  wrote:
> > >
> > > Hello Zoran,
> > > thanks. As far as I understand is thumb2 another mode of coding, that 
> > > might create more compact code.
> > > But I want to keep all compatible to my previous tool-chain and settings.
> > > The only file where I can found this "cortexa9t2hf" is
> > > ./meta/conf/machine/include/tune-cortexa9.inc
> > > but I can't see how I can control Yocto to generate "cortexa9hf-neon" as 
> > > before.
> > > Or have I been wrong the time before?
> > >
> > > bitbake gives me in 2.5:
> > >
> > > TUNE_FEATURES= "arm armv7a vfp thumb neon callconvention-hard 
> > > cortexa9"
> > > TARGET_FPU   = "hard"
> > >
> > > and in 2.7:
> > > TUNE_FEATURES= "arm vfp cortexa9 neon thumb callconvention-hard"
> > > TARGET_FPU   = "hard"
> > >
> > > so armv7a seem to be missing. In terms of thumb both is same. But is that 
> > > the reason? Where to set it?
> > > Arno
> > >
> > > >
> > > > Hello Arno,
> > > >
> > > > Your question, per say, has little to do with YOCTO forum. But I'll
> > > > try (as my best) to answer your question.
> > > >
> > > > Cortexa9hf should be armv7 A9 Hard Floating (it contains HW FP unit).
> > > >
> > > > Cortexa9t2hf is by analogy armv7 A9 T2 Hard Floating. Now, the
> > > > question is what is T2? T2 is addition to the previous architecture
> > > > Cortexa9hf, and addition is Thumb-2 mode.
> > > >
> > > > Hope this helps,
> > > >
> > > > Zoran
> > > > ___
> > > >
> > > > On Mon, Jun 17, 2019 at 2:03 PM Arno Steffens  wrote:
> > > > >
> > > > > 

Re: [yocto] devshell env in warrior

[Khem Raj]

On Mon, Jun 17, 2019 at 4:55 PM matthew stanger  wrote:
>
> I'm trying to figure out why when running devshell in Warrior CC/CFLAGS are 
> not the same as do_compile for a recipe. For example.
> devshell printenv yields:
> CC=aarch64-poky-linux-gcc   -fuse-ld=bfd 
> -fmacro-prefix-map=/home/matt/rdk_warrior/build/tmp/work/7271-poky-linux/brcm/18.3+AUTOINC+0a6fb7430f-0=/usr/src/debug/ursr/18.3+AUTOINC+0a6fb7430f-0
>  
> -fdebug-prefix-map=/home/matt/rdk_warrior/build/tmp/work/7271-poky-linux/brcm/18.3+AUTOINC+0a6fb7430f-0=/usr/src/debug/ursr/18.3+AUTOINC+0a6fb7430f-0
>  
> -fdebug-prefix-map=/home/matt/rdk_warrior/build/tmp/work/7271-poky-linux/brcm/18.3+AUTOINC+0a6fb7430f-0/recipe-sysroot=
>  
> -fdebug-prefix-map=/home/matt/rdk_warrior/build/tmp/work/7271-poky-linux/brcm/18.3+AUTOINC+0a6fb7430f-0/recipe-sysroot-native=
>   
> -fdebug-prefix-map=/home/matt/rdk_warrior/build/tmp/work-shared/tmobile-7271-kaon-mini/kernel-source=/usr/src/kernel
>
> do_compile() {
> /usr/bin/printenv | sort > debug.log
> }
> yields...
> CC=aarch64-poky-linux-gcc  -mcpu=cortex-a53+crc+crypto 
> -fstack-protector-strong  -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security 
> -Werror=format-security 
> --sysroot=/home/matt/rdk_warrior/build/tmp/work/tmobile_7271_kaon_mini-poky-linux/ursr/18.3+AUTOINC+0a6fb7430f-0/recipe-sysroot
>
> This causes some very different behavior out of the makefile. The recipe I"m 
> working with has no do_configure, and only calls a makefile through 
> do_compile. No appends/prepends or custom functions in the recipe. This 
> recipe is for a lovely Broadcom driver/userspace glob and I'm trying to 
> troubleshoot it with x64 but not being able to get a correct working env 
> makes life hard. Any idea's of where I might be going wrong?
>

Check that Makefiles are not overriding CC/CXX/LD etc. some old crufty
Makefiles I have seen doing that, you might see something like

CC = ${CROSS_COMPILE}gcc etc. which you should convert to weak defines
e.g. CC ?= 

> Cheers
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] prelink-cross with -fno-plt

[Khem Raj]

On Fri, May 24, 2019 at 6:58 PM Shane Peelar  wrote:
>
> Great!  Would you be willing to accept a patch that makes arch-x86_64.c 
> handle that condition like the other arches?
>

yes certainly.

> -Shane
>
> On Fri, May 24, 2019 at 12:27 PM Khem Raj  wrote:
>>
>>
>>
>> On 5/24/19 8:10 AM, Shane Peelar wrote:
>> > I did some reading into the sources in other architectures.  The closest
>> > match, arch_i386.c, makes the write conditional as you say.
>> > So do other arches, including |arch_arm.c, |arch_sh.c, |arch-mips.c,
>> > |arch-s390.c, |arch-s390x.c, and |arch-ia64.c.||
>> > ||
>> > ||
>> > Notably, |||arch-cris.c||| has the same assert as
>> > |||arch-x86_64.c||| instead of the conditional.
>> >
>> > The code roughly looks like follows:||
>> > ||
>> > |||
>> > |||
>> > 1. Check for dso->info[DT_PLTGOT].  If it does not exist, return 0
>> > 2. Call addr_to_sec on dso->info[DT_PLTGOT], return 1 if error
>> > 3. Look for the section named ".plt" in the ELF.
>> > 4. If the section cannot be found, return 0
>> > 5. Otherwise, write the address of .plt + constant (dependent on arch)
>> > to got[1]||
>> > ||
>> > |||
>> > |||
>> > In |||arch-x86_64.c and arch-cris.c|||, step (4) above is an
>> > assert:|||
>> >
>> > |||1. Check for dso->info[DT_PLTGOT].  If it does not exist, return 0
>> > 2. Call addr_to_sec on dso->info[DT_PLTGOT], return 1 if error
>> > 3. Look for the section named ".plt" in the ELF.
>> > 4. Assert that the section was found
>> > 5. Write the address of .plt + constant (dependent on arch) to got[1]
>> >
>> > I tested out making the assert conditional and nothing seemed to break
>> > at least.
>> > |||
>> > |||
>>
>> It seems ok to me.
>>
>> >
>> > On Fri, May 24, 2019 at 12:08 AM Khem Raj > > <mailto:raj.k...@gmail.com>> wrote:
>> >
>> >
>> >
>> > On 5/23/19 7:53 PM, Shane Peelar wrote:
>> >  > Any of them on the system pretty much, and yes they are also
>> > built with
>> >  > -fno-plt.
>> >
>> > OK, I think its better to them conditionally check for .plt section,
>> > can you describe more of whats going on when sections are checked.
>> >
>> >  >
>> >  > On Thu, May 23, 2019 at 9:59 PM Khem Raj > > <mailto:raj.k...@gmail.com>
>> >  > <mailto:raj.k...@gmail.com <mailto:raj.k...@gmail.com>>> wrote:
>> >  >
>> >  >
>> >  >
>> >  > On 5/23/19 8:05 AM, Shane Peelar wrote:
>> >  >  > Hi Everyone @ the Yocto project,
>> >  >  >
>> >  >  > I'm Shane Peelar, a PhD Candidate at the University of
>> > Windsor.
>> >  >  > I'm writing to you about prelink-cross, as part of the
>> > Yocto project.
>> >  >  > Specifically, I'm looking at using it with executables
>> > built using
>> >  >  > `-fno-plt` under GCC.
>> >  >  > I wasn't quite sure where to send this email to, so I
>> > figured I'd
>> >  > try
>> >  >  > here.  If there's a better place to send this, please let
>> > me know.
>> >  >  >
>> >  >  > Right now, prelink-cross seems to fail an assertion in
>> >  > arch-x86_64.c,
>> >  >  > line 421, when
>> >  >  > using it with an executable built with `-fno-plt`:
>> >  >  >
>> >  >  > ...
>> >  >  > assert (i < dso->ehdr.e_shnum)
>> >  >  > ...
>> >  >  >
>> >  >  > This snippet seems to be looking for the ".plt" section and,
>> >  > since it
>> >  >  > can't find it, the assertion fires.  This makes sense
>> > because in
>> >  >  > `-fno-plt` executables, the `.plt` section is missing
>> > entirely.
>> >  >  > I'm not an expert on ELF stuff, although I am learning
>> > quickly.  It
>> >  >  > looks like
>> >  >  > this code wants to write into GOT[1] the address of ".plt"
>> > + 0x16 --
>> >  >  > since ".plt" doesn't
>> >  >  > exist, does it make sense to just change this assert to an if
>> >  > statement
>> >  >  > like so:
>> >  >  >
>> >  >  > ...
>> >  >  >if (i < dso->ehdr.e_shnum)
>> >  >  >{ ... }
>> >  >  > ...
>> >  >  >
>> >  >  > and skip over that part?  Or is this a real error
>> > condition for
>> >  >  > prelink-cross and it really should not continue?  The
>> > executable in
>> >  >  > question is also non-PIE, if that makes a difference.
>> >  >  >
>> >  >
>> >  > what shared libs is this linking to ? are they also built with
>> >  > -fno-plt ?
>> >  >
>> >  >  > Thanks for your time,
>> >  >  > Shane
>> >  >  >
>> >  >
>> >
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] prelink-cross with -fno-plt

[Khem Raj]

On 5/24/19 8:10 AM, Shane Peelar wrote:
I did some reading into the sources in other architectures.  The closest 
match, arch_i386.c, makes the write conditional as you say.
So do other arches, including |arch_arm.c, |arch_sh.c, |arch-mips.c, 
|arch-s390.c, |arch-s390x.c, and |arch-ia64.c.||

||
||
Notably, |||arch-cris.c||| has the same assert as 
|||arch-x86_64.c||| instead of the conditional.


The code roughly looks like follows:||
||
|||
|||
1. Check for dso->info[DT_PLTGOT].  If it does not exist, return 0
2. Call addr_to_sec on dso->info[DT_PLTGOT], return 1 if error
3. Look for the section named ".plt" in the ELF.
4. If the section cannot be found, return 0
5. Otherwise, write the address of .plt + constant (dependent on arch) 
to got[1]||

||
|||
|||
In |||arch-x86_64.c and arch-cris.c|||, step (4) above is an 
assert:|||


|||1. Check for dso->info[DT_PLTGOT].  If it does not exist, return 0
2. Call addr_to_sec on dso->info[DT_PLTGOT], return 1 if error
3. Look for the section named ".plt" in the ELF.
4. Assert that the section was found
5. Write the address of .plt + constant (dependent on arch) to got[1]

I tested out making the assert conditional and nothing seemed to break 
at least.

|||
|||


It seems ok to me.



On Fri, May 24, 2019 at 12:08 AM Khem Raj <mailto:raj.k...@gmail.com>> wrote:




On 5/23/19 7:53 PM, Shane Peelar wrote:
 > Any of them on the system pretty much, and yes they are also
built with
 > -fno-plt.

OK, I think its better to them conditionally check for .plt section,
can you describe more of whats going on when sections are checked.

     >
 > On Thu, May 23, 2019 at 9:59 PM Khem Raj mailto:raj.k...@gmail.com>
 > <mailto:raj.k...@gmail.com <mailto:raj.k...@gmail.com>>> wrote:
 >
 >
 >
 >     On 5/23/19 8:05 AM, Shane Peelar wrote:
 >      > Hi Everyone @ the Yocto project,
 >      >
 >      > I'm Shane Peelar, a PhD Candidate at the University of
Windsor.
 >      > I'm writing to you about prelink-cross, as part of the
Yocto project.
 >      > Specifically, I'm looking at using it with executables
built using
 >      > `-fno-plt` under GCC.
 >      > I wasn't quite sure where to send this email to, so I
figured I'd
 >     try
 >      > here.  If there's a better place to send this, please let
me know.
 >      >
 >      > Right now, prelink-cross seems to fail an assertion in
 >     arch-x86_64.c,
 >      > line 421, when
 >      > using it with an executable built with `-fno-plt`:
 >      >
 >      > ...
 >      > assert (i < dso->ehdr.e_shnum)
 >      > ...
 >      >
 >      > This snippet seems to be looking for the ".plt" section and,
 >     since it
 >      > can't find it, the assertion fires.  This makes sense
because in
 >      > `-fno-plt` executables, the `.plt` section is missing
entirely.
 >      > I'm not an expert on ELF stuff, although I am learning
quickly.  It
 >      > looks like
 >      > this code wants to write into GOT[1] the address of ".plt"
+ 0x16 --
 >      > since ".plt" doesn't
 >      > exist, does it make sense to just change this assert to an if
 >     statement
 >      > like so:
 >      >
 >      > ...
 >      >        if (i < dso->ehdr.e_shnum)
 >      >        { ... }
 >      > ...
 >      >
 >      > and skip over that part?  Or is this a real error
condition for
 >      > prelink-cross and it really should not continue?  The
executable in
 >      > question is also non-PIE, if that makes a difference.
 >      >
 >
 >     what shared libs is this linking to ? are they also built with
 >     -fno-plt ?
 >
 >      > Thanks for your time,
 >      > Shane
 >      >
 >


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

Re: [yocto] EXT SENDER - yocto Digest, Vol 104, Issue 95

[Khem Raj]

Please keep the thread on list and avoid pm.

as I said you need

1. Write a recipe for your package
2. in do_install of the recipe you want to mention where it should be 
placed e.g.


install -D -m 0755  ${D}${bindir}/

would put it in /usr/bin on target when this package is included in image

3. Include the package in image via IMAGE_INSTALL



On 5/23/19 10:13 PM, Tg, Harish wrote:

Hi Raj,
 Another question I have is where do I place my custom "ubiattach" 
command. Also I am not sure from where does the yocto builds the rootfs /usr/bin 
components. Where do they copied from?

Thanks,
Harish.

-Original Message-----
From: Khem Raj [mailto:raj.k...@gmail.com]
Sent: Friday, May 24, 2019 7:07 AM
To: Tg, Harish ; yocto@yoctoproject.org
Subject: Re: [yocto] EXT SENDER - yocto Digest, Vol 104, Issue 95



On 5/23/19 5:59 AM, Tg, Harish wrote:

Hi,
   I have a question. How to add commands like "ubiattach" to /usr/bin of 
rootfs image. I struggling with the recipes. I do not want to write my own recipe but I 
need to edit some recipe and add the command. Which is the place? I am using yocto for my 
project on TI platform and Linux.
Kindly help.



There is oe-pkgdata-util which can help to map files to recipes but we do not 
have a database for mapping. Maybe it is a good thing to have

for your problem ubiattach is provided by mtd-utils-ubifs which is built from 
mtd-utils recipe. I found it via above tool

% oe-pkgdata-util find-path /usr/sbin/ubiattach.mtd-utils
mtd-utils-ubifs: /usr/sbin/ubiattach.mtd-utils

% oe-pkgdata-util lookup-recipe mtd-utils-ubifs mtd-utils

So you need to add

IMAGE_INSTALL_append = " mtd-utils-ubifs" in your image recipe or local.conf


Thanks,
Harish.

-Original Message-
From: yocto-boun...@yoctoproject.org
[mailto:yocto-boun...@yoctoproject.org] On Behalf Of
yocto-requ...@yoctoproject.org
Sent: Wednesday, May 22, 2019 6:57 PM
To: yocto@yoctoproject.org
Subject: EXT SENDER - yocto Digest, Vol 104, Issue 95

Send yocto mailing list submissions to
yocto@yoctoproject.org

To subscribe or unsubscribe via the World Wide Web, visit

https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.yoctoprojec
t.org_listinfo_yocto=DwICAg=QM_z7khAIdagwHt-12JlKA=4dfUpqj68eYAf
VJs5uk2XkolcOQysOP5VncSFx6bkao=swLBJyRzgqx-Ix1dnv04ZhN6a_WVQSmQSW5YY
Lg3h40=a4sSVLnzzAP3ZRYs01WvSaiSc9QQmfaT7zdBRe0HcwM=
or, via email, send a message with subject or body 'help' to
yocto-requ...@yoctoproject.org

You can reach the person managing the list at
yocto-ow...@yoctoproject.org

When replying, please edit your Subject line so it is more specific than "Re: 
Contents of yocto digest..."


Today's Topics:

 1. GPLv3 package present in rootfs (virendra kumar thakur)
 2. Building single package as image, respecting dependencies
(Norman Stetter)


--

Message: 1
Date: Wed, 22 May 2019 18:55:45 +0530
From: virendra kumar thakur 
To: yocto@yoctoproject.org
Subject: [yocto] GPLv3 package present in rootfs
Message-ID:

Content-Type: text/plain; charset="utf-8"

Hello team,

I want to remove some GPLv3 package from rootfs, but it is still present.

I am using INCOMPATIBLE_LICENSE = "GPL-3.0 LGPL-3.0 AGPL-3. 0"

still some package gnutls, libidn2, libassuan, are added into rootfs.
-- next part -- An HTML attachment was
scrubbed...
URL:
<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.yoctoprojec
t.org_pipermail_yocto_attachments_20190522_fb9ebe67_attachment-2D0001.
html=DwICAg=QM_z7khAIdagwHt-12JlKA=4dfUpqj68eYAfVJs5uk2XkolcOQys
OP5VncSFx6bkao=swLBJyRzgqx-Ix1dnv04ZhN6a_WVQSmQSW5YYLg3h40=BBPanVh
jmdOQaYXZFeb4RWi9MdRpGYBFLmqihDeSAds=>

--

Message: 2
Date: Wed, 22 May 2019 12:36:18 +
From: Norman Stetter 
To: "yocto@yoctoproject.org" 
Subject: [yocto] Building single package as image, respecting
dependencies
Message-ID:

Content-Type: text/plain; charset="iso-8859-1"

Hi there,

I am currently working on a minimal CLI only system.
The image is based on 'core-image-base' using sysvinit and busybox.
To reduce image size and boot time, I removed as many packages as possible. For 
some application cases I will need python3 though.
My idea was to have python3 as some kind of add-on in a squashfs image, that 
can be mounted only when needed.

So I tried to build an image only containing the python3 package, but as little 
as possible otherwise, like this:

inherit image
IMAGE_FSTYPES = "squashfs-xz"
DEFAULT_TASK_PROVIDER = ""
DISTRO_EXTRA_RDEPENDS = ""
DISTRO_FEATURES = ""
POKY_DEFAULT_EXTRA_RDEPENDS = ""
IMAGE_FEATURES = ""
IMAGE_LINGUAS = ""
CORE_IMAGE_BASE_INSTALL = ""
RDEPENDS_${PN} = ""
PACKAGE_EXCLUDE = "busy

Re: [yocto] EXT SENDER - yocto Digest, Vol 104, Issue 95

[Khem Raj]

That could be done by writing a recipe to build and/or package your 
version. So look how to write a new recipe, if its prebuilt you just 
might be able to package it using do_install() step in your recipe


and then add that package to IMAGE_INSTALL

see 
https://wiki.yoctoproject.org/wiki/Building_your_own_recipes_from_first_principles


especially section  "Build an example package based on a remote source 
archive"



On 5/23/19 9:58 PM, Tg, Harish wrote:

Hi Raj,
  My ubiattach is separate one which works for our project. Its not 
part of ubifs package. I need to place that in /usr/bin rootfs image. Also I 
couldn’t find the place where I need to copy this ubiattach command. You can 
take this as custom ubiattach command. I could locate local.conf but there is 
no IMAGE_INSTALL_append in it. I do not have clear idea. Please clarify.

Thanks,
Harish.

-Original Message-----
From: Khem Raj [mailto:raj.k...@gmail.com]
Sent: Friday, May 24, 2019 7:07 AM
To: Tg, Harish ; yocto@yoctoproject.org
Subject: Re: [yocto] EXT SENDER - yocto Digest, Vol 104, Issue 95



On 5/23/19 5:59 AM, Tg, Harish wrote:

Hi,
   I have a question. How to add commands like "ubiattach" to /usr/bin of 
rootfs image. I struggling with the recipes. I do not want to write my own recipe but I 
need to edit some recipe and add the command. Which is the place? I am using yocto for my 
project on TI platform and Linux.
Kindly help.



There is oe-pkgdata-util which can help to map files to recipes but we do not 
have a database for mapping. Maybe it is a good thing to have

for your problem ubiattach is provided by mtd-utils-ubifs which is built from 
mtd-utils recipe. I found it via above tool

% oe-pkgdata-util find-path /usr/sbin/ubiattach.mtd-utils
mtd-utils-ubifs: /usr/sbin/ubiattach.mtd-utils

% oe-pkgdata-util lookup-recipe mtd-utils-ubifs mtd-utils

So you need to add

IMAGE_INSTALL_append = " mtd-utils-ubifs" in your image recipe or local.conf


Thanks,
Harish.

-Original Message-
From: yocto-boun...@yoctoproject.org
[mailto:yocto-boun...@yoctoproject.org] On Behalf Of
yocto-requ...@yoctoproject.org
Sent: Wednesday, May 22, 2019 6:57 PM
To: yocto@yoctoproject.org
Subject: EXT SENDER - yocto Digest, Vol 104, Issue 95

Send yocto mailing list submissions to
yocto@yoctoproject.org

To subscribe or unsubscribe via the World Wide Web, visit

https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.yoctoprojec
t.org_listinfo_yocto=DwICAg=QM_z7khAIdagwHt-12JlKA=4dfUpqj68eYAf
VJs5uk2XkolcOQysOP5VncSFx6bkao=swLBJyRzgqx-Ix1dnv04ZhN6a_WVQSmQSW5YY
Lg3h40=a4sSVLnzzAP3ZRYs01WvSaiSc9QQmfaT7zdBRe0HcwM=
or, via email, send a message with subject or body 'help' to
yocto-requ...@yoctoproject.org

You can reach the person managing the list at
yocto-ow...@yoctoproject.org

When replying, please edit your Subject line so it is more specific than "Re: 
Contents of yocto digest..."


Today's Topics:

 1. GPLv3 package present in rootfs (virendra kumar thakur)
 2. Building single package as image, respecting dependencies
(Norman Stetter)


--

Message: 1
Date: Wed, 22 May 2019 18:55:45 +0530
From: virendra kumar thakur 
To: yocto@yoctoproject.org
Subject: [yocto] GPLv3 package present in rootfs
Message-ID:

Content-Type: text/plain; charset="utf-8"

Hello team,

I want to remove some GPLv3 package from rootfs, but it is still present.

I am using INCOMPATIBLE_LICENSE = "GPL-3.0 LGPL-3.0 AGPL-3. 0"

still some package gnutls, libidn2, libassuan, are added into rootfs.
-- next part -- An HTML attachment was
scrubbed...
URL:
<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.yoctoprojec
t.org_pipermail_yocto_attachments_20190522_fb9ebe67_attachment-2D0001.
html=DwICAg=QM_z7khAIdagwHt-12JlKA=4dfUpqj68eYAfVJs5uk2XkolcOQys
OP5VncSFx6bkao=swLBJyRzgqx-Ix1dnv04ZhN6a_WVQSmQSW5YYLg3h40=BBPanVh
jmdOQaYXZFeb4RWi9MdRpGYBFLmqihDeSAds=>

--

Message: 2
Date: Wed, 22 May 2019 12:36:18 +
From: Norman Stetter 
To: "yocto@yoctoproject.org" 
Subject: [yocto] Building single package as image, respecting
dependencies
Message-ID:

Content-Type: text/plain; charset="iso-8859-1"

Hi there,

I am currently working on a minimal CLI only system.
The image is based on 'core-image-base' using sysvinit and busybox.
To reduce image size and boot time, I removed as many packages as possible. For 
some application cases I will need python3 though.
My idea was to have python3 as some kind of add-on in a squashfs image, that 
can be mounted only when needed.

So I tried to build an image only containing the python3 package, but as little 
as possible otherwise, like this:

inherit image
IMAGE_FSTYPES = "squashfs-xz"
DEFAULT_TASK_PROVIDER = ""
DISTRO_E

Re: [yocto] Building Out-of-Tree Modules on the BBB Target

[Khem Raj]

On 5/23/19 9:14 PM, Zoran Stojsavljevic wrote:

 > I think this is a fair suggestion. Having prebuilt kernel available
 > that contains the configuration and header files used in the build is
 > all that is required for external modules to build in addition to
 > toolchain, so maybe its worth a try to create such a package and then
 > have kernel-source separated out which can be installed on top if one
 > needs

I am man of experimental try-outs. So, in order to see how big kernel is,
I did the following:
Fedora 29 (which I am using as a host) with kernel-headers (NOT full
kernel source tree):
[vuser@fedora29-ssd 5.0.16-200.fc29.x86_64]$ pwd
/usr/src/kernels/5.0.16-200.fc29.x86_64
[vuser@fedora29-ssd 5.0.16-200.fc29.x86_64]$ du --summarize
/*102124    . <<=== ~95MB*/

Kernel.org kernel 5.0.6, the full kernel source tree size:
[vuser@fedora29-ssd linux-5.0.6]$ pwd
/home/vuser/projects/kernel.org/linux-5.0.6 <http://kernel.org/linux-5.0.6>
[vuser@fedora29-ssd linux-5.0.6]$ du --summarize
/*960592    . <<=== ~900MB*/

These are ballpark numbers. You can draw conclusions for yourselves!

It is ~ 7x to 9x reduction in size. Having BBB's DDR2 of size 512MB,
and initramfs for testing purposes, in speaks for itself.



yes thats what I was expecting too. Anything smaller helps.



(I am aware that YOCTO kernels are less/smaller in size, but how smaller?)



Not in source. The binaries may be


Zoran
___


On Fri, May 24, 2019 at 3:00 AM Khem Raj <mailto:raj.k...@gmail.com>> wrote:




On 5/23/19 3:32 AM, Zoran Stojsavljevic wrote:
 > After some tests (and I had other problems to take care of, as well),
 > here is the following:
 >
 >> These have all been discussed off an on over the past 5 years.
 >> I can't get at bugzilla right now, but all the details are
logged in cases.
 >> A survey of all the distros, their kernel package, etc, were all
looked at.
 >> We had to balance the traditional packaging with some new concepts
 >> and landed with what we have now.
 >
 > I tried several tests. This is my final conclusion (two cases):
 >

https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/Issues/kernel-development.txt
 >
 > The kernel issue is described here: there is need to have the YOCTO
 > minimum configuration with the kernel setup:
 > [1] The entire kernel source code in:
 > /usr/src/kernel/`uname-r`/
 > [2] The header files in: /usr/src/kernel/`uname-r`/ directory structures>
 >
 > Point [1] is achieved with the following local.config file:
 >

https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/Issues/local-devsrc.conf
 >
 > Namely, with the following snippets in the local.conf:
 > TOOLCHAIN_TARGET_TASK_append = " packagegroup-core-tools-profile
 > packagegroup-core-buildessential kernel-devsrc"
 > KERNEL_DEV_TOOLS = "packagegroup-core-tools-profile
 > packagegroup-core-buildessential kernel-devsrc"
 > KERNEL_DEV_MODULE = "kernel-modules"
 > CORE_IMAGE_EXTRA_INSTALL += "${KERNEL_DEV_MODULE} \
 > ${KERNEL_DEV_TOOLS} \
 > systemtap \
 > "
 >
 > Problem with this approach is that such a kernel makes the rootfs too
 > big and impractical:
 > -rw-r--r--. 2 user vboxusers 101499952 May 17 14:32
 > core-image-minimal-beaglebone.rootfs.tar.xz
 >
 > The main issue is point [2]: how to achieve it?
 > The suggestion is to introduce the new package in YOCTO kernel,
 > called: kernel-headers
 > The OBVIOUS benefit is that it will serve to the purpose of building
 > modules out of the tree on the target with
 > minimal mpact to rootfs!

I think this is a fair suggestion. Having prebuilt kernel available
that contains the configuration and header files used in the build is
all that is required for external modules to build in addition to
toolchain, so maybe its worth a try to create such a package and then
have kernel-source separated out which can be installed on top if one
needs

 >
 > Thank you,
 > Zoran Stojsavljevic
 > ___
 >
 > On Thu, May 16, 2019 at 12:04 AM Bruce Ashfield
 > mailto:bruce.ashfi...@gmail.com>> wrote:
 >>
 >>
 >>
 >> On Wed, May 15, 2019 at 4:09 PM Zoran Stojsavljevic
mailto:zoran.stojsavlje...@gmail.com>> wrote:
 >>>
 >>>> The core-image-kernel-dev image is how I do all my on target
 >>>> testing when I introduce a new reference kernel for a release.
 >>>
 >>> Maybe you are correct. Maybe I should use/add in my local.conf
the following:
 

Re: [yocto] prelink-cross with -fno-plt

[Khem Raj]

On 5/23/19 7:53 PM, Shane Peelar wrote:
Any of them on the system pretty much, and yes they are also built with 
-fno-plt.


OK, I think its better to them conditionally check for .plt section,
can you describe more of whats going on when sections are checked.



On Thu, May 23, 2019 at 9:59 PM Khem Raj <mailto:raj.k...@gmail.com>> wrote:




On 5/23/19 8:05 AM, Shane Peelar wrote:
 > Hi Everyone @ the Yocto project,
 >
 > I'm Shane Peelar, a PhD Candidate at the University of Windsor.
 > I'm writing to you about prelink-cross, as part of the Yocto project.
 > Specifically, I'm looking at using it with executables built using
 > `-fno-plt` under GCC.
 > I wasn't quite sure where to send this email to, so I figured I'd
try
 > here.  If there's a better place to send this, please let me know.
 >
 > Right now, prelink-cross seems to fail an assertion in
arch-x86_64.c,
 > line 421, when
 > using it with an executable built with `-fno-plt`:
 >
 > ...
 > assert (i < dso->ehdr.e_shnum)
 > ...
 >
 > This snippet seems to be looking for the ".plt" section and,
since it
 > can't find it, the assertion fires.  This makes sense because in
 > `-fno-plt` executables, the `.plt` section is missing entirely.
 > I'm not an expert on ELF stuff, although I am learning quickly.  It
 > looks like
 > this code wants to write into GOT[1] the address of ".plt" + 0x16 --
 > since ".plt" doesn't
 > exist, does it make sense to just change this assert to an if
statement
 > like so:
 >
 > ...
 >        if (i < dso->ehdr.e_shnum)
 >        { ... }
 > ...
 >
 > and skip over that part?  Or is this a real error condition for
 > prelink-cross and it really should not continue?  The executable in
 > question is also non-PIE, if that makes a difference.
 >

what shared libs is this linking to ? are they also built with
-fno-plt ?

 > Thanks for your time,
 > Shane
 >


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

Re: [yocto] problem adding a user

[Khem Raj]

On 5/23/19 1:40 PM, Rudolf Streif wrote:

Greg,

It eluded me earlier but in both instances the variable containing the 
password does not seem to be expanded.


First version without the single quotes:

SAKURA_PASS = "$1$QVO3K6Ii$fvkoDKnlzz3d5uVoL7KcM0"

EXTRA_USERS_PARAMS = "\
     usermod -p ${SAKURA_PASS} ${SAKURA_USER}; \
     usermod -a -G sudo,dialout ${SAKURA_USER}; \
     "
results in:

NOTE: scribe: Performing usermod with [-R 
/home/gwilson/Qt/Qt-5.12.3/Yocto-build-RPi3/build-raspberrypi3/tmp/work/raspberrypi3-poky-linux-gnueabi/scribe/1.0-r0/rootfs
 -p sakura]

and with the quotes:

SAKURA_PASS = "$1$QVO3K6Ii$fvkoDKnlzz3d5uVoL7KcM0"

EXTRA_USERS_PARAMS = "\
     usermod -p '${SAKURA_PASS}' ${SAKURA_USER}; \
     usermod -a -G sudo,dialout ${SAKURA_USER}; \
     "
results in:
NOTE: scribe: Performing usermod with [-R 
/home/gwilson/Qt/Qt-5.12.3/Yocto-build-RPi3/build-raspberrypi3/tmp/work/raspberrypi3-poky-linux-gnueabi/scribe/1.0-r0/rootfs
 -p '' sakura]

It looks as if the variable SAKURA_PASS is not set at all. I looked at 
your scribe.bb  recipe you attached earlier but I 
could not find any reason why the variable is not set. Is there a chance 
that it is overridden somewhere elase?





This is correct with one small nit that we need to escape some 
characters which has special meaning for shell. e.g. $


e.g. in local.conf something like below

INHERIT += "extrausers"

EXTRA_USERS_PARAMS += "\
useradd sakura; \
usermod -p '\$1\$QVO3K6Ii\$fvkoDKnlzz3d5uVoL7KcM0' sakura; \
"

might work as you expect.


:rjs


On Wed, May 22, 2019 at 1:28 PM Greg Wilson-Lindberg 
mailto:gwil...@sakuraus.com>> wrote:


Rudolf,

Here is the first half of the file,  the whole file is over the 500k
limit of free pastebin:

https://pastebin.com/UcnKebce


And here is the 2nd half of the file:

https://pastebin.com/9117tdUU


Greg


*From:* Rudolf Streif mailto:rudolf.str...@ibeeto.com>>
*Sent:* Wednesday, May 22, 2019 12:42:40 PM
*To:* Greg Wilson-Lindberg
*Cc:* Yocto list discussion
*Subject:* Re: [yocto] problem adding a user
Greg,
Can you share the logfile via Pastebin?
:rjs

On Tue, May 21, 2019 at 11:09 AM Greg Wilson-Lindberg
mailto:gwil...@sakuraus.com>> wrote:

Rudolf,

Something else is happening to me. I changed to this in the
image recipe:

SAKURA_USER = "sakura"

SAKURA_PASSWD = "Distracted"
SAKURA_PASS = "$1$QVO3K6Ii$fvkoDKnlzz3d5uVoL7KcM0"

EXTRA_USERS_PARAMS = "\
     usermod -p '${SAKURA_PASS}' ${SAKURA_USER}; \
     usermod -a -G sudo,dialout ${SAKURA_USER}; \
     "

deleting all of the commented out lines, and I get this in the
log file:


/scribe/1.0-r0/rootfs -p '' sakura]


nothing between the single quotes. It's acting like SAKURA_PASS
is not defined.

This is only happening when I'm trying the MD5 password.


Greg


*From:* Rudolf Streif mailto:rudolf.str...@ibeeto.com>>
*Sent:* Tuesday, May 21, 2019 5:37:23 AM
*To:* Greg Wilson-Lindberg
*Cc:* Yocto list discussion
*Subject:* Re: [yocto] problem adding a user
Greg,

usermod does not work for the MD5 algorithm with the explicit
password hash as it contains the $ field delimiters which are
interpreted by the shell executing the usermod command. Use
single quotes around the password hash:

usermod -p '${SAKURA_PASS}' ${SAKURA_USER};

:rjs

On Mon, May 20, 2019, 11:55 Greg Wilson-Lindberg
mailto:gwil...@sakuraus.com>> wrote:

Hi Rudolf,

I've had more time to work with this and I'm still having problems 
getting
everything to work properly. I've attached the image recipe recipe 
that I'm
using so I don't leave any thing out that may be relevant.

When I build with a password that is no more more than 8 characters 
long
and no non-alphabetic characters:

SAKURA_PASSWD = "Distract"
SAKURA_PASS = "WRsDFfg1BsrDM"

everything works correctly.

I first tried that using the `openssl ...` form, and then I tried 
the
-1, MD5 BSD form and had problems, so I changed to doing the openssl
on the command line and making sure that I don't have any characters
that display as '.' or '/'. Again, if I don't do more than 8 
characters
and no special characters everything works.

When I changed to using 'Ds$tr@ct' it stopped working. The build 
finishes
and the log file shows the usermod being exectued correctly:

NOTE: scribe: Performing usermod with [-R 

Re: [yocto] prelink-cross with -fno-plt

[Khem Raj]

On 5/23/19 8:05 AM, Shane Peelar wrote:

Hi Everyone @ the Yocto project,

I'm Shane Peelar, a PhD Candidate at the University of Windsor.
I'm writing to you about prelink-cross, as part of the Yocto project.
Specifically, I'm looking at using it with executables built using 
`-fno-plt` under GCC.
I wasn't quite sure where to send this email to, so I figured I'd try 
here.  If there's a better place to send this, please let me know.


Right now, prelink-cross seems to fail an assertion in arch-x86_64.c, 
line 421, when

using it with an executable built with `-fno-plt`:

...
assert (i < dso->ehdr.e_shnum)
...

This snippet seems to be looking for the ".plt" section and, since it 
can't find it, the assertion fires.  This makes sense because in 
`-fno-plt` executables, the `.plt` section is missing entirely.
I'm not an expert on ELF stuff, although I am learning quickly.  It 
looks like
this code wants to write into GOT[1] the address of ".plt" + 0x16 -- 
since ".plt" doesn't
exist, does it make sense to just change this assert to an if statement 
like so:


...
       if (i < dso->ehdr.e_shnum)
       { ... }
...

and skip over that part?  Or is this a real error condition for 
prelink-cross and it really should not continue?  The executable in 
question is also non-PIE, if that makes a difference.




what shared libs is this linking to ? are they also built with -fno-plt ?


Thanks for your time,
Shane


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

Re: [yocto] EXT SENDER - yocto Digest, Vol 104, Issue 95

[Khem Raj]

On 5/23/19 5:59 AM, Tg, Harish wrote:

Hi,
  I have a question. How to add commands like "ubiattach" to /usr/bin of 
rootfs image. I struggling with the recipes. I do not want to write my own recipe but I 
need to edit some recipe and add the command. Which is the place? I am using yocto for my 
project on TI platform and Linux.
Kindly help.



There is oe-pkgdata-util which can help to map files to recipes but we 
do not have a database for mapping. Maybe it is a good thing to have


for your problem ubiattach is provided by mtd-utils-ubifs which is built 
from mtd-utils recipe. I found it via above tool


% oe-pkgdata-util find-path /usr/sbin/ubiattach.mtd-utils
mtd-utils-ubifs: /usr/sbin/ubiattach.mtd-utils

% oe-pkgdata-util lookup-recipe mtd-utils-ubifs
mtd-utils

So you need to add

IMAGE_INSTALL_append = " mtd-utils-ubifs" in your image recipe or local.conf


Thanks,
Harish.

-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of yocto-requ...@yoctoproject.org
Sent: Wednesday, May 22, 2019 6:57 PM
To: yocto@yoctoproject.org
Subject: EXT SENDER - yocto Digest, Vol 104, Issue 95

Send yocto mailing list submissions to
yocto@yoctoproject.org

To subscribe or unsubscribe via the World Wide Web, visit

https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.yoctoproject.org_listinfo_yocto=DwICAg=QM_z7khAIdagwHt-12JlKA=4dfUpqj68eYAfVJs5uk2XkolcOQysOP5VncSFx6bkao=swLBJyRzgqx-Ix1dnv04ZhN6a_WVQSmQSW5YYLg3h40=a4sSVLnzzAP3ZRYs01WvSaiSc9QQmfaT7zdBRe0HcwM=
or, via email, send a message with subject or body 'help' to
yocto-requ...@yoctoproject.org

You can reach the person managing the list at
yocto-ow...@yoctoproject.org

When replying, please edit your Subject line so it is more specific than "Re: 
Contents of yocto digest..."


Today's Topics:

1. GPLv3 package present in rootfs (virendra kumar thakur)
2. Building single package as image, respecting dependencies
   (Norman Stetter)


--

Message: 1
Date: Wed, 22 May 2019 18:55:45 +0530
From: virendra kumar thakur 
To: yocto@yoctoproject.org
Subject: [yocto] GPLv3 package present in rootfs
Message-ID:

Content-Type: text/plain; charset="utf-8"

Hello team,

I want to remove some GPLv3 package from rootfs, but it is still present.

I am using INCOMPATIBLE_LICENSE = "GPL-3.0 LGPL-3.0 AGPL-3. 0"

still some package gnutls, libidn2, libassuan, are added into rootfs.
-- next part --
An HTML attachment was scrubbed...
URL: 


--

Message: 2
Date: Wed, 22 May 2019 12:36:18 +
From: Norman Stetter 
To: "yocto@yoctoproject.org" 
Subject: [yocto] Building single package as image, respecting
dependencies
Message-ID:

Content-Type: text/plain; charset="iso-8859-1"

Hi there,

I am currently working on a minimal CLI only system.
The image is based on 'core-image-base' using sysvinit and busybox.
To reduce image size and boot time, I removed as many packages as possible. For 
some application cases I will need python3 though.
My idea was to have python3 as some kind of add-on in a squashfs image, that 
can be mounted only when needed.

So I tried to build an image only containing the python3 package, but as little 
as possible otherwise, like this:

inherit image
IMAGE_FSTYPES = "squashfs-xz"
DEFAULT_TASK_PROVIDER = ""
DISTRO_EXTRA_RDEPENDS = ""
DISTRO_FEATURES = ""
POKY_DEFAULT_EXTRA_RDEPENDS = ""
IMAGE_FEATURES = ""
IMAGE_LINGUAS = ""
CORE_IMAGE_BASE_INSTALL = ""
RDEPENDS_${PN} = ""
PACKAGE_EXCLUDE = "busybox openssl run-postinsts update-rc.d"
VIRTUAL-RUNTIME_dev_manager = ""
VIRTUAL-RUNTIME_login_manager = ""
VIRTUAL-RUNTIME_init_manager = ""
VIRTUAL-RUNTIME_initscripts = ""
VIRTUAL-RUNTIME_keymaps = ""
VIRTUAL-RUNTIME_base-utils = ""
PREFERRED_PROVIDER_virtual/base-utils = ""

IMAGE_INSTALL = "python3"

But like this I can only manually exclude packages I already have in my main OS 
image. Some packages can't be excluded at all, as python3 depends on them and 
won't build if they are excluded.

Is there a way to have dependencies between images? So I could have the 
python-image build know which dependencies are already built into my OS image 
and therefore not include them itself?

Or would it be better to avoid building a second image and rather build 
'python3' with my OS-image, adding it to PACKAGE_EXCLUDE and from within this 
build process pack all python3 files into an image? If I were to pursue this 
method, any suggestions on how to separate the python3 files from the rest of 
my rootfs, including 

Re: [yocto] Building Out-of-Tree Modules on the BBB Target

[Khem Raj]

On 5/23/19 3:32 AM, Zoran Stojsavljevic wrote:

After some tests (and I had other problems to take care of, as well),
here is the following:


These have all been discussed off an on over the past 5 years.
I can't get at bugzilla right now, but all the details are logged in cases.
A survey of all the distros, their kernel package, etc, were all looked at.
We had to balance the traditional packaging with some new concepts
and landed with what we have now.


I tried several tests. This is my final conclusion (two cases):
https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/Issues/kernel-development.txt

The kernel issue is described here: there is need to have the YOCTO
minimum configuration with the kernel setup:
[1] The entire kernel source code in:
/usr/src/kernel/`uname-r`/
[2] The header files in: /usr/src/kernel/`uname-r`/

Point [1] is achieved with the following local.config file:
https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/Issues/local-devsrc.conf

Namely, with the following snippets in the local.conf:
TOOLCHAIN_TARGET_TASK_append = " packagegroup-core-tools-profile
packagegroup-core-buildessential kernel-devsrc"
KERNEL_DEV_TOOLS = "packagegroup-core-tools-profile
packagegroup-core-buildessential kernel-devsrc"
KERNEL_DEV_MODULE = "kernel-modules"
CORE_IMAGE_EXTRA_INSTALL += "${KERNEL_DEV_MODULE} \
${KERNEL_DEV_TOOLS} \
systemtap \
"

Problem with this approach is that such a kernel makes the rootfs too
big and impractical:
-rw-r--r--. 2 user vboxusers 101499952 May 17 14:32
core-image-minimal-beaglebone.rootfs.tar.xz

The main issue is point [2]: how to achieve it?
The suggestion is to introduce the new package in YOCTO kernel,
called: kernel-headers
The OBVIOUS benefit is that it will serve to the purpose of building
modules out of the tree on the target with
minimal mpact to rootfs!


I think this is a fair suggestion. Having prebuilt kernel available
that contains the configuration and header files used in the build is 
all that is required for external modules to build in addition to 
toolchain, so maybe its worth a try to create such a package and then 
have kernel-source separated out which can be installed on top if one

needs



Thank you,
Zoran Stojsavljevic
___

On Thu, May 16, 2019 at 12:04 AM Bruce Ashfield
 wrote:




On Wed, May 15, 2019 at 4:09 PM Zoran Stojsavljevic 
 wrote:



The core-image-kernel-dev image is how I do all my on target
testing when I introduce a new reference kernel for a release.


Maybe you are correct. Maybe I should use/add in my local.conf the following:

KERNEL_DEV_TOOLS ?= "packagegroup-core-tools-profile
packagegroup-core-buildessential kernel-devsrc"
KERNEL_DEV_MODULE ?= "kernel-modules"
CORE_IMAGE_EXTRA_INSTALL += "${KERNEL_DEV_MODULE} \
  ${KERNEL_DEV_TOOLS} \
  systemtap \
 "
I need to try these... Maybe this addendum will solve the $1 mio USD problem?!


And IIRC the autobuilders are using a sato based image (Richard
could confirm more easily that I could what image type the
autobuilders are using for hello-world on target module tests).


I am just advertising something more simple. To have mandatory
/lib/modules/`uname -r` directory. And introduce few more packages, as
Fedora distro, for example, has: kernel-headers (assuming YOCTO
rootfs, the following will be installed: /usr/src/kernel/`uname
-r`/. This also makes addition of
/lib/modules/`uname -r`/build file (which is soft link to
usr/src/kernel/`uname -r`).



These have all been discussed off an on over the past 5 years. I can't get at 
bugzilla right now, but all the details are logged in cases. A survey of all 
the distros, their kernel package, etc, were all looked at. We had to balance 
the traditional packaging with some new concepts and landed with what we have 
now.




Or kernel-devel package. Then, the whole current kernel source code
will be introduced, and also support for it.



There's a case for this one as well, I'll probably have it done for the fall 
release. But our devsrc used to pretty much be the full source it has now been 
pruned down to something more manageable.  There are definitely some cases for 
having the full source on the target again, and it will be a separate package, 
just not the minimal one to build out of tree modules, etc.






SDK building with such a support is good/cool. But sometimes, before
introducing SDK, some tests should be done on target. NO need to
optionally include built-in layer hello-world driver example. Since I
(or you name the person) have own test drivers, which will be imported
out of tree, externally, to the target test bed!



I never use the SDK myself, so you are not alone in not going to it first. 
Hopefully I'll get some new patches out in the coming month before summer 
holidays really kick in.

Bruce




Just thinking loud...

Zoran
___

On Wed, May 15, 2019 at 4:25 PM Bruce Ashfield  wrote:




On Wed, May 

Re: [yocto] [Yocto] RPI WiFi not loading module

[Khem Raj]

On 5/23/19 2:14 AM, Jonas Andersson wrote:

Hi

I have problem to get my WiFi working on boot on Raspberry Pi 3.

The problem is that wlan0 interface not showing up, if I manually 
run modprobe brcmfmac it works.


To try to "force" the load of brcmfmac i added it to 
KERNEL_MODULE_AUTOLOAD and that generated an file 
in /etc/modules-load.d/ -> brcmfmac.conf but it is still not loaded.


I use systemd an to my understanding systemd-modules-load.service is 
handling module auto load, but that file is missing and I cant see how 
to include it in my build.


Building thud version and I have added the following to my image recipe:

DISTRO_FEATURES_append = " wifi"

IMAGE_INSTALL_append = " iw wpa-supplicant packagegroup-base 
module-init-tools"


IMAGE_INSTALL_append = "\
     linux-firmware-rpidistro-bcm43430 \
     linux-firmware-rpidistro-bcm43455 \
     bluez-firmware-rpidistro-bcm43430a1-hcd \
     bluez-firmware-rpidistro-bcm4345c0-hcd \
  "
Then i have symlinked wpa-supplicant service to load wpa-supplicant.conf 
file and that work when I manually loads the module.




I wonder if something like this will help you
https://github.com/YoeDistro/meta-yoe/tree/master/recipes-core/systemd


Best regards
Jonas


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

Re: [yocto] Fwd: /usr/share/common-license package/recipeinfo contains GPLv3 info

[Khem Raj]

On 5/23/19 2:42 AM, virendra kumar thakur wrote:



Hello team,

I am trying to build yocto image without GPLv3 package, I have added 
below things in local.conf and enable meta-gplv2 layer.


INCOMPATIBLE_LICENSE = "GPL-3.0 LGPL-3.0 AGPL-3. 0" in local.conf.


Can you try adding GPLv3+ to INCOMPATIBLE_LICENSE and see if that helps ?



After verifying from package.manifest and license.manifest file in 
build/tmp/deploy/license/ directory I observe that no GPLv3 package is 
present in rootfs.


But I can see in 
rootfs/usr/share/common-license/package/libgcrypt-lic/recipeinfo


LICENSE: GPLV2+ + +
PR: r0
PV : 1.8.4

Is present..

My doubt is why any GPLv3 is present in common-license directory?

From: "Burton, Ross" mailto:ross.bur...@intel.com>>
To: virendra kumar thakur >
Cc: Yocto-mailing-list >

Subject: Re: [yocto] GPLv3 package present in rootfs

On Wed, 22 May 2019 at 06:26, virendra kumar thakur
mailto:coolvee...@gmail.com>> wrote:

still some package gnutls, libidn2, libassuan, are added into rootfs.


Randomly picking libassuan:

LICENSE_${PN} = "LGPLv2.1+"

The library itself is LGPL-2.  Have you verified the *package*
licenses for what is actually going into the image?

Ross





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

Re: [yocto] PN is uppercase

[Khem Raj]

On 5/21/19 12:50 AM, Ralf Spiwoks wrote:

Hi Ross,

Thanks for your email. I am realising that I have not replied to your
email earlier. Sorry. I guess it was partly because your answer put
me slightly off. On the one hand, I thought that as a general approach,
Linux was case sensitive, unlike its big rival Windows, and I was not
aware  of package managers which would explicitly forbid uppercase
package names. I find the approach of allowing only lowercase package
names quite limiting, and frankly a drawback for using Yocto

On the other hand I have a few tens of packages to maintain, which
have uppercase letters in the package names and which did work with
Yocto in previous versions. So, because of a new convention we would
have to rework some of the packages or ignore the warning messages.
And until we find the effort for reworking those package recipes we
will stay with the latter option.


The package name rules are not new, they have been with OE/YP forever
so it should have failed always. Similar to debian see

https://www.debian.org/doc/debian-policy/ch-controlfields.html#list-of-fields



Thanks for your patience and your explanations. Cheers,

Ralf.

On 4/2/19 1:54 PM, Burton, Ross wrote:

On Tue, 2 Apr 2019 at 12:36, Ralf Spiwoks  wrote:

TWO questions:

1) Are those two issues related?


Probably not, unless you're trying to use a mixed-case override.

2) What is the logic behind allowing only lower case package names? 
This is to me

 a serious restriction on the use of Yocto.


Two reasons: some package managers forbid packages with uppercase
names; and for performance reasons overrides are lowercase and as
package names are often embedded in overrides this implies that
package names need to be lowercase.

What's the problem with using lowercase names?

Ross


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

Re: [yocto] Rocko broke down

[Khem Raj]

On 5/18/19 12:56 AM, Ari-Pekka Sihvonen wrote:
I am developing system using raspberry and made a pull on every yocto 
metas. Chen I baked the Image there was a major problem. My system did 
not read config.txt and cmdline.txt anymore. So the resulting Image was 
totally unusable. Lucily I had a copy of yocto tree so I could go on 
building images. Has something changed on rocko branch.




you have to be more specific here, maybe provide more step by step
what you did and what does not work


Regads
AP Sihvonen

Sent from my Huawei phone


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

Re: [yocto] distrodata documentation in 2.7 Mega Manual

[Khem Raj]

On Tue, May 21, 2019 at 12:31 PM Paul Barker  wrote:
>
> Just reading the 2.7 Mega Manual at 
> https://www.yoctoproject.org/docs/2.7/mega-manual/mega-manual.html and 
> noticed a possible bug.
>
> "24.15.9. Removed Classes" indicates that the `distrodata` class is now gone. 
> However it's still referred to in several other places in the documentation. 
> May need a bit of garbage collection.
>

same is needed for bugzilla.bbclass as well as distutils-tools

> Thanks,
>
> --
> Paul Barker
> Managing Director & Principal Engineer
> Beta Five Ltd
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Using a native tool from another recipe

[Khem Raj]

On Mon, May 13, 2019 at 11:17 PM Gabriele Zampieri
 wrote:
>
> Hi Khem,
>
> what do you mean with "build bpkg as a native recipe"? I though that the 
> DEPENDS = "build2-native" will achieve this task. Thanks to pointing out the 
> hosttool option.

yes DEPENDS = "build2-native" should have added the needed tool to build.

>
> Best regards,
> Gabriele
>
> Il giorno lun 13 mag 2019 alle ore 17:59 Khem Raj  ha 
> scritto:
>>
>> You need to either build bpkg as a native recipe or install and make it 
>> available as a hosttool from build machine distribution itself
>>
>> On Mon, May 13, 2019 at 6:07 AM Gabriele Zampieri  
>> wrote:
>>>
>>> Hi all,
>>>
>>> I need to add a couple of tools to my build system (build2 and odb). The 
>>> second one depends on the first. Following a snippet of the build2 recipe:
>>> 
>>> DEPENDS = "openssl-native"
>>> SRC_URI = "https://download.build2.org/${PV}/build2-toolchain-${PV}.tar.gz;
>>> SRC_URI[sha256sum] = 
>>> "42a254c46b59109b764afade0d50819b3d793a9167f46759fc6aa9d6d8a6ff37"
>>>
>>> S = "${WORKDIR}/build2-toolchain-${PV}"
>>>
>>> # build.sh located inside the tarball cannot be used to configure, compile 
>>> and
>>> # install in different steps. This task is misleading, but I didn't find any
>>> # other way to make it works
>>> do_compile_prepend() {
>>> ./build.sh --timeout 600 --sudo false \
>>> --make ${MAKE} ${PARALLEL_MAKE} \
>>> --trust yes \
>>> --install-dir ${prefix} g++
>>> }
>>>
>>> FILES_${PN}_append_class-nativesdk = " ${SDKPATHNATIVE}"
>>> FILES_${PN} = "${D}${prefix}/*"
>>>
>>> BBCLASSEXTEND = "native nativesdk"
>>> 
>>>
>>> Then the odb-compiler recipe
>>>
>>> 
>>> SECTION = "devtools"
>>> DEPENDS = "build2-native"
>>> CONFIG_NAME = "odb-gcc-X"
>>> do_configure() {
>>> cd ${B}
>>> bpkg create -d ${CONFIG_NAME} cc\
>>> config.cxx=g++  \
>>> config.cc.coptions=-O3  \
>>> config.bin.rpath=/usr/lib   \
>>> config.install.root=/usr\
>>> config.install.sudo=false
>>>
>>> }
>>> BBCLASSEXTEND = "native nativesdk"
>>> 
>>>
>>> When I try to build odb-compiler, bitbake complete the build2-native 
>>> recipe, but fails on do_configure due to 'bpkg command not found'.
>>>
>>> Are my recipes correct?
>>>
>>> Thanks,
>>> Gabriele
>>>
>>> --
>>> ___
>>> yocto mailing list
>>> yocto@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] /etc/limits with openssh

[Khem Raj]

On 5/14/19 7:47 AM, Daniel Ammann wrote:

Hi

I am trying to restrict non-privileged users from using up too many resources.
I added "* U100" to /etc/limits. If the user logs in using the serial console,
it works. If the user logs in using openssh, the limits are not applied. How do
I make this work for ssh login?

I am using beaglebone-yocto with core-image-base with added sshd. This is yocto
2.6.



if you have pam installed then you might want to experiment with 
settings in /etc/security/limits.conf



Thanks

Daniel


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

Re: [yocto] ntp recipe not able to install few packages in the rootfs

[Khem Raj]

On 5/14/19 2:42 AM, Pandey, Kamal wrote:

Hi
I was trying to add ntp package to my image, I used the meta-networking layer 
for the recipe and added the ntp package to my custom image.bb recipe.
After compiling I can see multiple packages in package-split directory of the 
working directory of ntp package, but these binaries are missing in the ROOTFS 
directory.


You can see below that ntpq is packaged into package of its own. So you 
need to add that to your IMAGE_INSTALL


something like

IMAGE_INSTALL_append = " ntpq"

in your image recipe might help


Below is my ntp recipe:


SUMMARY = "Network Time Protocol daemon and utilities"
DESCRIPTION = "The Network Time Protocol (NTP) is used to \
synchronize the time of a computer client or server to \
another server or reference time source, such as a radio \
or satellite receiver or modem."
HOMEPAGE = "http://support.ntp.org;
SECTION = "net"
LICENSE = "NTP"
LIC_FILES_CHKSUM = "file://COPYRIGHT;md5=e877a1d567a6a58996d2b66e3e387003"

DEPENDS = "libevent"

SRC_URI = 
"http://www.eecis.udel.edu/~ntp/ntp_spool/ntp4/ntp-4.2/ntp-${PV}.tar.gz \
file://ntp-4.2.4_p6-nano.patch \
file://reproducibility-fixed-path-to-posix-shell.patch \
file://reproducibility-respect-source-date-epoch.patch \
file://ntpd \
file://ntp.conf \
file://ntpdate \
file://ntpdate.default \
file://ntpdate.service \
file://ntpd.service \
file://sntp.service \
file://sntp \
file://ntpd.list \
"

SRC_URI[md5sum] = "1522d66574bae14abb2622746dad2bdc"
SRC_URI[sha256sum] = 
"709b222b5013d77d26bfff532b5ea470a8039497ef29d09363931c036cb30454"

inherit autotools update-rc.d useradd systemd pkgconfig

# The ac_cv_header_readline_history is to stop ntpdc depending on either
# readline or curses
EXTRA_OECONF += "--with-net-snmp-config=no \
  --without-ntpsnmpd \
  ac_cv_header_readline_history_h=no \
  --with-yielding_select=yes \
  --with-locfile=redhat \
  --without-rpath \
  "
CFLAGS_append = " -DPTYS_ARE_GETPT -DPTYS_ARE_SEARCHED"

USERADD_PACKAGES = "${PN}"
NTP_USER_HOME ?= "/var/lib/ntp"
USERADD_PARAM_${PN} = "--system --home-dir ${NTP_USER_HOME} \
--no-create-home \
--shell /bin/false --user-group ntp"

# NB: debug is default-enabled by NTP; keep it default-enabled here.
PACKAGECONFIG ??= "cap debug refclocks openssl \
 ${@bb.utils.filter('DISTRO_FEATURES', 'ipv6', d)} \
"
PACKAGECONFIG[openssl] = "--with-openssl-libdir=${STAGING_LIBDIR} \
   --with-openssl-incdir=${STAGING_INCDIR} \
   --with-crypto, \
   --without-openssl --without-crypto, \
   openssl"
PACKAGECONFIG[cap] = "--enable-linuxcaps,--disable-linuxcaps,libcap"
PACKAGECONFIG[readline] = "--with-lineeditlibs,--without-lineeditlibs,readline"
PACKAGECONFIG[refclocks] = "--enable-all-clocks,--disable-all-clocks,pps-tools"
PACKAGECONFIG[debug] = "--enable-debugging,--disable-debugging"
PACKAGECONFIG[mdns] = "ac_cv_header_dns_sd_h=yes,ac_cv_header_dns_sd_h=no,mdns"
PACKAGECONFIG[ipv6] = "--enable-ipv6,--disable-ipv6,"

do_install_append() {
 install -d ${D}${sysconfdir}/init.d
 install -m 644 ${WORKDIR}/ntp.conf ${D}${sysconfdir}
 install -m 755 ${WORKDIR}/ntpd ${D}${sysconfdir}/init.d
 install -d ${D}${bindir}
 install -m 755 ${WORKDIR}/ntpdate ${D}${bindir}/ntpdate-sync

 install -m 755 -d ${D}${NTP_USER_HOME}
 chown ntp:ntp ${D}${NTP_USER_HOME}

 # Fix hardcoded paths in scripts
 sed -i 's!/usr/sbin/!${sbindir}/!g' ${D}${sysconfdir}/init.d/ntpd 
${D}${bindir}/ntpdate-sync
 sed -i 's!/usr/bin/!${bindir}/!g' ${D}${sysconfdir}/init.d/ntpd 
${D}${bindir}/ntpdate-sync
 sed -i 's!/etc/!${sysconfdir}/!g' ${D}${sysconfdir}/init.d/ntpd 
${D}${bindir}/ntpdate-sync
 sed -i 's!/var/!${localstatedir}/!g' ${D}${sysconfdir}/init.d/ntpd 
${D}${bindir}/ntpdate-sync
 sed -i 
's!^PATH=.*!PATH=${base_sbindir}:${base_bindir}:${sbindir}:${bindir}!' 
${D}${bindir}/ntpdate-sync
 sed -i '1s,#!.*perl -w,#! ${bindir}/env perl,' ${D}${sbindir}/ntptrace
 sed -i '/use/i use warnings;' ${D}${sbindir}/ntptrace
 sed -i '1s,#!.*perl,#! ${bindir}/env perl,' ${D}${sbindir}/ntp-wait
 sed -i '/use/i use warnings;' ${D}${sbindir}/ntp-wait
 sed -i '1s,#!.*perl -w,#! ${bindir}/env perl,' ${D}${sbindir}/calc_tickadj
 sed -i '/use/i use warnings;' ${D}${sbindir}/calc_tickadj

 install -d ${D}/${sysconfdir}/default
 install -m 644 ${WORKDIR}/ntpdate.default ${D}${sysconfdir}/default/ntpdate
 install -m 0644 ${WORKDIR}/sntp ${D}${sysconfdir}/default/

 install -d ${D}/${sysconfdir}/network/if-up.d
 ln -s ${bindir}/ntpdate-sync ${D}/${sysconfdir}/network/if-up.d

 install -d 

Re: [yocto] Upgrading to Sumo triggered issue with python3 autopackaging - "ERROR: Nothing RPROVIDES 'python3-signal'"

[Khem Raj]

On 5/15/19 8:28 PM, Davis Roman wrote:

Hello,

I upgraded to Sumo(2.5) and now bitbake is complaining that nothing
rprovides python3-signal.

ERROR: Nothing RPROVIDES 'python3-signal' (but
/home/worker/building/sources/meta-bluetooth/recipes-bluetooth/bluetooth-app/bluetooth-app.bb
RDEPENDS on or otherwise requires it)



this is not provided by python3-core at runtime so your RDEPENDS should 
change from python3-signal to python3-core




After some searching I found that this is related to the restructuring
of python3 packaging in Sumo
(http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=b6777878ff03c3e956386020a19d11c875c835ae)

So according to the instructions in the above commit, I'm supposed to
first create a manifest file using:

$ bitbake python -c create_manifest

and then the json file appears to get created:

build/tmp/work/armv7ahf-neon-poky-linux-gnueabi/python3/3.5.5-r1.0/python3-manifest.json

After a quick inspection of the created python3-manifest.json, I see
that signal.py already appears on the list.

 "core": {
 "cached": [
 ...
 "${libdir}/python3.5/__pycache__/signal.*.pyc",
 ...
 ],
 "files": [
  ...
 "${libdir}/python3.5/signal.py",
  ...
 ],
 "rdepends": [],
 "summary": "Python interpreter and core modules"
 },

Assuming that nothing else needs to be done, I then proceed to again
bitbake my application but unfortunately the original error persists.

What am I missing?

Thank you,

Davis Roman


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

Re: [yocto] linux-raspberrypi_4.19.bb unknown commit

[Khem Raj]

On 5/16/19 8:53 AM, Andrei Gherzan wrote:


On 12/05/2019 16.04, Jean-Christian de Rivaz wrote:

Le 11.05.19 à 21:46, Paul Barker a écrit :

On Sat, 11 May 2019, at 20:44, Jean-Christian de Rivaz wrote:

Hi,

I try to use the Linux 4.19 for the RaspberryPi from the
meta-raspberrypi recipe linux-raspberrypi_4.19.bb but the commit
ab8652c03fa081b27de7e28a74c2536cb2aa3e5b from his SRCREV don't exists
into the repository github.com/raspberrypi/linux branch rpi-4.19.y . I
searched that commit on a few others branches but failed to find it.
Have anyone tested that recipe ?

The upstream rpi-4.19.y branch is still unstable and they enjoy rebasing 
commits. The breaks the commit references used in our recipes.

For now I recommend sticking to the 4.14.y kernels for Raspberry Pi.


Too bad, I need Linux >= 4.19 to enable cgroup2 memory.oom_group to
properly kill and restart xserver-nodm with chromium in kiosk mode
displaying videos all the days long. There a bug somewhere in
chromium/ffmpeg/gpu that eat all the available memory, and I don't have
time and money  to dig in that complexity and patch acceptance marathon.

Feel free to complain upstream:
https://github.com/raspberrypi/linux/issues/2931



this has been fixed upstream. So I think time to bump the SRCREV and 
change default kernel back to 4.19 again.

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

Re: [yocto] [meta-raspberrypi] RPi 7" Touch Display

[Khem Raj]

On Sat, May 18, 2019 at 11:02 PM Rudolf Streif 
wrote:

> Thanks, Khem. 64 bit, raspberrypi3-64 machine with vc4graphics.
>

Please try 32bit we only have hdmi tested in 64bit this far


>
> On Sat, May 18, 2019, 22:13 Khem Raj  wrote:
>
>>
>>
>> On 5/16/19 9:01 AM, Andrei Gherzan wrote:
>> > HI,
>> >
>> > On 16/05/2019 16.31, Rudolf J Streif wrote:
>> >> I am trying to use the "official" RPi 7" touch display
>> >> (https://www.raspberrypi.org/products/raspberry-pi-touch-display/)
>> >> with meta-raspberrypi (most recent from master). However, I cannot get
>> >> it to work. As a matter of fact the display does not even show the GPU
>> >> rainbow screen making me think that the GPU firmware packaged with
>> >> meta-raspberrypi does not support the DSI display. It works just fine
>> >> with the latest Raspbian release (screen and touch).
>> >>
>> >> I searched the web up and down but could not find anything. Maybe
>> >> somebody has an idea? Wrong firmware (maybe cannot be distributed
>> >> because of licensing...)?
>> > Sadly we don't actively test display and other related toys so they
>> > might be broken. Even so, I would be surprised if the DSI port doesn't
>> > work. What is you final config.txt (pastebin it please)?
>> >
>>
>> are you building 64bit or 32bit images ?
>> are you using vc4grpahics or userland graphics ?
>>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi] RPi 7" Touch Display

[Khem Raj]

On 5/16/19 9:01 AM, Andrei Gherzan wrote:

HI,

On 16/05/2019 16.31, Rudolf J Streif wrote:

I am trying to use the "official" RPi 7" touch display
(https://www.raspberrypi.org/products/raspberry-pi-touch-display/)
with meta-raspberrypi (most recent from master). However, I cannot get
it to work. As a matter of fact the display does not even show the GPU
rainbow screen making me think that the GPU firmware packaged with
meta-raspberrypi does not support the DSI display. It works just fine
with the latest Raspbian release (screen and touch).

I searched the web up and down but could not find anything. Maybe
somebody has an idea? Wrong firmware (maybe cannot be distributed
because of licensing...)?

Sadly we don't actively test display and other related toys so they
might be broken. Even so, I would be surprised if the DSI port doesn't
work. What is you final config.txt (pastebin it please)?



are you building 64bit or 32bit images ?
are you using vc4grpahics or userland graphics ?
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Debugging dev-deps

[Khem Raj]

also read through
https://wiki.yoctoproject.org/wiki/TipsAndTricks/Packaging_Prebuilt_Libraries

This might be helpful especially  section under Non-versioned Libraries

On Mon, May 13, 2019 at 10:56 AM Burton, Ross  wrote:
>
> On Mon, 13 May 2019 at 09:54, Matthias Schoepfer
>  wrote:
> > I am trying to write a recipe for a rather tricky component (that has
> > plugins and stuff). Anyhow, I cannot get bitbake not to complain that
> >  rdepends on -dev. And if I INSANE_SKIP it,
> > the -dev package will get installed. But I cannot figure out which file
> > is responsible. I tried to ldd all installed files in , but
> > could not get any results. Any hints on how to debug this further?!
>
> The problem is probably that the plugins are being shipped as
> /usr/lib/libpluginfoo.so, and so have the same names as development
> library symlinks which get packaged into PN-dev automatically.
> Alternatively unversioned libraries will also have the same issue.
>
> Look at what files go into what package (using oe-pkgdata-util), and
> ensure that PN-dev only contains headers and the link-time symlinks.
> For example libfoo.so -> libfoo.so.1, libfoo.so should be in PN-dev
> and libfoo.so.1 should be in PN.
>
> Ross
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Using a native tool from another recipe

[Khem Raj]

You need to either build bpkg as a native recipe or install and make it
available as a hosttool from build machine distribution itself

On Mon, May 13, 2019 at 6:07 AM Gabriele Zampieri 
wrote:

> Hi all,
>
> I need to add a couple of tools to my build system (build2 and odb). The
> second one depends on the first. Following a snippet of the build2 recipe:
>
> 
> DEPENDS = "openssl-native"
> SRC_URI = "https://download.build2.org/${PV}/build2-toolchain-${PV}.tar.gz
> "
> SRC_URI[sha256sum] =
> "42a254c46b59109b764afade0d50819b3d793a9167f46759fc6aa9d6d8a6ff37"
>
> S = "${WORKDIR}/build2-toolchain-${PV}"
>
> # build.sh located inside the tarball cannot be used to configure, compile
> and
> # install in different steps. This task is misleading, but I didn't find
> any
> # other way to make it works
> do_compile_prepend() {
> ./build.sh --timeout 600 --sudo false \
> --make ${MAKE} ${PARALLEL_MAKE} \
> --trust yes \
> --install-dir ${prefix} g++
> }
>
> FILES_${PN}_append_class-nativesdk = " ${SDKPATHNATIVE}"
> FILES_${PN} = "${D}${prefix}/*"
>
> BBCLASSEXTEND = "native nativesdk"
>
> 
>
> Then the odb-compiler recipe
>
>
> 
> SECTION = "devtools"
> DEPENDS = "build2-native"
> CONFIG_NAME = "odb-gcc-X"
> do_configure() {
> cd ${B}
> bpkg create -d ${CONFIG_NAME} cc\
> config.cxx=g++  \
> config.cc.coptions=-O3  \
> config.bin.rpath=/usr/lib   \
> config.install.root=/usr\
> config.install.sudo=false
>
> }
> BBCLASSEXTEND = "native nativesdk"
>
> 
>
> When I try to build odb-compiler, bitbake complete the build2-native
> recipe, but fails on do_configure due to 'bpkg command not found'.
>
> Are my recipes correct?
>
> Thanks,
> Gabriele
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Build error on dockerode using YP-Core warrior 2.7

[Khem Raj]

On Mon, May 13, 2019 at 7:19 AM Edson Seabra 
wrote:

> Hi,
>
>
> Thanks Khem Raj.
>
>
> As this package name is generate internally by poky/yocto I did this patch
> to make it build:
>
>
> *edson@ubuntu-16*:*oe*$ git diff package.py
>
> *diff --git a/meta/lib/oe/package.py b/meta/lib/oe/package.py*
>
> *index 6e83f01f14..3503313621 100644*
>
> *--- a/meta/lib/oe/package.py*
>
> *+++ b/meta/lib/oe/package.py*
>
> @@ -298,7 +298,7 @@ def npm_split_package_dirs(pkgdir):
>
>  for pathitem in relpth.split('/'):
>
>  if pathitem == 'node_modules':
>
>  continue
>
> -pkgitems.append(pathitem)
>
> +pkgitems.append(pathitem.lower())
>
>  pkgname = '-'.join(pkgitems).replace('_', '-')
>
>  pkgname = pkgname.replace('@', '')
>
>  pkgfile = os.path.join(root, dn, 'package.json')
>
>
> I do not feel confident to submit it. I would suggest a poky/yocto
> maintainer to step in.
>

Just change the concerned recipe name this patch is a bit too much

>
> Regards,
> Edson.
>
> --
> *From:* Khem Raj 
> *Sent:* Sunday, May 12, 2019 4:50 AM
> *To:* Edson Seabra
> *Cc:* yocto@yoctoproject.org
> *Subject:* Re: [yocto] Build error on dockerode using YP-Core warrior 2.7
>
> Use all lowercase in recipe name you seem to have mixed it with uppercase
>
> On Sat, May 11, 2019 at 5:58 PM Edson Seabra 
> wrote:
>
> Hi,
>
>
> I created the recipe for dockerode 2.5.8 using the command recipetool:
>
>
> recipetool create "npm://registry.npmjs.org;name=dockerode;version=2.5.8"
>
>
> The recipe creates a lot of ipk's package and fails on dockerode-JSONStream
> ipk.
>
>
> I can build dokerode with YP-Coce morty, almost sure I did with YP-Core
> thud.
>
>
> Any hint about how to find what  is this issue will be appreciated.
>
>
> NOTE. Other recipes, using npm.bbclass, build normally.
>
>
> If any additional information is needed just let me know...
>
>
>  here is the output of bitbake dockerode ==
>
> Build Configuration:
>
> BB_VERSION   = "1.42.0"
>
> BUILD_SYS= "x86_64-linux"
>
> NATIVELSBSTRING  = "universal"
>
> TARGET_SYS   = "x86_64-poky-linux"
>
> MACHINE  = "genericx86-64"
>
> DISTRO   = "node-poky"
>
> DISTRO_VERSION   = "2.7"
>
> TUNE_FEATURES= "m64 core2"
>
> TARGET_FPU   = ""
>
> IMAGE_LINGUAS= "en-us en-gb"
>
> MACHINE_FEATURES = "screen keyboard pci usbhost ext4 x86 acpi pcbios
> rtc"
>
> IMAGE_FSTYPES= "hddimg"
>
> DISTRO_FEATURES  = "argp pam largefile xattr nfs pci x11 ipv4 ipv6
> libc-backtrace libc-big-macros libc-bsd libc-cxx-tests libc-catgets
> libc-charsets libc-crypt libc-crypt-ufc libc-db-aliases libc-envz libc-fcvt
> libc-fmtmsg libc-fstab libc-ftraverse libc-getlogin libc-idn libc-inet-anl
> libc-libm libc-locales libc-locale-code libc-memusage libc-nis
> libc-nsswitch libc-rcmd libc-rtld-debug libc-spawn libc-streams libc-sunrpc
> libc-utmp libc-utmpx libc-wordexp libc-posix-clang-wchar libc-posix-regexp
> libc-posix-regexp-glibc libc-posix-wchar-io multiarch sysvinit opengl
> pulseaudio wifi virtualization"
>
> IMAGE_FEATURES   = "package-management read-only-rootfs tools-debug"
>
> meta-nodegrid
>
> meta-kernel  = "trunk:11630-11620"
>
> meta-zpe = "trunk:11630-11629"
>
> meta-oe  = "trunk:11630-11620"
>
> meta-graphics= "trunk:11630-11172"
>
> meta-networking  = "trunk:11630-11560"
>
> meta-python  = "trunk:11630-11620"
>
> meta-selinux = "master:b1dac7e2b26f869c991c6492aa7fa18eaa4b47f6"
>
> meta-virtualization  = "trunk:11630-11620"
>
> meta-tpm2= "trunk:11630-11090"
>
> meta-java= "master:2fc78571483465ca2fc69d6bd77632acd35e0770"
>
> meta
>
> meta-poky
>
> meta-yocto-bsp   = "warrior:1b425a8450872f915c30bd0a35b0b0df92172b70"
>
>
> Initialising tasks: 100%
> || Time: 0:00:02
>
> Sstate summary: Wanted 33 Found 27 Missed 6 Current 365 (81% match, 98%
> complete)
>
> *NOTE*: Executing SetScene Tasks
>
> *NOTE*: Executing RunQueue Tasks
>
&

Re: [yocto] Build error on dockerode using YP-Core warrior 2.7

[Khem Raj]

Use all lowercase in recipe name you seem to have mixed it with uppercase

On Sat, May 11, 2019 at 5:58 PM Edson Seabra 
wrote:

> Hi,
>
>
> I created the recipe for dockerode 2.5.8 using the command recipetool:
>
>
> recipetool create "npm://registry.npmjs.org;name=dockerode;version=2.5.8"
>
>
> The recipe creates a lot of ipk's package and fails on dockerode-JSONStream
> ipk.
>
>
> I can build dokerode with YP-Coce morty, almost sure I did with YP-Core
> thud.
>
>
> Any hint about how to find what  is this issue will be appreciated.
>
>
> NOTE. Other recipes, using npm.bbclass, build normally.
>
>
> If any additional information is needed just let me know...
>
>
>  here is the output of bitbake dockerode ==
>
> Build Configuration:
>
> BB_VERSION   = "1.42.0"
>
> BUILD_SYS= "x86_64-linux"
>
> NATIVELSBSTRING  = "universal"
>
> TARGET_SYS   = "x86_64-poky-linux"
>
> MACHINE  = "genericx86-64"
>
> DISTRO   = "node-poky"
>
> DISTRO_VERSION   = "2.7"
>
> TUNE_FEATURES= "m64 core2"
>
> TARGET_FPU   = ""
>
> IMAGE_LINGUAS= "en-us en-gb"
>
> MACHINE_FEATURES = "screen keyboard pci usbhost ext4 x86 acpi pcbios
> rtc"
>
> IMAGE_FSTYPES= "hddimg"
>
> DISTRO_FEATURES  = "argp pam largefile xattr nfs pci x11 ipv4 ipv6
> libc-backtrace libc-big-macros libc-bsd libc-cxx-tests libc-catgets
> libc-charsets libc-crypt libc-crypt-ufc libc-db-aliases libc-envz libc-fcvt
> libc-fmtmsg libc-fstab libc-ftraverse libc-getlogin libc-idn libc-inet-anl
> libc-libm libc-locales libc-locale-code libc-memusage libc-nis
> libc-nsswitch libc-rcmd libc-rtld-debug libc-spawn libc-streams libc-sunrpc
> libc-utmp libc-utmpx libc-wordexp libc-posix-clang-wchar libc-posix-regexp
> libc-posix-regexp-glibc libc-posix-wchar-io multiarch sysvinit opengl
> pulseaudio wifi virtualization"
>
> IMAGE_FEATURES   = "package-management read-only-rootfs tools-debug"
>
> meta-nodegrid
>
> meta-kernel  = "trunk:11630-11620"
>
> meta-zpe = "trunk:11630-11629"
>
> meta-oe  = "trunk:11630-11620"
>
> meta-graphics= "trunk:11630-11172"
>
> meta-networking  = "trunk:11630-11560"
>
> meta-python  = "trunk:11630-11620"
>
> meta-selinux = "master:b1dac7e2b26f869c991c6492aa7fa18eaa4b47f6"
>
> meta-virtualization  = "trunk:11630-11620"
>
> meta-tpm2= "trunk:11630-11090"
>
> meta-java= "master:2fc78571483465ca2fc69d6bd77632acd35e0770"
>
> meta
>
> meta-poky
>
> meta-yocto-bsp   = "warrior:1b425a8450872f915c30bd0a35b0b0df92172b70"
>
>
> Initialising tasks: 100%
> || Time: 0:00:02
>
> Sstate summary: Wanted 33 Found 27 Missed 6 Current 365 (81% match, 98%
> complete)
>
> *NOTE*: Executing SetScene Tasks
>
> *NOTE*: Executing RunQueue Tasks
>
> *WARNING*: dockerode-2.5.8-r0 do_populate_lic: dockerode: No generic
> license file exists for: Unknown in any provider
>
> *ERROR*: dockerode-2.5.8-r0 do_package_write_ipk: Fatal errors occurred
> in subprocesses:
>
> Command
> 'PATH="/home/edson/ng-trunk/nodegrid/tmp/sysroots-uninative/x86_64-linux/usr/bin:/home/edson/ng-trunk/poky/scripts:/home/edson/ng-trunk/nodegrid/tmp/work/core2-64-poky-linux/dockerode/2.5.8-r0/recipe-sysroot-native/usr/bin/x86_64-poky-linux:/home/edson/ng-trunk/nodegrid/tmp/work/core2-64-poky-linux/dockerode/2.5.8-r0/recipe-sysroot/usr/bin/crossscripts:/home/edson/ng-trunk/nodegrid/tmp/work/core2-64-poky-linux/dockerode/2.5.8-r0/recipe-sysroot-native/usr/sbin:/home/edson/ng-trunk/nodegrid/tmp/work/core2-64-poky-linux/dockerode/2.5.8-r0/recipe-sysroot-native/usr/bin:/home/edson/ng-trunk/nodegrid/tmp/work/core2-64-poky-linux/dockerode/2.5.8-r0/recipe-sysroot-native/sbin:/home/edson/ng-trunk/nodegrid/tmp/work/core2-64-poky-linux/dockerode/2.5.8-r0/recipe-sysroot-native/bin:/home/edson/ng-trunk/poky/bitbake/bin:/home/edson/ng-trunk/nodegrid/tmp/hosttools"
> opkg-build -Z xz -a "--memlimit=50% --threads=4" dockerode-JSONStream
> /home/edson/ng-trunk/nodegrid/tmp/work/core2-64-poky-linux/dockerode/2.5.8-r0/deploy-ipks/core2-64'
> returned non-zero exit status 1.: Traceback (most recent call last):
>
>   File "/home/edson/ng-trunk/poky/meta/lib/oe/utils.py", line 272, in run
>
> ret = self._target(*self._args, **self._kwargs)
>
>   File "/home/edson/ng-trunk/poky/meta/classes/package_ipk.bbclass", line
> 230, in ipk_write_pkg
>
> shell=True)
>
>   File
> "/opt/poky/2.7/sysroots/x86_64-pokysdk-linux/usr/lib/python3.7/subprocess.py",
> line 395, in check_output
>
> **kwargs).stdout
>
>   File
> "/opt/poky/2.7/sysroots/x86_64-pokysdk-linux/usr/lib/python3.7/subprocess.py",
> line 487, in run
>
> output=stdout, stderr=stderr)
>
> subprocess.CalledProcessError: Command
> 

Re: [yocto] Replacing a configuration file from another recipe

[Khem Raj]

On 4/29/19 5:35 AM, Damien LEFEVRE wrote:

Hi,

In our base image we use nginx. I created a nginx.bbappend to add our 
PHP configuration in a separated layer.


For a specific variant of the image I need to add an extra bit of nginx 
configuration.


I though I could create a new recipe to overwrite nginx.conf and include 
that recipe in the variant image definition, but bitbake shouts at me 
that I cannot modify a file from another recipe.


If that's the case, is it possible to create image name based bbappend 
files? Or do I need to create a separate nginx overwrite layer with 
higher priority than the base image nginx.bbappend for that image 
variant? (I wouldn't like that)




you might want to use a function to get this done and add it to 
IMAGE_POSTPROCESS_COMMAND in the specific image recipe.



Thanks,
-Damien


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

Re: [yocto] Timestamp error between zImage & uname-a [ Yocto-2.6.1 + Qemux86 ]

[Khem Raj]

On 5/10/19 12:10 AM, AshishKumar Mishra wrote:

HI Anuj ,

I was building minimal image using $ bitbake core-image-minimal haven't 
tried full-cmdline.


Not able to track why kernel "uname" has older  timestamp rather than 
the one from build/deploy/image

as seen by "ls -al 

Am i missing any command or sequence here




uname will show the time when it was built, which might be different 
time then the one when it was copied over to deploy.

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

Re: [yocto] Incorporating Xilinx DNNDK into Yocto

[Khem Raj]

On Fri, May 3, 2019 at 2:09 PM Emily S  wrote:
>
> Hi all -
>
> Xilinx has the Deep Neural Network Development Kit (DNNDK) that they just 
> released the source code for in the last month or so. They have the code 
> written nicely in the form of yocto recipes but it doesn't appear to be an 
> actual layer: 
> https://github.com/Xilinx/Edge-AI-Platform-Tutorials/tree/master/docs/DPU-Integration/reference-files/files
>  . Is there a possibility of creating a layer for it? Or should I look into 
> other options, like adding it as a submodule to my custom layer meta-l1calo: 
> https://github.com/kratsg/meta-l1calo?
>
> Or if anyone has additional options, suggestions are appreciated!

I think we need meta-ai


> Thanks for the help!
> Emily
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH 2/5] conf/machine: add rk3399 support

[Khem Raj]

On Mon, Apr 22, 2019 at 12:29 AM Ayaka  wrote:

>
>
> On Apr 22, 2019, at 11:47 AM, Khem Raj  wrote:
>
> This seems more a bsp layer thing may be meta-rockchip is better for this
> or meta-firefly
>
> You want to make a board vendor maintain a layer repository themselves? I
> saw every meta bsp repository would have some configures files. And those
> boards are sold around the world having many users, it is waste time to
> make people to collect layers.
>

It depends on how motivated the community is for example look at
meta-raspberrypi layer which effectively is a board layer using Broadcom
chip
So either way I am not suggesting one way or another if meta-rockchip
maintainer likes to maintain them then it’s ok

>
> Anyway, I hope the chip support would be merged.
>
> On Sun, Apr 21, 2019 at 10:06 AM Randy 'ayaka' Li 
> wrote:
>
>> RK3399 is a new generation powerful SoC from Rockchip, which has
>> Dual Cortex-A72 + Quad Cortex-A53, 64-bit CPU.
>>
>> Signed-off-by: Randy 'ayaka' Li 
>> ---
>>  conf/machine/excavator-rk3399.conf | 10 ++
>>  conf/machine/firefly-rk3399.conf   | 15 +++
>>  conf/machine/include/rk3399.inc| 17 +
>>  3 files changed, 42 insertions(+)
>>  create mode 100644 conf/machine/excavator-rk3399.conf
>>  create mode 100644 conf/machine/firefly-rk3399.conf
>>  create mode 100644 conf/machine/include/rk3399.inc
>>
>> diff --git a/conf/machine/excavator-rk3399.conf
>> b/conf/machine/excavator-rk3399.conf
>> new file mode 100644
>> index 000..c7134d2
>> --- /dev/null
>> +++ b/conf/machine/excavator-rk3399.conf
>> @@ -0,0 +1,10 @@
>> +# Copyright (C) 2017 Fuzhou Rockchip Electronics Co., Ltd
>> +# Released under the MIT license (see COPYING.MIT for the terms)
>> +
>> +#@TYPE: Machine
>> +#@NAME: EXCAVATOR 3399
>> +
>> +include conf/machine/include/rk3399.inc
>> +
>> +KERNEL_DEVICETREE = "rk3399-sapphire-excavator-linux.dtb"
>> +UBOOT_MACHINE = "evb-rk3399_defconfig"
>> diff --git a/conf/machine/firefly-rk3399.conf
>> b/conf/machine/firefly-rk3399.conf
>> new file mode 100644
>> index 000..fefafed
>> --- /dev/null
>> +++ b/conf/machine/firefly-rk3399.conf
>> @@ -0,0 +1,15 @@
>> +# Copyright (C) 2017 Fuzhou Rockchip Electronics Co., Ltd
>> +# Released under the MIT license (see COPYING.MIT for the terms)
>> +
>> +#@TYPE: Machine
>> +#@NAME: Firefly RK3399
>> +#@DESCRIPTION: Firefly-RK3399 is a Six-Core 64-bit High-Performance
>> Platform.
>> +#http://www.t-firefly.com/en/
>> +
>> +include conf/machine/include/rk3399.inc
>> +
>> +PREFERRED_PROVIDER_virtual/kernel = "linux-rockchip"
>> +KERNEL_DEVICETREE = "rockchip/rk3399-firefly-linux.dtb"
>> +UBOOT_MACHINE = "evb-rk3399_defconfig"
>> +
>> +GPTIMG_APPEND = "console=ttyS2,150n8 rw root=PARTUUID=614e-
>> rootfstype=ext4 init=/sbin/init"
>> diff --git a/conf/machine/include/rk3399.inc
>> b/conf/machine/include/rk3399.inc
>> new file mode 100644
>> index 000..6e2af57
>> --- /dev/null
>> +++ b/conf/machine/include/rk3399.inc
>> @@ -0,0 +1,17 @@
>> +# Copyright (C) 2019 SUMOMO Computer Association
>> +# Released under the MIT license (see COPYING.MIT for the terms)
>> +
>> +SOC_FAMILY = "rk3399"
>> +
>> +require conf/machine/include/tune-cortexa72.inc
>> +require conf/machine/include/soc-family.inc
>> +
>> +PREFERRED_PROVIDER_virtual/kernel = "linux"
>> +SERIAL_CONSOLES = "150;ttyS2"
>> +KERNEL_IMAGETYPE = "Image"
>> +#KBUILD_DEFCONFIG = "multi_v8_defconfig"
>> +
>> +PREFERRED_PROVIDER_virtual/bootloader ?= "u-boot-rockchip"
>> +
>> +IMAGE_FSTYPES = "rockchip-gpt-img"
>> +IMAGE_CLASSES = "rockchip-gpt-img"
>> --
>> 2.20.1
>>
>> --
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH 2/5] conf/machine: add rk3399 support

[Khem Raj]

This seems more a bsp layer thing may be meta-rockchip is better for this
or meta-firefly

On Sun, Apr 21, 2019 at 10:06 AM Randy 'ayaka' Li  wrote:

> RK3399 is a new generation powerful SoC from Rockchip, which has
> Dual Cortex-A72 + Quad Cortex-A53, 64-bit CPU.
>
> Signed-off-by: Randy 'ayaka' Li 
> ---
>  conf/machine/excavator-rk3399.conf | 10 ++
>  conf/machine/firefly-rk3399.conf   | 15 +++
>  conf/machine/include/rk3399.inc| 17 +
>  3 files changed, 42 insertions(+)
>  create mode 100644 conf/machine/excavator-rk3399.conf
>  create mode 100644 conf/machine/firefly-rk3399.conf
>  create mode 100644 conf/machine/include/rk3399.inc
>
> diff --git a/conf/machine/excavator-rk3399.conf
> b/conf/machine/excavator-rk3399.conf
> new file mode 100644
> index 000..c7134d2
> --- /dev/null
> +++ b/conf/machine/excavator-rk3399.conf
> @@ -0,0 +1,10 @@
> +# Copyright (C) 2017 Fuzhou Rockchip Electronics Co., Ltd
> +# Released under the MIT license (see COPYING.MIT for the terms)
> +
> +#@TYPE: Machine
> +#@NAME: EXCAVATOR 3399
> +
> +include conf/machine/include/rk3399.inc
> +
> +KERNEL_DEVICETREE = "rk3399-sapphire-excavator-linux.dtb"
> +UBOOT_MACHINE = "evb-rk3399_defconfig"
> diff --git a/conf/machine/firefly-rk3399.conf
> b/conf/machine/firefly-rk3399.conf
> new file mode 100644
> index 000..fefafed
> --- /dev/null
> +++ b/conf/machine/firefly-rk3399.conf
> @@ -0,0 +1,15 @@
> +# Copyright (C) 2017 Fuzhou Rockchip Electronics Co., Ltd
> +# Released under the MIT license (see COPYING.MIT for the terms)
> +
> +#@TYPE: Machine
> +#@NAME: Firefly RK3399
> +#@DESCRIPTION: Firefly-RK3399 is a Six-Core 64-bit High-Performance
> Platform.
> +#http://www.t-firefly.com/en/
> +
> +include conf/machine/include/rk3399.inc
> +
> +PREFERRED_PROVIDER_virtual/kernel = "linux-rockchip"
> +KERNEL_DEVICETREE = "rockchip/rk3399-firefly-linux.dtb"
> +UBOOT_MACHINE = "evb-rk3399_defconfig"
> +
> +GPTIMG_APPEND = "console=ttyS2,150n8 rw root=PARTUUID=614e-
> rootfstype=ext4 init=/sbin/init"
> diff --git a/conf/machine/include/rk3399.inc
> b/conf/machine/include/rk3399.inc
> new file mode 100644
> index 000..6e2af57
> --- /dev/null
> +++ b/conf/machine/include/rk3399.inc
> @@ -0,0 +1,17 @@
> +# Copyright (C) 2019 SUMOMO Computer Association
> +# Released under the MIT license (see COPYING.MIT for the terms)
> +
> +SOC_FAMILY = "rk3399"
> +
> +require conf/machine/include/tune-cortexa72.inc
> +require conf/machine/include/soc-family.inc
> +
> +PREFERRED_PROVIDER_virtual/kernel = "linux"
> +SERIAL_CONSOLES = "150;ttyS2"
> +KERNEL_IMAGETYPE = "Image"
> +#KBUILD_DEFCONFIG = "multi_v8_defconfig"
> +
> +PREFERRED_PROVIDER_virtual/bootloader ?= "u-boot-rockchip"
> +
> +IMAGE_FSTYPES = "rockchip-gpt-img"
> +IMAGE_CLASSES = "rockchip-gpt-img"
> --
> 2.20.1
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Compiling on target - building buildessentials error

[Khem Raj]

You may want to add following in local.conf

EXTRA_IMAGE_FEATURES_append = " tools-sdk tools-debug dbg-pkgs"

that should get you going. Then you can install the additional
packages you need.

On Sat, Apr 13, 2019 at 12:26 PM Patrick Schneider
 wrote:
>
> Hi guys,
> I am trying to use gcc on my target board. In order to do that I added 
> packagegroup-core-buildessentials to my image. At least I tried to.
> When building I get that error:
> packagegroup-core-buildessential : Depends: libstdc++-dev but it is not 
> installable
> After trying a lot of things and playing around with different packages it 
> seems that I am generally not able to add *-dev packages to my image, or at 
> least build them with bitbake to add them manually. Everything I try with 
> *-dev involved throws an error. For example if I am adding 'dev-pkgs' to my 
> EXTRA_IMAGE_FEATURES variable I get over 200 errors with all dev-packages 
> missing just like that above.
> I must have something misconfigured in my local/distro/machine/image conf 
> files but I can't figure out what.
> Any help appreciated.
>
> Best regards,
> Patrick Schneider
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Changing IMAGE_NAME [yocto krogoth]

[Khem Raj]

On Wed, Apr 10, 2019 at 2:49 AM Mauro Ziliani  wrote:

> Hi all.
>
> I need to change the default IMAGE_NAME of my image recipe.
>
> I make my image recipe as mysystem-image_1.0.bb and I'd like to produce
> and image (tar) with the name
>
> mysystem-image-1.0-.tar
>
>
Isn’t time stamp part of the standard image you get out of build ?

>
> So I setup
>
> IMAGE_NAME := "{IMAGE_BASENAME}-${PV}-${DATETIME}"
>
>
> I made some compilation of mysystem with the default IMAGE_NAME.
>
> Than I update the value of IMAGE_NAME.
>
>
> Now when I rebuild the image bitbke tell me
>
> ERROR: When reparsing mysystem-image_1.0.do_roots, the basehash value
> change from  to 
>
> If i restore the IMAGE_NAME to the default value this message disappear
>
>
> How can I change the IMAGE_NAME as I need and avoi this message?
>
>
> Best regards,
>
>   MZ
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Stripping debug symbols

[Khem Raj]

Build should strip it automatically what does your build recipe look like

On Thu, Apr 11, 2019 at 1:37 AM Mauro Ziliani  wrote:

> Hi all.
>
> I worked on my project woth Krogoth, gcc 5.3.0, on imx6dlsabresd board.
>
> My application is build with cmake 3.4.3, shipped with BSP.
>
>
> I'd like to strip debug symbols from the final binary, but if I prepend
> the strip parameter in CMAKE_{C,CXX}_FLAGS_RELEASE in my CMakeLists.txt,
> bitbake give me errors.
>
>
> What is the right path to follow to strip final binary?
>
> With debug info the binary is 109MB, without 5MB
>
>
> Best regards,
>
>  Mauro
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] problem with ruby

[Khem Raj]

probably it has to be added to linker flags explicitly.

On Tue, Apr 9, 2019 at 12:00 AM Clement CHERBEIX
 wrote:
>
> It's done but I keep the same problem, I've add zlib in the PACKAGECONFIG too 
> without any result...
>
>
>
> ________
> De : Khem Raj 
> Envoyé : lundi 8 avril 2019 20:04
> À : Clement CHERBEIX
> Cc : Yocto Project
> Objet : Re: [yocto] problem with ruby
>
> On Mon, Apr 8, 2019 at 9:44 AM Clément Cherbeix
>  wrote:
> >
> > Hello all,
> >
> > I’m trying to add the MIB mechanics in my yocto project, for that I use 
> > dadi (ruby depenedent) but I get an error when bitbake try to compile :
> >
> > DEBUG: Executing shell function do_compile
> >
> > ERROR:  Loading command: build (LoadError)
> >
> > cannot load such file -- zlib
> >
> > ERROR:  While executing gem ... (NoMethodError)
> >
> > undefined method `invoke_with_build_args' for nil:NilClass
> >
> > WARNING: 
> > /home/modem/tkh/build/tmp/work/x86_64-linux/libxml-ruby-native/2.8.0-r0/temp/run.do_compile.567:1
> >  exit 1 from 'LANG="en_US.UTF-8" LC_ALL="en_US.UTF-8" gem build $gem'
> >
> >
> >
> > I have tried to build the gem in an environment outside of Yocto and it was 
> > correct but when I try to do it in Yocto, I get my error.
> > Did someone have an idea on what to do ?
> > what is the recommended way of building ruby via gem in yocto ?
> >
> >
>
> It seems that it is using ruby-native but does not have zlib-native
> and it cant find this library. Can you add zlib to DEPENDS in ruby
> recipe and see if that helps.
>
> >
> > Here is my build environment :
> >
> > BB_VERSION   = "1.40.0"
> >
> > BUILD_SYS= "x86_64-linux"
> >
> > NATIVELSBSTRING  = "universal"
> >
> > TARGET_SYS   = "x86_64-poky-linux"
> >
> > DISTRO   = "poky"
> >
> > DISTRO_VERSION   = "2.6.1"
> >
> > TUNE_FEATURES= "m64 corei7"
> >
> >
> >
> > Thanks in advance !
> >
> >
> >
> > Clément C.
> >
> > --
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Development environment for Grub bootloader and Linux

[Khem Raj]

On Mon, Apr 8, 2019 at 9:39 AM Srinivasa RaoW  wrote:
>
> Dear All,
>
> I have a requirement of modifying Grub bootloader for x86 architecture but 
> Just read the Wiki Page of Yocto and it states as below”
>
> “The Yocto Project is an open-source project that delivers a set of tools 
> that create operating system images for embedded Linux systems”
>
> Towards this I have below questions:
>
> Does Yocto project support only Linux systems?

yes

> Do we have repositories/build tool chain for Grub bootloader?


> Which is the bootloader that Yocto project recommends for x86 architecture?

It supports multiple bootloaders e.g. grub2, syslinux, systemd-boot
etc. its upto distro to choose which ever they want

I would suggest to look into devtool workflow with yocto/OE this is
recommended tool for doing cross development

http://events17.linuxfoundation.org/sites/events/files/slides/2017%20ELC%20--%20Using%20devtool%20to%20Streamline%20your%20Yocto%20Project%20Workflow.pdf

>
> I am trying to setup a development environment under Ubunt Host for x86 
> target architecture.  Goal is to build Grub bootloader, Ubuntu linux and root 
> file system all together under one umbrella.
>
> Please let me know if Yocto has anything for this.
>
> Appreciate any input on this.
>
> Regards
>
> Srinivasa
>
>
>
> L Technology Services Ltd
>
> www.LTTS.com
>
> This Email may contain confidential or privileged information for the 
> intended recipient (s). If you are not the intended recipient, please do not 
> use or disseminate the information, notify the sender and delete it from your 
> system.
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] problem with ruby

[Khem Raj]

On Mon, Apr 8, 2019 at 9:44 AM Clément Cherbeix
 wrote:
>
> Hello all,
>
> I’m trying to add the MIB mechanics in my yocto project, for that I use dadi 
> (ruby depenedent) but I get an error when bitbake try to compile :
>
> DEBUG: Executing shell function do_compile
>
> ERROR:  Loading command: build (LoadError)
>
> cannot load such file -- zlib
>
> ERROR:  While executing gem ... (NoMethodError)
>
> undefined method `invoke_with_build_args' for nil:NilClass
>
> WARNING: 
> /home/modem/tkh/build/tmp/work/x86_64-linux/libxml-ruby-native/2.8.0-r0/temp/run.do_compile.567:1
>  exit 1 from 'LANG="en_US.UTF-8" LC_ALL="en_US.UTF-8" gem build $gem'
>
>
>
> I have tried to build the gem in an environment outside of Yocto and it was 
> correct but when I try to do it in Yocto, I get my error.
> Did someone have an idea on what to do ?
> what is the recommended way of building ruby via gem in yocto ?
>
>

It seems that it is using ruby-native but does not have zlib-native
and it cant find this library. Can you add zlib to DEPENDS in ruby
recipe and see if that helps.

>
> Here is my build environment :
>
> BB_VERSION   = "1.40.0"
>
> BUILD_SYS= "x86_64-linux"
>
> NATIVELSBSTRING  = "universal"
>
> TARGET_SYS   = "x86_64-poky-linux"
>
> DISTRO   = "poky"
>
> DISTRO_VERSION   = "2.6.1"
>
> TUNE_FEATURES= "m64 corei7"
>
>
>
> Thanks in advance !
>
>
>
> Clément C.
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] Worries kernels supported

[Khem Raj]

On Thu, Apr 4, 2019 at 2:29 PM akuster808  wrote:
>
> Hello,
>
> I noticed there are 3 kernels in Warrior. 4.18, 4.19 an 5.0. Do we
> really need 4.18?
> I see its the default version for poky-tiny. 4.18 is EOL but maintained
> by Windriver.

I would prefer it to be 4.19 since thats at least LTS

>
> regards,
> Armin
>
>
>
> --
> ___
> Openembedded-core mailing list
> openembedded-c...@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [oe] [OE-core] Git commit process question.

[Khem Raj]

On Wed, Apr 3, 2019 at 4:07 PM Paul Eggleton
 wrote:
>
> On Thursday, 4 April 2019 5:46:04 AM NZDT Khem Raj wrote:
> > On Wed, Apr 3, 2019 at 7:41 AM Tom Rini  wrote:
> > >
> > > On Wed, Apr 03, 2019 at 11:30:39AM +0100, Burton, Ross wrote:
> > > > On Tue, 2 Apr 2019 at 20:46, Tom Rini  wrote:
> > > > > > The kernel does not have "upgrade foo to the latest upstream
> > > > > > version" commits.
> > > > > >
> > > > > > With the Automatic Upgrade Helper this is a semi-automatic task, and
> > > > > > most of the time there is no specific motivation other than
> > > > > > upgrading
> > > > > > to the latest upstream version.
> > > > >
> > > > > But since that's just filling in a template the body can also be a
> > > > > template perhaps with useful AUH data (run at ... by ... ?) ?
> > > >
> > > > Apart from making the commit message longer what does this achieve?
> > > > The commit already has a timestamp and author.
> > >
> > > It's an etiquette thing.  Subject+Sign-off+Empty body is bad form.  AUH
> > > updates are a form of "trivial update" that every project has.  "Update
> > > $X from version $Y to $Z" is what a human would normally put.  It's
> > > weird looking at git log of nothing but subject+signed-off-by.  I'm not
> > > going to object further on this point, but I don't get it.
> >
> > if the content of subject is being repeated in body then I would
> > prefer an empty body
> > redundant information in commits should be avoided since it can create
> > impression that body does not have
> > useful information and skip reading it. We should strive to make commits
> > concise and useful.
>
> There is often (I won't say always, but often) something useful you can put in
> the commit message. If it's a recipe upgrade, you could put a pointer to the
> upstream changelog in it, for example. As the person doing the upgrade if your
> prior review of that changelog or other upstream release documentation
> indicated any backwards-compatibility issues or CVEs fixed then those really
> ought to be mentioned as well; if you're feeling especially generous you might
> mention highlights of any new functionality. (I have a proposal that might
> help us automate part of that which I've not yet fully fleshed out, hopefully
> one day soon I will get around to it.)
>
> The issue of empty commit messages is something I've complained about in the
> past, and not just about recipe upgrades. If I - as someone who is relatively
> familiar with OE - have to actually read beyond the shortlog / commit message
> to understand the basics of why a change has been made, then it's likely that
> the commit message wasn't good enough. Unlike other issues, once a commit goes
> in the message is set in stone within the git history, so if you are working
> on a change, *please* take a minute or two to document it adequately in the
> commit message so that others looking back can understand it.
>

Definitely, and I agree that we should put relevant information in
commits, usually
the information about side effects if any, links to changelog etc. are
useful too
however, we should not enforce a behavior which could result in
redundancy as explained

> Thanks,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto