TL;DR: Is there a way to force to recompile a package every time an image is generated?
I have a bbappend with a do_deploy_append appending to a file and if I modify this step, the recipe will not be recompiled when generating an image using it. This can lead to errors pretty hard to ind. Bitbake assumes it has been unchanged. I have only 2 packages like this, very small.
Is there a parameter to force those package being cleaned and recompiled without manually do it?
I am using Yocto morty
Generally speaking, if you want a task to always be executed, you should use the [nostamp] varflag on this task, which should be set to "1". For example, if you want the recipe to be recompiled every time, you should add the below line to the package's recipe:
do_compile[nostamp] = "1"
To always execute the do_configure task, you should add the following line:
do_configure[nostamp] = "1"
This applies for any task that you need to always be executed. Have a look here for more information on nostamp variable flag: http://www.yoctoproject.org/docs/2.3.2/bitbake-user-manual/bitbake-user-manual.html
Related
I am using yocto with the current kirkstone LTS release(for a long time). I tried to use the version information for recipes.
See: https://docs.yoctoproject.org/4.0.6/ref-manual/variables.html?highlight=preferred_version#term-PV
So I have a recipe like this: 'my-recipe_1.0.0.bb'
Now I want to install that recipe in this version in my image. So I have another recipe like 'image.bb' that installs the recipe with something like: 'IMAGE_INSTALL += "my-recipe".
Now I want the build to fail, if that recipe version does not exist. I use REQUIRED_VERSION for this, see: https://docs.yoctoproject.org/4.0.6/ref-manual/variables.html?highlight=preferred_version#term-REQUIRED_VERSION
So I added in my image.bb a line like this: 'REQUIRED_VERSION_my-recipe="1.0.0"'
This works perfectly fine and I can switch this way between different versions of my recipe.
Now comes the question: If I require a version of my recipe that does not exist, the documentation says I will get an error and an immediate build error. But instead, my build takes an existing recipe but not the one I required.
This leads to an unacceptable situation where my build build something I do not expect.
Now I wonder, if somebody has an idea what is going wrong.
I tried to use the REQUIRED_VERSION for different existing recipes. -> That worked as expected.
I tried to use the REQUIRED_VERSION for a not existing recipe. -> That did not work as expected. I got no build error.
Since the manual states that REQUIRED_VERSION "works in exactly the same manner as PREFERRED_VERSION" (except that it throws an error), maybe try using the forcevariable override:
REQUIRED_VERSION_my-recipe:forcevariable = "1.0.0"
Edit: Include this line in local.conf instead of the image.bb file for the expected behavior to take effect.
Hmm. What if you try including that line in local.conf instead of the
image.bb file? – thelummox Jan 13 at 16:11
Well, adding this to the local.conf raised the expected error. It even prints the available versions.
It is weird because local.conf is by definition not party of my layer but I can work with that.
After some time, I went to a project to redo a build and the command I give results in:
qbs build -p archive config:release modules.cpp.useRPaths:false
Restoring build graph from disk
ERROR: Property values set on the command line differ from the ones used for the previous build. Use the 'resolve' command if you really want to rebuild with the new properties.
Is there any way to determine which properties were set in the previous build?
No, the command-line frontend does not expose this functionality. But independent of that, it would be helpful if the error message listed the differing properties. You might want to create a task for that at bugreports.qt.io.
OK, so we're stuck on on-site TFS2015 at the moment. My Nuget Publisher build step is failing with:
##[error]Ambiguous option 's'. Possible values: Source SymbolSource SymbolApiKey.
It appears inside the build step they have put -s instead of -source, and in later versions they've added more commands starting with s. So what are my options?
Write my own in Powershell (Can do, but TFS Build is very clunky for this)
Find wherever this is defined in TFS (hopefully a template .ps file) and fix it there (Anyone know where this is kept?)
Upgrade to a later version of TFS (a fairly large, but perhaps inevitable undertaking)
Somehow override the -s command another way?
????????
Invoke NuGet.exe however you'd like via the Command Line task
If you did #3 (upgrade TFS), you'd find that the PowerShell build task can run an in-line PowerShell script, making it significantly less clunky.
You may be able to extract and modify the task with the tfx command line utility, but I can almost guarantee this will have nasty ramifications when you do eventually upgrade.
I'm adding my answer for details about step 5 maybe it will help team that are still using TFS 2015.
Nuget Publisher seems to use old version, which means "-s" option will not work.
To bypass this situation you can setup your build as follow:
1- Add Nuget Packager Step and specify the the Package Folder value:
2- Add a new step which would copy your artifacts(Note that contents that should be copied must end with nupkg):
3- And Finaly you can just run a command line that will perform the publish operation. In my case we are pushing the whole repository using init command(PackageRepository is the path to our internal feed that we set in we've set in Variables section):
So, I was given the task to upgrade our yocto based system from fido to morty. I have very little experience with yocto, I have been struggling with it and trying to understand it for almost a week now. I have managed to fix some issues, but now I'm facing a problem when trying to build the image:
ERROR: basic-image-1.0-r0 do_rootfs: The following packages could not be configured offline and rootfs is read-only: ['component']
ERROR: basic-image-1.0-r0 do_rootfs: Function failed: do_rootfs
If I disable the compoents the basic-image builds just fine, and both of them build just fine on their own, i.e bb component
I don't even know where to start looking for a solution. So if you have any idea what might be causing this or where to start looking for a solution, it would be greatly appreciated.
Ofcourse I have been browsing the yocto manuals, but there is so much stuff that I'm just overwhelmed by all of it.
Well, the "problem" stems from the fact that you have the following in your image:
IMAGE_FEATURES += "read-only-rootfs"
That implies that nothing can modify the rootfs during runtime, everything has to be done off-line, i.e. when constructing the rootfs in question.
Your package component (adcl and cfgmgr in your original question), all have a post-installation script including the following snippet:
pkg_postinst_${PN} () {
if test "x$D" != "x" then
# Need to run on first boot
exit 1
fi
}
(Something similar at least, which exit 1).
The conditional in my example checks if the pkg_postinst script is being run during rootfs creation, if so, it exits with 1 as exit status. That means that the pkg_postinst has to be run live on the target system. However, as the target system is read-only, this will be impossible, and the build fails.
You'll have to check for pkg_postinst scripts, and rewrite them, such that they're able to be run during rootfs creation.
I need to execute the file that is a result of a successful compilation, but I have no idea how to do so.
What I know is the full path of the file, so I need to run a command like double click on the file after compilation.. any idea?
If I understood your problem correctly then you should be able to do that with appropriate tasks
Of course, the concrete implementation depends on the kind of task runner you will use but e.g. with gulp you could use gulp-shell to execute your compilation / build result after the build (gulp) task is done