I have a buildroot directory with all my configs
I am using a package, and for a certain use case, I want to check where the package fails at runtime.
I am trying to modify the package a little bit, but I do not know how to build this package with my debug prints included.
I tried to like this
go to buildroot/dl/package/ folder
extract the package
change in source
gzip the package
delete the intermediate in buildroot/output/build/package
build make
Now build root uses some kind of hash value and rejects the package with my changes. It redownloads the package and replaced my changes.
ERROR: imx-kobs-a0e9adce2fb7fcd57e794d7f9a5deba0f94f521b.tar.gz has wrong sha256 hash:
ERROR: expected: 5855c8964f908ad30e5d4500180ee57c51af68186289ef1bdf8553ee60d3b1f5
ERROR: got : b5c22a971d9c9130b1b0f5ddd5b60b2eabd60607421c0f746ef0543b42960977
ERROR: Incomplete download, or man-in-the-middle (MITM) attack
dl-wrapper: Re-downloading 'imx-kobs-a0e9adce2fb7fcd57e794d7f9a5deba0f94f521b.tar.gz'...
How to use buildroot with more control?
Two options:
For quick tests, modify the source code in output/build/<pkg>-<version>/, and run make <pkg>-rebuild to force the rebuild of that package. Note that output/build/<pkg>-<version>/ folders are lost when doing a make clean in Buildroot, so this is only good for some quick debugging/investigation.
For actual development on the source code, I would suggest to use the <pkg>_OVERRIDE_SRCDIR mechanism. Create a local.mk file at the root of the Buildroot tree. In this file, put FOO_OVERRIDE_SRCDIR = $(HOME)/foo. From now on, Buildroot will no longer download/extract/patch the foo package, but instead will instead rsync the source code from $(HOME)/foo into the package build directory. Running make foo-rebuild will re-run rsync and restart the build of this package. This means you can change the source code in $(HOME)/foo and very quickly rebuild the package with those changes. See also slide 269 and following in https://bootlin.com/doc/training/buildroot/buildroot-slides.pdf.
Related
Is there anyway I can just call into a define such as LIBFOO_DIRCLEAN, and just do what was implemented in the define?
Inside HOST_LIBFOO_INSTALL_CMDS, I copy files to the target directory, and would like the 'make package-dirclean' to delete what was copied into the target directory. 'make clean', would obviously do this(any many more), but that is much more than I want to do.
I see the following buildroot variables. LIBFOO_EXTRACT_CMDS, LIBFOO_CONFIGURE_CMDS, LIBFOO_BUILD_CMDS, HOST_LIBFOO_INSTALL_CMDS, LIBFOO_INSTALL_TARGET_CMDS, etc.
make foo-dirclean is a simple tool that just deletes the package build directory. In most cases, when the list of files installed by a package does not change over time (only files content changes) you can simply rebuild the package and the target directory will be rebuilt correctly.
If you want you can implement your own foo-myclean step that implements your own logic. However you must understand deleting files in the target directory is not supported by Buildroot and thus you are on your own.
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've downloaded the sources for kdesvn from the github repo as I'm thinking to look into working on an addition to the project. Now turns out, I'm not even able to properly compile the downloaded sources: I've created a directory kdesvn-build changed into it and launched cmake ../ (as described on https://github.com/KDE/kdesvn/blob/master/INSTALL-cmake) which does some stuff but then stops saying:
CMake Error: The following variables are used in this project, but
they are set to NOTFOUND. Please set them or make sure they are set
and tested correctly in the CMake files: SUBVERSION_INCLUDE_DIR
Now, I don't know what SUBVERSION_INCLUDE_DIR should be set to nor could I find it searching around the web. Anyone?
It is a directory containing svn_*.h files. If you are on Linux, you'd need to install something like subversion-dev package. On FreeBSD headers are installed with main package, and the directory is /usr/local/include/subversion-1/.
I am having an issue where a recipe i'm using no longer has the variable libdir defined. It appears to only have libdir_native.
This recipe i'm using is poco-1.7.5 for Morty from openembedded so I assume the recipe should work properly.
As a result of the missing libdir variable none of the installed files are being packaged which is screwing up my build.
In the short term i've been able to fix the problem by creating an append file which makes libdir = "${libdir_native} but this doesn't seem like it should be necessary.
The only thing I can think of is that the Bitbake.conf file is not being source properly by Bitbake (or the wrong .conf is being used).
Any suggestions would be appreciated.
Based on the comments this seems to be the problem: Poco upstream installs libraries into /usr/lib/ but the yocto packaging expects them to be in ${libdir} which may be different from /usr/lib/.
The most common reason (for cmake recipes) for this is that the upstream project does not support CMAKE_INSTALL_LIBDIR. Check if the upstream build system has some alternative means for specifying libdir -- this is surprisingly common with cmake projects. If not, you could add support for CMAKE_INSTALL_LIBDIR in the upstream build system (and add a patch to your recipe).
An alternative hack would be to add a do_install_append() that checks if ${libdir} is not /usr/lib/, and moves everything from ${D}/usr/lib/ to ${D}${libdir} in that case.
I am trying to use https://github.com/qiemem/ControlFlowExtension as an alternative to if-else.
I have it to added to the extensions folder(C:\Program Files (x86)\NetLogo 5.1.0\extensions). The extracted zipped folder from github.
In the NetLogo code I use the following,
extensions[ControlFlowExtension-master]
But it still shows me the following error:
There is no release for the extension yet. The zip file that you downloaded is just the source code and doesn't contain the compiled JAR files that you need to use the extension with NetLogo.
If you want to try it out, you will have to build it yourself. For that, you will need to install sbt. Then, open a command terminal and cd to the folder where you unzipped the file you downloaded from GitHub. This folder should be under the NetLogo extensions folder and be called cf (rename it if it is not the case). Once you are in the cf folder, run:
sbt package
This should build cf.jar and allow you to use the extension by putting
extensions [ cf ]
at the top of the code tab in your NetLogo model.
Be aware, though, that the extension is still very much experimental. There may be bugs. The syntax could still change. This is why Bryan did not put out an official release yet.