Closed
Bug 518401
Opened 14 years ago
Closed 14 years ago
Clobber win32 l10n mozilla-central builders to pick up fix for "msys-perl-wrapper" message
Categories
(Firefox Build System :: General, defect, P2)
Tracking
(Not tracked)
RESOLVED
FIXED
mozilla1.9.3a1
People
(Reporter: armenzg, Assigned: benjamin)
References
Details
Attachments
(1 file)
858 bytes,
patch
|
ted
:
review+
Pike
:
review+
|
Details | Diff | Splinter Review |
This changeset http://hg.mozilla.org/mozilla-central/rev/f655090e14c3 should have fixed the "./build/msys-perl-wrapper: No such file or directory" we are getting in Win32 mozilla-central locales. I will probably have to do manual clobbering on the slaves since I don't think the clobberer website allows us to clobber it. Would it be sufficient to just remove "build/automation-build.mk"?
Comment 1•14 years ago
|
||
You can't just remove that file, it's a makefile that we need to build things.
Comment 2•14 years ago
|
||
Clobberer lets you clobber l10n builders.
Reporter | ||
Comment 3•14 years ago
|
||
I have clobbered: a) Firefox mozilla-central linux l10n b) Firefox mozilla-central linux l10n build through the clobberer page I will check it tomorrow
Reporter | ||
Comment 4•14 years ago
|
||
(In reply to comment #3) > I have clobbered: > a) Firefox mozilla-central linux l10n > b) Firefox mozilla-central linux l10n build > through the clobberer page > > I will check it tomorrow I did it for win32 not linux (wrong copy/paste)
Reporter | ||
Comment 5•14 years ago
|
||
I will have to check this tomorrow since today's nightly did not run due to the downtime (From the manually triggered l10n builds it seems that it did not get fixed)
Reporter | ||
Comment 6•14 years ago
|
||
The moz-central win32 L10n builders have been clobber twice already and the "msys-perl-wrapper" still does show up. I will have to work on a win32 slave and see if I can fix. Anyone has any pointers for this?
Comment 7•14 years ago
|
||
OK, I think I got it. In the l10n repacks, we run configure directly, i.e., not via client.mk. Thus ${srcdir} in configure.in is the relative path, which breaks. I've fixed other bugs for calling configure with a relative path, so I guess we should fix this one, too? Moving over to Core Buildconfig for that.
Assignee: armenzg → nobody
Component: Release Engineering → Build Config
Product: mozilla.org → Core
QA Contact: release → build-config
Version: other → Trunk
Assignee | ||
Comment 8•14 years ago
|
||
Assignee: nobody → benjamin
Attachment #402924 -
Flags: review?(ted.mielczarek)
Comment 9•14 years ago
|
||
Comment on attachment 402924 [details] [diff] [review] Use _topsrcdir instead, rev. 1 r=me fwiw.
Attachment #402924 -
Flags: review+
Updated•14 years ago
|
Attachment #402924 -
Flags: review?(ted.mielczarek) → review+
Assignee | ||
Comment 11•14 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/8dfe26c74f08
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Updated•14 years ago
|
Updated•14 years ago
|
Updated•6 years ago
|
Product: Core → Firefox Build System
You need to log in
before you can comment on or make changes to this bug.
Description
•