[yocto] PACKAGECONFIG variable related patches

[Joel Winarske]

What's the idiomatic pattern for applying (a) patch(es) if a PACKAGECONFIG
variable is set?

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

Re: [yocto] [kirkstone] dwarfsrcfiles + rust staticlib

[Joel Winarske]

I sorted it out.  I needed to export RUSTFLAGS like this:

cargo_do_compile:prepend() {
export RUSTFLAGS="--emit=llvm-ir"
}

On Tue, Feb 27, 2024 at 11:01 AM Joel Winarske via lists.yoctoproject.org
 wrote:

> The Rust recipe is located here:
>
> https://github.com/meta-flutter/meta-flutter/blob/jw/rive/recipes-devtools/rive/rive-taffy-ffi_0.3.0.bb
>
> On Tue, Feb 27, 2024 at 7:40 AM Joel Winarske via lists.yoctoproject.org
>  wrote:
>
>> `ar x` returns nothing.
>>
>> $ ar t ./libtaffy_ffi.a
>> taffy_ffi-6a284b6b44182cb3.taffy_ffi.ab6ea036-cgu.0.rcgu.o
>> taffy_ffi-6a284b6b44182cb3.4001iepzo748wc7r.rcgu.o
>> taffy-7cbe31eff8600da4.taffy.328dd793-cgu.0.rcgu.o
>> slotmap-4965e51b30b65dec.slotmap.6af9b30d-cgu.0.rcgu.o
>> std.std.ffc53cd6-cgu.0.rcgu.o
>> std.std.ffc53cd6-cgu.1.rcgu.o
>> std.std.ffc53cd6-cgu.10.rcgu.o
>> std.std.ffc53cd6-cgu.11.rcgu.o
>> std.std.ffc53cd6-cgu.12.rcgu.o
>> std.std.ffc53cd6-cgu.13.rcgu.o
>> std.std.ffc53cd6-cgu.14.rcgu.o
>> std.std.ffc53cd6-cgu.15.rcgu.o
>> std.std.ffc53cd6-cgu.2.rcgu.o
>> std.std.ffc53cd6-cgu.3.rcgu.o
>> std.std.ffc53cd6-cgu.4.rcgu.o
>> std.std.ffc53cd6-cgu.5.rcgu.o
>> std.std.ffc53cd6-cgu.6.rcgu.o
>> std.std.ffc53cd6-cgu.7.rcgu.o
>> std.std.ffc53cd6-cgu.8.rcgu.o
>> std.std.ffc53cd6-cgu.9.rcgu.o
>> panic_unwind-6b59a4f45c60d735.panic_unwind.f600cc85-cgu.0.rcgu.o
>> panic_unwind-6b59a4f45c60d735.panic_unwind.f600cc85-cgu.1.rcgu.o
>> object-2d6fc44f598fbc25.object.40806be7-cgu.0.rcgu.o
>> object-2d6fc44f598fbc25.object.40806be7-cgu.1.rcgu.o
>> object-2d6fc44f598fbc25.object.40806be7-cgu.10.rcgu.o
>> object-2d6fc44f598fbc25.object.40806be7-cgu.11.rcgu.o
>> object-2d6fc44f598fbc25.object.40806be7-cgu.12.rcgu.o
>> object-2d6fc44f598fbc25.object.40806be7-cgu.13.rcgu.o
>> object-2d6fc44f598fbc25.object.40806be7-cgu.14.rcgu.o
>> object-2d6fc44f598fbc25.object.40806be7-cgu.15.rcgu.o
>> object-2d6fc44f598fbc25.object.40806be7-cgu.2.rcgu.o
>> object-2d6fc44f598fbc25.object.40806be7-cgu.3.rcgu.o
>> object-2d6fc44f598fbc25.object.40806be7-cgu.4.rcgu.o
>> object-2d6fc44f598fbc25.object.40806be7-cgu.5.rcgu.o
>> object-2d6fc44f598fbc25.object.40806be7-cgu.6.rcgu.o
>> object-2d6fc44f598fbc25.object.40806be7-cgu.7.rcgu.o
>> object-2d6fc44f598fbc25.object.40806be7-cgu.8.rcgu.o
>> object-2d6fc44f598fbc25.object.40806be7-cgu.9.rcgu.o
>> memchr-c0d6e4e574632eeb.memchr.af0f6cf3-cgu.0.rcgu.o
>> memchr-c0d6e4e574632eeb.memchr.af0f6cf3-cgu.1.rcgu.o
>> memchr-c0d6e4e574632eeb.memchr.af0f6cf3-cgu.10.rcgu.o
>> memchr-c0d6e4e574632eeb.memchr.af0f6cf3-cgu.11.rcgu.o
>> memchr-c0d6e4e574632eeb.memchr.af0f6cf3-cgu.12.rcgu.o
>> memchr-c0d6e4e574632eeb.memchr.af0f6cf3-cgu.13.rcgu.o
>> memchr-c0d6e4e574632eeb.memchr.af0f6cf3-cgu.14.rcgu.o
>> memchr-c0d6e4e574632eeb.memchr.af0f6cf3-cgu.15.rcgu.o
>> memchr-c0d6e4e574632eeb.memchr.af0f6cf3-cgu.2.rcgu.o
>> memchr-c0d6e4e574632eeb.memchr.af0f6cf3-cgu.3.rcgu.o
>> memchr-c0d6e4e574632eeb.memchr.af0f6cf3-cgu.4.rcgu.o
>> memchr-c0d6e4e574632eeb.memchr.af0f6cf3-cgu.5.rcgu.o
>> memchr-c0d6e4e574632eeb.memchr.af0f6cf3-cgu.6.rcgu.o
>> memchr-c0d6e4e574632eeb.memchr.af0f6cf3-cgu.7.rcgu.o
>> memchr-c0d6e4e574632eeb.memchr.af0f6cf3-cgu.8.rcgu.o
>> memchr-c0d6e4e574632eeb.memchr.af0f6cf3-cgu.9.rcgu.o
>> addr2line-b038aec7c65acee8.addr2line.b9ae8a32-cgu.0.rcgu.o
>> addr2line-b038aec7c65acee8.addr2line.b9ae8a32-cgu.1.rcgu.o
>> addr2line-b038aec7c65acee8.addr2line.b9ae8a32-cgu.2.rcgu.o
>> addr2line-b038aec7c65acee8.addr2line.b9ae8a32-cgu.3.rcgu.o
>> addr2line-b038aec7c65acee8.addr2line.b9ae8a32-cgu.4.rcgu.o
>> addr2line-b038aec7c65acee8.addr2line.b9ae8a32-cgu.5.rcgu.o
>> addr2line-b038aec7c65acee8.addr2line.b9ae8a32-cgu.6.rcgu.o
>> addr2line-b038aec7c65acee8.addr2line.b9ae8a32-cgu.7.rcgu.o
>> addr2line-b038aec7c65acee8.addr2line.b9ae8a32-cgu.8.rcgu.o
>> addr2line-b038aec7c65acee8.addr2line.b9ae8a32-cgu.9.rcgu.o
>> gimli-7cd01052d9283c69.gimli.7f321bcb-cgu.0.rcgu.o
>> gimli-7cd01052d9283c69.gimli.7f321bcb-cgu.1.rcgu.o
>> gimli-7cd01052d9283c69.gimli.7f321bcb-cgu.10.rcgu.o
>> gimli-7cd01052d9283c69.gimli.7f321bcb-cgu.11.rcgu.o
>> gimli-7cd01052d9283c69.gimli.7f321bcb-cgu.12.rcgu.o
>> gimli-7cd01052d9283c69.gimli.7f321bcb-cgu.13.rcgu.o
>> gimli-7cd01052d9283c69.gimli.7f321bcb-cgu.14.rcgu.o
>> gimli-7cd01052d9283c69.gimli.7f321bcb-cgu.15.rcgu.o
>> gimli-7cd01052d9283c69.gimli.7f321bcb-cgu.2.rcgu.o
>> gimli-7cd01052d9283c69.gimli.7f321bcb-cgu.3.rcgu.o
>> gimli-7cd01052d9283c69.gimli.7f321bcb-cgu.4.rcgu.o
>> gimli-7cd01052d9283c69.gimli.7f321bcb-cgu.5.rcgu.o

Re: [yocto] [kirkstone] dwarfsrcfiles + rust staticlib

[Joel Winarske]

The Rust recipe is located here:
https://github.com/meta-flutter/meta-flutter/blob/jw/rive/recipes-devtools/rive/rive-taffy-ffi_0.3.0.bb

On Tue, Feb 27, 2024 at 7:40 AM Joel Winarske via lists.yoctoproject.org
 wrote:

> `ar x` returns nothing.
>
> $ ar t ./libtaffy_ffi.a
> taffy_ffi-6a284b6b44182cb3.taffy_ffi.ab6ea036-cgu.0.rcgu.o
> taffy_ffi-6a284b6b44182cb3.4001iepzo748wc7r.rcgu.o
> taffy-7cbe31eff8600da4.taffy.328dd793-cgu.0.rcgu.o
> slotmap-4965e51b30b65dec.slotmap.6af9b30d-cgu.0.rcgu.o
> std.std.ffc53cd6-cgu.0.rcgu.o
> std.std.ffc53cd6-cgu.1.rcgu.o
> std.std.ffc53cd6-cgu.10.rcgu.o
> std.std.ffc53cd6-cgu.11.rcgu.o
> std.std.ffc53cd6-cgu.12.rcgu.o
> std.std.ffc53cd6-cgu.13.rcgu.o
> std.std.ffc53cd6-cgu.14.rcgu.o
> std.std.ffc53cd6-cgu.15.rcgu.o
> std.std.ffc53cd6-cgu.2.rcgu.o
> std.std.ffc53cd6-cgu.3.rcgu.o
> std.std.ffc53cd6-cgu.4.rcgu.o
> std.std.ffc53cd6-cgu.5.rcgu.o
> std.std.ffc53cd6-cgu.6.rcgu.o
> std.std.ffc53cd6-cgu.7.rcgu.o
> std.std.ffc53cd6-cgu.8.rcgu.o
> std.std.ffc53cd6-cgu.9.rcgu.o
> panic_unwind-6b59a4f45c60d735.panic_unwind.f600cc85-cgu.0.rcgu.o
> panic_unwind-6b59a4f45c60d735.panic_unwind.f600cc85-cgu.1.rcgu.o
> object-2d6fc44f598fbc25.object.40806be7-cgu.0.rcgu.o
> object-2d6fc44f598fbc25.object.40806be7-cgu.1.rcgu.o
> object-2d6fc44f598fbc25.object.40806be7-cgu.10.rcgu.o
> object-2d6fc44f598fbc25.object.40806be7-cgu.11.rcgu.o
> object-2d6fc44f598fbc25.object.40806be7-cgu.12.rcgu.o
> object-2d6fc44f598fbc25.object.40806be7-cgu.13.rcgu.o
> object-2d6fc44f598fbc25.object.40806be7-cgu.14.rcgu.o
> object-2d6fc44f598fbc25.object.40806be7-cgu.15.rcgu.o
> object-2d6fc44f598fbc25.object.40806be7-cgu.2.rcgu.o
> object-2d6fc44f598fbc25.object.40806be7-cgu.3.rcgu.o
> object-2d6fc44f598fbc25.object.40806be7-cgu.4.rcgu.o
> object-2d6fc44f598fbc25.object.40806be7-cgu.5.rcgu.o
> object-2d6fc44f598fbc25.object.40806be7-cgu.6.rcgu.o
> object-2d6fc44f598fbc25.object.40806be7-cgu.7.rcgu.o
> object-2d6fc44f598fbc25.object.40806be7-cgu.8.rcgu.o
> object-2d6fc44f598fbc25.object.40806be7-cgu.9.rcgu.o
> memchr-c0d6e4e574632eeb.memchr.af0f6cf3-cgu.0.rcgu.o
> memchr-c0d6e4e574632eeb.memchr.af0f6cf3-cgu.1.rcgu.o
> memchr-c0d6e4e574632eeb.memchr.af0f6cf3-cgu.10.rcgu.o
> memchr-c0d6e4e574632eeb.memchr.af0f6cf3-cgu.11.rcgu.o
> memchr-c0d6e4e574632eeb.memchr.af0f6cf3-cgu.12.rcgu.o
> memchr-c0d6e4e574632eeb.memchr.af0f6cf3-cgu.13.rcgu.o
> memchr-c0d6e4e574632eeb.memchr.af0f6cf3-cgu.14.rcgu.o
> memchr-c0d6e4e574632eeb.memchr.af0f6cf3-cgu.15.rcgu.o
> memchr-c0d6e4e574632eeb.memchr.af0f6cf3-cgu.2.rcgu.o
> memchr-c0d6e4e574632eeb.memchr.af0f6cf3-cgu.3.rcgu.o
> memchr-c0d6e4e574632eeb.memchr.af0f6cf3-cgu.4.rcgu.o
> memchr-c0d6e4e574632eeb.memchr.af0f6cf3-cgu.5.rcgu.o
> memchr-c0d6e4e574632eeb.memchr.af0f6cf3-cgu.6.rcgu.o
> memchr-c0d6e4e574632eeb.memchr.af0f6cf3-cgu.7.rcgu.o
> memchr-c0d6e4e574632eeb.memchr.af0f6cf3-cgu.8.rcgu.o
> memchr-c0d6e4e574632eeb.memchr.af0f6cf3-cgu.9.rcgu.o
> addr2line-b038aec7c65acee8.addr2line.b9ae8a32-cgu.0.rcgu.o
> addr2line-b038aec7c65acee8.addr2line.b9ae8a32-cgu.1.rcgu.o
> addr2line-b038aec7c65acee8.addr2line.b9ae8a32-cgu.2.rcgu.o
> addr2line-b038aec7c65acee8.addr2line.b9ae8a32-cgu.3.rcgu.o
> addr2line-b038aec7c65acee8.addr2line.b9ae8a32-cgu.4.rcgu.o
> addr2line-b038aec7c65acee8.addr2line.b9ae8a32-cgu.5.rcgu.o
> addr2line-b038aec7c65acee8.addr2line.b9ae8a32-cgu.6.rcgu.o
> addr2line-b038aec7c65acee8.addr2line.b9ae8a32-cgu.7.rcgu.o
> addr2line-b038aec7c65acee8.addr2line.b9ae8a32-cgu.8.rcgu.o
> addr2line-b038aec7c65acee8.addr2line.b9ae8a32-cgu.9.rcgu.o
> gimli-7cd01052d9283c69.gimli.7f321bcb-cgu.0.rcgu.o
> gimli-7cd01052d9283c69.gimli.7f321bcb-cgu.1.rcgu.o
> gimli-7cd01052d9283c69.gimli.7f321bcb-cgu.10.rcgu.o
> gimli-7cd01052d9283c69.gimli.7f321bcb-cgu.11.rcgu.o
> gimli-7cd01052d9283c69.gimli.7f321bcb-cgu.12.rcgu.o
> gimli-7cd01052d9283c69.gimli.7f321bcb-cgu.13.rcgu.o
> gimli-7cd01052d9283c69.gimli.7f321bcb-cgu.14.rcgu.o
> gimli-7cd01052d9283c69.gimli.7f321bcb-cgu.15.rcgu.o
> gimli-7cd01052d9283c69.gimli.7f321bcb-cgu.2.rcgu.o
> gimli-7cd01052d9283c69.gimli.7f321bcb-cgu.3.rcgu.o
> gimli-7cd01052d9283c69.gimli.7f321bcb-cgu.4.rcgu.o
> gimli-7cd01052d9283c69.gimli.7f321bcb-cgu.5.rcgu.o
> gimli-7cd01052d9283c69.gimli.7f321bcb-cgu.6.rcgu.o
> gimli-7cd01052d9283c69.gimli.7f321bcb-cgu.7.rcgu.o
> gimli-7cd01052d9283c69.gimli.7f321bcb-cgu.8.rcgu.o
> gimli-7cd01052d9283c69.gimli.7f321bcb-cgu.9.rcgu.o
> rustc_demangle-e53ade3145326c47.rustc_demangle.625b5e5b-cgu.0.rcgu.o
> rustc_demangle-e53ade3145326c47.rustc_demangle.625b5e5b-cgu.1.rcgu.o
> rustc_demangle-e53ade3145326c47.rustc_demangle.625b5e5b-cgu.10.rcgu.o
> rustc_demangle-e53ade3145326c47.rustc_demangle.625b5e5b-cgu.11.rcgu.o
> rustc_demangle-e53ade3145326c47.rustc_demangle.625b5e5b

Re: [yocto] [kirkstone] dwarfsrcfiles + rust staticlib

[Joel Winarske]

-cgu.98.rcgu.o
compiler_builtins-8cb3deaee7783e49.compiler_builtins.2ade58f2-cgu.99.rcgu.o



On Sat, Feb 24, 2024 at 6:06 PM Khem Raj  wrote:

> try to run ar x on the .a file and see what objects it contains.
>
> On Fri, Feb 23, 2024 at 5:51 PM Joel Winarske 
> wrote:
> >
> > Running readelf -h on the file does work and it shows that it is indeed
> the correct machine architecture
> >
> > ELF Header:
> >   Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
> >   Class: ELF64
> >   Data:  2's complement, little endian
> >   Version:   1 (current)
> >   OS/ABI:UNIX - System V
> >   ABI Version:   0
> >   Type:  REL (Relocatable file)
> >   Machine:   AArch64
> >   Version:   0x1
> >   Entry point address:   0x0
> >   Start of program headers:  0 (bytes into file)
> >   Start of section headers:  201744 (bytes into file)
> >   Flags: 0x0
> >   Size of this header:   64 (bytes)
> >   Size of program headers:   0 (bytes)
> >   Number of program headers: 0
> >   Size of section headers:   64 (bytes)
> >   Number of section headers: 165
> >   Section header string table index: 1
> >
> >
> > On Fri, Feb 23, 2024 at 5:40 PM Joel Winarske 
> wrote:
> >>
> >> I'm hitting qa issue when attempting to install a archive file built
> with Rust:
> >>
> >> dwarfsrcfiles:
> /home/joel/agl/raspberrypi4/tmp/work/aarch64-agl-linux/rive-taffy-ffi/0.3.0-r0/package/usr/lib/taffy_ffi/libtaffy_ffi.a:
> not a valid ELF file
> >>
> >> I can link this same archive file with C code and the executable runs.
> It's a valid archive.
> >>
> >> Any suggestions?
> >
> >
> > 
> >
>

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

Re: [yocto] [kirkstone] dwarfsrcfiles + rust staticlib

[Joel Winarske]

Running readelf -h on the file does work and it shows that it is indeed the
correct machine architecture

ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
  Class: ELF64
  Data:  2's complement, little endian
  Version:   1 (current)
  OS/ABI:UNIX - System V
  ABI Version:   0
  Type:  REL (Relocatable file)
  Machine:   AArch64
  Version:   0x1
  Entry point address:   0x0
  Start of program headers:  0 (bytes into file)
  Start of section headers:  201744 (bytes into file)
  Flags: 0x0
  Size of this header:   64 (bytes)
  Size of program headers:   0 (bytes)
  Number of program headers: 0
  Size of section headers:   64 (bytes)
  Number of section headers: 165
  Section header string table index: 1


On Fri, Feb 23, 2024 at 5:40 PM Joel Winarske 
wrote:

> I'm hitting qa issue when attempting to install a archive file built with
> Rust:
>
> dwarfsrcfiles:
> /home/joel/agl/raspberrypi4/tmp/work/aarch64-agl-linux/rive-taffy-ffi/0.3.0-r0/package/usr/lib/taffy_ffi/libtaffy_ffi.a:
> not a valid ELF file
>
> I can link this same archive file with C code and the executable runs.
> It's a valid archive.
>
> Any suggestions?
>

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

[yocto] [kirkstone] dwarfsrcfiles + rust staticlib

[Joel Winarske]

I'm hitting qa issue when attempting to install a archive file built with
Rust:

dwarfsrcfiles:
/home/joel/agl/raspberrypi4/tmp/work/aarch64-agl-linux/rive-taffy-ffi/0.3.0-r0/package/usr/lib/taffy_ffi/libtaffy_ffi.a:
not a valid ELF file

I can link this same archive file with C code and the executable runs.
It's a valid archive.

Any suggestions?

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

[yocto] Rootless Podman

[Joel Winarske]

Anyone successfully building using Rootless Podman?

I'm seeing a variety of strange issues.

My baseline podman config:
--user 1001:1001
--ipc host
--privileged
--security-opt label=disable
--pid host
--userns keep-id
--ulimit host
--mount type=devpts,destination=/dev/pts
--security-opt label=disable
--group-add keep-groups

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

Re: [yocto] Mold linker

[Joel Winarske]

Oh cool!

I'll run some tests on a few builds.

Thanks for pointing that out.


On Thu, Feb 16, 2023 at 12:42 PM Ross Burton  wrote:

> On 15 Feb 2023, at 05:35, Joel Winarske via lists.yoctoproject.org
>  wrote:
> >
> > Has anyone played around with the mold linker?
> >
> > https://github.com/rui314/mold
> >
> >
> > Curious what the build time difference might be on a large multi-core
> machine.
>
> I have a branch in poky-contrib:ross/mold.  It’s been blindly updated to
> the latest release but not tested, but the wins were not as impressive as
> one would hope for most builds.
>
> Worth keeping an eye on though, and if you’re interested then my branch
> would be a good starting point, at least for showing where work to oe-core
> needs to be done to generalise the linker choice further.
>
> Ross

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

[yocto] Mold linker

[Joel Winarske]

Has anyone played around with the mold linker?

https://github.com/rui314/mold


Curious what the build time difference might be on a large multi-core
machine.


Joel

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

Re: [yocto] [meta-raspberrypi] Is Preempt-rt still supported in master / latest releases?

[Joel Winarske]

I created an issue:
https://github.com/agherzan/meta-raspberrypi/issues/1147

I would use Kuzemko Aleksandr's solution in bbappend until there is support
in meta-raspberrypi.

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

Re: [yocto] [meta-raspberrypi] Is Preempt-rt still supported in master / latest releases?

[Joel Winarske]

Hi,

You should open issue with the upstream layer referencing this dialog:
https://github.com/agherzan/meta-raspberrypi

Joel

On Thu, Feb 2, 2023, 11:18 PM Carles Sole via lists.yoctoproject.org
 wrote:

> Hello Joel,
>
> I do get the same, but my understanding is that the RT features are not
> enabled. I would expect to get:
>
>   Linux raspberrypi4-64 5.15.34-v8 #1 SMP PREEMPT *RT* Tue Apr 19
> 19:21:26 UTC 2022 aarch64 aarch64 aarch64 GNU/Linux
>
> When I check the .config file in the work folder CONFIG_PREEMPT=y is set
> but I would expect to see CONFIG_PREEMPT_RT=y instead.
>
> That is what you get for rpi4 32 bit as mentioned by Aleksandr above. Is
> my understanding wrong?
> 
>
>

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

