Closed Bug 1294433 (SM2.46) Opened 4 years ago Closed 3 years ago

Tracking bug for build and release of SeaMonkey 2.46

Categories

(SeaMonkey :: Release Engineering, defect, P1)

SeaMonkey 2.46 Branch
defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: ewong, Assigned: ewong)

References

()

Details

Attachments

(23 files, 18 obsolete files)

5.51 KB, patch
Details | Diff | Splinter Review
3.75 KB, patch
philip.chee
: review+
Callek
: review+
Callek
: feedback-
Details | Diff | Splinter Review
2.72 KB, patch
iann_bugzilla
: review+
Details | Diff | Splinter Review
1.70 KB, patch
iann_bugzilla
: review+
Details | Diff | Splinter Review
2.72 KB, patch
Details | Diff | Splinter Review
2.25 KB, patch
Details | Diff | Splinter Review
2.06 KB, patch
iann_bugzilla
: review+
iann_bugzilla
: approval-comm-aurora+
iann_bugzilla
: approval-comm-beta+
iann_bugzilla
: approval-comm-release+
Details | Diff | Splinter Review
1.20 KB, patch
ewong
: review+
Details | Diff | Splinter Review
3.01 KB, patch
ewong
: review+
Details | Diff | Splinter Review
11.03 KB, text/plain
ewong
: review+
Details
1.09 KB, patch
Details | Diff | Splinter Review
2.71 KB, patch
Details | Diff | Splinter Review
964 bytes, patch
Details | Diff | Splinter Review
1021 bytes, patch
Details | Diff | Splinter Review
1.06 KB, patch
Details | Diff | Splinter Review
1.50 KB, patch
Details | Diff | Splinter Review
16.26 KB, patch
Details | Diff | Splinter Review
4.61 KB, patch
Details | Diff | Splinter Review
2.13 KB, patch
Details | Diff | Splinter Review
1.20 KB, patch
Details | Diff | Splinter Review
146.81 KB, patch
Details | Diff | Splinter Review
1.00 KB, patch
Details | Diff | Splinter Review
15.24 KB, patch
Details | Diff | Splinter Review
This is a tracking bug for Build and Release of SeaMonkey 2.45

