Closed Bug 513067 Opened 15 years ago Closed 15 years ago

"make install" broken when objdir path contains '+'

Categories

(Firefox Build System :: General, defect)

All
Linux
defect
Not set
normal

Tracking

(status1.9.2 beta1-fixed)

RESOLVED FIXED
Tracking Status
status1.9.2 --- beta1-fixed

People

(Reporter: fta+bugzilla, Assigned: fta+bugzilla)

References

Details

(Keywords: regression)

Attachments

(1 file)

my latest ubuntu build fails because modules/* is now missing at install time.

http://launchpadlibrarian.net/30909179/buildlog_ubuntu-karmic-i386.firefox-3.7_3.7~a1~hg20090827r32030%2Bnobinonly-0ubuntu1~umd1_FAILEDTOBUILD.txt.gz

In yesterday's build, it contained modules/distribution.js

http://launchpadlibrarian.net/30874616/buildlog_ubuntu-karmic-i386.firefox-3.7_3.7~a1~hg20090826r31978%2Bnobinonly-0ubuntu1~umd2_FULLYBUILT.txt.gz

Looking at the build logs, it seems the installer changed with bug 463605.
This is keeping Linux distros from being able to package builds.
Blocks: 463605
Keywords: regression
Product: Firefox → Core
QA Contact: build.config → build-config
Flags: blocking1.9.2?
Is this via "make install" or "make package"?
Also, this didn't land on 1.9.2.
Flags: blocking1.9.2? → blocking1.9.2-
Our nightly builds still contain the modules dir (including distribution.js), so I'm not sure what's happening here.
(In reply to comment #2)
> Is this via "make install" or "make package"?

make install

(In reply to comment #3)
> Also, this didn't land on 1.9.2.

Oops, my mistake.
Ignore the linkification of the the rXXXXX to point at SVN, that was unintended.
Regression range includes bug 463605.

We need to get this fixed soon, as it's blocking Ubuntu from doing nightly builds of Firefox 3.7, which are being used by their testing community.

Ted/Benjamin, can you look into this?
Can Ubuntu provide a patch? They're going to want to test it in their own environment, no doubt.  Or can they at least narrow it down to a regressing changeset?  Help us help you.
(In reply to comment #9)
> Can Ubuntu provide a patch? They're going to want to test it in their own
> environment, no doubt.  Or can they at least narrow it down to a regressing
> changeset?  Help us help you.

As has been mentioned in numerous comments above, bug 463605 is the regressor.
I heard "seems like" in comment 0, and "appears in the long list" in 8 -- I didn't hear that someone had tested that it actually caused the problem.  The rest of my question stands.
It's very hard to try to figure out a problem if you can't see what commands being executed, or be provided with any information on how Ubuntu builds Firefox (eg how the single package is being split into several). Both of which make the logs in comment #0 fairly opaque. "Help us help you"
the problem is quite simple.
Here is the result of "make install DESTDIR=debian/tmp":
http://paste.ubuntu.com/261696/

Everything after line 67 is clearly wrong, there's an absolute path somewhere.
It's visible in the build logs i've provided in comment 0.
...like when it went from:

/usr/bin/perl -I../../xpinstall/packager -e 'use Packager; Packager::Copy( "../../dist", "../../dist/firefox-3.7", "packages-static", "unix", 1, 0, 1);'

to:

/usr/bin/perl -I../../xpinstall/packager -e 'use Packager; Packager::Copy( "/tmp/buildd/firefox-3.7-3.7~a1~hg20090829r32079+nobinonly/build-tree/mozilla/browser/installer/../../dist", "/tmp/buildd/firefox-3.7-3.7~a1~hg20090829r32079+nobinonly/build-tree/mozilla/browser/installer/../../dist/firefox-3.7", "packages-static", "unix", 1, 0, 1);'
when using absolute *src* paths, Packager.pm fails for wildcards:
http://paste.ubuntu.com/262003/
I changed to absolute paths because with relative paths, listing directories in the packaging manifest was broken for me on Mac. Also, in light of the usage documentation here:
http://mxr.mozilla.org/mozilla-central/source/xpinstall/packager/Packager.pm#539
it clearly wants absolute paths.

I'll update my Linux tree and give it a try.
Summary: install regression → "make install" broken on Ubuntu builds
I can't reproduce this running "make install DESTDIR=foo" from the objdir of my build on Ubuntu 9.04. Perhaps this is specific to something else in the Ubuntu build process?
Attached patch fix installerSplinter Review
The important part is that I build in "/tmp/buildd/firefox-3.7-3.7~a1~hg20090829r32079+nobinonly/build-tree", i.e. with a "~" in the path.
Since you moved to absolute paths, that "~" became relevant, especially as the installer is written in Perl and uses regular expressions.

Patch attached. wfm.
Attachment #397610 - Flags: review?
Summary: "make install" broken on Ubuntu builds → "make install" broken when objdir path contains ~
It's not clear to me what this patch fixes. Where are the tildes being mangled in that script? They're not special in the regex, are they?
Attachment #397610 - Flags: review? → review?(ted.mielczarek)
Oops, i meant the "+".

$ perl
$a = "foo+bar";
$b = "/$a/baz";       
print "0: '$b'\n";
$b =~ s/$a//;
print "1: '$b'\n";   
$b =~ s/\Q$a\E//;
print "2: '$b'\n";
0: '/foo+bar/baz'
1: '/foo+bar/baz'
2: '//baz'
Yes, we need to quote things when used as regexen like this -- good find.  Fabien, can you see if there are other such places in the installer code that need help?
Summary: "make install" broken when objdir path contains ~ → "make install" broken when objdir path contains '+'
I checked for all regexps using $srcdir, found & fixed the two instances.
All other =~ (in Packager.pm) are fine.
Comment on attachment 397610 [details] [diff] [review]
fix installer

Ah, thanks for the detective work and the explanation here. Just another reason to hate Packager.pm. (bug 511648 can't get fixed soon enough!)
Attachment #397610 - Flags: review?(ted.mielczarek) → review+
Assignee: nobody → fta+bugzilla
http://hg.mozilla.org/mozilla-central/rev/370ff63d1a86
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: