Re: [yocto] Getting absolute paths in yocto generated native binary #bitbake #native #toolchain #sdk

2021-10-05 Thread Chuck Wolber
Native recipes are meant for the build machine itself to aid your build. If
you are packaging something to run on a destination machine, you should be
producing non-native recipe images.

..Ch:W..

On Tue, Oct 5, 2021 at 1:59 PM Jean-Pierre Doyon 
wrote:

> I'm attempting to create a USB first boot tarball for our custom iMX6
> board that would contain the imx-usb-loader executable, config files and
> u-boot/SPL files. The goal being to deploy that to the production machine
> to program the empty boards right after being assembled.
>
> While I had plenty of hurdles figuring out how to do this (I'm still
> pretty newbie with Yocyo), I managed to get everything just the way I
> wanted it. But when I get the tarball to the production machine, which runs
> the exact same Ubuntu 18.04 LTS Linux as the build machine, the imx_usb
> tool won't run. The reason being that it's missing some library. Running
> LDD on the executable turns up this:
>
> └─$> ldd usr/bin/imx_usb
> linux-vdso.so.1 =>  (0x7ffd7031d000)
> libusb-1.0.so.0 => /lib/x86_64-linux-gnu/libusb-1.0.so.0 
> (0x7f986a47e000)
> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f986a0b4000)
> libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x7f986a86c000)
> libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
> (0x7f9869e97000)
> 
> /home/jpdoyon/newtrax-layersetup-dunfell/build/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2
>  => /lib64/ld-linux-x86-64.so.2 (0x7f986a696000)
> librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f9869c8f000)
>
> Why is the ld-linux-x86-64.so.2 using an absolute path while all the other
> libraries aren't?
>
> If I install the library in the location above, then the executable starts
> working... So how do I make sure Yocto doesn't do this?
>
> 
>
>

-- 
*"Perfection must be reached by degrees; she requires the slow hand of
time." - Voltaire*

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54975): https://lists.yoctoproject.org/g/yocto/message/54975
Mute This Topic: https://lists.yoctoproject.org/mt/86104726/21656
Mute #sdk:https://lists.yoctoproject.org/g/yocto/mutehashtag/sdk
Mute #toolchain:https://lists.yoctoproject.org/g/yocto/mutehashtag/toolchain
Mute #bitbake:https://lists.yoctoproject.org/g/yocto/mutehashtag/bitbake
Mute #native:https://lists.yoctoproject.org/g/yocto/mutehashtag/native
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [yocto] Google GN support

2021-10-05 Thread Joel Winarske
> look at meta-browser/meta-chromium as well.

The download archive (tar.xz) approach may be the easiest solution.  Then
one would just need to make a versioned recipe for each LTS.

Thanks Khem!

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54974): https://lists.yoctoproject.org/g/yocto/message/54974
Mute This Topic: https://lists.yoctoproject.org/mt/86105559/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [yocto] Getting absolute paths in yocto generated native binary #bitbake #native #toolchain #sdk

2021-10-05 Thread Khem Raj
On Tue, Oct 5, 2021 at 1:59 PM Jean-Pierre Doyon  wrote:
>
> I'm attempting to create a USB first boot tarball for our custom iMX6 board 
> that would contain the imx-usb-loader executable, config files and u-boot/SPL 
> files. The goal being to deploy that to the production machine to program the 
> empty boards right after being assembled.
>
> While I had plenty of hurdles figuring out how to do this (I'm still pretty 
> newbie with Yocyo), I managed to get everything just the way I wanted it. But 
> when I get the tarball to the production machine, which runs the exact same 
> Ubuntu 18.04 LTS Linux as the build machine, the imx_usb tool won't run. The 
> reason being that it's missing some library. Running LDD on the executable 
> turns up this:
>
> └─$> ldd usr/bin/imx_usb
> linux-vdso.so.1 =>  (0x7ffd7031d000)
> libusb-1.0.so.0 => /lib/x86_64-linux-gnu/libusb-1.0.so.0 
> (0x7f986a47e000)
> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f986a0b4000)
> libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x7f986a86c000)
> libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
> (0x7f9869e97000)
> 
> /home/jpdoyon/newtrax-layersetup-dunfell/build/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2
>  => /lib64/ld-linux-x86-64.so.2 (0x7f986a696000)
> librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f9869c8f000)
>
> Why is the ld-linux-x86-64.so.2 using an absolute path while all the other 
> libraries aren't?
>
> If I install the library in the location above, then the executable starts 
> working... So how do I make sure Yocto doesn't do this?
>

yocto provides a layer to abstract native binaries on top of build
host and thats what you are seeing. Its as designed.

>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54973): https://lists.yoctoproject.org/g/yocto/message/54973
Mute This Topic: https://lists.yoctoproject.org/mt/86104726/21656
Mute #sdk:https://lists.yoctoproject.org/g/yocto/mutehashtag/sdk
Mute #toolchain:https://lists.yoctoproject.org/g/yocto/mutehashtag/toolchain
Mute #bitbake:https://lists.yoctoproject.org/g/yocto/mutehashtag/bitbake
Mute #native:https://lists.yoctoproject.org/g/yocto/mutehashtag/native
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [yocto] Google GN support