Re: [yocto] [meta-raspberrypi] Is Preempt-rt still supported in master / latest releases?

[Joel Winarske]

In the case of kirkstone, this is what I get using `LINUX_KERNEL_TYPE =
"preempt-rt"`:

Linux raspberrypi4-64 5.15.34-v8 #1 SMP PREEMPT Tue Apr 19 19:21:26 UTC
2022 aarch64 aarch64 aarch64 GNU/Linux

I've experienced KERNEL_FEATURE conflicts using meta-virtualization with
DISTRO_FEATURES += "virtualization kvm" with meta-raspberrypi.  Where the
fragment applied is not compatible with Aarch64, and it just disables the
linux-raspberrypi default config.  It's quite possible you are also
experiencing something similar.  I would check the kernel build logs and
see what fragments are being applied, and if there are any complaints with
any of them.  The error may be a single line in a log file, and not
entirely descriptive.  More context here:
https://github.com/agherzan/meta-raspberrypi/pull/1141

Working CI job:
https://github.com/meta-flutter/meta-flutter/blob/kirkstone/.github/workflows/kirkstone-rpi4-64-vulkan.yml

On Thu, Feb 2, 2023 at 2:24 AM Carles Sole via lists.yoctoproject.org
 wrote:

> Hello Joel,
>
> thanks for your reply. I was not aware about this possibility. I have
> tried it and the preemptive rt kernel is built instead of standard
> ("linux-raspberrypi4_64-preempt-rt-build" is available in
> build/work/linux-raspberrypi/...) but still the configuration file does not
> set the CONFIG_PREEMPT_RT=y for raspberrypi4-64, even if a .cfg is added
> using a .bbappend file. So in the end the RT option is not enabled.
>
> Any idea why it works for raspberrypi4 but not for raspberrypi4-64?
>
> Best Regards,
> Carles
> 
>
>

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

Re: [yocto] [meta-raspberrypi] Is Preempt-rt still supported in master / latest releases?

[Joel Winarske]

In kirkstone for example, you build preempt-rt variant by adding to
local.conf:

LINUX_KERNEL_TYPE = "preempt-rt"

Does this no longer work?

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

Re: [yocto] user service autostart

[Joel Winarske]

Like maybe simply:

systemd_postinst_ontarget () {
if [ "${SYSTEMD_AUTO_ENABLE}" = "enable" ]; then
for service in ${FLUTTER_USER_SERVICE_ESCAPED}; do
 su 
systemctl --user enable "$service"
systemctl --user start "$service"
done
fi
}

On Thu, Jul 28, 2022 at 8:00 PM Joel Winarske via lists.yoctoproject.org
 wrote:

> How does one enable a user service for a specific user at postinst?
>
> User service in question is located in ${system_user_unitdir}.
>
> Seems the problem is related to determining what user, which makes sense
> why this combo is not allowed: "systemctl --user --root=..."
>
> I'm figuring this run as root?  Is there a way to have it run for a
> specific user?
> systemd_postinst_ontarget () {
> if [ "${SYSTEMD_AUTO_ENABLE}" = "enable" ]; then
> for service in ${FLUTTER_USER_SERVICE_ESCAPED}; do
> systemctl --user enable "$service"
> systemctl --user start "$service"
> done
> fi
> }
>
> Thanks,
> Joel
>
> 
>
>

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

[yocto] user service autostart

[Joel Winarske]

How does one enable a user service for a specific user at postinst?

User service in question is located in ${system_user_unitdir}.

Seems the problem is related to determining what user, which makes sense
why this combo is not allowed: "systemctl --user --root=..."

I'm figuring this run as root?  Is there a way to have it run for a
specific user?
systemd_postinst_ontarget () {
if [ "${SYSTEMD_AUTO_ENABLE}" = "enable" ]; then
for service in ${FLUTTER_USER_SERVICE_ESCAPED}; do
systemctl --user enable "$service"
systemctl --user start "$service"
done
fi
}

Thanks,
Joel

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

Re: [yocto] Adding systemd to yocto

[Joel Winarske]

Line 30-36 include changes to convert a sysvinit image to systemd.
https://github.com/jwinarske/manifests/blob/honister/conf/rpi64_config#L30



On Thu, Apr 28, 2022, 10:19 AM Edgar Mobile  wrote:

> Greetings,
>
> I tried to add systemd to weston-image-core by adding the following lines
> in local.conf:
>
> DISTRO_FEATURES:append = " systemd" VIRTUAL-RUNTIME_init_manager =
> "systemd"
>
> And indeed, bitbake seems to use them in somve way:
>
> DISTRO_FEATURES="acl alsa argp bluetooth debuginfod ext2 ipv4 ipv6
> largefile pcmcia usbgadget usbhost wifi xattr nfs zeroconf pci 3g nfc x11
> vfat seccomp largefile opengl ptest multiarch wayland vulkan systemd\"
> VIRTUAL-RUNTIME_init_manager = \"systemd pulseaudio sysvinit
> gobject-introspection-data ldconfig"
> POKY_DEFAULT_DISTRO_FEATURES="largefile opengl ptest multiarch wayland
> vulkan"
>
> However, if I start the system in qemu none of  the expected systemd
> binaries like systemd, systemd-journal etc. is present. Did I miss
> something?
>
> Regards
>
> 
>
>

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

Re: [yocto] NPM support on Dunfell

[Joel Winarske]

The takeaways using inherit npm:

1. Does not support 'scoped packages'

2. fetching is not multi-threaded.  A NPM based recipe will run uni-proc
with a considerable amount of overhead; each package is pulled and cached
independently.  Whereas "npm install" or "npm ci" runs multi-threaded.

For my use case I used base.bbclass, and implemented it all manually.  The
downside with this approach is there is no long term support via DL_DIR.

A reference for others that might hit this:
https://github.com/meta-webthings/meta-webthings/blob/dunfell/recipes/webthings-gateway/webthings-gateway_git.bb

Cheers,
Joel


On Mon, Apr 11, 2022 at 7:18 PM Joel Winarske 
wrote:

> I'm seeing some gaps and performance issues.
>
> Examples:
> 1. Setting NPM_INSTALL_DEV = "1" I am rewarded with:
>
> 169
> <https://github.com/meta-flutter/meta-flutter/runs/5982719348?check_suite_focus=true#step:10:169>npm
> ERR! Could not install from
> "../../__w/meta-flutter/rpi4-drm-dunfell-latest/raspberrypi4-64/tmp/work/aarch64-poky-linux/webthings-gateway/1.0.0+gitAUTOINC+4c600fc973-r0/git/node_modules/@babel/compat-data"
> as it does not contain a package.json file.
> 170
> <https://github.com/meta-flutter/meta-flutter/runs/5982719348?check_suite_focus=true#step:10:170>
>
> The upstream build uses equivalent to:
> npm --user root --cache "${NPM_CACHE}" ci
> ./node_modules/.bin/webpack
> npm --cache "${NPM_CACHE}" prune --production
>
> 2. Running npm_do_configure is taking 48+ minutes.  Granted it's a large
> project, but basically the configure task is running uni-proc.
>
> Who is the POC supporting NPM on Dunfell?
>
> Thanks,
> Joel
>

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

[yocto] NPM support on Dunfell

[Joel Winarske]

I'm seeing some gaps and performance issues.

Examples:
1. Setting NPM_INSTALL_DEV = "1" I am rewarded with:

169
npm
ERR! Could not install from
"../../__w/meta-flutter/rpi4-drm-dunfell-latest/raspberrypi4-64/tmp/work/aarch64-poky-linux/webthings-gateway/1.0.0+gitAUTOINC+4c600fc973-r0/git/node_modules/@babel/compat-data"
as it does not contain a package.json file.
170


