Red Hat Bugzilla – Bug 103455
rpmbuild crashes with broken pipe during check-files
Last modified: 2007-04-18 12:57:17 EDT
Description of problem:
When RPM does an execv(/usr/lib/rpm/check-files ) I get a broken pipe:
getOutputFrom(): Broken pipe
and the build crashes.
Version-Release number of selected component (if applicable):
Happens every time with certain RPM file lists. It SEEMED to happen less often
when I took out the wild cards and just listed all the files to go into the
RPM, but I have RPM specification files which crash with only 20 or so files in
the file list.
Steps to Reproduce:
1. I have to run rpmbuild -bb with my RPM spec file.
It's completely reporducible with my current specification file
Does you package have a BuildRoot:?
Either add a BuildRoot: or disable the files check by
My RPM cannot use a BuildRoot because it includes files in /etc/rc.d as well as in /home/<...> and
RPM will not let me set a BuildRoot of /
I added the line
and it had no effect, I still get a broken pipe when RPM runs check-files
When I moved that statement into the RPM definition file, I was told that a tag of 0 was an error.
I may be putting this line inthe wrong place. I am sorry not to know more about RPM; the book
Maximum RPM does not discuss the file check.
All packages can use a BuildRoot:, copy the files from
wherever to same path in $RPM_BUILD_ROOT.
$RPM_BUILD_ROOT usage is going to be mandatory in rpm, that's why RPM_BUILD_ROOT
is preferred to disabling.
I had to wait a few days do calm down before I responded to your latest.
I am dismayed that Red Hat would declare that it's NOTABUG for RPM to crash
when I give it a valid RPM spec file. The fact that check-files crashes when I
don't have an RPM build root is a BUG as I see it. How can you say it's not a
bug for RPM to crash? Even if the input were invalid, it ought at least to
emit a sensible error message.
Is this a new Red Hat policy, saying that it's NOTABUG to add new features to
longstanding system routines so that they crash without error messages on valid
Your solution of using a build root and then moving the files out of the build
tree to wherever they actually go will make my package work on teh target
computer, but what about the RPM database? Suppose I build an RPM that puts a
file in /etc/rd.c/init.d as Apache, Tomcat, and MySQL do. When the old version
of RPM installs a file, the RPM database knows the package the file came from;
when I query the RPM database, I can find the name of the package which
installed the file. This is HUGELY helpful.
If I move the file in the post-install script, won't this bypass the RPM
database? My customers won't appreciate my filling system directories with
files they can't trace to RPM packages, that's what Windows applications do.
What about making automatic backups of existing configuration files as done by
the currently-supported "Conf" directive?
I have NO INTEREST in a list of files which are not part of my RPM. My product
consists of a number of .jsp files which are sold separately depending on what
features the customer buys. Most RPMs always include some but not all of
the .jsp files so a list of omitted files is of no value whatsoever.
check-files appears to be something you added to RPM and made it the default
behavior like the Microsoft animated paper clip. Unlike the paper clip, which
goes away if I tell it to, I can't get check-files to get out of my way so I
can get my work done.
PLEASE send me a patch to check-files so it will exit cleanly so I can get my
work done. Your insructions how to turn it off did not work. Replacing
the "exit 1" with "exit 0" did not work, the socket still breaks. If I change
the "exit 1" to "exit 100" will I be able to build RPMs?
If not, I'll have to revert to TAR files, you've broken RPM so that I can't use
I say it's a bug.
Created attachment 117671 [details]
Checkfile which does nothing if no BUILD_ROOT is defined
This should help you building this RPMs :)
what about just displaying a warning message if no build_root is defined??
i think if a application exits with broken pipe ERROR!! this is always a bug,
that needs to be resolved.