Hello, a recommendation: try to not be all over the place in your emails. Send one email per issue, and keep it tight and focused. If you have patches and aren't sure about them, push them to a branch somewhere where we can take a pre-look, and someone will suggest further steps.
Alex On Fri, 29 Aug 2025 at 19:33, Joseph Mills via lists.openembedded.org <[email protected]> wrote: > > Hello all, > I’m Joseph, I’m an independent consultant. I just inherited an internal > distro that historically never built a “full distro,” and I’m porting it from > dunfel & kirkstone to scarthgap. The client only needs a BSP subset, but in > my spare time I’m trying to push general fixes back upstream. I have created > a package group that doesn't install anything but does build everything in OE. > > I have found some things when building the clients multilib inteli7 > machine's. A number of packages are not installed to the correct > libdir(/usr/lib vs /usr/lib64). I have noticed that this mainly affects > python modules that are going to sites dir(PYTHON_SITEPACKAGES_DIR). see > https://github.com/openembedded/meta-openembedded/pull/990/files > > Scope / testing > SoC families: > * Intel: core2, corei7 (multi variants), (about 70K steps) > * Atmel: ipac9x25, som9x25, soma5d35, soma5d36(multi variants) (about 45K > steps) > * TI: som5728m, som3354 (about 60K steps) > * Renesas: somrzg2l (multi variants) (about 70K steps) > * Nuvoton: som35d1f(multi variants), (about 70K steps) > * NXP: somimx6(multi variants), somimx8(multi variants) (about 60K steps) > * Nvidia: somagx (about 70K steps) > > Each of the som's have multiple carriers. Lots of device trees :) fun stuff. > > Goals: I have 3 massive build servers. One is my own and the other two are > the clients. > serverA: no sstate to dl builds everything from scratch. > serverB: shares with other servers and developers. > CACHE_PATH = > "/srv/yocto/${DISTRO_CODENAME}-${DISTRO_VERSION}/${RELEASE_TYPE}" > ARCHIVE_PATH ?= > "${DISTRO_CODENAME}-${DISTRO_VERSION}/${RELEASE_TYPE}/${MACHINE}" > DL_DIR = "/srv/yocto/${DISTRO_CODENAME}-${DISTRO_VERSION}/downloads" > SSTATE_DIR = "${CACHE_PATH}/sstate-cache" > BUILDHISTORY_DIR = "${CACHE_PATH}/buildhistory" > PERSISTENT_DIR = "${CACHE_PATH}/cache" > BB_CACHEDIR = "${CACHE_PATH}/parser-cache" > CACHE = "${CACHE_PATH}/startup-cache" > serverC: same as serverB helps with the matrix of the builds. > > The build system is kas and does(now) have full CI/CD (build, deploy-image, > deploy-sdk, deploy-ota) > Handling of Distro features are handled via the machine's file's and kas. > > devkit(som+carrier or SBC) code is open source (MIT). I can share KAS > manifests/build logs if helpful. > > Submission shape > Do you prefer I send these as small series by subsystem (e.g., meta-gnome > first, then meta-python, then meta-oe), or one change at a time? > > Path policy — For multilib cleanups, is moving empty /usr/lib parents in > do_install:append acceptable when ${libdir} is lib64, or is there a stronger > class-level approach you’d like? > > I’m new to posting here, so suggestions on etiquette, scope, and preferred > structure are welcome. > > Another thing I am confused about is devshell. My current workflow(advice > appreciated) > 1) something does not build. I clean the package/recipe. > 2) drop to devshell. > 3) if there is no git repo, run. > 3.a git init; git add -A; git commit -s -m "Upstream import: ${PN} ${PV} > (${SRCREV})"; git tag oe-base > 3.b hack hack > 3.c git add -p > 3.d git commit -s -m "<META_PART> DESC" > 3.e git format-patch oe-base --cover-letter --suffix=.patch -o ../patches > 3.f cp ../000..... -> meta-layer/rec..../patch_dir > 4) build and see if it passes. if not repeat :( > > before 3.f is there any way to build in the devshell without having to export > a bunch of stuff ? In my past in devshell I have only built u-boot and linux. > (ARCH, CROSS_COMPILE etc). It would be nice not to drop in and out of the > devshell until the build is fixed. Any advice on internal commands that I may > be missing would be great. > > Some more things about the build. I have my own world recipe (it's really a > package group with a lot of rrecomends) I build this but do not ship to any > images. > > I am willing to share any code or whatever that is opensource and does not > harm IP. > > Thanks for maintaining OE and I look forward to your advice, > jmills > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#119154): https://lists.openembedded.org/g/openembedded-devel/message/119154 Mute This Topic: https://lists.openembedded.org/mt/114964946/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
