Closed
Bug 518401
Opened 16 years ago
Closed 16 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•16 years ago
|
||
You can't just remove that file, it's a makefile that we need to build things.
Comment 2•16 years ago
|
||
Clobberer lets you clobber l10n builders.
| Reporter | ||
Comment 3•16 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•16 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•16 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•16 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•16 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•16 years ago
|
||
Assignee: nobody → benjamin
Attachment #402924 -
Flags: review?(ted.mielczarek)
Comment 9•16 years ago
|
||
Comment on attachment 402924 [details] [diff] [review]
Use _topsrcdir instead, rev. 1
r=me fwiw.
Attachment #402924 -
Flags: review+
Updated•16 years ago
|
Attachment #402924 -
Flags: review?(ted.mielczarek) → review+
| Assignee | ||
Comment 11•16 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Updated•16 years ago
|
Updated•16 years ago
|
Updated•8 years ago
|
Product: Core → Firefox Build System
You need to log in
before you can comment on or make changes to this bug.
Description
•