6572 2014-07-24 17:32:40 +0000 BB_GENERATE_MIRROR_TARBALLS creates non-unique filenames 2014-07-25 16:22:44 +0000 1 1 7 Build System, Metadata & Runtime BitBake bitbake 1.6.1 x86 Multiple RESOLVED NOTABUG Undecided major --- 1 lists.volker richard.purdie poky.bs.watcher poky.watcher --- --- Don't know oldest_to_newest 44679 0 lists.volker 2014-07-24 17:32:40 +0000 For releases we do the following steps: 1. download all files while having BB_GENERATE_MIRROR_TARBALLS="1" bitbake -c fetchall <imagename> 2. move all downloaded files to the fileserver The fileserver folder can only create files and not modify them to catch all unexpected behaviour of overwritten files 3. set yocto in offline mode (BB_NO_NETWORK) and use the folder of the file server via SOURCE_MIRROR_URL This way we are sure that every build is repeatable with local available files. Now the files downloaded should never change like busybox-1.22.1.tar.bz2 and if their is a change in the checksum the copy process fails (extra layer of check). Now the git repositories management is different. File names do not contain the git hash value like git2_git.yoctoproject.org.linux-yocto-3.10.git.tar.gz As result, it seem that if the hash changes, the file changes, too. Therefore, from my understanding, this file can change unexpectedly if the version stays the same but the git hash changes. 44718 1 richard.purdie 2014-07-25 16:22:44 +0000 The tarballs contain all the git metadata so they contain multiple hashes. The filenames do contain all the other configuration information such as the location of the repository. From a build reproducibility standpoint, the git checkouts are of specific revisions set by the recipes, if that revision were unavailable the build would fail. So yes, these tarballs are updated but this shouldn't be an issue, in general only extra metadata would get added to them. Obviously if you have them set to AUTOREV, it will not select specific revisions and this is not suited to release purposes but we'd simply not recommend doing that.