16016 2025-10-16 15:34:10 +0000 Add test case to verify that Poky can build poky 2026-06-08 05:52:01 +0000 1 1 10 QA/Testing Functional (self) Testing oe-selftest unspecified x86 Multiple NEW Medium+ enhancement 6.1 M1 1 ross.burton unassigned adityags2004 antonin.godard brian.avery randy.macleod tim.orling yoann.congal --- --- No (bug/feature does not impact docs) oldest_to_newest 102976 0 ross.burton 2025-10-16 15:34:10 +0000 We should have an automated test to validate that a poky image can build a poky image. Traditionally we have build-appliance-image, but that has a more complicated history (being designed for VirtualBox/VMWare) and isn't tested in any automated manner. I propose a simpler approach: have a standard image that pulls in all the dependencies (git, gcc, etc). Boot that up, use bitbake-setup to grab latest poky, setup DL_DIR to point at the AB mirror for speed, do a build. 102978 1 ross.burton 2025-10-16 15:35:44 +0000 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? 103053 2 ross.burton 2025-10-23 15:14:48 +0000 *** Bug 10974 has been marked as a duplicate of this bug. *** 105590 3 adityags2004 2026-05-27 09:15:27 +0000 I would like to work on this bug. 105672 4 randy.macleod 2026-05-29 14:16:13 +0000 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 \ 105673 5 randy.macleod 2026-05-29 14:36:57 +0000 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. 105683 6 adityags2004 2026-06-01 06:04:13 +0000 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 105769 7 adityags2004 2026-06-08 05:52:01 +0000 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