Kernel is not within downloads/*tar.gz but within dynamic folder build/tmp-glibc/workshared/...?

That gitrAUTOINC stuff looks more than suspicious. And you are sure to building a consistent 2.7b5 state without any such machine override?

I do agree to your suspicion! But I don’t use “use-head-next”

For us and hundreds of other customers regular builds work just fine so I guess your exotic use case might just not really be supported, sorry.

What I need is just a fixed reproducible build of a toradex angstrom image with fixed downloads that doesn’t change or update onthefly. Is this exotic? So I need archived files and folders that can be used for a build on every Linux VM anytime and anywhere. So I have to get rid of this gitAUTOINC stuff.

I actually just tried above exact same procedure again here and after some initial hick-up downloading stuff from NVIDIA’s server it worked just fine. Could it be that you are behind a company firewall blocking certain destination IP addresses or protocols?

What I do is:

online: repo init, repo sync, bitbake fetchall → downloads1

online: copy&add&commit downloads1 into new own git repo downloads2

offline: build based on downloads1 → successful

offline: build based on downloads2 (symbolic link within build) → failed

diff -rg downloads1 downloads2:

downloads1/.git/objects: xy

downloads1/git2/anongit.freedesktop.org.evtest: branches/ info/ refs

downloads1/git2/git.sv.gnu.org.config.git: branches/ info/ refs

So from my point of view there might be a dependency on objects and branch information.

But I expected a dependency only on tar.gz files which could be archived at each customer site for reproducibility

Thanks for letting us know about your special use case. However as regular offline building actually works just fine I doubt we will be able to do much about it, sorry.