[PLUG] Need help with making a RPM

[Karl M. Hegbloom]

Richard Kurth <rkurth at starband.net> writes:

>  I need some help with the building of an RPM. What would case a
>  Segmentation fault I get one when it is reading the files list. It
>  does not tell me where the problem is and I can not find anything
>  on the RPM mail-list or any of the how-to's that are out there. If
>  I don't have a file list it does not give me a Segmentation fault
>  and creates the RPM but with out a file list there are no files
>  loaded in the RPM

A segmentation fault is when a program attempts to access memory
outside of the region allocated to it by the operating system.  There
are features of the CPU that are utilized by the operating system to
implement this.  (It's part of the virtual memory subsystem.)  You
will not find much about that in the HOWTO's, but you will find quite
a lot in textbooks about operating systems.  There are several good
choices of reading material on the subject available at Powell's
Technical Bookstore.  It's not 15 days for dummies type of reading.

So anyway, what's happening is that "rpm" has a bug that is triggering
a segmentation violation.

What you can do is turn on core dumps in your shell, with, assuming
you use "bash", "ulimit -c unlimited".  Then, run the command again,
and wait for it to dump core.  Then, you type "gdb rpm core", and open
the core dump in the debugger.  Now you can type "where" and attempt
to get a stack trace showing where the core dump occured.  Chances are
that you will not be able to get any useful information, however,
since the "rpm" binary has most likely been stripped (info binutils)
and there's no way for GDB to map raw addresses to function names or
variable names.  If this is the case, which it most likely is, you
will need to get an unstripped copy of "rpm" and try again...

By the way, if you have a core file and don't know what created it,
just type "gdb /bin/ls core" and GDB will tell you it's not a core
from "/bin/ls", then tell you what program created that core dump.

> Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.77827
> + umask 022
> + cd /usr/src/redhat/BUILD
> + rm -rf /usr/src/redhat/BUILD/autoserv
> + zcat /usr/src/redhat/SOURCES/autocontrolpro-3.0.tar.gz
> + tar -xf -
> + exit 0
> Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.64205
> + umask 022
> + cd /usr/src/redhat/BUILD
> + cp -a /usr/src/redhat/BUILD/autoserv /usr/
> + cp /usr/src/redhat/BUILD/autoserv/autoserv /etc/rc.d/init.d/
> + /usr/lib/rpm/brp-compress
> + /usr/lib/rpm/brp-strip
> + /usr/lib/rpm/brp-strip-comment-note
> Processing files: autocontrolpro-3.0-0
> Segmentation fault

I find it amusing that RPM reimplements the Make utility like that.
It's like that old adage that "those who do not study Unix are doomed
to reimplement it, poorly".  Debian's package build system is Makefile
driven.  A debian/rules script is a Makefile named "rules", marked
executable, with a shebang line that looks like:

8<------------------------------------------------------------>8
#!/usr/bin/make -f
# ...
8<------------------------------------------------------------>8

... so that it can be run like a script.

Also, packages are NEVER built as root, since once in a while, an
upstream "install" target will have a missing ${DESTDIR} or somesuch,
and wreak major havoc with the builder's computer.  So, the right way,
on Debian is to use "fakeroot", like this:

nonroot:~/src/pkg% fakeroot debian/rules binary

That will build the software, install it to a staging area, then
package it into a .deb package.

-- 
As any limb well and duly exercised, grows stronger,
the nerves of the body are corroborated thereby. --I. Watts.  .''`.
 Debian -- The blue collar Linux distribution.               : :' :
 <URL:http://www.debian.org/social_contract>		     `. `'