The upstream build uses equivalent to:
npm --user root --cache "${NPM_CACHE}" ci
./node_modules/.bin/webpack
npm --cache "${NPM_CACHE}" prune --production

2. Running npm_do_configure is taking 48+ minutes.  Granted it's a large
project, but basically the configure task is running uni-proc.

Who is the POC supporting NPM on Dunfell?

Thanks,
Joel

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

Re: [yocto] Google GN support

[Joel Winarske]

I had to revisit this for Google Flutter LTS support as upstream (Google
Flutter team) wasn't interested in providing tar.xz releases.

We have two working solutions for Flutter gclient as of today.

1. gclient fetcher.  This fetches the project using gclient and archives
the whole source tree.  I call it the gclient snapshot solution.  Downside
is initial fetch time due to archive time, but subsequent build times are
good.  So only really useful if you don't switch versions often.

2. Pre-process project using python script and add cipd fetcher support to
layer.  This script creates an inc file that gets included by a recipe.
Initial fetch time is about 2.5x build time, with similar build times to
gclient fetcher; ~3 minutes, some sub 3 minutes.  The current approach
before this method average build times were ~6 minutes.  So this approach
improves build time, and provides LTS.  It factors out the use of
gclient/depot_tools in the fetch process.

gclient_bitbake.py.  The script generates a do_run_hooks task using gn
conditionals.
*
https://github.com/meta-flutter/meta-flutter/blob/jw/lts/scripts/gclient_bitbake.py

script output
*
https://github.com/meta-flutter/meta-flutter/blob/jw/lts/conf/include/flutter-engine_2.10.3.inc

cipd:// fetcher impl:
*
https://github.com/meta-flutter/meta-flutter/blob/jw/lts/classes/cipd.bbclass
* https://github.com/meta-flutter/meta-flutter/blob/jw/lts/lib/cipd.py

It currently only works out of the box for the flutter project, but I did
use it to create a recipe for luci-go -> cipd.
*
https://github.com/meta-flutter/meta-flutter/blob/jw/lts/recipes-devtools/luci-go/luci-go-native_git.bb

I mocked up changes to support the v8 project; see gaps for generic
support.  It does require dynamically compiling python code to manage
conditionals, and needs a bit more work.  After which python_bitbake.py
should work for any gclient based project.

gs:// fetcher (Google Storage) support is also planned.  So in cases which
download google storage artifacts in hook, it would allow moving that to
SRC_URI as gs:// element for LTS scenario.

If anyone finds this useful/interesting or they want to collaborate on
improvements let me know.

I do think cipd:// fetcher support would be a good addition to oe-core.


Joel

On Tue, Oct 5, 2021 at 3:55 PM Joel Winarske via lists.yoctoproject.org
 wrote:

>
> > 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 (#56413): https://lists.yoctoproject.org/g/yocto/message/56413
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] [dunfell] hidden files/folders in WORKDIR

[Joel Winarske]

I'm finding that if I create files/folders (prefixed with '.') in WORKDIR,
they don't get cleaned up with INHERIT += "rm_work".

Is this a feature or a bug?

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

Re: [yocto] raspberrypi0-2w

[Joel Winarske]

https://github.com/agherzan/meta-raspberrypi/blob/master/conf/machine/raspberrypi0-2w-64.conf

On Thu, Dec 2, 2021 at 7:08 AM safouane maaloul 
wrote:

> Hello, I  writed a conf file  to get the raspberrypi0-2 to work in 32 mode
> to have the camera packages raspivid. It works just fine. But the problem I
> don't have wlan0 interface. I tried everything but I didn't succeed in
> getting to work. Here is my conf file:
>
> #@TYPE: Machine
> #@NAME: RaspberryPi0 2 Wifi Development Board
> #@DESCRIPTION: Machine configuration for the RaspberryPi0 2 Wifi in 32
> bits mode
>
> include conf/machine/raspberrypi3.conf
>
> MACHINEOVERRIDES := "${@'${MACHINEOVERRIDES}'
> .replace(':${MACHINE}',':raspberrypi3:${MACHINE}')}"
>
> MACHINE_EXTRA_RRECOMMENDS += "\
> linux-firmware-rpidistro-bcm43436 \
> linux-firmware-rpidistro-bcm43436s \
> bluez-firmware-rpidistro-bcm43430b0-hcd \
> linux-firmware-rpidistro-bcm43430 \
> "
>
>
>
>
> Best regards,
>
> --
> *SAFOUANE MAALOUL*
>
> *maaloulsafou...@gmail.com *
>
>
> 
>
>

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

Re: [yocto] Building -native with clang

[Joel Winarske]

Thanks, I'll check it out.

This works:

DEPENDS += "\
compiler-rt \
libcxx \
llvm \
"

RUNTIME = "llvm"
TOOLCHAIN = "clang"
PREFERRED_PROVIDER:libgcc = "compiler-rt"

RUNTIME:class-native = "llvm"
TOOLCHAIN:class-native = "clang"
PREFERRED_PROVIDER:libgcc:class-native = "compiler-rt"

On Thu, Nov 18, 2021 at 12:04 PM Khem Raj  wrote:

> Look into chromium recipe
>
> On Thu, Nov 18, 2021 at 11:55 AM Joel Winarske 
> wrote:
> >
> > How do I get a -native recipe to use clang-native?  I have this in my
> recipe, and target variant builds with clang:
> >
> > RUNTIME = "llvm"
> > TOOLCHAIN = "clang"
> > PREFERRED_PROVIDER:libgcc = "compiler-rt"
> >
> > All the environment variables are setup for gcc in the case of -native.
> No sign of clang.
> >
> > This is with honister.
> >
> >
> > Joel
> >
> > 
> >
>

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

[yocto] Building -native with clang

[Joel Winarske]

How do I get a -native recipe to use clang-native?  I have this in my
recipe, and target variant builds with clang:

RUNTIME = "llvm"
TOOLCHAIN = "clang"
PREFERRED_PROVIDER:libgcc = "compiler-rt"

All the environment variables are setup for gcc in the case of -native.  No
sign of clang.

This is with honister.


Joel

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

Re: [yocto] pre-built native only tool for native and nativesdk

[Joel Winarske]

My solution was to use recipe name without `-native`, and simply use empty
packages (no-op) for target.  Only nativesdk- and -native variants have an
affect.  Then add `TOOLCHAIN_HOST_TASK:append = " nativesdk-flutter-sdk"`
to local.conf.

https://github.com/meta-flutter/meta-flutter/blob/honister/recipes-graphics/flutter-apps/flutter-sdk_git.bb

On Tue, Nov 9, 2021 at 3:32 PM Joel Winarske 
wrote:

> Actually by removing `inherit native` and adding -native to the recipe
> name doesn't make it build for native.
>
> On Tue, Nov 9, 2021 at 3:23 PM Joel Winarske 
> wrote:
>
>> To eliminate target option from the recipe I just need to make sure the
>> name of the recipe ends with -native, then removing inherit native works
>> fine.
>>
>> On Tue, Nov 9, 2021 at 2:09 PM Joel Winarske via lists.yoctoproject.org
>>  wrote:
>>
>>> I'm trying to sort out how to install a pre-built host-only tool for
>>> native and nativesdk only.
>>>
>>> Using `inherit native` my-recipe-native and nativesdk-my-recipe both
>>> build fine, only -c populate_sdk generates "rdepends upon non-existent
>>> task do_package_write_rpm".  Looking at native.bbclass it includes
>>> `inherit nopackage` which explains the error.
>>>
>>> If I remove the `inherit native` and update my recipe name to not
>>> include `-native` I can build the -native version, only I can't build
>>> nativesdk-*-native.  A target build is invalid.
>>>
>>> What is the recommended pattern to do this, and is there an example of
>>> this anywhere?
>>>
>>>
>>> Thanks,
>>> Joel
>>>
>>> 
>>>
>>>

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

Re: [yocto] pre-built native only tool for native and nativesdk

[Joel Winarske]

Actually by removing `inherit native` and adding -native to the recipe name
doesn't make it build for native.

On Tue, Nov 9, 2021 at 3:23 PM Joel Winarske 
wrote:

> To eliminate target option from the recipe I just need to make sure the
> name of the recipe ends with -native, then removing inherit native works
> fine.
>
> On Tue, Nov 9, 2021 at 2:09 PM Joel Winarske via lists.yoctoproject.org
>  wrote:
>
>> I'm trying to sort out how to install a pre-built host-only tool for
>> native and nativesdk only.
>>
>> Using `inherit native` my-recipe-native and nativesdk-my-recipe both
>> build fine, only -c populate_sdk generates "rdepends upon non-existent
>> task do_package_write_rpm".  Looking at native.bbclass it includes
>> `inherit nopackage` which explains the error.
>>
>> If I remove the `inherit native` and update my recipe name to not include
>> `-native` I can build the -native version, only I can't build
>> nativesdk-*-native.  A target build is invalid.
>>
>> What is the recommended pattern to do this, and is there an example of
>> this anywhere?
>>
>>
>> Thanks,
>> Joel
>>
>> 
>>
>>

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

Re: [yocto] pre-built native only tool for native and nativesdk

[Joel Winarske]

To eliminate target option from the recipe I just need to make sure the
name of the recipe ends with -native, then removing inherit native works
fine.

On Tue, Nov 9, 2021 at 2:09 PM Joel Winarske via lists.yoctoproject.org
 wrote:

