i'm trying to apply a patch during the creation of my image with bitbake commande.
i have my file: u-boot-tftp.pacth under the directory: /file/u-boot-tftp.
here is my u-boot-tftp.bbappend :
DEPENDS += "dtc-native"
SRC_URI = "file://u-boot-tftp.patch"
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
while building my image, im having this error :
Applying patch u-boot-tftp.patch
can't find file to patch at input line 3
Perhaps you used the wrong -p or --strip option?
No file to patch. Skipping patch.
2 out of 2 hunks ignored
Patch u-boot-tftp.patch does not apply (enforce with -f)
i tried to run the unpack commande : bitbake -c unpack -f u-boot-tftp but it din't work, i looked it up the internet and nothing seems to work.
Any help would be appreciated.
thanx
best regards.
You are overriding the SRC_URI variable in your bbappend. So the original U-Boot sources are not used and the U-Boot recipe has only your patch as the whole source.
Use SRC_URI += instead of SRC_URI = in you bbappend (like you did with DEPENDS).
can't find file to patch at input line 3
From the above error, it seems that yocto is unable to locate the patch. You can either update FILESEXTRAPATHS_prepend path or change the directory where the patch is located.
While executing do_patch(), it will search patch for multiple paths which can be seen in build/tmp/work//u-boot-tftp//temp/log.do_patch. Check whether it searches for the patch in "/file/u-boot-tftp" folder or not. and update the path accordingly.
Related
I'm playing with a Yocto project that has in its conf/bblayers.conf file the following line:
ADDONSLAYERS += "${#'${OEROOT}/layers/meta-qt5' if os.path.isfile('${OEROOT}/layers/meta-qt5/conf/layer.conf') else ''}"
I partially bitbaked the project but now I want to try to disable the whole meta-qt5 layer.
After commenting out the line above, how to remove the already built files from the output folder and go on with the others?
I tried with bitbake -c cleansstate meta-qt5 but it doesn't work. I guess it works with recipes only, and not with whole layers.
Easiest way to clean a build is to remove TMPDIR temporary folder (default is <build>/tmp).
That will remove previous compilation results, but those are also kept in SSTATE_DIR cache folder. Next build will not rebuild all, it will reuse cache results to speed it up.
Then, you can clean your cache folder for obsolete entries with sstate-cache-management.sh script:
# Example of usage (after sourcing oe-init-build-env)
sstate-cache-management.sh --cache-dir=../sstate-cache -d -y
In bitbake disable downloading the module from repository every time i compiles the module. compile the module not download it everytime.
tried using noexec flag in the recipe but it didn't help.
Regards
Mayank
bitbake usually caches downloads in ${DL_DIR} (which defaults to ${TOPDIR}/downloads.
If it always downloads a particular component you must be either
changing the SRC_URI in the recipe
changing something else significant in the recipe
using something like HEAD in the SRC_URI which is changing between builds.
It might help if you posted the recipe.
See the documentation for DL_DIR here
I'm kinda a new to writing spec files and building RPM's. Currently I have one RPM that is supposed to deploy some files in 1 of 2 possible directories that will vary with the OS.
How can I, within the %files section, verify them? I can't use variable...I can't verify both paths because one will for sure fail...I tried to define a macro earlier in the %install section but it will be defined just once and won't be redefined on every RPM installation...
what can I do here?
Thanks
I had a similar situation where additional files were included in the RPM in case of a DEBUG build over and above all files in the RELEASE build.
The trick is to pass a list of files to %files alongwith a regular list of files below it:
%install
# Create a temporary file containing the list of files
EXTRA_FILES=$RPM_BUILD_ROOT/ExtraFiles.list
touch %{EXTRA_FILES}
# If building in DEBUG mode, then include additional test binaries in the package
%if %{build_mode} == "DEBUG"
# %{build_mode} is a variable that is passed to the spec file when invoked by the build script
# Like: rpmbuild --define "build_mode DEBUG"
echo path/to/file1 > %{EXTRA_FILES}
echo path/to/file2 >> %{EXTRA_FILES}
%endif
%files -f %{EXTRA_FILES}
path/to/release/file1
path/to/release/file2
In your case, you can leverage the %if conditional in the %install section, use the OS as a spec variable passed to rpmbuild (or detect it in the RPM spec itself) and then pass the file containing the list to %files
The %files section can have variables in it, but usually this would be something like your path that is defined so you don't have to repeat it a bunch. so %{long_path}/file_name, where long_path was defined earlier in the spec file. the %files section is all the information that goes into the RPM database, and is created when you build the RPM so you won't be able to change those values based on machine information when installed.
If you really want to do this, you could include a tar file inside of the main tarball that gets extracted depending on certain conditions (since the spec file is just bash). Now keep in mind this is an awful idea. The files won't be tracked by the RPM database, so when you remove the RPM these files will still exist.
In reality you should build two RPMs, this will allow for better support going forward into the future in the event you have to hand this off to someone, as well as preserving your own sanity a year from now when you need to update the RPM.
This is how I solved my problem
step 1 :
In Build section .. somewhere I wrote :
%build
.....
#check my condition here & if true define some macro
%define is_valid %( if [ -f /usr/bin/myfile ]; then echo "1" ; else echo "0"; fi )
#after his normal continuation
.....
...
Step 2: in install section
%install
......
#do something in that condition
if %is_valid
install -m 0644 <file>
%endif
#rest all your stuff
................
Step 3:in files section
%files
%if %is_valid
%{_dir}/<file>
%endif
That's it
It works.
PS : I cannot give you full code hence giving all useful snippet
Forrest suggests the best solution, but if that is not possible practical you can detect the OS version at runtime in the post-install section, move the script to the appropriate location, and then delete it post-uninstall, eg:
# rpm spec snippets
%define OS_version %(hacky os detection)
...
Source2: script.sh
...
%install
install %{_sourcedir}/script.sh %{buildroot}/some/known/location
...
%post
%if %{OS_version} == "..."
mv /some/known/location/script.sh /distro/specific/script.sh
%elif %{OS_version} == "..."
...
%preun
rm -rf /all/script/locations
Much more error prone than building different RPMs on different OSes, but will scale a little better if you need to support many different OSes.
I've a master project with many sobprojects, that I compile using qmake.
In a sub-project I must copy some files before compilation (some header file). I've seen some command to perform operation before and after linking, but I'd like to know if it's possible to perform some shell operation before start compilation. I can't refer to them, but I must to copy them (don't ask why please, it's not my fault :-( ). Any suggestion?
Thanks in advance for your replies.
see my last answer on nearly the same question:
Copy some file to the build directory after compiling project with Qt
the only difference for you is to change in point 5:
POST_TARGETDEPS += copyfiles ## copy files after source compilation
to:
PRE_TARGETDEPS += copyfiles ## copy files before source compilation
when executing qmake there have to exist all files already in filesystem before
I think what you want to do can be accomplished with careful use of the QMAKE_EXTRA_COMPILERS and QMAKE_EXTRA_TARGETS variables. The Qt Labs article The Power of QMake gives a reasonable introduction to it. The ".commands" part of the extra compiler can be any arbitrary command, including a shell command.
The other suggestion I found in this e-mail exchange is to "... take a look at mkspecs/features/*.prf - especially those of moc and uic.." for other possible ways to do it.
I also just played around with QMAKE_EXTRA_TARGETS to solve the question, but could not manage to get it done ;)
One other (simple) solution which might work for you is to wrap the call to gcc/g++: in the .pro file, set QMAKE_CXX=./g++Wrapper and in the g++Wrapper shell script, call the original compiler while doing anything you want before and after the call:
#!/bin/bash
DoWhateverYouWantBeforeCompilation
g++ $*
DoWhateverYouWantAfterCompilation
By evaluating the command line parameters, you could also restrict your actions to specific files.
how can I change Qt install path after I building it ?
Example : qmake.exe search binaries to original install path, how can I change/redefine it ?
Thanks.
Edit : I finally found this patch to apply to Qt :
http://ftp-developpez.com/qt/binaires/win32/patcher/QtPatcher.7z
http://ftp-developpez.com/qt/binaires/win32/patcher/QtPatche_src.7z
I was looking into this and found a way that works (in qt 4.7.2) by customizing qt with a qt.conf file.
In my case, I added a qt4-4.7.2/bin/qt.conf (I think it must be in the same place as the qmake executable)
With the following contents:
[Paths]
Prefix = c:/my_path/to/qt4-4.7.2
and the qmake -query started returning the proper paths!
See: http://qt-project.org/doc/qt-5.0/qtdoc/qt-conf.html for more details
You can change path to binaries and many other hardcoded paths in qmake using qmake -set command.
See Configuring qmake's Environment for details.
I can answer it for windows, not so sure about others. Remove the path variables if any present in the environmental variable PATH.
In Qt-Creator goto,
Tools->Options->Qt4->Qt Versions
In the right hand side area, you will find Auto- Detected and Manual. Under Manual add a new entry by clicking the + symbol in the far right. Specify the QMake location by clicking Browse . Change the Default Qt Version to your newly specified Version. Of course, you have to re -build the application. Hope that it helps.
On Unix/Linux:
You can also use LD_LIBRARY_PATH+PATH for workarounds. But still, some defaults are hardcoded in the code, yes. A rebuild is a must.
On unix you can make a symbolic link, otherwise you probably need to rebuild it
This worked for me with Qt 5.15.2:
cd ~/Qt/Tools/QtCreator/share/qtcreator/QtProject
grep -inr '<olduser>' | cut -d: -f1 | xargs sed -i 's/<olduser>/<newuser>/g'
Replace <olduser> and <newuser> obviously.