2021-10-05 Thread Khem Raj
On Tue, Oct 5, 2021 at 2:34 PM Joel Winarske  wrote:
>
> I'm looking into best practice LTS support for Google GN based projects.  
> This includes Chromium, Flutter, SKIA, etc.
>
> The weakness I see today for GN projects is that it's a build system within a 
> build system, and doesn't  support idiomatic download caching, download vs 
> patching isn't clear as it should be, etc.
>
> Two approaches to resolve this come to mind:
> 1. Do something similar to how meta-rust does it.  Pre-process GN build files 
> and generate Yocto recipes using a hostside tool (similar to cargo-bitbake 
> for meta-rust).  This would skip usage of gclient entirely, and the tradeoff 
> is to incur download performance penalty.
>
> 2. Implement build parsing in a gclient/gn fetcher class.
>
> I feel the first approach would be easier to maintain and provide better 
> flexibility.  It would incur a new host dependency, and require an additional 
> step to generate an updated recipe.
>
> I suspect the second approach would be an OE maintenance headache, as 
> complexities would be directly exposed in OE.  Is this why gclient fetcher 
> support came and went?
>
> I'm figuring/hoping there are a few opinions floating around on this subject.
>
> Is there a better approach?

look at meta-browser/meta-chromium as well.

>
> Thanks,
> Joel
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54972): https://lists.yoctoproject.org/g/yocto/message/54972
Mute This Topic: https://lists.yoctoproject.org/mt/86105559/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[yocto] Google GN support

2021-10-05 Thread Joel Winarske
I'm looking into best practice LTS support for Google GN based projects.
This includes Chromium, Flutter, SKIA, etc.

The weakness I see today for GN projects is that it's a build system within
a build system, and doesn't  support idiomatic download caching, download
vs patching isn't clear as it should be, etc.

Two approaches to resolve this come to mind:
1. Do something similar to how meta-rust does it.  Pre-process GN build
files and generate Yocto recipes using a hostside tool (similar to
cargo-bitbake for meta-rust).  This would skip usage of gclient entirely,
and the tradeoff is to incur download performance penalty.

2. Implement build parsing in a gclient/gn fetcher class.

I feel the first approach would be easier to maintain and provide better
flexibility.  It would incur a new host dependency, and require an
additional step to generate an updated recipe.

I suspect the second approach would be an OE maintenance headache, as
complexities would be directly exposed in OE.  Is this why gclient fetcher
support came and went?

I'm figuring/hoping there are a few opinions floating around on this
subject.

Is there a better approach?

Thanks,
Joel

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54971): https://lists.yoctoproject.org/g/yocto/message/54971
Mute This Topic: https://lists.yoctoproject.org/mt/86105559/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[yocto] Getting absolute paths in yocto generated native binary #bitbake #native #toolchain #sdk

2021-10-05 Thread Jean-Pierre Doyon
I'm attempting to create a USB first boot tarball for our custom iMX6 board 
that would contain the imx-usb-loader executable, config files and u-boot/SPL 
files. The goal being to deploy that to the production machine to program the 
empty boards right after being assembled.

While I had plenty of hurdles figuring out how to do this (I'm still pretty 
newbie with Yocyo), I managed to get everything just the way I wanted it. But 
when I get the tarball to the production machine, which runs the exact same 
Ubuntu 18.04 LTS Linux as the build machine, the imx_usb tool won't run. The 
reason being that it's missing some library. Running LDD on the executable 
turns up this:

└─$> ldd usr/bin/imx_usb
   linux-vdso.so.1 =>  (0x7ffd7031d000)
   libusb-1.0.so.0 => /lib/x86_64-linux-gnu/libusb-1.0.so.0 (0x7f986a47e000)
   libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f986a0b4000)
   libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x7f986a86c000)
   libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f9869e97000)
   
/home/jpdoyon/newtrax-layersetup-dunfell/build/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2
 => /lib64/ld-linux-x86-64.so.2 (0x7f986a696000)
   librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f9869c8f000)

Why is the ld-linux-x86-64.so.2 using an absolute path while all the other 
libraries aren't?

If I install the library in the location above, then the executable starts 
working... So how do I make sure Yocto doesn't do this?

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54970): https://lists.yoctoproject.org/g/yocto/message/54970
Mute This Topic: https://lists.yoctoproject.org/mt/86104726/21656
Mute #toolchain:https://lists.yoctoproject.org/g/yocto/mutehashtag/toolchain
Mute #sdk:https://lists.yoctoproject.org/g/yocto/mutehashtag/sdk
Mute #bitbake:https://lists.yoctoproject.org/g/yocto/mutehashtag/bitbake
Mute #native:https://lists.yoctoproject.org/g/yocto/mutehashtag/native
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [yocto] #dunfell Path to sources in debugfs

2021-10-05 Thread Robert Berger

Hi,

My comments are inline.

On 05/10/2021 17:04, bohdan.shubenok@sigma.software wrote:

Hi all,

I`m trying to debug coredump generated on embedded system running 
dunfel. 


Just to clarify your user space applications crashes and you try to see 
why? In other words you would like to load the application and the core 
file into your debugger and inspect it?


The issue I`m facing is with the source files path in 
"-dbg.rootfs" archive and within dedug portion of a package.