> I'm trying to sort out how to install a pre-built host-only tool for
> native and nativesdk only.
>
> Using `inherit native` my-recipe-native and nativesdk-my-recipe both build
> fine, only -c populate_sdk generates "rdepends upon non-existent task
> do_package_write_rpm".  Looking at native.bbclass it includes `inherit
> nopackage` which explains the error.
>
> If I remove the `inherit native` and update my recipe name to not include
> `-native` I can build the -native version, only I can't build
> nativesdk-*-native.  A target build is invalid.
>
> What is the recommended pattern to do this, and is there an example of
> this anywhere?
>
>
> Thanks,
> Joel
>
> 
>
>

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

[yocto] pre-built native only tool for native and nativesdk

[Joel Winarske]

I'm trying to sort out how to install a pre-built host-only tool for native
and nativesdk only.

Using `inherit native` my-recipe-native and nativesdk-my-recipe both build
fine, only -c populate_sdk generates "rdepends upon non-existent task
do_package_write_rpm".  Looking at native.bbclass it includes `inherit
nopackage` which explains the error.

If I remove the `inherit native` and update my recipe name to not include
`-native` I can build the -native version, only I can't build
nativesdk-*-native.  A target build is invalid.

What is the recommended pattern to do this, and is there an example of this
anywhere?


Thanks,
Joel

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#55293): https://lists.yoctoproject.org/g/yocto/message/55293
Mute This Topic: https://lists.yoctoproject.org/mt/86943509/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

[Joel Winarske]

Hi Greg,

Do you have this in your local.conf?

DISTRO_FEATURES_append = " opengl"

On Tue, Oct 5, 2021, 11:22 AM Greg Wilson-Lindberg 
wrote:

> 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 <
> 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 
> > > 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 (#54978): https://lists.yoctoproject.org/g/yocto/message/54978
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] Google GN support

[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]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] Google GN support

[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]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto][poky][master][PATCH} VirGL: depends on virtual/gbm

[Joel Winarske]

It looks like a Mesa dependency is looming for NVIDIA:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9902

Thanks

On Fri, May 28, 2021 at 1:30 PM Alexander Kanavin 
wrote:

> Thanks, it took me a moment to understand that this still does not mean
> that nvidia supports gbm somehow, somewhere, but rather that virgl needs to
> be explicit about needing gbm.
>
> The patch should be going to the oe-core list.
>
> Alex
>
> On Fri, 28 May 2021 at 21:16, Joel Winarske 
> wrote:
>
>>
>> This addresses cases where the platform doesn't depend on Mesa.  Tegra is
>> one example.
>>
>> From 427d6248379bf37f5522d4bb1013b8c0b7a26b5b Mon Sep 17 00:00:00 2001
>> From: Joel Winarske 
>> Date: Fri, 28 May 2021 12:10:46 -0700
>> Subject: [PATCH] VirGL depends on gbm.h
>>
>> Signed-off-by: Joel Winarske 
>> ---
>>  meta/recipes-graphics/virglrenderer/virglrenderer_0.9.1.bb | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/meta/recipes-graphics/virglrenderer/virglrenderer_0.9.1.bb
>> b/meta/recipes-graphics/virglrenderer/virglrenderer_0.9.1.bb
>> index 3991895823..65bd1af942 100644
>> --- a/meta/recipes-graphics/virglrenderer/virglrenderer_0.9.1.bb
>> +++ b/meta/recipes-graphics/virglrenderer/virglrenderer_0.9.1.bb
>> @@ -8,7 +8,7 @@ HOMEPAGE = "https://virgil3d.github.io/;
>>  LICENSE = "MIT"
>>  LIC_FILES_CHKSUM = "file://COPYING;md5=c81c08eeefd9418fca8f88309a76db10"
>>
>> -DEPENDS = "libdrm virtual/libgl libepoxy"
>> +DEPENDS = "libdrm virtual/libgl virtual/libgbm libepoxy"
>>  SRCREV = "363915595e05fb252e70d6514be2f0c0b5ca312b"
>>  SRC_URI = "git://
>> anongit.freedesktop.org/virglrenderer;branch=branch-0.9.1 \
>> file://0001-meson.build-use-python3-directly-for-python.patch
>> \
>> --
>> 2.30.2
>>
>>
>>
>> 
>>
>>

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

[yocto][poky][master][PATCH} VirGL: depends on virtual/gbm

[Joel Winarske]

This addresses cases where the platform doesn't depend on Mesa.  Tegra is
one example.

>From 427d6248379bf37f5522d4bb1013b8c0b7a26b5b Mon Sep 17 00:00:00 2001
From: Joel Winarske 
Date: Fri, 28 May 2021 12:10:46 -0700
Subject: [PATCH] VirGL depends on gbm.h

Signed-off-by: Joel Winarske 
---
 meta/recipes-graphics/virglrenderer/virglrenderer_0.9.1.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-graphics/virglrenderer/virglrenderer_0.9.1.bb
b/meta/recipes-graphics/virglrenderer/virglrenderer_0.9.1.bb
index 3991895823..65bd1af942 100644
--- a/meta/recipes-graphics/virglrenderer/virglrenderer_0.9.1.bb
+++ b/meta/recipes-graphics/virglrenderer/virglrenderer_0.9.1.bb
@@ -8,7 +8,7 @@ HOMEPAGE = "https://virgil3d.github.io/;
 LICENSE = "MIT"
 LIC_FILES_CHKSUM = "file://COPYING;md5=c81c08eeefd9418fca8f88309a76db10"

-DEPENDS = "libdrm virtual/libgl libepoxy"
+DEPENDS = "libdrm virtual/libgl virtual/libgbm libepoxy"
 SRCREV = "363915595e05fb252e70d6514be2f0c0b5ca312b"
 SRC_URI = "git://anongit.freedesktop.org/virglrenderer;branch=branch-0.9.1
\
file://0001-meson.build-use-python3-directly-for-python.patch \
-- 
2.30.2

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

Re: [yocto] Problem with YOCTO Dunfell and host Fedora 33

[Joel Winarske]

Hi Zoran,

Your cannelloni recipe is set to autorev, meaning it's not locked to a
commit.  So when something changes upstream you have to manage it.

Chances are Canelloni introduced a CMake change which is overwriting
(opposed to appending) one or more variables required for cross compiling.
Perhaps try to cross compile (not a host build) Canelloni by itself without
Yocto involved.  Once that's sorted, then reintroduce yocto.


Joel


On Thu, May 20, 2021, 6:58 AM Zoran  wrote:

> Hello Yocto developers,
>
> I have few problems running the following self proprietary script from
> one of my public git repos:
> https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/yocto-setup.sh
>
> I recall that last time I used the script (I used then Fedora 31), the
> ./yocto setup dunfell worked seamlessly, did setup the environment,
> and upon bitbake -k core-image-minimal completed the tasks without any
> problem.
>
> Now, I am using Fedora 33 (in the meantime I did two Fedora version
> upgrades).
>
> The problem is that while compiling the cannelloni package, the
> following errors were issued (please, look into the attached file
> cmake_problem.txt).
>
> This cmake problem was introduced after switching from Fedora 31 to Fedora
> 33 ?!
>
> Any clue/idea why this is happening??? What is the cause of the problem?
>
> Thank you,
> Zoran
> ___
>
> 
>
>

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

[yocto] git-lfs #dunfell

[joel . winarske]

I am seeing problems in git fetcher using a github repo using lfs + ssh in 
dunfell.

I find if I set "lfs=0" it still attempts to download the lfs objects and 
fails.  Same behavior if "lfs=1".

SRC_URI = 
"git://g...@github.com:/account/cool-thing.git;protocol=ssh;lfs=1;branch=cool_branch"

A suggested workaround by technoweenie here: 
https://github.com/git-lfs/git-lfs/issues/1044

Only git clone via ssh works (pulls lfs objects) fine outside of the yocto tree.

Any ideas?

Thanks,
Joel

git-lfs/ 2. 9. 2 (GitHub; linux amd64; go 1. 13. 5 )
git version 2. 25. 1

$ git-lfs filter-process
Error downloading object: cool-thing/app/lib/agl/aarch64/libfmt.a ( 328664b ): 
Smudge error: Error downloading cool-thing/app/lib/agl/aarch64/libfmt.a ( 
328664b0bd0cad33f28722b9a6ccd5ac9adea4485885bacd35082775e41601d8 ): batch 
request: missing protocol: ""

missing protocol: ""
batch request
github.com/git-lfs/git-lfs/errors.newWrappedError
github.com/git-lfs/git-lfs/errors/types.go: 198
github.com/git-lfs/git-lfs/errors.Wrap
github.com/git-lfs/git-lfs/errors/errors.go: 74
github.com/git-lfs/git-lfs/tq.(*tqClient).Batch
github.com/git-lfs/git-lfs/tq/api.go: 68
github.com/git-lfs/git-lfs/tq.Batch
github.com/git-lfs/git-lfs/tq/api.go: 40
github.com/git-lfs/git-lfs/tq.(*TransferQueue).enqueueAndCollectRetriesFor
github.com/git-lfs/git-lfs/tq/transfer_queue.go: 520
github.com/git-lfs/git-lfs/tq.(*TransferQueue). collectBatches.func1
github.com/git-lfs/git-lfs/tq/transfer_queue.go: 432
runtime.goexit
/usr/lib/go- 1. 13 /src/runtime/asm_amd64.s: 1357
Error downloading cool-thing/app/lib/agl/aarch64/libfmt.a ( 
328664b0bd0cad33f28722b9a6ccd5ac9adea4485885bacd35082775e41601d8 )
github.com/git-lfs/git-lfs/errors.newWrappedError
github.com/git-lfs/git-lfs/errors/types.go: 198
github.com/git-lfs/git-lfs/errors.Wrapf
github.com/git-lfs/git-lfs/errors/errors.go: 85
github.com/git-lfs/git-lfs/lfs.(*GitFilter).downloadFile
github.com/git-lfs/git-lfs/lfs/gitfilter_smudge.go: 115
github.com/git-lfs/git-lfs/lfs.(*GitFilter).Smudge
github.com/git-lfs/git-lfs/lfs/gitfilter_smudge.go: 76
github.com/git-lfs/git-lfs/commands.smudge
github.com/git-lfs/git-lfs/commands/command_smudge.go: 127
github.com/git-lfs/git-lfs/commands.filterCommand
github.com/git-lfs/git-lfs/commands/command_filter_process.go: 118
github.com/spf13/cobra.(*Command).execute
github.com/spf13/cobra/command.go: 766
github.com/spf13/cobra.(*Command).ExecuteC
github.com/spf13/cobra/command.go: 850
github.com/spf13/cobra.(*Command).Execute
github.com/spf13/cobra/command.go: 800
github.com/git-lfs/git-lfs/commands.Run
github.com/git-lfs/git-lfs/commands/run.go: 97
main.main
github.com/git-lfs/git-lfs/git- lfs.go : 33
runtime.main
/usr/lib/go- 1. 13 /src/runtime/proc.go: 203
runtime.goexit
/usr/lib/go- 1. 13 /src/runtime/asm_amd64.s: 1357
Smudge error
github.com/git-lfs/git-lfs/errors.newWrappedError
github.com/git-lfs/git-lfs/errors/types.go: 198
github.com/git-lfs/git-lfs/errors.NewSmudgeError
github.com/git-lfs/git-lfs/errors/types.go: 284
github.com/git-lfs/git-lfs/lfs.(*GitFilter).Smudge
github.com/git-lfs/git-lfs/lfs/gitfilter_smudge.go: 85
github.com/git-lfs/git-lfs/commands.smudge
github.com/git-lfs/git-lfs/commands/command_smudge.go: 127
github.com/git-lfs/git-lfs/commands.filterCommand
github.com/git-lfs/git-lfs/commands/command_filter_process.go: 118
github.com/spf13/cobra.(*Command).execute
github.com/spf13/cobra/command.go: 766
github.com/spf13/cobra.(*Command).ExecuteC
github.com/spf13/cobra/command.go: 850
github.com/spf13/cobra.(*Command).Execute
github.com/spf13/cobra/command.go: 800
github.com/git-lfs/git-lfs/commands.Run
github.com/git-lfs/git-lfs/commands/run.go: 97
main.main
github.com/git-lfs/git-lfs/git- lfs.go : 33
runtime.main
/usr/lib/go- 1. 13 /src/runtime/proc.go: 203
runtime.goexit
/usr/lib/go- 1. 13 /src/runtime/asm_amd64.s: 1357

Current time in UTC:
2020-12-12 15:41:16

ENV:
LocalWorkingDir=/b/lv- 0. 1 
/apps/apps_proc/poky/build/tmp-glibc/work/aarch64-oe-linux/cool-thing/git+AUTOINC+
 3158acc56b -r0/git
LocalGitDir=/b/lv- 0. 1 
/apps/apps_proc/poky/build/tmp-glibc/work/aarch64-oe-linux/cool-thing/git+AUTOINC+
 3158acc56b -r0/git/.git
LocalGitStorageDir=/b/lv- 0. 1 
/apps/apps_proc/poky/build/tmp-glibc/work/aarch64-oe-linux/cool-thing/git+AUTOINC+
 3158acc56b -r0/git/.git
LocalMediaDir=/b/lv- 0. 1 
/apps/apps_proc/poky/build/tmp-glibc/work/aarch64-oe-linux/cool-thing/git+AUTOINC+
 3158acc56b -r0/git/.git/lfs/objects
LocalReferenceDirs=
TempDir=/b/lv- 0. 1 
/apps/apps_proc/poky/build/tmp-glibc/work/aarch64-oe-linux/cool-thing/git+AUTOINC+
 3158acc56b -r0/git/.git/lfs/tmp
ConcurrentTransfers= 3
TusTransfers= false
BasicTransfersOnly= false
SkipDownloadErrors= false
FetchRecentAlways= false
FetchRecentRefsDays= 7
FetchRecentCommitsDays= 0
FetchRecentRefsIncludeRemotes= true
PruneOffsetDays= 3
PruneVerifyRemoteAlways= false
PruneRemoteName=origin
LfsStorageDir=/b/lv- 0. 1 

Re: [yocto] project that builds target and host

[Joel Winarske]

What are some nasty hack options?

The major surgery would be less maintainable.

On Wed, May 13, 2020, 12:51 PM Ross Burton  wrote:

> On Wed, 13 May 2020 at 20:28, Joel Winarske 
> wrote:
> > In this case I already have a Target and Native recipe.  The Project
> generates a Native artifact when building the Target.  Not resolvable
> without major surgery.  This artifact is then required in other Target
> recipes.
>
> A target recipe can't drop files into the native sysroot, so it's
> either nasty hacks or major surgery.
>
> Ross
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#49403): https://lists.yoctoproject.org/g/yocto/message/49403
Mute This Topic: https://lists.yoctoproject.org/mt/74175514/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] project that builds target and host

[Joel Winarske]

Hi,

I have a project that generates a native artifact during the target build.
Both the native and target artifacts are needed for other target recipes.

What's the recommended pattern for handling this?


Thanks,
Joel
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#49384): https://lists.yoctoproject.org/g/yocto/message/49384
Mute This Topic: https://lists.yoctoproject.org/mt/74175514/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] Zeus - Post Build folder corruption #yocto

[Joel Winarske]

Has anyone seen this post build?  Where there are folders created of random 
items?  Some folders have a path deep of 5+.

joel@hammer:/media/joel/SolidState/rpi/rpi4-64$ ls
'!='                       'os.path.join('\'''
bitbake-cookerdaemon.log  'os.path.normpath(d.getVar('\''S'\''))'
cache                     'os.path.normpath(d.getVar('\''WORKDIR'\''))'
conf                      ''\''patches'\'')}'
'${@d.getVar('\''S'\'')'    sstate-cache
else                       tmp
if
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#49051): https://lists.yoctoproject.org/g/yocto/message/49051
Mute This Topic: https://lists.yoctoproject.org/mt/72765331/21656
Mute #yocto: https://lists.yoctoproject.org/mk?hashtag=yocto=6691583
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] python argparse or alternate method

[Joel Winarske]

Hi Konrad,

Thanks, that helps a lot.  It works!  I used straight split() which
prevented the first value from being null.

Yes, I agree less pythonic :)  The only recipe I've seen building gn based
projects is OSSystem's meta-browser/chromium.  I followed it's pattern, as
the Flutter Engine is a derivative of Chrome.

The issue with these large gn based projects is that they're self contained
builds.  A build system within a build system.  I must admit though the
gclient DEPS download scheme is efficient.  I initially looked at parsing
out the DEPs file into a large SRC_URI list, but quickly hit Yocto
serializing them.  Perhaps OE could benefit from tighter integration with
gn.

I'm open to any other alternative approaches.


Cheers,
Joel

On Wed, Apr 1, 2020 at 1:09 PM Konrad Weihmann 
wrote:

> Hi Joel,
>
> okay, I see - although I have to admit the argparse idea looks very weird,
> the error is that according to
>
> https://docs.python.org/3/library/argparse.html#argparse.ArgumentParser.parse_args
> the pkgconfig_args variable should be a list not a single string.
>
> so doing pkgconfig_args = d.getVar("PACKAGECONFIG_CONFARGS").split(" ")
> should fix the issue.
> But from a bitbake perspective you should really think about choosing a
> less pythonic version
>
> Best
>
> Konrad
> On 01.04.20 22:00, Joel Winarske wrote:
>
> Hi Konrad,
>
> I left out the details of the path encoding :)  Effectively I was
> attempting to duplicate get_out_dir() as found here:
> https://github.com/flutter/engine/blob/master/tools/gn
>
> My recipe is here:
> https://github.com/jwinarske/meta-flutter/blob/zeus/recipes-graphics/flutter-engine/flutter-engine_git.bb
>
> Cheers,
> Joel
>
> On Wed, Apr 1, 2020 at 10:46 AM Konrad Weihmann 
> wrote:
>
>> There is a single tick missing, but I'm sure you get the point
>> On 01.04.20 19:37, Konrad Weihmann wrote:
>>
>> What about
>>
>> do_configure() {
>>
>>cd ${@bb.utils.contains('PACKAGECONFIG_CONFARGS', '--verbose',
>> out/verbose', 'out', d)}
>>
>> }
>> On 01.04.20 18:55, Joel Winarske wrote:
>>
>> Hello,
>>
>> I'm trying the below in a recipe.  Bitbake gives me: ERROR: Unable to
>> parse ...: Exited with "2"
>>
>> inherit python3native
>>
>> require utils.inc
>>
>> do_configure() {
>>
>> cd ${@get_out_dir(d)}
>> }
>>
>> (in utils.inc)
>> def get_out_dir(d):
>> import os
>> import argparse
>> pkgconfig_args = d.getVar("PACKAGECONFIG_CONFARGS")
>>
>> parser = argparse.ArgumentParser()
>> parser.add_argument("--verbose", help="increase output verbosity",
>> action="store_true")
>> args = parser.parse_args(pkgconfig_args)
>> if args.verbose:
>> return os.path.join('out', 'verbose')
>>
>> return 'out'
>>
>>
>>
>> What am I doing wrong, or is there a better way?  Seems like it doesn't
>> like "args = parser.parse_args(pkgconfig_args)"
>>
>> The output directory is a combination of the arguments.
>>
>>
>> Thanks!
>> Joel
>>
>>
>> 
>>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#49016): https://lists.yoctoproject.org/g/yocto/message/49016
Mute This Topic: https://lists.yoctoproject.org/mt/72705531/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] python argparse or alternate method

[Joel Winarske]

Hi Konrad,

I left out the details of the path encoding :)  Effectively I was
attempting to duplicate get_out_dir() as found here:
https://github.com/flutter/engine/blob/master/tools/gn

My recipe is here:
https://github.com/jwinarske/meta-flutter/blob/zeus/recipes-graphics/flutter-engine/flutter-engine_git.bb

Cheers,
Joel

On Wed, Apr 1, 2020 at 10:46 AM Konrad Weihmann 
wrote:

> There is a single tick missing, but I'm sure you get the point
> On 01.04.20 19:37, Konrad Weihmann wrote:
>
> What about
>
> do_configure() {
>
>cd ${@bb.utils.contains('PACKAGECONFIG_CONFARGS', '--verbose',
> out/verbose', 'out', d)}
>
> }
> On 01.04.20 18:55, Joel Winarske wrote:
>
> Hello,
>
> I'm trying the below in a recipe.  Bitbake gives me: ERROR: Unable to
> parse ...: Exited with "2"
>
> inherit python3native
>
> require utils.inc
>
> do_configure() {
>
> cd ${@get_out_dir(d)}
> }
>
> (in utils.inc)
> def get_out_dir(d):
> import os
> import argparse
> pkgconfig_args = d.getVar("PACKAGECONFIG_CONFARGS")
>
> parser = argparse.ArgumentParser()
> parser.add_argument("--verbose", help="increase output verbosity",
> action="store_true")
> args = parser.parse_args(pkgconfig_args)
> if args.verbose:
> return os.path.join('out', 'verbose')
>
> return 'out'
>
>
>
> What am I doing wrong, or is there a better way?  Seems like it doesn't
> like "args = parser.parse_args(pkgconfig_args)"
>
> The output directory is a combination of the arguments.
>
>
> Thanks!
> Joel
>
>
> 
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#49013): https://lists.yoctoproject.org/g/yocto/message/49013
Mute This Topic: https://lists.yoctoproject.org/mt/72705531/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-