We expect an actual release on TBA.
Depends on: 1294434
2.45 seems like it isn't going to be released.  2.46 will be
the one to be released.  So morphing this bug to 2.46
Alias: SM2.45 → SM2.46
Depends on: SM246-RELNOTE
No longer depends on: SM245-RELNOTE
Summary: Tracking bug for build and release of SeaMonkey 2.45 → Tracking bug for build and release of SeaMonkey 2.46
Version: SeaMonkey 2.45 Branch → SeaMonkey 2.46 Branch
What still needs to be done to get a release out? FIREFOX_49_0_BUILD4 was tagged a couple of days ago and FF 49.0 released, thus the m-c changeset should be defined (plus any SM-specific patches). It appears that build-system and l10n issues are finally resolved (thanks!), so please let's go ahead.
Other than switching Linux builds to GTK2 (bug 1213152), I don't see any open issues mentioned in the September 13 status meetings that could be solved for the 2.46 time frame (well, and the release notes will have to be written, bug 1302639). I'm counting 115 fixed SM-specific bugs since the 2.40 release.
Also, landing bug 903439 for the API keys would be good to have for this release.
(In reply to rsx11m from comment #2)
> It appears that build-system and l10n issues are finally resolved (thanks!)

Hmm, does bug 1231349 still apply? Bummer if it does.
and here we go!
Assignee: nobody → ewong
Status: NEW → ASSIGNED
Attachment #8795568 - Flags: review?(bugspam.Callek)
Depends on: 1305909
Depends on: 1305911
Depends on: 1305912
Depends on: 1305915
Attachment #8795614 - Flags: review?(philip.chee)
Ftr, I pushed a build2 patch to buildbot-configs repo (http://hg.mozilla.org/build/buildbot-configs/rev/30abcd0e61b8) but backed it out (http://hg.mozilla.org/build/buildbot-configs/rev/09170423624d) since we need more changes in c-r.
Comment on attachment 8795614 [details] [diff] [review]
[mozconfigs/tooltool] disable gtk3

Review of attachment 8795614 [details] [diff] [review]:
-----------------------------------------------------------------

I'm less eager to see this done, because gtk2 isn't tested in any form aiui.

I'm also less certain that this change won't break the build due to compare-dir stuff with c-c and m-c for `build/unix/`
Attachment #8795614 - Flags: review+
Attachment #8795614 - Flags: feedback-
(In reply to Justin Wood (:Callek) from comment #11)
> I'm less eager to see this done, because gtk2 isn't tested in any form aiui.

Well, we know that GTK3 has plenty of issues with SeaMonkey using the default but also the modern theme, thus I'm rather eager to fall back to GTK2 which seems to work fine.
Comment on attachment 8795614 [details] [diff] [review]
[mozconfigs/tooltool] disable gtk3

[Approval Request Comment]
Regression caused by (bug #): 
User impact if declined:  gtk3 issues in the build.
Testing completed (on m-c, etc.): 
Risk to taking this patch (and alternatives if risky):
String changes made by this patch: none

reported that gtk3 has issues so we need to disable it and
use gtk2 instead.
Attachment #8795614 - Flags: approval-comm-release?
Comment on attachment 8795614 [details] [diff] [review]
[mozconfigs/tooltool] disable gtk3

approvals as needed
Attachment #8795614 - Flags: approval-comm-release?
Attachment #8795614 - Flags: approval-comm-release+
Attachment #8795614 - Flags: approval-comm-beta+
Attachment #8795614 - Flags: approval-comm-aurora+
taking a page off bug 1286440, I'm finding it weird that mac's repacks
have their compile env disabled yet not with the other platforms.  
I don't understand.  Is this just the situation that since it works
with linux and windows, let's not fudge it? or is there a deeper meaning?
Attachment #8795957 - Flags: review?(iann_bugzilla)
Attachment #8795957 - Flags: review?(bugspam.Callek)
https://hg.mozilla.org/releases/comm-release/rev/ff3c86e5c3cd510756f5a889162867cc7b708e0f
Bug 1294433 - Disable compile env for all platform repacks. r+a=post-land-review
Attachment #8795978 - Flags: review?(bugspam.Callek)
(In reply to Edmund Wong (:ewong) from comment #18)
> https://hg.mozilla.org/build/buildbot-configs/rev/
> 5b4e204bcdf7594605aaa1d80567b04e69742c46
> Bug 1294433 - Update configs for SeaMonkey 2.46 (build2)

Backed out https://hg.mozilla.org/build/buildbot-configs/rev/b58d1c934d2c.
(forgot the relbranch for l10n)
Attachment #8795978 - Attachment is obsolete: true
Attachment #8795978 - Flags: review?(bugspam.Callek)
Attachment #8795979 - Flags: review?(bugspam.Callek)
(In reply to Edmund Wong (:ewong) from comment #21)
> https://hg.mozilla.org/build/buildbot-configs/rev/
> 351a8c68d8e6b97b227153a79d50670f6ba34bf2
> Bug 1294433 - Update configs for SeaMonkey 2.46 (build2)

Backed out once again.. like 2.40..  forgot to add the
relbranch to comm-r and moz-r  sorry for the bugspam.
Attachment #8795979 - Attachment is obsolete: true
Attachment #8795979 - Flags: review?(bugspam.Callek)
Attachment #8795980 - Flags: review?(bugspam.Callek)
*nearly* did a screw up with the 'forget to change SEAMONKEY_2_39' fauxpas.
Attachment #8795980 - Attachment is obsolete: true
Attachment #8795980 - Flags: review?(bugspam.Callek)
Attachment #8795984 - Flags: review?(bugspam.Callek)
this is needed to disable gtk3 building.  it wasn't sufficient to
have the gtk3 disabled in build/unix/mozconfig.gtk.  

Will need to ask for approval in m-r and will make a branch for that
Attachment #8796047 - Flags: review?(mh+mozilla)
Comment on attachment 8796047 [details] [diff] [review]
[mozconfig for m-r] disable gtk3

Approval Request Comment
[Feature/regressing bug #]:
[User impact if declined]: gtk3 issues 
[Describe test coverage new/current, TreeHerder]:
[Risks and why]: in order to build a gtk2 only c-r build, the m-r's
build/unix/mozconfig.gtk need to be changed as well.
[String/UUID change made/needed]: none

fwiw.. will create a special branch for this.  (probably gonna use
the relbranch for this)
Attachment #8796047 - Flags: approval-mozilla-release?
Comment on attachment 8796047 [details] [diff] [review]
[mozconfig for m-r] disable gtk3

apparently I don't need a review
Attachment #8796047 - Flags: review?(mh+mozilla)
Attachment #8796047 - Flags: approval-mozilla-release?
Comment on attachment 8796047 [details] [diff] [review]
[mozconfig for m-r] disable gtk3

going to push this to the SEA_COMM490_20160927_RELBRANCH.
Attachment #8796047 - Flags: review?(iann_bugzilla)
Attachment #8796396 - Flags: review?(bugspam.Callek)
With regards to updates to 2.46, we're still going to use aus2 as there
seems to be a bunch of stuff needing to be done to move to balrog.

And as far as I know and understand, we need to make changes to the update
code (i.e. where the clients point to for updates), but I'll need to
confirm by looking at our current code.
Depends on: 1306543
Thanks to the help from :glandium (bug 1306543), we cannot build (as right now) in 
Linux* for gtk2.

So what is the solution?  I can only think of two right now..

1) re-enable GTK3 
2) figure if it's feasible/possible to upgrade the glib on our CentOS 6 builders
   (need to ask Callek 'bout this...)
Flags: needinfo?(philip.chee)
Flags: needinfo?(iann_bugzilla)
Flags: needinfo?(bugspam.Callek)
Depends on: 1293928
Looks like a patch is up and approved for bug 1306543 to reduce glib requirements as it would also imply compatibility issues with current LTS distributions not providing that version either.
Comment on attachment 8795614 [details] [diff] [review]
[mozconfigs/tooltool] disable gtk3

r=me
Flags: needinfo?(philip.chee)
Attachment #8795614 - Flags: review?(philip.chee) → review+
Depends on: 1277293, 1061348
Thanks frg for linking those two bugs!
Attachment #8797349 - Flags: review?(bugspam.Callek)
Attachment #8795984 - Attachment is obsolete: true
Attachment #8796396 - Attachment is obsolete: true
Attachment #8797349 - Attachment is obsolete: true
Attachment #8795984 - Flags: review?(bugspam.Callek)
Attachment #8796396 - Flags: review?(bugspam.Callek)
Attachment #8797349 - Flags: review?(bugspam.Callek)
Attachment #8797366 - Flags: review?(bugspam.Callek)
Depends on: 1307371
Depends on: 1307380
Attachment #8797366 - Attachment is obsolete: true
Attachment #8797366 - Flags: review?(bugspam.Callek)
Attachment #8797923 - Flags: review?(bugspam.Callek)
Depends on: 1307718
Depends on: 1307731
ewong before you trigger the next build better check if the fix in bug 1301940 also needs to be applied to c-r.
While figuring out bug 1231349, I came across the issue that we were
not sending the right mozillaDir and mozillaSrcDir to CCReleaseRepackFactory.
Attachment #8798311 - Flags: review?(bugspam.Callek)
Attachment #8797923 - Attachment description: [configs] update configs for SeaMonkey 2.46 (build6) → [configs] update configs for SeaMonkey 2.46 (build6) [checked-in]
Attachment #8798311 - Attachment description: [configs] mozillaSrcDir and mozillaDir belongs to branchConfig. (v1) → [configs] mozillaSrcDir and mozillaDir belongs to branchConfig. (v1) [checked-in]
Attachment #8795957 - Flags: review?(iann_bugzilla) → review+
Flags: needinfo?(iann_bugzilla)
Attachment #8796047 - Flags: review?(iann_bugzilla) → review+
Comment on attachment 8799609 [details] [diff] [review]
[mozconfigs] need to include mozconfig.win-common for release and release-l10n

>+++ b/suite/app/Makefile.in
>@@ -86,20 +86,21 @@ cd ..; rm -rf $(ABS_STAGE)/$(dir); \
> DONOTPACK = {e2fda1a4%
>+IGNOREPAT = inspector@%
> 
> pack-ext: $(STAGEDIST)
> 	@echo "Packaging extensions..."
>-	$(foreach dir,$(filter-out $(DONOTPACK),$(subst $(STAGEDIST)/,,$(wildcard $(STAGEDIST)/*))),$(_PACKAGE_EXTENSIONS))
>+	$(foreach dir,$(filter-out $(DONOTPACK),$(subst $(STAGEDIST)/,,$(filter-out $(IGNOREPAT),wildcard $(STAGEDIST)/*)))),$(_PACKAGE_EXTENSIONS))
Part of another patch?

>+++ b/suite/config/mozconfigs/win32/release
>@@ -1,8 +1,9 @@
>+. "$topsrcdir/build/mozconfig.win-common"
> . "$topsrcdir/build/mozconfig.common"
> 
> ac_add_options --enable-application=suite
> ac_add_options --enable-update-channel=${MOZ_UPDATE_CHANNEL}
> ac_add_options --enable-jemalloc
> ac_add_options --enable-calendar
> ac_add_options --enable-require-all-d3dc-versions
> 
>diff --git a/suite/config/mozconfigs/win32/release-l10n b/suite/config/mozconfigs/win32/release-l10n
>--- a/suite/config/mozconfigs/win32/release-l10n
>+++ b/suite/config/mozconfigs/win32/release-l10n
>@@ -1,8 +1,9 @@
>+. "$topsrcdir/build/mozconfig.win-common"
> . "$topsrcdir/build/mozconfig.common"
> 
> ac_add_options --with-l10n-base=../../l10n
> ac_add_options --enable-application=suite
> ac_add_options --enable-update-channel=${MOZ_UPDATE_CHANNEL}
> ac_add_options --disable-compile-environment
> 
> # Needed to enable breakpad in application.ini
r/a=me with spurious bits removed.
Attachment #8799609 - Flags: review?(iann_bugzilla)
Attachment #8799609 - Flags: review+
Attachment #8799609 - Flags: approval-comm-release+
Attachment #8799609 - Flags: approval-comm-beta+
Attachment #8799609 - Flags: approval-comm-aurora+
[Triage Comment]

spurious stuff removed.  forwarding r+ and a+ 's
Attachment #8799619 - Flags: review+
Attachment #8799619 - Flags: approval-comm-release+
Attachment #8799619 - Flags: approval-comm-beta+
Attachment #8799619 - Flags: approval-comm-aurora+
https://hg.mozilla.org/releases/comm-release/rev/7592f8dcb92954b7900e6243113deb54d9830cfb
Bug 1294433 - Fix Win32 mozconfig. include mozconfig.win-common r+a=IanN
https://hg.mozilla.org/releases/comm-release/rev/8603e8c5ae24a8fab282296de898349fd8b0b950
Bug 1294433 - Fix Win32 mozconfig. include mozconfig.win-common r+a=IanN
https://hg.mozilla.org/releases/comm-beta/rev/b34e2170409cf06af840d4615b4c58a6d8c4472e
Bug 1294433 - Fix Win32 mozconfig. include mozconfig.win-common r+a=IanN
https://hg.mozilla.org/releases/comm-aurora/rev/b61207c063fac02e88d870f54eb84b50cdce7281
Bug 1294433 - Fix Win32 mozconfig. include mozconfig.win-common r+a=IanN
https://hg.mozilla.org/comm-central/rev/29bd777a31ce207512c12ef786f4cf261e57e6b7
Bug 1294433 - Fix Win32 mozconfig. include mozconfig.win-common r+a=IanN
Depends on: 1293943
I am wondering why exactly is bug 1293943 busting us on Windows repacks?
Depends on: 1309372
See that 2.46 is build with VS2015 Update 2. If possible I would suggest switching to Update 3. Stability improvements and automatic telemetry in the runtime disabled.
this is an example of me doing a "monkey-see-monkey-do".  TB had to
include a --disable-compile-environment to enable the l10n repacks;
but it isn't necessary.. on the following assumption that we don't
need to do universal builds/repacks (do we, stefan?) [i.e. having
both i686 and x86-64]
Attachment #8800506 - Flags: review?(iann_bugzilla)
Attachment #8800506 - Flags: feedback?(stefanh)
Comment on attachment 8800506 [details] [diff] [review]
[mozconfigs] drop --disable-compile-environment

No.. this patch doesn't unhork us from the current bustage (which is
bug 1231349).
Comment on attachment 8800506 [details] [diff] [review]
[mozconfigs] drop --disable-compile-environment

>+++ b/suite/config/mozconfigs/macosx-universal/release-l10n
>@@ -1,12 +1,13 @@
>+. "$topsrcdir/build/macosx/mozconfig.common"
>+

So apart from the above change (different bug maybe?), this is just backing out a previous patch?
Assuming an f+ from stefanh r/a=me
Flags: needinfo?(ewong)
Attachment #8800506 - Flags: review?(iann_bugzilla)
Attachment #8800506 - Flags: review+
Attachment #8800506 - Flags: approval-comm-release+
Attachment #8800506 - Flags: approval-comm-beta+
Attachment #8800506 - Flags: approval-comm-aurora+
(In reply to Ian Neal from comment #59)
> Comment on attachment 8800506 [details] [diff] [review]
> [mozconfigs] drop --disable-compile-environment
> 
> >+++ b/suite/config/mozconfigs/macosx-universal/release-l10n
> >@@ -1,12 +1,13 @@
> >+. "$topsrcdir/build/macosx/mozconfig.common"
> >+
> 
> So apart from the above change (different bug maybe?), this is just backing
No, same bug.  

> out a previous patch?
> Assuming an f+ from stefanh r/a=me

And yes, this is just backing out the --disable-compile-environment change.
Flags: needinfo?(ewong)
Comment on attachment 8800506 [details] [diff] [review]
[mozconfigs] drop --disable-compile-environment

(In reply to Edmund Wong (:ewong) from comment #57)
> this is an example of me doing a "monkey-see-monkey-do".  TB had to
> include a --disable-compile-environment to enable the l10n repacks;
> but it isn't necessary.. on the following assumption that we don't
> need to do universal builds/repacks (do we, stefan?) [i.e. having
> both i686 and x86-64]

IIRC we still support running the app in 32-bit mode... se for example bug 1255588, comment #2. So we need universal builds then, don't we?

Note: I haven't followed the 64-/32-bit discussion that much, so you should probably double-check this (that is, don't just accept my '-' without further investigation).
Attachment #8800506 - Flags: feedback?(stefanh) → feedback-
Firefox plans to kill universal builds in FF 53 see bug 1295375. With support for older osx versions already dropped not sure how many users still need 32 bit support. Personally I suspect not many but not a mac user yet.
(In reply to Frank-Rainer Grahl from comment #62)
> Firefox plans to kill universal builds in FF 53 see bug 1295375.

Yes (see my comment above and the bug I was refering to), I know ;-). SeaMonkey 46 is Gecko 49.

> With
> support for older osx versions already dropped not sure how many users still
> need 32 bit support. Personally I suspect not many but not a mac user yet.
The main problem here is plugins (Silverlight): https://bugzilla.mozilla.org/show_bug.cgi?id=1183613#c9
>> Yes (see my comment above and the bug I was refering to), I know ;-). SeaMonkey 46 is Gecko 49.

Ahh ok. I am on x64 for long now and don't use Flash or Silverlight so I tend to forget that others still need them :) Also thought that Silverlight was whitelisted too for the time being.
[Triage Comment]

I'm forwarding the previous patch's review and approval for only
the removal of the --disable-compile-environment part.  I'm
leaving the macosx-universal inclusion of mozconfig.common for a later
patch.
Attachment #8800506 - Attachment is obsolete: true
Attachment #8801977 - Flags: review+
Attachment #8801977 - Flags: approval-comm-release+
Attachment #8801977 - Flags: approval-comm-beta+
Attachment #8801977 - Flags: approval-comm-aurora+
https://hg.mozilla.org/releases/comm-release/rev/027ab5cdfbb303871dd6be37d9a24263ded8d0b0
Bug 1294433 - Remove --disable-compile-environment from mozconfigs. r+a=IanN
Depends on: 1312353
Depends on: 1313587
I wish there was an easier way of doing this; but as it stands, in order
to get 2.46 out, we'll need to remove cZ and DOMi from our extensions list.

So the next step forward is the following:

1 - remove inspector and domi from confvars.sh
2 - possibly some buildbot stuff
3 - client.py changes
4 - run build #7
5 - if things go well.. repacks are ok and we go to the next step.
    if things go pear-shape..well..  build #8 anyone?  ;/
So, if a version of either extension is installed in a user's profile it will be retained on an update, thus not shipping it should only affect new installations - right?

I assume that you've tried the patches in bug 485871 for the cZ repack problem already?
Attached patch 2.46 repack fix. (obsolete) — Splinter Review
This patch disables building calendar and doesn't include inspector and chatzilla.

repacks ignore these extensions.
Attachment #8817149 - Flags: review?(iann_bugzilla)
Attachment #8817149 - Flags: review?(bugspam.Callek)
(In reply to Edmund Wong (:ewong) from comment #69)
> Created attachment 8817149 [details] [diff] [review]
> 2.46 repack fix.
> 
> This patch disables building calendar and doesn't include inspector and
> chatzilla.
> 
> repacks ignore these extensions.

And this patch is mainly frg's work.  Just credit where credit's due.
Attachment #8817149 - Attachment is patch: true
Comment on attachment 8817149 [details] [diff] [review]
2.46 repack fix.

Review of attachment 8817149 [details] [diff] [review]:
-----------------------------------------------------------------

For me, that patch looks fine, I'm not surprised by any of it, even though it's been a longer time since I worked with the build system. ;-)
I only wonder why the options for that zip command changed, but it's a fine change as well.
Attachment #8817149 - Flags: feedback+
Comment on attachment 8817149 [details] [diff] [review]
2.46 repack fix.

I don't think you need to remove lightning as that seems to package fine.
As you say this is mainly https://bugzilla.mozilla.org/attachment.cgi?id=8816976

r=me for patch without the calendar removal
Attachment #8817149 - Flags: review?(iann_bugzilla) → review+
(In reply to Robert Kaiser from comment #72)
> Comment on attachment 8817149 [details] [diff] [review]
> 2.46 repack fix.
> 
> Review of attachment 8817149 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> For me, that patch looks fine, I'm not surprised by any of it, even though
> it's been a longer time since I worked with the build system. ;-)
> I only wonder why the options for that zip command changed, but it's a fine
> change as well.

The reason why I added the D to the ZIP command is because without it,
it was storing folders in the ZIP file which was causing havok to the
repack process.
this is the repack patch that includes the calendar stuff.  This patch
still busts the repack part.  will attach the log for reference.
Attached file repack process with patch C1. (obsolete) —
this is still getting errors when I include calendar.
Attached file repack process log with patch C1 (obsolete) —
Attachment #8817939 - Attachment is obsolete: true
Colour me stumped(as of this comment) as to why we're hitting bug 1293943;
when no one else seems to be hitting it.

Anyway.. I'm going to transplant https://hg.mozilla.org/comm-central/rev/6497b3aa36e15daf7bc6828c2e9e421f33e95b6d to c-r's relbranch
What I've done:

1) applied frg's patch
2) transplanted https://hg.mozilla.org/comm-central/rev/6497b3aa36e15daf7bc6828c2e9e421f33e95b6d
3) made changes in suite/locales/Makefile.in to remove the --no-iri.

Current situation:

Busted because of:

c:/builds/slave/rel-c-r-rpk/build/comm-release/objdir-l10n/_virtualenv/Scripts/python.exe c:/builds/slave/rel-c-r-rpk/build/comm-release/mozilla/config/nsinstall.py -D c:/builds/slave/rel-c-r-rpk/build/comm-release/objdir-l10n/dist/win32/en-US/
(cd c:/builds/slave/rel-c-r-rpk/build/comm-release/objdir-l10n/dist/win32/en-US/ && wget --no-cache -nv -N  'http://archive.mozilla.org/pub/seamonkey/candidates/2.46-candidates/build6/unsigned/win32/en-US/seamonkey-2.46.zip')
Downloaded http://archive.mozilla.org/pub/seamonkey/candidates/2.46-candidates/build6/unsigned/win32/en-US/seamonkey-2.46.zip to c:/builds/slave/rel-c-r-rpk/build/comm-release/objdir-l10n/dist/win32/en-US//win32/en-US/seamonkey-2.46.zip
c:/builds/slave/rel-c-r-rpk/build/comm-release/objdir-l10n/_virtualenv/Scripts/python.exe c:/builds/slave/rel-c-r-rpk/build/comm-release/mozilla/config/nsinstall.py -D c:/builds/slave/rel-c-r-rpk/build/comm-release/objdir-l10n/dist/win32/en-US/
(cd c:/builds/slave/rel-c-r-rpk/build/comm-release/objdir-l10n/dist/win32/en-US/ && wget --no-cache -nv -N 'http://archive.mozilla.org/pub/seamonkey/candidates/2.46-candidates/build6/unsigned/win32/en-US/SeaMonkey Setup 2.46.exe')
Downloaded http://archive.mozilla.org/pub/seamonkey/candidates/2.46-candidates/build6/unsigned/win32/en-US/SeaMonkey Setup 2.46.exe to c:/builds/slave/rel-c-r-rpk/build/comm-release/objdir-l10n/dist/win32/en-US/SeaMonkey Setup 2.46.exe
c:/builds/slave/rel-c-r-rpk/build/comm-release/mozmake.exe -C ../../calendar/lightning LOCALE_MERGEDIR= wget-en-US
mozmake.exe[1]: Entering directory 'c:/builds/slave/rel-c-r-rpk/build/comm-release/objdir-l10n/calendar/lightning'
(cd ../../dist/xpi-stage && wget -nv -N http://archive.mozilla.org/pub/calendar/lightning/candidates/2.46-candidates/build6/unsigned/lightning-5.1.en-US.win32.xpi)
http://archive.mozilla.org/pub/calendar/lightning/candidates/2.46-candidates/build6/unsigned/lightning-5.1.en-US.win32.xpi:
19:17:23 ERROR 404: Not Found.
c:/builds/slave/rel-c-r-rpk/build/comm-release/calendar/lightning/lightning-packager.mk:87: recipe for target 'wget-en-US' failed
mozmake.exe[1]: *** [wget-en-US] Error 1
mozmake.exe[1]: Leaving directory 'c:/builds/slave/rel-c-r-rpk/build/comm-release/objdir-l10n/calendar/lightning'
Makefile:259: recipe for target 'calendar-wget-en-US' failed
pymake\..\..\mozmake.exe: *** [calendar-wget-en-US] Error 2

So it's not finding the right lightning path.  

As it stands... the way forward is to postpone this how-to-find-lightning
thought and go with no-extensions plan..
This patch is based on an earlier patch which removes the inspector, chatzilla and calendar extensions due to their incompatibility with the current repack process.  Even though IanN said in an earlier comment to re-include calendar,
he did confirm earlier today (my today) that it's ok to exclude calendar.  Got KaiRo's approval as well (both here and on irc).

I had already pushed the m-b and m-r patches to the relbranch:
https://hg.mozilla.org/releases/mozilla-release/rev/8b8d2820718f

https://hg.mozilla.org/releases/mozilla-release/rev/c8c24c1f96ec
Attachment #8817149 - Attachment is obsolete: true
Attachment #8817938 - Attachment is obsolete: true
Attachment #8817957 - Attachment is obsolete: true
Attachment #8817958 - Attachment is obsolete: true
Attachment #8817149 - Flags: review?(bugspam.Callek)
Attachment #8818190 - Flags: review+
Attachment #8818192 - Flags: review?(bugspam.Callek)
Comment on attachment 8818192 [details] [diff] [review]
[configs] update for SeaMonkey 2.46 (build 7)

Pushed to buildbot-configs: (for post-land-review)
  https://hg.mozilla.org/build/buildbot-configs/rev/44a0a6e6887c4ffeefa759b3d53741543d8bc414
Comment on attachment 8818190 [details]
repack fix.  (final patch to be pushed)

Pushed to comm-release:
https://hg.mozilla.org/releases/comm-release/rev/2229823cdfa8
Comment on attachment 8818190 [details]
repack fix.  (final patch to be pushed)

You'd figure I'd goof even with a final patch.  

There's a missing change that I just pushed to c-r's relbranch:

https://hg.mozilla.org/releases/comm-release/rev/1018ca679090

OTR, the goofup is my fault and not frg's despite him being the
author.
this patch is an addendum to the build 7 patch.
Attachment #8818192 - Attachment is obsolete: true
Attachment #8818244 - Attachment is obsolete: true
Attachment #8818192 - Flags: review?(bugspam.Callek)
Attachment #8818422 - Flags: review?(bugspam.Callek)
osx64 repacks failed due to the following reasons:

  1) it failed to use the tooltool package clang
  2) it was pointing to the wrong directory for l10n base since 
     we're doing universal builds, it needs to be ../../../l10n.

Once I've pushed this... I'm wondering if I should do a build 10 (*sigh*)
or I can move the current tags in c-r to tag the newest push.
Attachment #8818776 - Flags: review?(bugspam.Callek)
https://hg.mozilla.org/releases/comm-release/rev/e0a2bca1b335d447a1af9d65ba9b9f26cce7b0ea
Bug 1294433 - Fix osx64 release_l10n mozconfig to use the tooltool clang package. a+r=release
Comment on attachment 8818776 [details] [diff] [review]
[mozconfigs] fix the l10nbase and include the universal mozconfig

Pushed to comm-release:
https://hg.mozilla.org/releases/comm-release/rev/e0a2bca1b335

And took the least-cumbersome path and just moved the tags to
the newest cset.
l10nbase really didn't need any changing.  Since we're repacking, all we need is the repack directory.. we don't need to repack twice for i386 and x86_64.
so with this patch, I've changed it back to ../../l10n; but since we still
need the tooltool clang packages, changed the release-l10n to source
the build/macosx/local-mozconfig.common file which sets up the clang stuff.

I didn't backout the previous patch, since that would require more steps than
is necessary (i.e. backout prev. patch.. push new patch..  push tag changes)
whereas this only required two (push this change and push tag changes).
[this is more or less for the record.. ]
https://hg.mozilla.org/releases/comm-release/rev/21f833d1beb4ded3d4ad91a77d36e2eac2c12030
Bug 1294433 - l10n repacks do not need universal configures, but do need the tooltool clang package CLOSED TREE a+r=release
Depends on: 1323922
to lessen the confusion, I'm suggesting we not generate our candidates in nightly/.  for one thing, post-stage-decom environment,  the nightly/*candidates aren't copied to candidates/  (if it was ever)
Attachment #8819198 - Flags: review?(bugspam.Callek)
https://hg.mozilla.org/build/buildbot-configs/rev/9f6f650afe5b0594e8f4032b017145b2ecb65ca8
Bug 1294433 - Use candidates/ and not nightly/ for the post_signing check
Attachment #8819198 - Attachment is obsolete: true
Attachment #8819198 - Flags: review?(bugspam.Callek)
Attachment #8819200 - Flags: review?(bugspam.Callek)
https://hg.mozilla.org/build/buildbot-configs/rev/142cdc2bd28d23eb4c7a57e0b2983b1474f65484
Bug 1294433 - Use candidates/ and not nightly/ for the post_signing check and remove mozilla.org from the ftp url.
stage.mozilla.org is gone.  use archive.mozilla.org instead.
Attachment #8819201 - Flags: review?(bugspam.Callek)
https://hg.mozilla.org/build/buildbot-configs/rev/e7f848fd66213176f88018ab0ecda6abc3962cde
Bug 1294433 - stage.mozilla.org is gone. we use archive.mozilla.org now.
release candidates really shouldn't be going to nightly/ (not even
sure why it was set to nightly but it has been done for this long). However,
to unconfuse the release process, the release candidates should go
to the /pub/seamonkey/candidates/ folder.

This is only ONE patch out of the possible plethora that I'm attaching (and pushing for post-land-review). 

These patches are 'stop-gap' patches so that I can get 2.46 out the window.
Attachment #8819667 - Flags: review?(bugspam.Callek)
Attachment #8819674 - Flags: review?(bugspam.Callek)
Attachment #8819741 - Flags: review?(bugspam.Callek)
Depends on: 1324670
Depends on: 1274632
No longer depends on: 1274632
Attachment #8797923 - Flags: review?(bugspam.Callek)
Attachment #8795568 - Flags: review?(bugspam.Callek)
Attachment #8795957 - Flags: review?(bugspam.Callek)
Attachment #8798311 - Flags: review?(bugspam.Callek)
Attachment #8818422 - Attachment description: [configs] update configs for 2.46 (build9) → [configs] update configs for 2.46 (build9) [checked-in]
Attachment #8818422 - Flags: review?(bugspam.Callek)
Attachment #8818776 - Flags: review?(bugspam.Callek)
This patch was manually applied to unhork the l10nverify failure.
This patch was needed to fix the l10nverifyfactory as it used the old
rsync method, which no longer work as we've moved to AWS.

It also moves all release-related stuff to candidates/ and not nightly/
Attachment #8822312 - Attachment is obsolete: true
Attachment #8822312 - Flags: review?(bugspam.Callek)
Attachment #8822313 - Flags: review?(bugspam.Callek)
Comment on attachment 8822315 [details] [diff] [review]
[custom] Replace nightly/ with candidates/ and use aws client for L10nVerification (v3)

overdid the review removal
Attachment #8822315 - Flags: review?(bugspam.Callek)
Comment on attachment 8822303 [details] [diff] [review]
[configs] use S3Bucket in L10nVerifyFactory [checked-in]

Was pushed: https://hg.mozilla.org/build/buildbot-configs/rev/142b31a15e35
Attachment #8822303 - Attachment description: [configs] use S3Bucket in L10nVerifyFactory → [configs] use S3Bucket in L10nVerifyFactory [checked-in]
No longer depends on: 1305911
Attachment #8822315 - Flags: review?(bugspam.Callek)
https://hg.mozilla.org/build/buildbotcustom/rev/e083ef1292706012cd45e07ff0714ae6eb39a173
Bug 1294433 - Fix l10n verifications to use the aws client and use archiveServer rather than stagingServer.
No longer depends on: 1312353
2.46 was released some time ago.  Closing this bug.  l10n repack bug shouldn't block this anymore.
No longer depends on: operation_babelfish
Now closed
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Flags: needinfo?(bugspam.Callek)
Resolution: --- → FIXED
Comment on attachment 8819200 [details] [diff] [review]
[configs] remove mozilla.org and replace nightly/ with candidates/

ewong should the various review requests here be cleared?
Flags: needinfo?(ewong)
Attachment #8819741 - Flags: review?(bugspam.Callek)
Flags: needinfo?(ewong)
Attachment #8819200 - Flags: review?(bugspam.Callek)
Attachment #8819201 - Flags: review?(bugspam.Callek)
Attachment #8819674 - Flags: review?(bugspam.Callek)
Attachment #8819667 - Flags: review?(bugspam.Callek)
You need to log in before you can comment on or make changes to this bug.