When loaded in QtCreator some sources can`t be found :


The part is missing is "*build/..*". Such notation is obviosly cancels 
itself and adding empty "build" folder manually helps.
This path allings with how it builds. Here is a part of Makefile found 
in build path for sqlite:


    build/Makefile:20:VPATH = ../sqlite-autoconf-3310100
    build/Makefile:313:abs_srcdir = 
/home/bohdan/noah/noah/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/sqlite3/3_3.31.1-r0/build/../sqlite-autoconf-3310100
    build/Makefile:315:abs_top_srcdir = 
/home/bohdan/noah/noah/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/sqlite3/3_3.31.1-r0/build/../sqlite-autoconf-3310100

    build/Makefile:358:srcdir = ../sqlite-autoconf-3310100

So I tried to disable out-of-tree build for sqlite by replacing 
*'inherit autotools*' with '*inherit autotools-brokensep*'. After 
building and loading new debugfs QtCreator was able to found required 
sources:



Is this a known issue or me doing something wrong with build setup?


This is very strange, but also I am not quite sure how exactly you debug.
I assume you run gdbserver on the target and connect from some cross-gdb 
on your host to it.


You could try to install gdb onto your target plus debug info and 
sources to exclude the cross-gdb configuration problem as I describe below.


If you use gdbserver/cross-gdb I assume directories on your target 
rootfs and host roots are different. So you need to tell your cross-gdb 
on the host where to find the debug info and the sources.


Can you please try something like this?

http://docs.yoctoproject.org/singleindex.html#using-the-gdbserver-method

What I would inspect carefully is something like that:

$ cd directory-holding-the-debugfs-directory
$ arch-gdb
(gdb) set sysroot debugfs
(gdb) set substitute-path /usr/src/debug debugfs/usr/src/debug
(gdb) target remote IP-of-target:1234

At least in the latest and greatest version this works. I remember a bug 
a long time ago with some ancient yocto release with cross-debugging, 
but this was resolved with some upgrade and was certainly older than 
dunfell.


Regards,

Robert

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54969): https://lists.yoctoproject.org/g/yocto/message/54969
Mute This Topic: https://lists.yoctoproject.org/mt/86094129/21656
Mute #dunfell:https://lists.yoctoproject.org/g/yocto/mutehashtag/dunfell
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [yocto][meta-rockchip][PATCH] rockchip.wks: use uuid for /boot during fstab-update

2021-10-05 Thread Trevor Woerner
On Fri 2021-10-01 @ 03:20:35 PM, Markus Volk wrote:
> Since the recent patch to switch to UUIDs [0aa5e600: "use uuid
> instead of hard-coding root device"] wic fstab-update is not able
> to get the correct value for the used device anymore and falls to
> the default 'sda'. Thus wrong /dev/sda entries are generated in fstab.
> 
> For partitions that should be updated automatically this can be avoided
> by either generate entries using uuid or label.
> 
> Signed-off-by: MarkusVolk 
> ---
>  wic/rockchip.wks | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

I tweaked the patch so that the fields lined up vertically, but otherwise…
Applied to meta-rockchip, master.
Thanks!

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54968): https://lists.yoctoproject.org/g/yocto/message/54968
Mute This Topic: https://lists.yoctoproject.org/mt/85999141/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [yocto] [meta-rockchip][PATCH 3/3] nanopi-m4: add common override

2021-10-05 Thread Trevor Woerner
On Wed 2021-09-29 @ 01:29:38 AM, Trevor Woerner wrote:
> Add a common override for both nanopi-m4 MACHINEs.
> 
> Signed-off-by: Trevor Woerner 
> ---
>  conf/machine/include/nanopi-m4.inc | 3 +++
>  1 file changed, 3 insertions(+)

Applied to meta-rockchip, master.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54967): https://lists.yoctoproject.org/g/yocto/message/54967
Mute This Topic: https://lists.yoctoproject.org/mt/85942470/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [yocto] [meta-rockchip][PATCH 2/3] include/nanopi-m4: remove KMACHINE

2021-10-05 Thread Trevor Woerner
On Wed 2021-09-29 @ 01:29:37 AM, Trevor Woerner wrote:
> There is no "nanopi-m4" defined in any yocto kernel metadata (yet?), therefore
> remove this superfluous line.
> 
> Build (core-image-base) and run tested (both systemd and sysvinit) on:
> - nanopi-m4
> 
> Signed-off-by: Trevor Woerner 
> ---
>  conf/machine/include/nanopi-m4.inc | 1 -
>  1 file changed, 1 deletion(-)

Applied to meta-rockchip, master.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54966): https://lists.yoctoproject.org/g/yocto/message/54966
Mute This Topic: https://lists.yoctoproject.org/mt/85942469/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [yocto] [meta-rockchip][PATCH 1/3] linux-yocto: remove mmc aliases

2021-10-05 Thread Trevor Woerner
On Wed 2021-09-29 @ 01:29:36 AM, Trevor Woerner wrote:
> Now that we're booting via UUID, we no longer need these aliases in the DT.
> Personally I wasn't able to prove to myself that they actually worked (at
> least not with 5.13.y) and fiddling with these aliases didn't seem to affect
> the mmc probe order on boot. Additionally it looks like some of these aliases
> will be landing upstream shortly.
> 
> Build (core-image-base) and run tested (both systemd and sysvinit) on:
> - rock64
> - rock-pi-e
> 
> (i.e. the two rk3328 MACHINEs)
> 
> Signed-off-by: Trevor Woerner 
> ---
>  ...an-dtsi-rk3328-add-mmc0-mmc1-aliases.patch | 27 ---
>  recipes-kernel/linux/linux-yocto%.bbappend|  3 ---
>  2 files changed, 30 deletions(-)
>  delete mode 100644 
> recipes-kernel/linux/files/0001-ayufan-dtsi-rk3328-add-mmc0-mmc1-aliases.patch

Applied to meta-rockchip, master.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54965): https://lists.yoctoproject.org/g/yocto/message/54965
Mute This Topic: https://lists.yoctoproject.org/mt/85942468/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [yocto] #dunfell Path to sources in debugfs

2021-10-05 Thread Khem Raj



On 10/5/21 7:04 AM, bohdan.shubenok@sigma.software wrote:

Hi all,

I`m trying to debug coredump generated on embedded system running 
dunfel. The issue I`m facing is with the source files path in 
"-dbg.rootfs" archive and within dedug portion of a package.

When loaded in QtCreator some sources can`t be found :


The part is missing is "*build/..*". Such notation is obviosly cancels 
itself and adding empty "build" folder manually helps.
This path allings with how it builds. Here is a part of Makefile found 
in build path for sqlite:


    build/Makefile:20:VPATH = ../sqlite-autoconf-3310100
    build/Makefile:313:abs_srcdir = 
/home/bohdan/noah/noah/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/sqlite3/3_3.31.1-r0/build/../sqlite-autoconf-3310100
    build/Makefile:315:abs_top_srcdir = 
/home/bohdan/noah/noah/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/sqlite3/3_3.31.1-r0/build/../sqlite-autoconf-3310100

    build/Makefile:358:srcdir = ../sqlite-autoconf-3310100

So I tried to disable out-of-tree build for sqlite by replacing 
*'inherit autotools*' with '*inherit autotools-brokensep*'. After 
building and loading new debugfs QtCreator was able to found required 
sources:



Is this a known issue or me doing something wrong with build setup?


I think its not a general problem with autotool based projects doing out 
of tree builds but just with sqlite3 package. Perhaps you might want to 
look at compiler commandline options being passed to sqlite3 build and 
see if paths can be adjusted during build to account for out of tree build.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54964): https://lists.yoctoproject.org/g/yocto/message/54964
Mute This Topic: https://lists.yoctoproject.org/mt/86094129/21656
Mute #dunfell:https://lists.yoctoproject.org/g/yocto/mutehashtag/dunfell
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [yocto] virtual/egl on Raspberry Pi 4

2021-10-05 Thread Greg Wilson-Lindberg
Hi Khem,

I added the VC4GRAPHICS line and here is the complete error that I get:


ERROR: Nothing PROVIDES 'virtual/egl' (but 
/home/gwilson/Qt-5.15.6/Yocto-build-RPi4/sources/meta-qt5/recipes-qt/qt5/qtbase_git.bb
 DEPENDS on or otherwise requires it)
vc-graphics PROVIDES virtual/egl but was skipped: 
PREFERRED_PROVIDER_virtual/libgles2 set to mesa, not vc-graphics
opengldummy PROVIDES virtual/egl but was skipped: 
PREFERRED_PROVIDER_virtual/libgles2 set to mesa, not opengldummy
vc-graphics-hardfp PROVIDES virtual/egl but was skipped: 
PREFERRED_PROVIDER_virtual/libgles2 set to mesa, not vc-graphics-hardfp
qtglesstream-dummy-client PROVIDES virtual/egl but was skipped: 
PREFERRED_PROVIDER_virtual/libgles2 set to mesa, not qtglesstream-dummy-client
NOTE: Runtime target 'zint' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['zint', 'qtbase', 'virtual/egl']

Regards,

Greg


From: Khem Raj 
Sent: Tuesday, October 5, 2021 9:31:49 AM
To: Greg Wilson-Lindberg
Cc: yocto@lists.yoctoproject.org
Subject: Re: [yocto] virtual/egl on Raspberry Pi 4

that should have worked well for userland recipe to provide it. Maybe
you need to set

VC4GRAPHICS = ""

in local.conf

On Tue, Oct 5, 2021 at 8:53 AM Greg Wilson-Lindberg
 wrote:
