I'm working on Linux.
I have installed a ruby rpm on my system sing following command,
rpm –ivh zenith_ruby_1.8.6-1.0-2.el5.src.rpm
Now i have added some debugging statments in the source files of this rpm
and i want to rebuild this rpm with my changes in source file.
I tried using following command
rpmbuild -ba rpmbuild/SPECS/zenith_ruby-1.8.6-p369.spec
But execution of this commands leads to overwriting the source file that cause removal of by changes from source file.
Is there any way to re-build with our changes in source file?
You should make your changes a patch that gets applied during the build process.
See this tutorial for instructions
I found the solution for above problem.
We need to execute following command to build already installed RPM :
rpmbuild -bc --short-circuit rpmbuild/SPECS/zenith_ruby-1.8.6-p369.spec
Related
I have a rpm created for dev environment and CONTAINS a configuration file that points to dev. Now I have to create the rpm for another environment for which I need to replace just one file in the SOURCES folder and update the reference in .spec and rebuild it. Issue is that I don't have the .spec file that I used to create the rpm for dev.
So upon searching, came across rpmrebuild and I was able to see the .spec file in the editor.
When I give rpmrebuild command, the spec file opens in the editor.
Here's the small snippet from the file
/root/rpmbuild/SOURCES /root/rpmbuild/SOURCES
%files
%attr(0755, root, root) "/opt/**{replace/with/newfile/path**}"
But updating that that gives me - File not found: /root/.tmp/rpmrebuild.2345/work/root/opt/{path/to/newfile}
I don't know if I have to use rpmrebuild command with any --params in order to replace the file in the SOURCES and its reference in the .spec. There are no other changes to be made.
Please guide.
Note: I am a unix novice
I presume you do not have the src.rpm for this package. If you do, then it's very easy, simply install that with rpm -ihv /path/to/src/rpm as you would do with any RPM file. The contents, unless specified otherwise, will be extracted to ~/rpmbuild. The spec will be under ~/rpmbuild/SPECS, the sources under ~/rpmbuild/SOURCES, etc.
If you do not have the src.rpm but only the RPM itself, install the rpmrebuild package from the EPEL repos and then:
$ rpmrebuild -e -p /path/to/package
It will open the spec in your default editor. Edit it and save the spec wherever you want.
Then, assuming you have all the needed source files (declared in the spec using the SourceN directives), you can call:
$ rpmbuild -bb /path/to/spec
To rebuild the RPM from the edited spec.
I have a Yocto build for i.mx6 and I want to modify its Kernel. I figured that if I copy Kernel source outside the Yocto project and make my modifications without dealing with patches, I can speed things up significantly. But the thing is, the Kernel source I have to use is already patched and I want to fetch and continue working from there. I will work on the already-patched source files and re-arranging them is a painful process.
For starting point, my patches work fine, and I can get a working image using bitbake fsl-image-multimedia-full command. The Kernel source I want to use is created after this process.
I have tried copying the source under ..../tmp/work-shared/imx6qsabresd/kernel-source. Although make zImage and make modules finished without any trouble, manual building was not successful with an error in a dtsi file (Unable to parse...). Of course, I have checked the file and there was no syntax error.
Also, I checked the kernel source files I copied and it seems that the patches are successfully implemented.
Am I doing something wrong with the patches? With my manual build routine, I can build unpatched kernel source with no errors. I am sure that there are experienced Yocto users here that have their own workarounds to make this process shorter. So, any help is appreciated. Thanks in advance.
You can also edit files in tmp/work-shared/<machine>/kernel-source then compile modified kernel with bitbake -C compile virtual/kernel
My favorite method of doing kernel development in a Yocto project is to create an SDK and build the kernel outside of the Yocto system. This allows more rapid builds because make will only build new changes, whereas a kernel build within Yocto always starts from scratch.
Here are some of my notes on compiling the Linux kernel outside of the Yocto system. The exact paths for this will depend on your exact configuration and software versions. In your case, IMAGE_NAME=fsl-image-multimedia-full
Run bitbake -c populate_sdk ${IMAGE_NAME}. You will get a
self-extracting and self-installing shell script.
Run the shell script (for me it was
tmp/deploy/sdk/${NAME}-glibc-i686-${IMAGE_NAME}-cortexa9hf-neon-toolchain-1.0.0.sh),
and agree to the default SDK location (for me it was
usr/local/oecore-i686).
Source the scripts generated by the install script. I use the
following helper script to load the SDK so I don't have to keep
track of the paths involved. You need to source this in each time
you want to use the SDK.
enable_sdk.sh:
#!/bin/bash
if [[ "$0" = "$BASH_SOURCE" ]]
then
echo "Error: you must source this script."
exit 1
fi
source /usr/local/oecore-i686/environment-setup-corei7-32-${NAME}-linux
source /usr/local/oecore-i686/environment-setup-cortexa9hf-neon-${NAME}-linux-gnueabi
Copy the defconfig file from your Yocto directory to your kernel
directory (checked out somewhere outside of the Yocto tree) as
.config.
Run make oldconfig in your kernel directory so that the Linux
kernel build system picks up the existing .config.
Note: you may have to answer questions about config options that
are not set in the .config file.
Note: running make menuconfig will fail when the SDK is enabled,
because the SDK does not have the ncurses libraries set up
correctly. For this command, run it in a new terminal that has not
enabled the SDK so that it uses the local ncurses-dev packages you
have installed.
Run make -jN to build the kernel.
To run the new kernel, copy the zImage and ${NAME}.dtb files to
your NFS/TFTP share or boot device. I use another script to speed
up the process.
update_kernel.sh:
#!/bin/bash
set -x
sudo cp /path-to-linux-source/arch/arm/boot/dts/${NAME}.dtb /srv/nfs/${DEVICE}/boot/
sudo cp /path-to-linux-source/arch/arm/boot/zImage /srv/nfs/${DEVICE}/boot/
set +x
You can also point Yocto to your local Linux repo in your .bb
file. This is useful for making sure your kernel changes still
build correctly within Yocto.
SRC_URI = "git:///path-to-linux-source/.git/;branch=${KBRANCH};protocol=file"
UPDATE: Over a year later, I realize that I completely missed the question about broken patches. Without more information, I can't be sure what went wrong copying the kernel source from Yocto to an external build. I'd suggest opening a Bitbake devshell for the kernel and doing a diff with the external directory after manually applying patches to see what went wrong, or just copy the source from inside the devshell to your external directory.
https://www.yoctoproject.org/docs/1.4.2/dev-manual/dev-manual.html#platdev-appdev-devshell
When debugging certain commands or even when just editing packages, devshell can be a useful tool. When you invoke devshell, source files are extracted into your working directory and patches are applied.
Since it can't parse it, there seems to be a problem with patch. How do you patch the device tree? Are you patching it in the .bb file?
If so, check your patch for possible syntax errors, it's very easy to overlook the syntax errors in device tree. You can remove the patch and do it manually from bitbake -c devshell <kernel-name>
If not, please try to do it there and check again. Please share results if any of these helps you.
I am building rpm in RHEL-6 using rpmbuild command as
rpmbuild -bb rpm.spec
This command creates a temporary script which it executes while making rpm. Now the issue is that rpmbuild is creating some extra section in this tmp file which is causing rpm creation to fail. This extra section is mentioned neither in the build script of rpm nor in the rpm.spec file. I am not sure why this is happening. Can someone please suggest me what I might be missing?
I have created an rpm without source using the binary file I had been provided. In a nutshell, I am trying to automate a silent install of sybase client via an rpm. However I need help whether we can put the following silent install command in the %install section of the spec file -
setup.bin –f <responseFileName> -i silent -DAGREE_TO_SYBASE_LICENSE=true -DRUN_SILENT=true
Any help will be much appreciated.
If you want a script to be executed when you install a package, it must be put in the %post section. According to your comment, this is what you did.
The problem is that if you run the install script that way, rpm will not be able to track the installed files. It will not know that those files belong to the package, will not remove them when you uninstall the rpm, will not handle updates properly, etc. You will have a broken rpm.
If you can't build a proper rpm, just use a simple install script that does what you want.
I have a debian package that I built that contains a tar ball of the files, a control file, and a postinst file. Its built using dpkg-deb and it installs properly using dpkg.
The modification I would like to make is to have the installation directory of the files be determined at runtime based on an environment variable that will be set when dpkg -i is run on the deb file. I echo out the environment variable in the postinst script and I can see that its set properly.
My questions:
1) Is it possible to dynamically determine the installation directory at runtime?
2) If its possible how would I go about this? I have read about the rules file and the mypackage.install files but I don't know if either of these would allow me to accomplish this.
I could hack it by copying the files to the target location in the posinst script but I would prefer to do it the right way if possible.
Thanks in advance!
So this is what I found out about this problem over the past couple of weeks.
With prepackaged binaries you can't build a debian package with a destination directory dynamicall determined at runtime. I believe that this might be possible if installing a package that is built from source where you can set the install directory using configure. But in this case since these are embedded Ubuntu machines they don't have make so I didn't pursue such an option. I did work out a non traditional method (hack) for installing that did work. Since debian packages simply contain a tar ball relative to / simply build your package relative to a directory under /tmp. In the postinst script you can then determine where to copy the files from the archive into a permanent location.
I expected that after rebooting and the automatic deletion of the subdirectory under /tmp that dpkg might not know that the file package existed. This wasn't a problem. When I ran 'dpkg -l myapp' it showed as still installed. Updating the package using dpkg/apt-get also worked without a hitch.
What I did find is that if you attempted to remove the package using 'dpkg -r myapp' that dpkg would try and remove /tmp which wasn't good. However /tmp isn't easily removed so it never succeeded. Plus in our situation we never remove packages but instead simply upgrade them.
I eventually had to abandon the universal package due to code differences in the sources resulting in having to recompile per platform but I would have left it this way and it did work.
I tried using --instdir to change the install directory of the package and it does relocate the files but dpkg fails since the dpkg file can't be found relative to the new instdir. Using --instdir is sort of like a chroot. I also tried --admindir and --root in various combinations to see if I could use the dpkg system relative to / but install relocate the files but they didn't work. I guess rpm has a relocate option that works but not Ubuntu.
You can also write a script that runs dpkg-deb with a different environment for 6 times, generating 6 different packages. When you make a modification, you simply have to run your script, and all 6 packages gets generated and you can install them on your machines avoiding postinst hacking!
Why not install to a standard location, and simply use a postinst script to create symbolic links to the desired location? This is much cleaner, and shouldn't break anything in dpk -I.