Clobber win32 l10n mozilla-central builders to pick up fix for "msys-perl-wrapper" message

RESOLVED FIXED in mozilla1.9.3a1

Status

defect
P2
normal
RESOLVED FIXED
10 years ago
Last year

People

(Reporter: armenzg, Assigned: benjamin)

Tracking

Trunk
mozilla1.9.3a1
x86
macOS
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

Reporter

Description

10 years ago
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"?
You can't just remove that file, it's a makefile that we need to build things.
Clobberer lets you clobber l10n builders.
Reporter

Comment 3

10 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

10 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

10 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

10 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

10 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

10 years ago
Assignee: nobody → benjamin
Attachment #402924 - Flags: review?(ted.mielczarek)

Comment 9

10 years ago
Comment on attachment 402924 [details] [diff] [review]
Use _topsrcdir instead, rev. 1

r=me fwiw.
Attachment #402924 - Flags: review+
Attachment #402924 - Flags: review?(ted.mielczarek) → review+
Reporter

Updated

10 years ago
Duplicate of this bug: 519517
Assignee

Comment 11

10 years ago
http://hg.mozilla.org/mozilla-central/rev/8dfe26c74f08
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Blocks: C192ConfSync
Flags: in-testsuite-
Target Milestone: --- → mozilla1.9.3a1
Blocks: 550657
No longer blocks: C192ConfSync
Blocks: 566167

Updated

Last year
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.