On Mon, Jan 30, 2023 at 2:57 PM Jose Quaresma <quaresma.j...@gmail.com> wrote: > Denys Dmytriyenko <de...@denix.org> escreveu no dia segunda, 30/01/2023 à(s) > 17:18: >> >> On Mon, Jan 30, 2023 at 11:02:25AM -0600, Ryan Eatmon via >> lists.yoctoproject.org wrote: >> > >> > >> > On 1/30/2023 9:20, Jose Quaresma wrote: >> > >This patch adds the possibility to change some bitbake variable >> > >that cannot be changed anywhere else, one of then is the TMPDIR. >> > > >> > >Using the same TMPDIR it is very sensitive and prone to several errors >> > >when used in more complex situations. >> > >This configuration forces that all native packages have to be the same >> > >between all >> > >machines and this requirement is very easy to break. >> > >Suppose you use a macinhe override somewhere on a native recipe >> >> Even w/o multiconfig, this will break for multi-machine builds. Native >> packages are for the build host and have no knowledge about the target. >> You should probably look into cross packages instead of native ones for >> this use case. >> >> Altering native packages between different targets will cause them to >> rebuild, which they shouldn't. Moreover, it will mess up your sstate >> and lead to weird issues down the road when trying to re-use your >> sstate mirror/cache. > > Is that the issue of rebuilding some native packages that I am trying to > avoid. > But it is very hard to fix this in OE-core and everything else layers what > happens. > > For your information I have some other issues with multiconfig and native > packages > that have the source files provided on the layer. this two recipes don't work > with the > rm_work bbclass because the in one of the machines > texinfo-dummy-native gettext-minimal-native > > Another issue is that sometimes one of the machines uses the > SOURCE_DATE_EPOCH_FALLBACK > and the other uses SOURCE_DATE_EPOCH and this also triggers a rebuild of one > of the machines. > > Recently a new issue with the rm_work and the spdx > comes in https://lists.openembedded.org/g/openembedded-core/message/174276 > where I have the steps to reproduce. > > All of these issues can be solved easily with TMDIR for each machine, > but because I understand it can be invasive I submit this patch that doesn't > change anything > in meta-ti but can add the possibility to use a different TMPDIR for each > machine. > > A different TMPDIR for each machine is also referenced in the official > documentation > "Minimally, each configuration file must define the machine and the temporary > directory BitBake uses for the build. Suggested practice dictates that you do > not overlap the temporary directories used during the builds." > https://docs.yoctoproject.org/bitbake/bitbake-user-manual/bitbake-user-manual-intro.html#executing-a-multiple-configuration-build > >> > >and this requirement is no longer met. >> > >Many of these anomalies can be verified with the use of the rm_work and >> > >create-spdx bitbake classes. >> > > >> > >A previous attempt [1] had already been made but was refused >> > >but this way it can be done without side effects for other users. >> > > >> > >[1] https://lists.yoctoproject.org/g/meta-ti/message/14767 >> > >> > >> > So the difference between this patch and the previous one, is that >> > you are now included a file that is not there normally so that you >> > can put the contents of the previous patch in the new include file >> > to get around the issue in the archiver. > > The archiver issue is fixed but it will be very easy to break again. > Myself recently broke it again so I added a test to help there > https://git.yoctoproject.org/poky/commit/?id=b5baa7dc8bd1c0d2d78c532d97a44120346b5edd > >> > >> > I'm not saying I'm opposed to this approach (yet), I'm just trying >> > to understand the entire story. >> > >> > Did you find anything in looking at fixing the archiver to better >> > support the multi-config issue? > > The issue now is different and is related with spdx and rm_work > https://lists.openembedded.org/g/openembedded-core/message/174276 > > With this patch I can set a new TMPDIR folder for each machine and > can build successfully.
If you don't have spdx enabled then these sort of issues happen less often, but after the above patch was merged in oe-core (and also backported to kirkstone), we cannot build multiconfig targets from meta-ti anymore with spdx enabled. This is special to spdx because of the way the task dependencies are done, which requires it to be executed before rm_work. This is OK when a machine specific TMPDIR is used and explodes quite quickly (due races) when sharing TMPDIR because of the parallel rm_work tasks that end up removing stuff that is still required by other parallel tasks. Cheers, -- Ricardo Salveti
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#15704): https://lists.yoctoproject.org/g/meta-ti/message/15704 Mute This Topic: https://lists.yoctoproject.org/mt/96629864/21656 Group Owner: meta-ti+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/meta-ti/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-