>
> I am compiling in 32 bit mode.
>
>
>
> From: Khem Raj 
> Sent: Monday, October 4, 2021 5:15 PM
> To: Greg Wilson-Lindberg 
> Cc: yocto@lists.yoctoproject.org
> Subject: Re: [yocto] virtual/egl on Raspberry Pi 4
>
>
>
> It should have automatically found user land package as one of providers but 
> if it is not doing so that means it’s being ignored because it’s not 
> compatible arch or something
>
> Are you compiling 32bit mode ?
>
>
>
>
>
> On Mon, Oct 4, 2021 at 4:08 PM Greg Wilson-Lindberg  
> wrote:
>
> Hi Khem,
> Yes, the Raspberry Pi boards do use closed source drivers. What I need is how 
> do I include the proper package that will bring in the necessary virtual/egl 
> for the Raspberry Pi 4.
>
> Greg
> > -Original Message-
> > From: Khem Raj 
> > Sent: Monday, October 4, 2021 14:17
> > To: Greg Wilson-Lindberg ;
> > yocto@lists.yoctoproject.org
> > Subject: Re: [yocto] virtual/egl on Raspberry Pi 4
> >
> >
> >
> > On 10/4/21 12:39 PM, Greg Wilson-Lindberg wrote:
> > > Hello list,
> > >
> > > I'm working on a Qt supplied boot2qt Yocto build currently based on
> > > Zeus that is running on a Raspberry Pi 4. I recently updated the qt
> > > version to 5.15.6 and Qt changed something in the Yocto configuration
> > > that they are using and now one of the recipes that we use is failing
> > > saying that in needs 'virtual/egl' but that it is not provided by any 
> > > recipe.
> > >
> > > In the searching that I have done I have found that the raspberry pi 4
> > > is particular on which package supplies the virtual/egl but I haven't
> > > seen anything that indicates what I should do to re-enable it.
> > >
> > > Can anyone tell me what I need to do to enable the correct driver to
> > > get virtual/egl provided on the Raspberry Pi 4? Or maybe even better,
> > > how I could search through the packages that are enabled on the old
> > > and new Yocto trees so that I can figure out what changed between the
> > > releases and re-enable the virtual/egl.
> > >
> >
> > it should be provided by userland package if you are using closed source
> > graphics driver.
> >
> > > Best Regards,
> > >
> > > Greg Wilson-Lindberg
> > >
> > >
> > >
> > > 
> > >

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54963): https://lists.yoctoproject.org/g/yocto/message/54963
Mute This Topic: https://lists.yoctoproject.org/mt/86076611/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [yocto] file package dependency

2021-10-05 Thread Khem Raj



On 10/5/21 5:10 AM, Timur wrote:
Hi, I'm building a yocto release from the thud branch. The size of the 
OS image is very critical, so I need to remove as much as I can. Looking 
at the dependency information, I can see that the "file" package is not 
required by any other package, but yet it is installed. I really have to 
remove this package because it is quite large with its magic database, 
but I can't find who is installing it and why.




I think looking into buildhistory metadata might give some hints, it 
stores the information about image to package dependencies in a dotty 
file which you can either open in a viewer or text editor and see who 
might be pulling the package which provides file utility. So firstly you 
have to find which package provides file utility which could be done via 
oe-pkg-utils tool








-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54962): https://lists.yoctoproject.org/g/yocto/message/54962
Mute This Topic: https://lists.yoctoproject.org/mt/86091587/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [yocto] virtual/egl on Raspberry Pi 4

2021-10-05 Thread Khem Raj
that should have worked well for userland recipe to provide it. Maybe
you need to set

VC4GRAPHICS = ""

in local.conf

On Tue, Oct 5, 2021 at 8:53 AM Greg Wilson-Lindberg
 wrote:
>
> I am compiling in 32 bit mode.
>
>
>
> From: Khem Raj 
> Sent: Monday, October 4, 2021 5:15 PM
> To: Greg Wilson-Lindberg 
> Cc: yocto@lists.yoctoproject.org
> Subject: Re: [yocto] virtual/egl on Raspberry Pi 4
>
>
>
> It should have automatically found user land package as one of providers but 
> if it is not doing so that means it’s being ignored because it’s not 
> compatible arch or something
>
> Are you compiling 32bit mode ?
>
>
>
>
>
> On Mon, Oct 4, 2021 at 4:08 PM Greg Wilson-Lindberg  
> wrote:
>
> Hi Khem,
> Yes, the Raspberry Pi boards do use closed source drivers. What I need is how 
> do I include the proper package that will bring in the necessary virtual/egl 
> for the Raspberry Pi 4.
>
> Greg
> > -Original Message-
> > From: Khem Raj 
> > Sent: Monday, October 4, 2021 14:17
> > To: Greg Wilson-Lindberg ;
> > yocto@lists.yoctoproject.org
> > Subject: Re: [yocto] virtual/egl on Raspberry Pi 4
> >
> >
> >
> > On 10/4/21 12:39 PM, Greg Wilson-Lindberg wrote:
> > > Hello list,
> > >
> > > I'm working on a Qt supplied boot2qt Yocto build currently based on
> > > Zeus that is running on a Raspberry Pi 4. I recently updated the qt
> > > version to 5.15.6 and Qt changed something in the Yocto configuration
> > > that they are using and now one of the recipes that we use is failing
> > > saying that in needs 'virtual/egl' but that it is not provided by any 
> > > recipe.
> > >
> > > In the searching that I have done I have found that the raspberry pi 4
> > > is particular on which package supplies the virtual/egl but I haven't
> > > seen anything that indicates what I should do to re-enable it.
> > >
> > > Can anyone tell me what I need to do to enable the correct driver to
> > > get virtual/egl provided on the Raspberry Pi 4? Or maybe even better,
> > > how I could search through the packages that are enabled on the old
> > > and new Yocto trees so that I can figure out what changed between the
> > > releases and re-enable the virtual/egl.
> > >
> >
> > it should be provided by userland package if you are using closed source
> > graphics driver.
> >
> > > Best Regards,
> > >
> > > Greg Wilson-Lindberg
> > >
> > >
> > >
> > > 
> > >

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54961): https://lists.yoctoproject.org/g/yocto/message/54961
Mute This Topic: https://lists.yoctoproject.org/mt/86076611/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [yocto] virtual/egl on Raspberry Pi 4

2021-10-05 Thread Greg Wilson-Lindberg
I am compiling in 32 bit mode.

From: Khem Raj 
Sent: Monday, October 4, 2021 5:15 PM
To: Greg Wilson-Lindberg 
Cc: yocto@lists.yoctoproject.org
Subject: Re: [yocto] virtual/egl on Raspberry Pi 4

