Hi,
Von: "Robert P. J. Day" <rpj...@crashcourse.ca> An: daniel.schnel.ext...@ifm.com Kopie: yocto@yoctoproject.org Datum: 24.01.2013 21:47 Betreff: Re: [yocto] PREMIRRORS_prepend & friends Gesendet von: yocto-boun...@yoctoproject.org On Thu, 24 Jan 2013, daniel.schnel.ext...@ifm.com wrote: > > Hi, > > after hours of trying and googling I finally make my first coming out here > on this list to get some help with PREMIRRORS_prepend & friends.So please > be friendly ;) > > I want to setup local mirrors for our yocto build for reproducability > purposes. I am using ELDK-5.2.1 which is based on yocto-1.2 > > I have made the following settings in my local.conf: > > PREMIRRORS_prepend = "\ > git://.*/.* git://git@dettlx79: \n \ > ftp://.*/.* http://dettlx79/sources \n \ > http://.*/.* http://dettlx79/sources \n \ > https://.*/.* http://dettlx79/sources \n \" > > > BB_FETCH_PREMIRRORONLY = "1" ... snip ... i documented how i set up my own local mirror here: http://www.crashcourse.ca/wiki/index.php/OE_Creating_your_%22own_mirror%22 it's all based on eventually storing tarballs of the sources, no matter how you fetched the original sources. is that what you're after for reproducibility? We want to guarantee even after +5 years or so that the bits of our binaries are the same whenever we hit the build trigger. In my eyes this can only be achieved if the sources are archived via revision control system, because otherwise we would be dependent on archives and their filename always staying unmodified over time. This is a policy outside of our realm and so a revision control system would get this straight. I could now use a naive approach and do cd downloads/ && git init && git commit -a -m "all files committed" But this isn't optimal as there are already git repositories inside download2/git2/ which seems to originate from downloads/git2_*.tar.gz archives, no ? So far I have successfully built my image via downloading the sources via internet. >From here these are the steps I want to try for the PREMIRRORS: 1.) provide the exact downloads/ directory via http:// only (not via files://) 2.) provide archives only via http but git repositories via in-house mirrored git repositories and git:// protocol (don't use git archives like git2_...tar.gz from the http:// mirror) The latter I have not been able to manage. Any ideas if this scenario can be achieved ? And can you shed some light into the yocto approach of archiving external git repos as tar.gz archives ? Regards, Daniel Schnell. _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto