Closed Bug 500205 Opened 13 years ago Closed 13 years ago

L10n repack fails if ChatZilla or venkman are missing from build

Categories

(SeaMonkey :: Build Config, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
seamonkey2.0b1

People

(Reporter: kairo, Assigned: kairo)

Details

Attachments

(2 files, 1 obsolete file)

I did the first bunch of release automation tests with ChatZilla excluded as I didn't have a staging CVS and didn't want to tag any live repo. What I did find out with that was that we fail L10n repackaging when either ChatZilla or venkman are configured off.
This is not hard to fix, so I think we should just add that flexibility to our build system.
Here's the pretty easy patch to ifdef the relevant pieces to only be used if we haven't excluded the extensions.
Attachment #384880 - Flags: review?(bugzilla)
Summary: L10n repack fails if ether ChatZilla or venkman are missing from build → L10n repack fails if ChatZilla or venkman are missing from build
Attachment #384880 - Flags: review?(bugzilla) → review+
Pushed as http://hg.mozilla.org/comm-central/rev/4f619bab5b2e
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → seamonkey2.0b1
This doesn't work well, ChatZilla's langpacks are missing from todays nightly builds. Plus sk tinderbox should be red due to missing strings in ChatZilla localization, but it turned green/orange today.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(In reply to comment #3)
> This doesn't work well, ChatZilla's langpacks are missing from todays nightly
> builds. Plus sk tinderbox should be red due to missing strings in ChatZilla
> localization, but it turned green/orange today.

Is this in comm-central or comm-1.9.1 nightlies? The former could very well have a configuration problem due to their hacky way of doing rebuilds, I'll need to look into that in this case.
Both c-c and c-1.9.1
Attached patch oops (obsolete) — Splinter Review
All I can say is: D'Oh!

I should have tested that not only the exclusion works but also the inclusion. MOZ_EXTENSIONS isn't even defined in the comm-central build system - which I should know, of course.
The only thing we can do reasonably is test if the directory exists before executing make on it, and this patch does that.
And this time I tested that it works for the more common case of actually _in_cluding things ;-)
Attachment #386412 - Flags: review?(bugzilla)
Another d'Oh! I should actually attach the right one of my patches ;-)
Attachment #386412 - Attachment is obsolete: true
Attachment #386413 - Flags: review?(bugzilla)
Attachment #386412 - Flags: review?(bugzilla)
Attachment #386412 - Attachment description: test for the directories instead → oops
Attachment #386413 - Flags: review?(bugzilla) → review+
Pushed the new patch as http://hg.mozilla.org/comm-central/rev/b9dd4c1ffd4d - I hope this is really fixed now.
Status: REOPENED → RESOLVED
Closed: 13 years ago13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.