For bonus fun we could regularly run the test with sstate mirrors set: it should build an image entirely from sstate as the AB just built it.  A build without sstate would be essential to actually test, but would take a lot of time, so likely shouldn't be something that is done regularly, just as part of the milestone QA maybe?

*** Bug 10974 has been marked as a duplicate of this bug. ***

I would like to work on this bug.

Hi Aditya,
That's great news. It's not a small task but there is some work to build on.


See:

meta/recipes-core/packagegroups/packagegroup-core-buildessential.bb
meta/recipes-core/packagegroups/packagegroup-self-hosted.bb

You might send a commit to have self-hosted use the list in
core-buildessential since it looks like each package listed in buildessential is
also listed in self-hosted:

# Slow but clear pipeline
oe-core.git on master

$ rg "^   " meta/recipes-core/packagegroups/packagegroup-core-buildessential.bb | cut -d" " -f 5| rg [a-z] > /tmp/core-be-list.txt


❯ for i in `cat /tmp/core-be-list.txt`; do echo $i; grep $i meta/recipes-core/packagegroups/packagegroup-self-hosted.bb; done
autoconf
    autoconf \
automake
    automake \
binutils
    binutils \
    binutils-symlinks \
binutils-symlinks
    binutils-symlinks \
cpp
    cpp \
    cpp-symlinks \
cpp-symlinks
    cpp-symlinks \
gcc
    gcc \
    gcc-symlinks \
gcc-symlinks
    gcc-symlinks \
g++
    g++ \
    g++-symlinks \
g++-symlinks
    g++-symlinks \
gettext
    gettext \
    gettext-runtime \
make
    automake \
    make \
libstdc++
    libstdc++ \
    libstdc++-dev \
libstdc++-dev
    libstdc++-dev \
libtool
    libtool \
pkgconfig
    pkgconfig \

Aside from that minor change, it might be good to put a plan together 
to say how you're going to approach this task. It's pretty simple mechanically
but there are some decisions that should be agreed on from the start.
Off-hand, topics include:
1. Do you use bitbake-setup in the test class / on target ?
2. Does the target do the git clone of bitbake over the network or
   are it and oe-core packaged at build-time somehow.
3. Start with qemux86-64, then qemuarm64, then maybe qemuriscv64 targets.

There's probably more so start some discussion on the email list and/or
in the tech call on Tuesdays if you can/want to join. I'm probably over-planning
this so just come up with a brief outline initially.

Hi,

Thanks for the pointers and the detailed guidance — this is really helpful.

I’d be interested in working on this bug. The suggestion about reusing
packagegroup-core-buildessential within packagegroup-self-hosted makes sense,
and I can look into preparing a patch for that as an initial improvement.

Regarding the larger task, I agree it would be useful to start with a basic
plan. My initial approach would be:

1. Begin with a simple selftest that validates building a Poky target
   (starting with qemux86-64).
2. Evaluate using bitbake-setup within the test environment.
3. Start with cloning poky/bitbake on the target over the network for
   simplicity, and then explore alternatives such as packaging sources
   at build time if needed.
4. Extend testing gradually to other targets such as qemuarm64 and
   qemuriscv64.

I’ll refine this further and share an outline for feedback before
moving ahead with implementation.

Thanks again for the guidance.

Regards,
Aditya

Hi,

After reviewing the scope and discussions around this bug, it looks like
this involves a broader implementation effort and will require more time
for proper design and agreement on approach.

At this point, I would like to temporarily step back from working on this
bug and focus on another issue that is more suitable for my current stage,
so I can continue contributing while building more experience.

I plan to return to this after completing that work and gaining a deeper
understanding.

Thanks for the guidance so far.

Regards,
Aditya