It should have automatically found user land package as one of providers but if 
it is not doing so that means it’s being ignored because it’s not compatible 
arch or something
Are you compiling 32bit mode ?


On Mon, Oct 4, 2021 at 4:08 PM Greg Wilson-Lindberg 
mailto:gwil...@sakuraus.com>> wrote:
Hi Khem,
Yes, the Raspberry Pi boards do use closed source drivers. What I need is how 
do I include the proper package that will bring in the necessary virtual/egl 
for the Raspberry Pi 4.

Greg
> -Original Message-
> From: Khem Raj mailto:raj.k...@gmail.com>>
> Sent: Monday, October 4, 2021 14:17
> To: Greg Wilson-Lindberg mailto:gwil...@sakuraus.com>>;
> yocto@lists.yoctoproject.org
> Subject: Re: [yocto] virtual/egl on Raspberry Pi 4
>
>
>
> On 10/4/21 12:39 PM, Greg Wilson-Lindberg wrote:
> > Hello list,
> >
> > I'm working on a Qt supplied boot2qt Yocto build currently based on
> > Zeus that is running on a Raspberry Pi 4. I recently updated the qt
> > version to 5.15.6 and Qt changed something in the Yocto configuration
> > that they are using and now one of the recipes that we use is failing
> > saying that in needs 'virtual/egl' but that it is not provided by any 
> > recipe.
> >
> > In the searching that I have done I have found that the raspberry pi 4
> > is particular on which package supplies the virtual/egl but I haven't
> > seen anything that indicates what I should do to re-enable it.
> >
> > Can anyone tell me what I need to do to enable the correct driver to
> > get virtual/egl provided on the Raspberry Pi 4? Or maybe even better,
> > how I could search through the packages that are enabled on the old
> > and new Yocto trees so that I can figure out what changed between the
> > releases and re-enable the virtual/egl.
> >
>
> it should be provided by userland package if you are using closed source
> graphics driver.
>
> > Best Regards,
> >
> > Greg Wilson-Lindberg
> >
> >
> >
> > 
> >

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54960): https://lists.yoctoproject.org/g/yocto/message/54960
Mute This Topic: https://lists.yoctoproject.org/mt/86076611/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[yocto] Yocto Project Status WW40`21

2021-10-05 Thread Stephen Jolley
Current Dev Position: YP 3.4 M4

Next Deadline: 4th Oct. 2021 YP 3.4 M4 build

 

Next Team Meetings:

*   Bug Triage meeting Thursday Oct. 7th at 7:30am PDT (

https://zoom.us/j/454367603?pwd=ZGxoa2ZXL3FkM3Y0bFd5aVpHVVZ6dz09)
*   Monthly Project Meeting Tuesday Oct. 5th at 8am PDT (

https://zoom.us/j/990892712?pwd=cHU1MjhoM2x6ck81bkcrYjRrcmJsUT09
 )
*   Weekly Engineering Sync Tuesday Oct. 12th at 8am PDT (

https://zoom.us/j/990892712?pwd=cHU1MjhoM2x6ck81bkcrYjRrcmJsUT09
 )
*   Twitch -  See https://www.twitch.tv/theyoctojester

 

Key Status/Updates:

*   The final 3.4 build is now due.
*   We should be in a reasonable position and ready for the 3.4 build,
except for the SOURCE_DATE_EPOCH corruption issues we're seeing. Once those
issues and the related sstate reuse issues are fixed, we'll build 3.4. At
this point there are other patches but they're causing failures and clearly
aren't ready for merging.
*   There continues to be an sstate reuse issue where native sstate on
aarch64 and x86_64 hosts isn't generating correct hashes when combined with
hash equivalence.
*   Intermittent issues took a significant rise last week as SWAT caught
up with the backlog of issues. Help is very much welcome on these issues.
You can see the list of failures we're continuing to see by searching for
the "AB-INT" tag in bugzilla:

https://bugzilla.yoctoproject.org/buglist.cgi?quicksearch=AB-INT

 

Ways to contribute:

*   There are bugs identified as possible for newcomers to the project:

https://wiki.yoctoproject.org/wiki/Newcomers
*   There are bugs that are currently unassigned for YP 3.4. See:

https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium.2B_3.4_Unassigned_Enhan
cements.2FBugs
*   We'd welcome new maintainers for recipes in OE-Core. Please see the
list at:

http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/conf/distro/include/main
tainers.inc and discuss with the existing maintainer, or ask on the OE-Core
mailing list. We will likely move a chunk of these to "Unassigned" soon to
help facilitate this.

 

YP 3.4 Milestone Dates:

*   YP 3.4 M4 build date 2021/10/04
*   YP 3.4 M4 Release date 2021/10/29

 

Tracking Metrics:

*   WDD 2671 (last week 2676) (

https://wiki.yoctoproject.org/charts/combo.html)
*   OE-Core/Poky Patch Metrics

*   Total patches found: 1318 (last week 1309)
*   Patches in the Pending State: 488 (37%) [last week 484 (37%)]

 

The Yocto Project's technical governance is through its Technical Steering
Committee, more information is available at:

 
https://wiki.yoctoproject.org/wiki/TSC

 

The Status reports are now stored on the wiki at:

https://wiki.yoctoproject.org/wiki/Weekly_Status

 

[If anyone has suggestions for other information you'd like to see on this
weekly status update, let us know!]

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

*Cell:(208) 244-4460

* Email:  sjolley.yp...@gmail.com
 

 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54959): https://lists.yoctoproject.org/g/yocto/message/54959
Mute This Topic: https://lists.yoctoproject.org/mt/86096064/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [yocto] [meta-zephyr 0/2] add support of the zephyr-openamp-rsc-table sample on STM32MP157

2021-10-05 Thread Arnaud Pouliquen
Hello Saini,

On 10/5/21 9:08 AM, Saini, Naveen Kumar wrote:
> This is only cover letter, I do not see patches on mailing list..

Yes something strange, they are not listed on same page of the archive on
https://lists.yoctoproject.org/

Patch 1/2 and patch 2/2 associated with this one are visible in the Yocto 
archive:

link to the patches on mail-archive.com:
https://www.mail-archive.com/yocto@lists.yoctoproject.org/msg07088.html
https://www.mail-archive.com/yocto@lists.yoctoproject.org/msg07089.html

Please tell me if you need that I resend the series.

Regards,
Arnaud


> 
> Regards,
> Naveen
> 
>> -Original Message-
>> From: yocto@lists.yoctoproject.org  On
>> Behalf Of Arnaud Pouliquen
>> Sent: Wednesday, September 29, 2021 5:41 PM
>> To: yocto@lists.yoctoproject.org
>> Cc: Kumar Gala ; Kevin Townsend
>> 
>> Subject: [yocto] [meta-zephyr 0/2] add support of the zephyr-openamp-rsc-
>> table sample on STM32MP157
>>
>> Add capability to genereate the "zephyr-openamp-rsc-table" sample in yocto
>> build.
>>
>> This example demonstrates inter-processor communication based on a
>> resource table, with the objective of responding to the Linux kernel rpmsg
>> sample.
>>
>> This sample is compatible with the stm32mp157c_dk2 board.
>> The support of the board is also added in this series.
>>
>> Arnaud Pouliquen (2):
>>   conf: machine: add stm32mp157c-dk2 support
>>   zephyr-kernel: add openamp-rsc-table sample
>>
>>  conf/machine/stm32mp157c-dk2.conf  |  8 
>>  .../zephyr-kernel/zephyr-openamp-rsc-table.bb  | 10 ++
>>  2 files changed, 18 insertions(+)
>>  create mode 100644 conf/machine/stm32mp157c-dk2.conf  create mode
>> 100644 recipes-kernel/zephyr-kernel/zephyr-openamp-rsc-table.bb
>>
>> --
>> 2.17.1
> 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54958): https://lists.yoctoproject.org/g/yocto/message/54958
Mute This Topic: https://lists.yoctoproject.org/mt/85944703/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[yocto] file package dependency

2021-10-05 Thread Timur
Hi, I'm building a yocto release from the thud branch. The size of the 
OS image is very critical, so I need to remove as much as I can. Looking 
at the dependency information, I can see that the "file" package is not 
required by any other package, but yet it is installed. I really have to 
remove this package because it is quite large with its magic database, 
but I can't find who is installing it and why.


--
Timur Aydın
TEL: 536 939 65 88


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54956): https://lists.yoctoproject.org/g/yocto/message/54956
Mute This Topic: https://lists.yoctoproject.org/mt/86091587/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [yocto] Enabling Websockets in Mosquitto in yocto zeus #zeus

2021-10-05 Thread Nicolas Jeker
On Fri, 2021-10-01 at 03:45 -0700, poorn...@elmeasure.com wrote:
> Greetings !
> 
> I could able to add Mosquitto in Yocto Zeus , but as default websockets
> is disabled in Mosquitto . Can anyone help me how to enable websockets
> in Mosquitto in yocto zeus.
> 

There's a 'websockets' PACKAGECONFIG for the mosquitto recipe. You can
read more about how to change PACKAGECONFIGs in the documentation [1].

Be aware that since yocto dunfell, the websockets PACKAGECONFIG is
enabled by default, so you can remove it if you update to a newer
version in the future.

[1]:
https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#var-PACKAGECONFIG

> Thanks in Advance
> 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54955): https://lists.yoctoproject.org/g/yocto/message/54955
Mute This Topic: https://lists.yoctoproject.org/mt/85995510/21656
Mute #zeus:https://lists.yoctoproject.org/g/yocto/mutehashtag/zeus
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [yocto] [meta-zephyr 0/2] add support of the zephyr-openamp-rsc-table sample on STM32MP157

2021-10-05 Thread Naveen Saini
This is only cover letter, I do not see patches on mailing list..

Regards,
Naveen

