How to properly "freeze" Yocto for production

[marlonsmith]

Hi everyone,

My company is designing a product based on the i.MX6 and we're considering Yocto (or Ubuntu) for the OS.  I've been able to use Yocto dora to build something that runs on our custom board to test it out.

The Yocto repos are always being updated, and eventually dora will be taken down/no longer supported.  At some point when our product is ready for release, we will no longer want to receive updates to Yocto or rely on its repositories; we'll want to freeze the source.  We will want to be able to make changes to our application (bug fixes, etc.) but we won't want anything to change otherwise.

What's the best method of creating our own copy of Yocto that includes everything we need and doesn't rely on any of the sources being hosted externally?

Thanks

Marlon

[OtavioSalvador]

Hello Marlon,

As tomd. has advised, the Google's repo tool is perfect for it. We use it for the several customers when doing custom BSPs and platforms for products.

It alone won't solve all your issues but it provides a good base to start. As you probably know, we use it in the FSL Community BSP to easy the setup and maintenance of the demo platform. Please pay attention to security implications of not updating the underneath system

Take a look in our example platform and in case of doubts please let me know.

[bryan_prather]

If you are trying to use your own local mirror and set BB_NO_NETWORK = 1 then the following error is generated.

ERROR: ExpansionError during parsing /home/opti/sandbox/mahyar-ym/sources/meta-boundary/recipes-boundary/devregs/devregs.bb: Failure expanding variable SRCPV, expression was ${@bb.fetch2.get_srcrev(d)} which triggered exception NetworkAccess: Network access disabled through BB_NO_NETWORK (or set indirectly due to use of BB_FETCH_PREMIRRORONLY) but access requested with command git -c core.fsyncobjectfiles=0 ls-remote git://github.com/boundarydevices/devregs.git refs/heads/master refs/tags/master^{} (for url None)

Is there a way to use your own mirror without needing to go outside?  For regulatory reasons we need to archive the files that are part of the the build for the image and toolchain so that we can recreate them in the future and no that nothing has changed.

Once you have all the files in the download directory is anything required that would required retrieval from an external repository.?

[OtavioSalvador]

You don't need BB_NO_NETWORK, you want BB_FETCH_PREMIRRORONLY.

Set BB_FETCH_PREMIRRORONLY to your company server and enjoy.

[joshuaostrander]

Yes BB_FETCH_PREMIRRORONLY does prevent the full git clone again, but it still depends on the git ls-remote.  I would like to build this with NO network dependencies.  Is there any way to do that?  It seems no alteration will remove the need for this recipe to call git ls-remote.

[OtavioSalvador]

You are looking for BB_NO_NETWORK variable. It disables network access during build.

[joshuaostrander]

Correct, I am trying to use BB_NO_NETWORK, unfortunately the build will still fail during do_fetch for the linux-imx recipe because it wants to do a git ls-remote.  Here is the actual failure:

ERROR: linux-imx-4.1.15-r0 do_fetch: Function failed: Network access disabled through BB_NO_NETWORK (or set indirectly due to use of BB_FETCH_PREMIRRORONLY) but access requested with command git -c core.fsyncobjectfiles=0 ls-remote git://git.freescale.com/imx/linux-imx.git (for url None)

[santhoshkarthik]

Hi @Joshua Ostrander @OtavioSalvador

   I am facing the same problem, I want to compile yocto offline without accessing the Internet. Please share me the procedure, if you are able to compile yocto offline

[dellgreen]

Take a look at BB_ALLOWED_NETWORKS in conjunction with other suggested recommendations above :smileyhappy:

[OtavioSalvador]

As far as I know, it tries to fetch when the revision is not cached or when using AUTOREV. I suggest you to update your mirror and make sure it includes the respective revision before disabling the network access.   

[tomd_]

I can highly recommend google's repo tool. You can define all your meta-layers and the corresponding repositories that you use in your production environment including the specific revision. The revision ensures that you always get the specific version of the repo that you want to have. You can find a very basic example here: toolmmy/yocto-poky-td · GitHub

I would also suggest to create your own mirror for all the required build packages (stored in the download folder). You can use this mirror of all the tarballs as a simple symbolic link our you can host a HTTP server that provides all the tarballs. You only need to set the following information in your local.conf

#Using our own sources mirror

INHERIT += "own-mirrors"

SOURCE_MIRROR_URL = "http://<your server>/yocto/mirror/downloads/"

BB_GENERATE_MIRROR_TARBALLS = "1"

[gusarambula]

You may change the manifest to set it to a static commit as is the case of the Freescale BSP release, which is not changing as the fsl-community-bsp. This way it will sync always to a specific commit, another option is simply not to sync repo.

Regarding your application I would recommend adding a layer with your customization while on a specific commit as previously stated (so it won’t be updated). This allows you to have all your code and changes in a modular way and it’s how Freescale’s BSP works. You can see the current layers being used  by running the following command:

$bitbake-layers show-layers

For more information on layers please refer to the Yocto Project Development Manual (link below) which contains some recommendations and the guidelines for a layer to be compliant with the Yocto Project.

http://www.yoctoproject.org/docs/1.3/dev-manual/dev-manual.html#understanding-and-creating-layers