Re: [OE-core] Core workflow: sstate for all, bblock/bbunlock, tools for why is sstate not being reused?

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Tue, 2024-02-13 at 14:25 +0100, Alexander Kanavin wrote:
> On Thu, 8 Feb 2024 at 14:42, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> > hashserve.db is a full hash serve database. When we run a build without
> > specifying a hash serve to use, bitbake will start a local one and this
> > is the file which backs it. In a build with a remote hashserve, it
> > won't be present.
> > 
> > the unihashes file is bitbake's internal lookup cache. It exists so
> > that if the hashserve isn't local, we have a local lookup of our "last"
> > value.
> > 
> > This means the file is good for the current (last) build not much
> > beyond that.
> > 
> > I'm not saying any of this entirely solves the problem at hand, just
> > that some of the data is there.
> 
> So perhaps we need the following interface:
> 
> bitbake -S export-hashes targets...
> 
> would save all relevant entries for the targets from outhash and
> unihash tables into a local file (similar to locked-sigs.inc creation
> with -S lockedsigs). This avoids exporting the entire database, which
> is both excessive and unnecessary, and at the same time ensures
> everything relevant is in the export (merely copying bb_unihashes.dat
> does not guarantee that).
> 
> Then we'd also need a way to import the data, but I'm not sure where
> to put that. 'bitbake -S' is not suitable. A new command to
> bitbake-hashclient perhaps? But bitbake-hashclient doesn't discover
> where the hash server should be from bitbake config, and won't
> autostart it if/when needed.

In theory you can start a local hash server and then report all the
hashes to it?

Cheers,

Richard