1294433 - (SM2.46) Tracking bug for build and release of SeaMonkey 2.46

Status: RESOLVED FIXED

(SeaMonkey :: Release Engineering, defect, P1)

Description

[Edmund Wong (:ewong)]

This is a tracking bug for Build and Release of SeaMonkey 2.45

We expect an actual release on TBA.

Comment 1

[Edmund Wong (:ewong)]

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

Comment 2

[rsx11m]

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.

Comment 3

[rsx11m]

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.

Comment 4

[rsx11m]

Also, landing bug 903439 for the API keys would be good to have for this release.

Comment 5

[rsx11m]

(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.

Comment 6

[Edmund Wong (:ewong)]

Attachment: [configs] update config for SeaMonkey 2.46

and here we go!

Comment 7

[Edmund Wong (:ewong)]

https://hg.mozilla.org/build/buildbot-configs/rev/2a2d0081d95e4d57774d52c30e3d654189a65b42
Bug 1294433 - Update configs for SeaMonkey 2.46

Comment 8

[Edmund Wong (:ewong)]

https://hg.mozilla.org/build/buildbot-configs/rev/30abcd0e61b8e3c52aed7596d30d74420fdb38b5
Bug 1294433 - Update configs for SeaMonkey 2.46 (build 2)

Comment 9

[Edmund Wong (:ewong)]

Attachment: [mozconfigs/tooltool] disable gtk3

Comment 10

[Edmund Wong (:ewong)]

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 11

[Justin Wood (:Callek)]

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/`

Comment 12

[rsx11m]

(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 13

[Edmund Wong (:ewong)]

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.

Comment 14

[Justin Wood (:Callek)]

Comment on attachment 8795614 [details] [diff] [review]
[mozconfigs/tooltool] disable gtk3

approvals as needed

Comment 15

[Edmund Wong (:ewong)]

Attachment: [mozconfigs] disable compile env for all platform repacks.

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?

Comment 16

[Edmund Wong (:ewong)]

https://hg.mozilla.org/releases/comm-release/rev/ff3c86e5c3cd510756f5a889162867cc7b708e0f
Bug 1294433 - Disable compile env for all platform repacks. r+a=post-land-review

Comment 17

[Edmund Wong (:ewong)]

Attachment: [configs] update config for SeaMonkey 2.46 (build 2)

Comment 18

[Edmund Wong (:ewong)]

https://hg.mozilla.org/build/buildbot-configs/rev/5b4e204bcdf7594605aaa1d80567b04e69742c46
Bug 1294433 - Update configs for SeaMonkey 2.46 (build2)

Comment 19

[Edmund Wong (:ewong)]

(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)

Comment 20

[Edmund Wong (:ewong)]

Attachment: [configs] update configs for SeaMonkey 2.46 (build2)

Comment 21

[Edmund Wong (:ewong)]

https://hg.mozilla.org/build/buildbot-configs/rev/351a8c68d8e6b97b227153a79d50670f6ba34bf2
Bug 1294433 - Update configs for SeaMonkey 2.46 (build2)

Comment 22

[Edmund Wong (:ewong)]

(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.

Comment 23

[Edmund Wong (:ewong)]

Attachment: [configs] update configs for SeaMonkey 2.46 (build2)

Comment 24

[Edmund Wong (:ewong)]

Attachment: [configs] update configs for SeaMonkey 2.46 (build2)

*nearly* did a screw up with the 'forget to change SEAMONKEY_2_39' fauxpas.

Comment 25

[Edmund Wong (:ewong)]

https://hg.mozilla.org/build/buildbot-configs/rev/5d1303005c307674fec6f3fa5816fbb47321623e
Bug 1294433 - Update configs for SeaMonkey 2.46 (build2)

Comment 26

[Edmund Wong (:ewong)]

Attachment: [mozconfig for m-r] disable gtk3

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

Comment 27

[Edmund Wong (:ewong)]

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)

Comment 28

[Edmund Wong (:ewong)]

Comment on attachment 8796047 [details] [diff] [review]
[mozconfig for m-r] disable gtk3

apparently I don't need a review

Comment 29

[Edmund Wong (:ewong)]

Comment on attachment 8796047 [details] [diff] [review]
[mozconfig for m-r] disable gtk3

going to push this to the SEA_COMM490_20160927_RELBRANCH.

Comment 30

[Edmund Wong (:ewong)]

https://hg.mozilla.org/releases/comm-release/rev/9bf352ec2a307bc96e45905f8398f99e58315c7f
Bug 1294433 - Disable gtk3 building for 2.46 release. r+a=Callek

https://hg.mozilla.org/releases/comm-release/rev/34c0678223623c5885fa5cc6bf6ca65a0e04f15f
Bug 1294433 - Disable compile env for all platform repacks. r+a=post-land-review

Comment 31

[Edmund Wong (:ewong)]

Attachment: [configs] Update config for 2.46 build3

Comment 32

[Edmund Wong (:ewong)]

https://hg.mozilla.org/build/buildbot-configs/rev/fe2be8e1bf8dc857c8fb14ea2a110db2c3206b55
Bug 1294433 - Update configs for SeaMonkey 2.46 (build3)

Comment 33

[Edmund Wong (:ewong)]

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.

Comment 34

[Edmund Wong (:ewong)]

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...)

Comment 35

[rsx11m]

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 36

[Philip Chee]

Comment on attachment 8795614 [details] [diff] [review]
[mozconfigs/tooltool] disable gtk3

r=me

Comment 37

[Edmund Wong (:ewong)]

Thanks frg for linking those two bugs!

Comment 38

[Edmund Wong (:ewong)]

Attachment: [configs] update configs for SeaMonkey 2.46 (build4)

Comment 39

[Edmund Wong (:ewong)]

https://hg.mozilla.org/build/buildbot-configs/rev/c261f94f74fdff88e3978024d73709b1d6af1e34
Bug 1294433 - Update configs for SeaMonkey 2.46 (build 4)

Comment 40

[Edmund Wong (:ewong)]

Attachment: [configs] update configs for SeaMonkey 2.46 (build5)

Comment 41

[Edmund Wong (:ewong)]

https://hg.mozilla.org/build/buildbot-configs/rev/8082d56618bfc952d492c66f72b7e76bd0965bc2
Bug 1294433 - Update configs for SeaMonkey 2.46 (build 5)

Comment 42

[Edmund Wong (:ewong)]

Attachment: [configs] update configs for SeaMonkey 2.46 (build6) [checked-in]

Comment 43

[Edmund Wong (:ewong)]

https://hg.mozilla.org/build/buildbot-configs/rev/697aa0213c9542d2475fa57a214e883d3cfbe7b0
Bug 1294433 - Update configs for SeaMonkey 2.46 (build 6)

Comment 44

[Frank-Rainer Grahl (:frg)]

ewong before you trigger the next build better check if the fix in bug 1301940 also needs to be applied to c-r.

Comment 45

[Edmund Wong (:ewong)]

Attachment: [configs] mozillaSrcDir and mozillaDir belongs to branchConfig. (v1) [checked-in]

While figuring out bug 1231349, I came across the issue that we were
not sending the right mozillaDir and mozillaSrcDir to CCReleaseRepackFactory.

Comment 46

[Edmund Wong (:ewong)]

https://hg.mozilla.org/build/buildbot-configs/rev/0812b3e5803082ad8f77b76a6efea09af434a5d1
Bug 1294433 - mozillaDir and mozillaSrcDir belongs to branchConfig.

Comment 47

[Edmund Wong (:ewong)]

Attachment: [mozconfigs] need to include mozconfig.win-common for release and release-l10n

Comment 48

[Ian Neal]

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.

Comment 49

[Edmund Wong (:ewong)]

Attachment: [mozconfigs] need to include mozconfig.win-common for release and release-l10n (v2)

[Triage Comment]

spurious stuff removed.  forwarding r+ and a+ 's

Comment 50

[Edmund Wong (:ewong)]

https://hg.mozilla.org/releases/comm-release/rev/7592f8dcb92954b7900e6243113deb54d9830cfb
Bug 1294433 - Fix Win32 mozconfig. include mozconfig.win-common r+a=IanN

Comment 51

[Edmund Wong (:ewong)]

https://hg.mozilla.org/releases/comm-release/rev/8603e8c5ae24a8fab282296de898349fd8b0b950
Bug 1294433 - Fix Win32 mozconfig. include mozconfig.win-common r+a=IanN

Comment 52

[Edmund Wong (:ewong)]

https://hg.mozilla.org/releases/comm-beta/rev/b34e2170409cf06af840d4615b4c58a6d8c4472e
Bug 1294433 - Fix Win32 mozconfig. include mozconfig.win-common r+a=IanN

Comment 53

[Edmund Wong (:ewong)]

https://hg.mozilla.org/releases/comm-aurora/rev/b61207c063fac02e88d870f54eb84b50cdce7281
Bug 1294433 - Fix Win32 mozconfig. include mozconfig.win-common r+a=IanN

Comment 54

[Edmund Wong (:ewong)]

https://hg.mozilla.org/comm-central/rev/29bd777a31ce207512c12ef786f4cf261e57e6b7
Bug 1294433 - Fix Win32 mozconfig. include mozconfig.win-common r+a=IanN

Comment 55

[Edmund Wong (:ewong)]

I am wondering why exactly is bug 1293943 busting us on Windows repacks?

Comment 56

[Frank-Rainer Grahl (:frg)]

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.

Comment 57

[Edmund Wong (:ewong)]

Attachment: [mozconfigs] drop --disable-compile-environment

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]

Comment 58

[Edmund Wong (:ewong)]

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 59

[Ian Neal]

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

Comment 60

[Edmund Wong (:ewong)]

(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.

Comment 61

[Stefan [:stefanh]]

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).

Comment 62

[Frank-Rainer Grahl (:frg)]

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.

Comment 63

[Stefan [:stefanh]]

(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

Comment 64

[Frank-Rainer Grahl (:frg)]

>> 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.

Comment 65

[Edmund Wong (:ewong)]

Attachment: [mozconfigs] remove disable-compile-environment (w/o macosx mozconfig.common inclusion part)

[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.

Comment 66

[Edmund Wong (:ewong)]

https://hg.mozilla.org/releases/comm-release/rev/027ab5cdfbb303871dd6be37d9a24263ded8d0b0
Bug 1294433 - Remove --disable-compile-environment from mozconfigs. r+a=IanN

Comment 67

[Edmund Wong (:ewong)]

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?  ;/

Comment 68

[rsx11m]

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?

Comment 69

[Edmund Wong (:ewong)]

Attachment: 2.46 repack fix.

This patch disables building calendar and doesn't include inspector and chatzilla.

repacks ignore these extensions.

Comment 70

[Edmund Wong (:ewong)]

(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.

Comment 71

[Edmund Wong (:ewong)]

fwiw.. I'll be including the following transplants:

https://hg.mozilla.org/releases/mozilla-beta/rev/0a03ea21d564
 
https://hg.mozilla.org/releases/mozilla-release/rev/623b09253994

Comment 72

[Robert Kaiser]

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.

Comment 73

[Ian Neal]

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

Comment 74

[Edmund Wong (:ewong)]

(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.

Comment 75

[Edmund Wong (:ewong)]

Attachment: repack patch [incl. calendar] [patch C1]

this is the repack patch that includes the calendar stuff.  This patch
still busts the repack part.  will attach the log for reference.

Comment 76

[Edmund Wong (:ewong)]

Attachment: repack process with patch C1.

this is still getting errors when I include calendar.

Comment 77

[Edmund Wong (:ewong)]

Attachment: repack process log with patch C1

Comment 78

[Ian Neal]

Attachment: log from repack using frg's patch on linux

Comment 79

[Edmund Wong (:ewong)]

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

Comment 80

[Edmund Wong (:ewong)]

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..

Comment 81

[Edmund Wong (:ewong)]

Attachment: repack fix. (final patch to be pushed)

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

Comment 82

[Edmund Wong (:ewong)]

https://hg.mozilla.org/releases/comm-release/rev/2229823cdfa83745335eb45860571daf1f6fce93
Bug 1294433 - Fix repacks to remove extensions. r=IanN a=ewong

Comment 83

[Edmund Wong (:ewong)]

Attachment: [configs] update for SeaMonkey 2.46 (build 7)

Comment 84

[Edmund Wong (:ewong)]

https://hg.mozilla.org/build/buildbot-configs/rev/44a0a6e6887c4ffeefa759b3d53741543d8bc414
Bug 1294433 - Update configs for SeaMonkey 2.46 - build7

Comment 85

[Edmund Wong (:ewong)]

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 86

[Edmund Wong (:ewong)]

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 87

[Edmund Wong (:ewong)]

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.

Comment 88

[Edmund Wong (:ewong)]

Attachment: [configs] update configs for SeaMonkey 2.46 (build8)

this patch is an addendum to the build 7 patch.

Comment 89

[Edmund Wong (:ewong)]

https://hg.mozilla.org/build/buildbot-configs/rev/569b6b243d1cffc041ad0d9f1ffbfcde890f0c8b
Bug 1294433 - Update SeaMonkey 2.46 configs for build 8

Comment 90

[Edmund Wong (:ewong)]

Attachment: [mozconfigs] comment out OSX64'S inclusion of lightning's universal.mk

Comment 91

[Edmund Wong (:ewong)]

https://hg.mozilla.org/releases/comm-release/rev/6fe0f5662a084ff3d6cc0a69a00490c0910b3b35
Bug 1294433 - Comment out macosx inclusion of lightning.mk r+a=release

Comment 92

[Edmund Wong (:ewong)]

Also pushed this to m-r's relbranch:
 https://hg.mozilla.org/releases/mozilla-release/rev/c80b65bce21333b7d607c15409582de2dca304a0

Comment 93

[Edmund Wong (:ewong)]

Attachment: [configs] update configs for 2.46 (build9) [checked-in]

Comment 94

[Edmund Wong (:ewong)]

https://hg.mozilla.org/build/buildbot-configs/rev/5f8c07b6fe2b494367a88802d388af9aa02127c9
Bug 1294433 - Update SeaMonkey 2.46 configs for build 9

Comment 95

[Edmund Wong (:ewong)]

Attachment: [mozconfigs] fix the l10nbase and include the universal mozconfig

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.

Comment 96

[Edmund Wong (:ewong)]

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 97

[Edmund Wong (:ewong)]

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.

Comment 98

[Edmund Wong (:ewong)]

Attachment: [mozconfigs] l10nbase fix and do not setup the universal stuff

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.. ]

Comment 99

[Edmund Wong (:ewong)]

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

Comment 100

[Edmund Wong (:ewong)]

Attachment: [configs] change nightly to candidates.

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)

Comment 101

[Edmund Wong (:ewong)]

https://hg.mozilla.org/build/buildbot-configs/rev/9f6f650afe5b0594e8f4032b017145b2ecb65ca8
Bug 1294433 - Use candidates/ and not nightly/ for the post_signing check

Comment 102

[Edmund Wong (:ewong)]

Attachment: [configs] remove mozilla.org and replace nightly/ with candidates/

Comment 103

[Edmund Wong (:ewong)]

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.

Comment 104

[Edmund Wong (:ewong)]

Attachment: [configs] replace stage.mozilla.org with archive.mozilla.org

stage.mozilla.org is gone.  use archive.mozilla.org instead.

Comment 105

[Edmund Wong (:ewong)]

https://hg.mozilla.org/build/buildbot-configs/rev/e7f848fd66213176f88018ab0ecda6abc3962cde
Bug 1294433 - stage.mozilla.org is gone. we use archive.mozilla.org now.

Comment 106

[Edmund Wong (:ewong)]

Attachment: [tools] change nightly/ to candidates/

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.

Comment 107

[Edmund Wong (:ewong)]

Attachment: [tools] change nightly/ to candidates/ (patch 2)

Comment 108

[Edmund Wong (:ewong)]

Attachment: [tools] set nightlyDir as candidates.

Comment 109

[Edmund Wong (:ewong)]

Attachment: [tools] change nightly/ to candidates/ in partialmarupload.py

Comment 110

[Edmund Wong (:ewong)]

Attachment: [tools] replace nightly with candidates in moz{Beta,Release}*.cfg

Comment 111

[Edmund Wong (:ewong)]

https://hg.mozilla.org/SeaMonkey/tools/rev/32e6e0594f0b04eca7fae5221136f7ba78e391cf
Bug 1294433 - tools changes to run candidates check in candidates and not nightly/

https://hg.mozilla.org/SeaMonkey/tools/rev/0c3a9b48f9c59f36cb4cfe4cb4675c5171b6a92b
Bug 1294433 - Change nightly to candidates. (patch 2)

https://hg.mozilla.org/SeaMonkey/tools/rev/2194e5704ba08eefcd96180a931f6a2fc6a94e9d
Bug 1294433 - Set nightlyDir as candidates

https://hg.mozilla.org/SeaMonkey/tools/rev/ba1d5464758096debdda91765a47144a3f8cfb27
Bug 1294433 - Change nightly/ to candidates/ in partialmarupload.py

https://hg.mozilla.org/SeaMonkey/tools/rev/aa52f0a1ff137744317d54ccafd558b35badbad6
Bug 1294433 - Replace nightly with candidates

https://hg.mozilla.org/SeaMonkey/tools/rev/22dc826c73fa834f9e1b78cd7c50d35920bd8a8b
Bug 1294433 - Fix for patchers.

Comment 112

[Edmund Wong (:ewong)]

Attachment: [configs] use S3Bucket in L10nVerifyFactory [checked-in]

This patch was manually applied to unhork the l10nverify failure.

Comment 113

[Edmund Wong (:ewong)]

https://hg.mozilla.org/build/buildbot-configs/rev/142b31a15e35e83807bd819f20c636922e6e7d62
Bug 1294433 - Use S3Bucket in L10nVerifyFactory

Comment 114

[Edmund Wong (:ewong)]

Attachment: [custom] Replace nightly/ with candidates/ and use aws client for L10nVerification

Comment 115

[Edmund Wong (:ewong)]

Attachment: [custom] Replace nightly/ with candidates/ and use aws client for L10nVerification (v2)

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/

Comment 116

[Edmund Wong (:ewong)]

Attachment: [custom] Replace nightly/ with candidates/ and use aws client for L10nVerification (v3)

Comment 117

[Edmund Wong (:ewong)]

Comment on attachment 8822315 [details] [diff] [review]
[custom] Replace nightly/ with candidates/ and use aws client for L10nVerification (v3)

overdid the review removal

Comment 118

[Edmund Wong (:ewong)]

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

Comment 119

[Edmund Wong (:ewong)]

https://hg.mozilla.org/build/buildbotcustom/rev/e083ef1292706012cd45e07ff0714ae6eb39a173
Bug 1294433 - Fix l10n verifications to use the aws client and use archiveServer rather than stagingServer.

Comment 120

[Edmund Wong (:ewong)]

2.46 was released some time ago.  Closing this bug.  l10n repack bug shouldn't block this anymore.

Comment 121

[Frank-Rainer Grahl (:frg)]

Now closed

Comment 122

[Frank-Rainer Grahl (:frg)]

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?