Developing and Debugging Packages with tsrpm

This document describes how to build a package with the correct dependencies for a new platform using tsrpm. If you have a project that you want to package and redistribute as an RPM, please review the appropriate sections in the RPM Tutorial, especially the section about creating new .spec files, located at http://www.rpm.org/max-rpm/s1-rpm-build-creating-spec-file.html.

Porting a New Package

tsrpm is aware of many common issues in building RPMs for non-x86 targets. The porting effort for a new package source RPM often first involves ensuring that you are building a package after you build its dependencies. The general procedure is as follows:

1. Collect all the relevant source packages – This should include the main package in which you are interested and its dependencies.
2. Unpack the packages using tsrpm --extract – Extract the packages into the source layout that tsrpm expects.
3. Ensure that you build the packages in the order of dependencies.
4. Extend your local build environment by cross-installing relevant dependencies.
5. Finally, build the main package of interest.

If the out-of-the-box build fails for a package, some additional work might be required. Use the following tips to make the build process smoother:

• Avoid creating cross-compilation patches, since these are difficult to maintain across package revisions.
• When possible, add package hints to allow the RPM to build without making additional modifications. Check the README file in the tsrpm directory for a list of the environment variables, functions, and so forth, which control tsrpm.
• Review other .tshint files within the TimeSys-supplied source RPMs for information that might apply to your situation.
• If you must change the .spec file, try to make the changes in a way that will help future maintainers. For example, rather than replacing all occurrences of gcc with $TSRPM_CROSS_COMPILE-gcc, use %{_cc} instead.

Debugging Package Builds

If packages do not build out-of-the-box with tsrpm, the next task is to debug the build. Sometimes this is a matter of iterating through package configuration settings to get the build working. At other times, active edit-compile-build-debug cycles are required. Both of these activities are simplified by working in the tsrpm shell environment. For example, to enter the tsrpm shell environment for troubleshooting dropbear builds, do the following:

 RPM_PACKAGE_NAME=dropbear tsrpm --target=mipsel --run-tool \
   cd mipsel/BUILD/dropbear-0.9.1-2/\; exec bash
bash 2.05b$ export TSRPM_HINTS='dropbear.tshint'
bash 2.05b$ export TERM=xterm

After the tsrpm environment is configured as shown in the previous example, you can iterate on configure-build-edit-debug steps for troubleshooting builds or runtime failures while porting the package using your favorite command line tools.

Another convenient approach to troubleshooting builds is simply to run individual commands inside the tsrpm environment. For example, to perform a verbose compilation of file foo.c, just invoke the compilation as a tsrpm --run-tool command:

tsrpm --target=ppc7xx --run-tool ppc7xx-linux-gcc -v foo.c

Tracing tsrpm Build Overrides

tsrpm modifies the invocation and the behavior of many programs that run as a part of an RPM build. This is useful when troubleshooting builds; for example, configure failures are fairly common. Touching the configure.verbose file in your working directory allows you to trace the execution of the configure script when it runs under the control of tsrpm. This tracing method will also work for all programs that are in the /lib/override directory of your tsrpm installation. Touching the runnext.verbose file shows you which commands and command line arguments that tsrpm is actually running.