1092468 - Migrate SeaMonkey to VS2015u2

Status: RESOLVED FIXED

(SeaMonkey :: Release Engineering, defect)

Description

[Edmund Wong (:ewong)]

VS2010 support is slated to be removed in Dec. 15th.  Our Windows slaves
are all Windows 2003 and VS2013 can't be installed on them.

I was thinking of tagging this along with bug 1085767, but since we
aren't even infrastructure-wise in the same league as TB, I figured
a separate bug to track our migration plan would be better.

Both bug 1009807 and bug 1089138 are the FF bugs that got them
building.

Comment 1

[charles.fuller]

The original post from Edmund Wong is not quite correct - Visual Studio 2013 is available for: Windows 7 Service Pack 1, Windows 8, Windows 8.1, Windows Server 2003, Windows Server 2008 R2 SP1, Windows Server 2008 Service Pack 2, Windows Server 2012, Windows Server 2012 R2, Windows Vista Service Pack 2, Windows XP Service Pack 3. See the page https://www.microsoft.com/en-gb/download/details.aspx?id=40784 to download the appropriate version of the software - a re-start might be necessary.

Comment 2

[Edmund Wong (:ewong)]

(In reply to charles.fuller from comment #1)
> The original post from Edmund Wong is not quite correct - Visual Studio 2013
> is available for: Windows 7 Service Pack 1, Windows 8, Windows 8.1, Windows
> Server 2003, Windows Server 2008 R2 SP1, Windows Server 2008 Service Pack 2,
> Windows Server 2012, Windows Server 2012 R2, Windows Vista Service Pack 2,
> Windows XP Service Pack 3. See the page
> https://www.microsoft.com/en-gb/download/details.aspx?id=40784 to download
> the appropriate version of the software - a re-start might be necessary.

We're talking about "Visual Studio 2013" that can't be installed
on Windows 2003.  The link you gave me was for the "Visual C++ Redistributable
Packages for Visual Studio 2013".

This is what we need:
https://www.visualstudio.com/products/visual-studio-professional-with-msdn-vs#Fragment_SystemRequirements

Comment 4

[erpman1]

It's a common mistake that charles made between the VC Redistributable runtimes for VS2013 and the "full" VS2013 software package.  The Visual C++ 2013 redist runtime packages only allow programs created in VS2013 to actually run while the the FULL Visual Studio 2013 application is used to make or create programs like the recent versions of Seamonkey.  The full VS2013 software requires minimum of either Windows 7 SP1 or Windows Server 2008 R2 SP1.  Hope this clears things up for some people.

How soon will Seamonkey be "migrated" to Visual Studio 2013, Edmund?  It's been almost 7 months since this bug report was created.  There needs to be substantial progress on this.

Comment 5

[rsx11m]

This depends on Bug 1116887 - Rename and reimage a single seamonkey VM into win2k8 -64 bit and will be ultimately tracked in Bug 1114876 - [Tracking Bug] Get initial SeaMonkey Windows 2008 configured.

Comment 6

[Edmund Wong (:ewong)]

Going to morph this to VS2015u1 as this is what m-c needs now.

Comment 8

[Edmund Wong (:ewong)]

Attachment: [mozconfigs/tooltool] proposed patch (v1)

This only reflects changes to use VS2015U1.  The u2 patch is waiting
until the m-i patch from bug 1259782 is merged to m-c.

Comment 9

[Justin Wood (:Callek)]

Comment on attachment 8744795 [details] [diff] [review]
[mozconfigs/tooltool] proposed patch (v1)

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

A skim of the patch looks good, but I think we may not have public access to this file.... Needs that testing

Comment 10

[Philip Chee]

Comment on attachment 8744795 [details] [diff] [review]
[mozconfigs/tooltool] proposed patch (v1)

> ac_add_options --enable-tests
Apropos of nothing do we want to enable tests? Neither Thunderbird nor Firefox does this.
> ac_add_options --enable-require-all-d3dc-versions
Idle question: What does this do?

suite/config/mozconfigs/win32/l10n-mozconfig

> # Windows 8 SDK is required for gamepad support
> # 1006630
> ac_add_options --disable-gamepad
Hmm. Aren't we switching to the Windows 10 SDK?

> suite/config/mozconfigs/win64/debug (was added)
> suite/config/mozconfigs/win64/l10n-mozconfig (was added)
> suite/config/mozconfigs/win64/nightly (was added)
Since these are new files might as well copy the rest of Thunderbird (except for MOZ_TELEMETRY_REPORTING)

> # Package js shell
> export MOZ_PACKAGE_JSSHELL=1

> # Disable checking that add-ons are signed by the trusted root
> MOZ_ADDON_SIGNING=0
> # Disable enforcing that add-ons are signed by the trusted root
> MOZ_REQUIRE_ADDON_SIGNING=0

suite/config/tooltool-manifests/win32/releng.manifest
suite/config/tooltool-manifests/win64/releng.manifest
> +"version": "Visual Studio 2015 Update 1 / SDK 10.0.10586.0",
Is Update 1 enough? I think mozilla-central just switched to Update 2

> This only reflects changes to use VS2015U1.  The u2 patch is waiting
> until the m-i patch from bug 1259782 is merged to m-c.
I think it's merged.

> \ No newline at end of file
Tsk.

Comment 11

[Edmund Wong (:ewong)]

(In reply to Philip Chee from comment #10)
> Comment on attachment 8744795 [details] [diff] [review]
> [mozconfigs/tooltool] proposed patch (v1)
> 
> > ac_add_options --enable-tests
> Apropos of nothing do we want to enable tests? Neither Thunderbird nor
> Firefox does this.

Sure.
> > ac_add_options --enable-require-all-d3dc-versions
> Idle question: What does this do?

Basically it includes all versions of the d3dcompiler as
mentioned in bug 999260.

> 
> suite/config/mozconfigs/win32/l10n-mozconfig
> 
> > # Windows 8 SDK is required for gamepad support
> > # 1006630
> > ac_add_options --disable-gamepad
> Hmm. Aren't we switching to the Windows 10 SDK?
> 
> > suite/config/mozconfigs/win64/debug (was added)
> > suite/config/mozconfigs/win64/l10n-mozconfig (was added)
> > suite/config/mozconfigs/win64/nightly (was added)
> Since these are new files might as well copy the rest of Thunderbird (except
> for MOZ_TELEMETRY_REPORTING)
> 
> > # Package js shell
> > export MOZ_PACKAGE_JSSHELL=1
> 
> > # Disable checking that add-ons are signed by the trusted root
> > MOZ_ADDON_SIGNING=0
> > # Disable enforcing that add-ons are signed by the trusted root
> > MOZ_REQUIRE_ADDON_SIGNING=0
> 

 I didn't include the last two because it's covered in bug 1219507.


> suite/config/tooltool-manifests/win32/releng.manifest
> suite/config/tooltool-manifests/win64/releng.manifest
> > +"version": "Visual Studio 2015 Update 1 / SDK 10.0.10586.0",
> Is Update 1 enough? I think mozilla-central just switched to Update 2

Yes, I just changed that to Update 2.

> 
> > This only reflects changes to use VS2015U1.  The u2 patch is waiting
> > until the m-i patch from bug 1259782 is merged to m-c.
> I think it's merged.
> 
And it has.

> > \ No newline at end of file
> Tsk.

Oops.

Comment 12

[Edmund Wong (:ewong)]

Attachment: [mozconfigs/tooltool] proposed patch (v2)

Comment 13

[Philip Chee]

Comment on attachment 8748055 [details] [diff] [review]
[mozconfigs/tooltool] proposed patch (v2)

> suite/config/mozconfigs/win32/debug

> +if test "$PROCESSOR_ARCHITECTURE" = "AMD64" -o "$PROCESSOR_ARCHITEW6432" = "AMD64"; then
> +  . $topsrcdir/build/win32/mozconfig.vs2015-win64
> +else
> +  . $topsrcdir/build/win32/mozconfig.vs2010
I don't think mozconfig.vs2010 exists. MXR can't find it.
You probably need to port Bug 982928 and Bug 1264499 first.

> suite/config/mozconfigs/win32/nightly

> +ac_add_options --enable-require-all-d3dc-versions
Move this up to just after ac_add_options --enable-jemalloc

> suite/config/tooltool-manifests/win64/releng.manifest

> +"version": "Visual Studio 2015 Update 1 / SDK 10.0.10586.0",
> +"size": 330570496,
> +"digest": "0379fd087705f54aeb335449e6c623cd550b656d7110acafd1e5b315e1fc9272b7cdd1e37f99d575b16ecba4e8e4fe3af965967a3944c023b83caf68fa684888",
> +"algorithm": "sha512",
> +"filename": "vs2015u1.zip",
> +"unpack": true
If we have Update 2 do we still need Update 1?

> suite/config/tooltool-manifests/win32/l10n.manifest
Do the l10n manifests need VS20xx? All they do is repacks right?

Comment 14

[Edmund Wong (:ewong)]

(In reply to Philip Chee from comment #13)
> Comment on attachment 8748055 [details] [diff] [review]
> [mozconfigs/tooltool] proposed patch (v2)
> 
> > suite/config/mozconfigs/win32/debug
> 
> > +if test "$PROCESSOR_ARCHITECTURE" = "AMD64" -o "$PROCESSOR_ARCHITEW6432" = "AMD64"; then
> > +  . $topsrcdir/build/win32/mozconfig.vs2015-win64
> > +else
> > +  . $topsrcdir/build/win32/mozconfig.vs2010
> I don't think mozconfig.vs2010 exists. MXR can't find it.
> You probably need to port Bug 982928 and Bug 1264499 first.

I'll just include those bugs fixes in  here.  (I'm already
spinning in bugs as it is. :P )

> 
> > suite/config/mozconfigs/win32/nightly
> 
> > +ac_add_options --enable-require-all-d3dc-versions
> Move this up to just after ac_add_options --enable-jemalloc

Ok.
> 
> > suite/config/tooltool-manifests/win64/releng.manifest
> 
> > +"version": "Visual Studio 2015 Update 1 / SDK 10.0.10586.0",
> > +"size": 330570496,
> > +"digest": "0379fd087705f54aeb335449e6c623cd550b656d7110acafd1e5b315e1fc9272b7cdd1e37f99d575b16ecba4e8e4fe3af965967a3944c023b83caf68fa684888",
> > +"algorithm": "sha512",
> > +"filename": "vs2015u1.zip",
> > +"unpack": true
> If we have Update 2 do we still need Update 1?
No.  Will fix that.

> 
> > suite/config/tooltool-manifests/win32/l10n.manifest
> Do the l10n manifests need VS20xx? All they do is repacks right?

Right, but it needs to run configure which requires all the build stuff
in place.

Comment 15

[Edmund Wong (:ewong)]

(In reply to Edmund Wong (:ewong) from comment #14)
> (In reply to Philip Chee from comment #13)
> > Comment on attachment 8748055 [details] [diff] [review]
> > [mozconfigs/tooltool] proposed patch (v2)
> > 
> > > suite/config/mozconfigs/win32/debug
> > 
> > > +if test "$PROCESSOR_ARCHITECTURE" = "AMD64" -o "$PROCESSOR_ARCHITEW6432" = "AMD64"; then
> > > +  . $topsrcdir/build/win32/mozconfig.vs2015-win64
> > > +else
> > > +  . $topsrcdir/build/win32/mozconfig.vs2010
> > I don't think mozconfig.vs2010 exists. MXR can't find it.
> > You probably need to port Bug 982928 and Bug 1264499 first.
> 
> I'll just include those bugs fixes in  here.  (I'm already
> spinning in bugs as it is. :P )

 On second thoughts, I don't think we're ready for bug 1264499
(especially doing the mozconfig.vs-latest change as that'll break
TB as well.  I think that needs to be a separate bug.
> > 
> > > suite/config/tooltool-manifests/win64/releng.manifest
> > 
> > > +"version": "Visual Studio 2015 Update 1 / SDK 10.0.10586.0",
> > > +"size": 330570496,
> > > +"digest": "0379fd087705f54aeb335449e6c623cd550b656d7110acafd1e5b315e1fc9272b7cdd1e37f99d575b16ecba4e8e4fe3af965967a3944c023b83caf68fa684888",
> > > +"algorithm": "sha512",
> > > +"filename": "vs2015u1.zip",
> > > +"unpack": true
> > If we have Update 2 do we still need Update 1?
> No.  Will fix that.
> 
> > 
> > > suite/config/tooltool-manifests/win32/l10n.manifest
> > Do the l10n manifests need VS20xx? All they do is repacks right?
> 
> Right, but it needs to run configure which requires all the build stuff
> in place.

I think I'll need to backtrack on that answer.  Apparently we still
use the releng.manifest, so yeah.  Need to fix that.

Comment 16

[Edmund Wong (:ewong)]

Attachment: [mozconfigs/tooltool] proposed patch (v3)

Comment 17

[Philip Chee]

Comment on attachment 8749491 [details] [diff] [review]
[mozconfigs/tooltool] proposed patch (v3)

r=me with the following points addressed.

suite/config/mozconfigs/win64/debug

> if test "$PROCESSOR_ARCHITECTURE" = "AMD64" -o "$PROCESSOR_ARCHITEW6432" = "AMD64"; then
>   . $topsrcdir/build/win32/mozconfig.vs2015-win64
> else
>   . $topsrcdir/build/win32/mozconfig.vs2013-win64
.......................^^^^^

> fi
I think this should point to the win64 dir e.g. Thunderbird just has:
. $topsrcdir/build/win64/mozconfig.vs2015
...................^^^^^

No need to test for PROCESSOR_ARCHITECTURE because win64.
ditto for:
suite/config/mozconfigs/win64/l10n-mozconfig
suite/config/mozconfigs/win64/nightly

Everything else looks OK.

Comment 18

[Ian Neal]

I presume you have seen Bug 1270664?

Comment 19

[Ian Neal]

and Bug 1270714?

Comment 20

[Edmund Wong (:ewong)]

Now I have. :)

Anyone interested in filing a bug?

Or do I just do everything here? Terribly confused.

Comment 21

[Ian Neal]

(In reply to Edmund Wong (:ewong) from comment #20)
> Now I have. :)
> 
> Anyone interested in filing a bug?
> 
> Or do I just do everything here? Terribly confused.

Depends if they actually land it or not, there's talk that they will make SSE a requirement going forward (https://bugzilla.mozilla.org/show_bug.cgi?id=1270664#c9)

Comment 22

[Ian Neal]

So it looks like it will be backed out of current aurora (Bug 1270664) Gecko 48 i.e. SM 2.45
We probably need to clone the bug itself and the bugs listed under Bug 1271755 - [meta] Require SSE to run Firefox

Comment 23

[Philip Chee]

> +ac_add_options --enable-application=mail

ooops I think this should be suite

Comment 24

[Edmund Wong (:ewong)]

Attachment: [mozconfigs/tooltool] proposed patch (v4)

Comment 25

[Edmund Wong (:ewong)]

Attachment: [mozconfigs/tooltool] proposed patch (v5)

this is also with the additional nl at the end of the tooltool manifests.

Comment 26

[Edmund Wong (:ewong)]

since they're backing out the m-a changes (and we haven't landed the
patch in c-a), it shouldn't make a difference.

What I'd like to do is (when approved), push the patch to c-c, and
test it if our Win2003 builders choke. (most likely will.. :P but
here's hoping they'll take the tooltool package and run with it) but
at least I can test it on the loaner.

Comment 27

[Philip Chee]

Comment on attachment 8754286 [details] [diff] [review]
[mozconfigs/tooltool] proposed patch (v5)

> # Run client.py
> mk_add_options CLIENT_PY_ARGS="$([ -f $topsrcdir/build/client.py-args ] && cat $topsrcdir/build/client.py-args)"
> mk_add_options ALWAYS_RUN_CLIENT_PY=1
All the Thunderbird files have this at the end. What does this do?

> suite/config/mozconfigs/win64/l10n-mozconfig
For L10n don't we need to build lightning locales too? e.g.

# Build lightning locales
ac_add_options --enable-calendar

Also note that. Thunderbird enables lightning in all their mozconfig files.

Comment 28

[Edmund Wong (:ewong)]

(In reply to Philip Chee from comment #27)
> Comment on attachment 8754286 [details] [diff] [review]
> [mozconfigs/tooltool] proposed patch (v5)
> 
> > # Run client.py
> > mk_add_options CLIENT_PY_ARGS="$([ -f $topsrcdir/build/client.py-args ] && cat $topsrcdir/build/client.py-args)"
> > mk_add_options ALWAYS_RUN_CLIENT_PY=1
> All the Thunderbird files have this at the end. What does this do?

It  looks up the client.py-args file and runs the miscellaneous hgtool.py
commands.  It also allows us to specify specific mozilla-central patches
when pushing to try-comm-central.   We don't need this.


> 
> > suite/config/mozconfigs/win64/l10n-mozconfig
> For L10n don't we need to build lightning locales too? e.g.

I haven't been keeping myself up to date with the lightning
integration.  Is this complete?  If so, yeah; but at this moment,
I'm inclined not to complicate things.

> 
> # Build lightning locales
> ac_add_options --enable-calendar
> 
> Also note that. Thunderbird enables lightning in all their mozconfig files.

We don't bundle lightning with SeaMonkey yet, (afaik).

Comment 29

[Edmund Wong (:ewong)]

Attachment: [mozconfigs/tooltool] proposed patch (v6) (fix bitrot)

Comment 30

[Edmund Wong (:ewong)]

https://hg.mozilla.org/comm-central/rev/fc226ce75631929267fcecee3f8ba974c00fafb8
Bug 1092468 - Migrate SeaMonkey to VS2015u2. r+a=RattyAway

Comment 31

[Edmund Wong (:ewong)]

Comment on attachment 8755695 [details] [diff] [review]
[mozconfigs/tooltool] proposed patch (v6) (fix bitrot)

Pushed to comm-central:
https://hg.mozilla.org/comm-central/rev/fc226ce75631

Comment 32

[Adrian Kalla [:adriank]]

(In reply to Edmund Wong (:ewong) from comment #28)
> > > suite/config/mozconfigs/win64/l10n-mozconfig
> > For L10n don't we need to build lightning locales too? e.g.
> 
> I haven't been keeping myself up to date with the lightning
> integration.  Is this complete?  If so, yeah; but at this moment,
> I'm inclined not to complicate things.

It is complete - see bug 516026 :)


> > # Build lightning locales
> > ac_add_options --enable-calendar
> > 
> > Also note that. Thunderbird enables lightning in all their mozconfig files.
> 
> We don't bundle lightning with SeaMonkey yet, (afaik).

We do, see bug 516026 :)

Comment 33

[Edmund Wong (:ewong)]

Attachment: [mozconfigs] additional patch to update the mozconfigs

Comment 34

[Philip Chee]

Comment on attachment 8757739 [details] [diff] [review]
[mozconfigs] additional patch to update the mozconfigs

Looks reasonable. r=me

Comment 35

[Edmund Wong (:ewong)]

https://hg.mozilla.org/comm-central/rev/5ae21421f70966b91ead523185a9468c6e1c6b8e
Bug 1092468 - Additional patch to update the mozconfigs. r+a=RattyAway

Comment 36

[Edmund Wong (:ewong)]

Attachment: [mozconfig] fix for path typo

Comment 37

[Edmund Wong (:ewong)]

https://hg.mozilla.org/comm-central/rev/1933cb34ca1c08be7156f155f8d487bc268b9f55
Bug 1092468 - Fix for path typo. r+a=bustagefix

Comment 38

[Frank-Rainer Grahl (:frg)]

MOZ_REQUIRE_ADDON_SIGNING seems to be dead/changed. I think it's now MOZ_REQUIRE_SIGNING. I don't see any references to MOZ_REQUIRE_ADDON_SIGNING in the m-c source tree using dxr.

Comment 39

[Edmund Wong (:ewong)]

All of the patches (preferably w/ typo fixes included in one whole patch) need to be 
transplanted/pushed to c-a to c-b (if not c-r as well).

Comment 40

[Edmund Wong (:ewong)]

correction.  It only needs to be pushed to comm-beta.

Comment 41

[Edmund Wong (:ewong)]

Attachment: [c-b][mozconfigs] patch to be applied to c-b

for c-b

Comment 42

[Edmund Wong (:ewong)]

Comment on attachment 8768016 [details] [diff] [review]
[c-b][mozconfigs] patch to be applied to c-b

asking Callek's review..  just in case he sees this before Ratty (and since
it is a critical patch that needs reviewing).

Comment 43

[Edmund Wong (:ewong)]

Attachment: [c-b][mozconfigs] proposed patch (v2) [checked-in]

forgot the debug file and re-added the eof newline.

Comment 44

[Edmund Wong (:ewong)]

(In reply to Edmund Wong (:ewong) from comment #43)
> Created attachment 8769408 [details] [diff] [review]
> [c-b][mozconfigs] proposed patch (v2)
> 
> forgot the debug file and re-added the eof newline.

Going for a post-land-review.

Comment 45

[Edmund Wong (:ewong)]

https://hg.mozilla.org/releases/comm-beta/rev/f4630059ac9038491e1e16a65441fbf6c2777e00
Bug 1092468 - Update win32 mozconfigs and add win64 mozconfigs to c-b. r+a=bustagefix

Comment 46

[Edmund Wong (:ewong)]

Comment on attachment 8769408 [details] [diff] [review]
[c-b][mozconfigs] proposed patch (v2) [checked-in]

Pushed to releases/comm-beta:
https://hg.mozilla.org/releases/comm-beta/rev/f4630059ac90

Comment 47

[Edmund Wong (:ewong)]

Comment on attachment 8769408 [details] [diff] [review]
[c-b][mozconfigs] proposed patch (v2) [checked-in]

This needs to be pushed to c-r as well

Comment 48

[Philip Chee]

Comment on attachment 8769408 [details] [diff] [review]
[c-b][mozconfigs] proposed patch (v2) [checked-in]

This looks reasonable. I have, of course, no way to test this.
rs=me

Comment 49

[Edmund Wong (:ewong)]

I'm closing this bug as 'fixed' because...

1) All the patches are either pushed or uplifted.
2) Our current windows slaves aren't even working and won't work until
   we get them upgraded to Win2008r2.