Just to explain the environment:
I generate tarballs out of the fetched libs:
BB_GENERATE_MIRROR_TARBALLS = “1”
BB_NO_NETWORK = “0”
CONNECTIVITY_CHECK_URIS=“”
DISABLE_NETWORK_SANITY = “1”
these downloads tarballs are archived within a new git repo to have reproducible builds.
the do_fetch tells that a fetch fails, that a tarball has been saved, that another fetch failslink text
the gnu tarball is fetched weeks ago and archived for reuse (unpacked before each build). But the do_fetch now deletes this tar.gz and tries to fetch a new one.
Ok, I understand now, in this step you really try to fetch the tarball from the network, not from a local tarball.
It really seems that fetching just fails. git.sv.gnu.org recently moved to git.savannah.gnu.org. There is already a patch for that in rocko, not sure whether that will get backported to morty.
Are you using INHERIT += "toradex-mirrors" in your local.conf? This should add Toradex source mirrors to the mirros list which should have a tarball of said git repository.
in fact I’ve checked the availability of the network tarball and (desperately) changed the mirror within its gnu recipe.
But:
There are more recipes than this one which have changed recently
I would prefer that bitbake NEVER tries the network mirror once the local tarballs are established.
But even the switch BB_NO_NETWORK = “1” still leads to network access trials: gnu-config-native-20150728+gitAUTOINC+b576fa87c1-r0 do_fetch: Network access disabled through BB_NO_NETWORK (or set indirectly due to use of BB_FETCH_PREMIRRORONLY) but access requested with command LANG=C git -c core.fsyncobjectfiles=0 fetch -f --prune --progress git://git.sv.gnu.org/config.git refs/:refs/ (for url git://git.sv.gnu.org/config.git)
inherit += “toradex-mirrors” at least fixes the ever changing public git servers
BB_NO_NETWORK = “1” blocks effectively the network access, but gnu complains that it would like to fetch online resources although the tarball is already locally available. So I assume an error within the recipe which always tries t fetch the hottest and newest branch / tag / whatsoever
I doubt that this conclusion is correct. You write above you changed the mirror in the recipe. I guess with that the recipe and your local tarballs (which have been generated before the mirror update) do not match up anymore.
As far as I understand bitbake uses the mirror name/url to locate the tarball. So when you update the mirror in a recipe, you really need to regenerate tarballs…
In fact changing the mirror in the recipe has only been a test to check what is going on. I reverted it immediately because I only want to find out why the network is accessed at all.
So because everything is reverted: clean checkout of the recipes, artefacts (deploy, tmp-glibc. cache,…) deleted, fresh checkout of the local tarballs - the question remains: Why tries e.g. gnu and pk_config to update its tarballs?