> -Original Message-
> From: yocto@lists.yoctoproject.org  On
> Behalf Of Arnaud Pouliquen
> Sent: Wednesday, September 29, 2021 5:41 PM
> To: yocto@lists.yoctoproject.org
> Cc: Kumar Gala ; Kevin Townsend
> 
> Subject: [yocto] [meta-zephyr 0/2] add support of the zephyr-openamp-rsc-
> table sample on STM32MP157
> 
> Add capability to genereate the "zephyr-openamp-rsc-table" sample in yocto
> build.
> 
> This example demonstrates inter-processor communication based on a
> resource table, with the objective of responding to the Linux kernel rpmsg
> sample.
> 
> This sample is compatible with the stm32mp157c_dk2 board.
> The support of the board is also added in this series.
> 
> Arnaud Pouliquen (2):
>   conf: machine: add stm32mp157c-dk2 support
>   zephyr-kernel: add openamp-rsc-table sample
> 
>  conf/machine/stm32mp157c-dk2.conf  |  8 
>  .../zephyr-kernel/zephyr-openamp-rsc-table.bb  | 10 ++
>  2 files changed, 18 insertions(+)
>  create mode 100644 conf/machine/stm32mp157c-dk2.conf  create mode
> 100644 recipes-kernel/zephyr-kernel/zephyr-openamp-rsc-table.bb
> 
> --
> 2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54954): https://lists.yoctoproject.org/g/yocto/message/54954
Mute This Topic: https://lists.yoctoproject.org/mt/85944703/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [yocto] [meta-security,dunfell][PATCH] recipes-security/fscrypt: Add fscrypt .bb file

2021-10-05 Thread Bhupesh Sharma
Hello Armin,

Many thanks for your review.

On Sun, 26 Sept 2021 at 03:01, akuster808  wrote:
>
>
>
> On 9/19/21 12:19 PM, Bhupesh Sharma wrote:
> > fscrypt is a high-level tool for the management of Linux
> > filesystem encryption. fscrypt manages metadata, key generation,
> > key wrapping, PAM integration, and provides a uniform interface
> > for creating and modifying encrypted directories.
> >
> > Add recipe for the same in 'recipes-security'.
>
> Was this a double post? or a V2?

Sorry for the double post, but since I had some issues subscribing to
the OE-list, my first attempt to post was not accepted by the mailing
list server.

> I follow the OE/YP Stable process and this appears to be adding a new
> package to a stable release which is not allowed..  I have no issue
> taking it for Master.

Sure. I realized my mistake later-on. I should have sent it for the
'master' branch and not stable / dunfell. Can you please consider
taking this into the 'master' branch, or should I send the patch
separately.

Thanks and sorry for the late reply,
Bhupesh

> -armin
> >
> > Signed-off-by: Bhupesh Sharma 
> > ---
> >  recipes-security/fscrypt/fscrypt_1.0.0.bb | 49 +++
> >  1 file changed, 49 insertions(+)
> >  create mode 100644 recipes-security/fscrypt/fscrypt_1.0.0.bb
> >
> > diff --git a/recipes-security/fscrypt/fscrypt_1.0.0.bb 
> > b/recipes-security/fscrypt/fscrypt_1.0.0.bb
> > new file mode 100644
> > index 000..a70d310
> > --- /dev/null
> > +++ b/recipes-security/fscrypt/fscrypt_1.0.0.bb
> > @@ -0,0 +1,49 @@
> > +SUMMARY = "fscrypt is a high-level tool for the management of Linux 
> > filesystem encryption"
> > +DESCIPTION = "fscrypt manages metadata, key generation, key wrapping, PAM 
> > integration, \
> > +and provides a uniform interface for creating and modifying encrypted 
> > directories. For \
> > +a small, low-level tool that directly sets policies, see fscryptctl \
> > +(https://github.com/google/fscryptcl)."
> > +HOMEPAGE = "https://github.com/google/fscrypt;
> > +SECTION = "base"
> > +LICENSE = "Apache-2.0"
> > +LIC_FILES_CHKSUM = 
> > "file://src/${GO_IMPORT}/LICENSE;md5=3b83ef96387f14655fc854ddc3c6bd57"
> > +
> > +BBCLASSEXTEND = "native nativesdk"
> > +
> > +# fscrypt depends on go and libpam
> > +DEPENDS += "go-dep-native libpam"
> > +
> > +SRCREV = "92b1e9a8670ccd3916a7d24a06cab1e4c9815bc4"
> > +SRC_URI = "git://github.com/google/fscrypt.git"
> > +GO_IMPORT = "import"
> > +
> > +S = "${WORKDIR}/git"
> > +
> > +inherit go
> > +inherit goarch
> > +
> > +do_compile() {
> > + export GOARCH=${TARGET_GOARCH}
> > + export GOROOT="${STAGING_LIBDIR_NATIVE}/${TARGET_SYS}/go"
> > + export GOPATH="${WORKDIR}/git"
> > +
> > + # Pass the needed cflags/ldflags so that cgo
> > + # can find the needed headers files and libraries
> > + export CGO_ENABLED="1"
> > + export CGO_CFLAGS="${CFLAGS} --sysroot=${STAGING_DIR_TARGET}"
> > + export CGO_LDFLAGS="${LDFLAGS} --sysroot=${STAGING_DIR_TARGET}"
> > +
> > + cd ${S}/src/${GO_IMPORT}
> > + oe_runmake
> > +
> > + # Golang forces permissions to 0500 on directories and 0400 on files 
> > in
> > + # the module cache which prevents us from easily cleaning up the build
> > + # directory. Let's just fix the permissions here so we don't have to
> > + # hack the clean tasks.
> > + chmod -R u+w ${S}/pkg/mod
> > +}
> > +
> > +do_install() {
> > + install -d ${D}/${bindir}
> > + install ${S}/src/${GO_IMPORT}/bin/fscrypt ${D}/${bindir}/fscrypt
> > +}
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54953): https://lists.yoctoproject.org/g/yocto/message/54953
Mute This Topic: https://lists.yoctoproject.org/mt/85725373/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-