I have a Yocto (poky)-based project where I would like to avoid downloading all the dependencies from the internet. I have found the PREMIRRORS variable that can be used to tell the build to get the dependencies from a local directory. The documentation does not, however, mention how to create such directory.
Is there some way to ask the build system to fetch all the packages to some place where they can be easily collected, or at least enumerate all the URLs so they can be mass-fetched?
See here please:
https://www.yoctoproject.org/docs/2.6/mega-manual/mega-manual.html#getting-source-files-and-suppressing-the-build
The directory can be then used directly as a PREMIRRORS location.
Related
To edit source in Yocto, I have to execute devtool modify <recipe>. I know the name of the source file, say foo.cpp, not the recipe. Using information captured elsewhere I can find out which recipe corresponds to my source file. To me that's the brute force method. Is there a recommended way to find the recipe using Yocto tools?
I have already viewed dependencies and reverse dependencies with Toaster. That did not help.
I am trying to determine how I can find what recipe a source file from the build/tmp/work directory came from. Basically normally most of the recipes in the source folder are uri. Then get downloaded and installed to various temp folders. I want to create a patch for some of the files, but I can't seem to figure out which files belong to what recipes.
Thank you
Run oe-pkgdata-util find-path /path/on/target/to/file. This will give you the package installing the file. From there, run oe-pkgdata-util lookup-recipe <pkg-name>, this will give you which recipe is creating the package. That should be enough to find out which recipe you need to modify. You then need to check whether the file you want to modify is part of the recipe (Yocto artifact) or part of the software that the recipe builds. For the former, you can override the file, for the latter, you can create a patch (you can use devtool to help you create the patch).
I have a project that is mostly complete for a custom third party SoM which requires custom bootstrap/bootloaders, currently the recipe is in a meta-bsp layer which works alright however they are built in the aarch64-poky-linux build directory. We have multiple SoM models from this manufacturer that each require different bootloader configs and I'd like them to be built in a machine specific non-linux directory if possible like aarch64-<machine>-none or something. Is this possible?
We are using dunfell release.
Recipes are in meta-mfg/recipes-bsp/mfg-/mfg-_version.bb
Fairly standard recipe setup including:
SECTION = "bootloaders"
SRC_URI..
DEPENDS (native packages only)
do_configure()
do_compile()
do_install()
Current build directory: tmp/work/aarch64-poky-linux/mfg-bootloader/1.x.x-rx/
Preferred build directory: tmp/work/aarch64-<machine>-none/mfg-bootloader/1.x.x-rx/
When building for different machines/soms it uses the same directory and uses the previous build which may be incorrect. We do have a workaround where we don't stamp the configure/build/install tasks so they always rebuild however we'd like a cleaner more appropriate implementation.
Is there any way to accomplish this?
I haven't been able to find any information so far.
I have been pointed to the solution from the IRC channel for anyone with the same question:
Add PACKAGE_ARCH = "${MACHINE_ARCH}" to the recipe to build in machine specific folders.
I have build a nuget package at published it to a nuget.server site. But when I try to use the package form the server the .targets file from build folder is not in the file. But if I use the package from a local folder it works as it should. How do I get it to work ?
If i look in the package in the folder on the server it looks ok.
It's not clear to me if you mean using (referencing and restoring) a package, or building (packing) a package.
If the problem is with packing the nupkg, NuGet requires the props and targets files to have specific filenames in specific folders, but if you got it to work at least once, you probably already know that. If this is not the problem with packing, you need to give us more information because not using the correct filename convention is the most common problem and I can't guess what else the problem could be. In particular, if the package is being packed differently on your local machine compared to when it is packed on the server, it means there is something different between how you pack on the two computers, so we need more information about how the build and pack work with your project.
If the problem is with using (restoring) the package, there are a few possibilities. My best guess is that you once had a package without the targets file working correctly, and you restored the package on the server. By design, NuGet packages are immutable which means it's invalid for the contents of a package (same ID and version) to change. This allows NuGet to download the package from a remote feed once, save it in the global package folder (not a cache; they never expire) and the next time NuGet needs to restore the same package (id + version) it uses the one in the global package folder, it does not download again. This means if you once built a bad nupkg and restored it on a machine, then fix the nupkg and kept the same version number, that machine will never get the fixed nupkg. You need to delete it from the global packages folder. I'm not 100% sure, but I think if you have a local file feed and you restore a project that uses packages.config, the nupkg does not get saved in the global packages folder, so doesn't have the same problem. In short, I think the problem is that you changed the nupkg contents once without changing the version number, and one of the machines has the old copy in its global packages folder that it keeps using.
If that's not the problem, the next most likely cause is that the nupkg on the server feed has different contents to the nupkg in the local feed. I've never used NuGet.Server, but some nuget respositories (like nuget.org) do not allow overwriting nupkgs. So, if you pushed a nupkg to your server, fixed a problem in your nupkg without changing the version, then tried to push again, the second push might have failed.
In summary, your question doesn't provide enough information for us to help you, but I wrote about the most common issues above. If it doesn't help, you need to provide us with more information. An example of the problem is the best way to give us enough information to help you.
I'm new to yocto. I'm trying to learn how the packages are added, how to create new layers and so on... just poking around. Started by cloning poky and playing around.
To my understanding, the bblayers.conf file is critical to the project configuration and what you end up building (what layers and packages go into your final image).
This might be the wrong assumption, but I also have a feeling that the build/ folder is where things you build (bitbake) stay. Images, lots of things needed to build them, a big cache of stuff... You can delete it and rebuild it if you somehow broke it. Or you can just copy everything without the build/ folder and continue working on a different computer.
Apparently it's not quite the case. The build/conf/ folder has the important .conf files like the bblayers.conf.
Can someone explain why is this the case? Is there an elegant way to separate the project config and the build folder?
There are a couple layers to the Yocto Project, mainly:
-BSPDIR: TOPDIR (build),sources,setup-environment
-BSPDIR/setup-environment: initial all the variable to for bitbake;
-BSPDIR/sources: meta-data/
-TOPDIR: conf/ sstate-cache/ cache/ tmp/ downloads/
-TOPDIR/downloads: recipe fetched packages;
-TOPDIR/conf/ : stored all the configuration. Mainly bblayers.conf, local.conf, sanity_info;
-TOPDIR/conf/bblayers.conf: stored all the path to meta-data that will be loaded;
-TOPDIR/conf/local.conf: configuration to build
-TOPDIR/conf/sanity_info: path double check to make sure that all the path used in the last compile match the current compile;
-TOPDIR/tmp/: Where all the compiling and building work happen
In BSPDIR/sources/poky/meta/conf/bitbake.conf
sources/poky/meta/conf/bitbake.conf:TMPDIR ?= "${TOPDIR}/tmp"
sources/poky/meta/conf/bitbake.conf:PERSISTENT_DIR = "${TOPDIR}/cache"
sources/poky/meta/conf/bitbake.conf:DL_DIR ?= "${TOPDIR}/downloads"
sources/poky/meta/conf/bitbake.conf:SSTATE_DIR ?= "${TOPDIR}/sstate-cache"
TOPDIR is where you initialize when run setup-environment or oe-init-build-env; All the other bitbake configuration environment variable can be changed based on your need in conf/local.conf;
e.g. modify conf/local.conf to change the downloads directory from TOPDIR/downloads;
DL_DIR ?= "/home/downloads/"
To create new layer, please watch this video: https://www.youtube.com/watch?v=3HsaoVqX7dg
You might have followed the Yocto Project Quick Start Guide.
The earliest step in yocto after installing (cloning git repositories and installing packages) is to create your OE (OpenEmbedded) environment, which is done via:
source oe-init-build-env
This automatically creates and leads you to the build folder.
Matter that you can give any directory of your system as parameter for this call (Reference Manual - Build Overview):
source oe-init-build-env [build_dir]
⤑ This is also the step, where your 'project config' is separated from the actual build folder.
⤑ As you assumed, in practice you would at most copy the layers and not the build folder. Even better is to leave sources from others in their git repositories and only copy and maintain your own layers.
it is true an issue in the modern Yocto build system.
file bblayers.conf has to be synthesized based on MACHINE and DISTRO information using all provided (usually with the help of repo manifest file) layers by: collecting data from each available layer file layer.conf as well as conf/machine, conf/distro, images.
Instead bblayers.conf is usually copied over from the base layer conf/bblayers.conf location with the help of setup-environment script.
this approach provides no "one click" buildable environment but require maintainer/developer to look into readme to identify what layers are missing to be added to the build/conf/bblayers.conf.