139638 - source rpm fails to build because of regxpcom error

Status: RESOLVED INCOMPLETE

(Firefox Build System :: General, defect)

Description

[Al Koskelin]

From Bugzilla Helper:
User-Agent: Mozilla/4.78 [en] (X11; U; Linux 2.4.9-31custom i686)
BuildID:    0.9.9 & 1.0-rc1

With both 0.9.9 & 1.0-rc1, mozilla fails to build correctly from the source rpm.
I run the command `rpm --rebuild mozilla-0.9.9-0.src.rpm` and let it compile for
quite a while and then it errors out saying, among other things, "regxpcom: No
such file or directory". I run Red Hat 7.2 but I have talked to other people
that have built them fine on other RH 7.2 distro so I am at a loss.

Reproducible: Always
Steps to Reproduce:
1.rpm --rebuild mozilla-0.9.9-0.src.rp
2.wait

Actual Results:  [snip]
+ ./regxpcom
/var/tmp/rpm-tmp.90982: ./regxpcom: No such file or directory
error: Bad exit status from /var/tmp/rpm-tmp.90982 (%install)


RPM build errors:
    cannot open Depends index using db3 - Cannot allocate memory (12)
    Bad exit status from /var/tmp/rpm-tmp.90982 (%install)


Expected Results:  The RPM should build correctly and completely.

Comment 1

[hacker formerly known as [e-mail]]

rpms -> blizzard

Comment 2

[Christopher Blizzard (:blizzard)]

RPM build errors:
    cannot open Depends index using db3 - Cannot allocate memory (12)
    Bad exit status from /var/tmp/rpm-tmp.90982 (%install)

There's your error.  That doesn't have anything to do with Mozilla as near as I
can tell.

Comment 3

[Al Koskelin]

I fixed the db3 error by upgrading my db1 and db1-devel packages(RPMs). Now that
I look back on it, I got that error before while building other source RPMs, but
it's never really caused a problem. However, even after that was fixed, the
regxpcom error still prevents mozilla from building. This is the last 8 lines
that are now ouput before the rpm command fails:

[snip]
+ MOZILLA_FIVE_HOME=/var/tmp/mozilla-root/usr/lib/mozilla
+ ./regxpcom
/var/tmp/rpm-tmp.16597: ./regxpcom: No such file or directory
error: Bad exit status from /var/tmp/rpm-tmp.16597 (%install)


RPM build errors:
    Bad exit status from /var/tmp/rpm-tmp.16597 (%install)

Comment 4

[Christopher Blizzard (:blizzard)]

Are you messing with the build options or anything?  Why is regxpcom not being
copied to the install root?  The build is extremely loud so the clue to your
problem is somewhere in the build.  Run the build from inside script for clues.

Comment 5

[Al Koskelin]

Sorry, but I didn't do anything with the build options. I just run rpm --rebuild
mozilla-0.9.9-0.src.rpm (or mozilla-1.0rc1-0.src.rpm) from the freshly download
RPM. I redirected all output to a file and I don't see anything suspicious until
that error. I've (temporarily) posted the output at:
http://linuxgames.com/alkini/mozilla/moz_build-1.0-rc1.out.gz

Other things that seem interesting to note:

1) in the RPM output, it mentions this:
`regxpcom' -> `/var/tmp/mozilla-root//usr/lib/mozilla/regxpcom'
well, that file that it's referring to is a symbolic link that points to
../../xpcom/tools/registry/regxpcom, which does not exist. In fact, the entire
directory /var/tmp/mozilla-root/usr/xpcom does not exist.

2) building mozilla manually seems to work fine. In
/usr/src/redhat/BUILD/mozilla I ran a simple "make" and everything seemed to
compile fine. Is that what you meant by "Run the build from inside script for
clues" ?

Comment 6

[Christopher Blizzard (:blizzard)]

I suspect that the cp command isn't following the symlinks, as it should.  What
linux distro is this, anyway?

Comment 7

[Al Koskelin]

Like I mentioned in the original report, I run Red Hat 7.2 but I'm fairly
certain that I have talked to other people that have built the source RPMs fine
on other RH 7.2 installations so I am not sure what's going on.

Comment 8

[Christopher Blizzard (:blizzard)]

I've been building on 7.x for a long time, including 7.2 and I've never had this
problem.  There has to be something different about your setup.  The fact that
the symlink is being copied instead of following it is the big clue.

Comment 9

[Keyser Sose]

*** Bug 138387 has been marked as a duplicate of this bug. ***

Comment 10

[Keyser Sose]

Marking NEW based on dupe but this could be long gone by now..

Comment 11

[Aleksey Nogin]

IMHO the dup "direction" should be reverced - bug 138387 has tons of usefule
information (backtraces, etc) that this one does not have.

Comment 12

[Keyser Sose]

Resetting the target milestone. As long as we know the other bug has the info
thats fine thanks for pointing that out.