1351984 - (SM2.48) Tracking bug for build and release of SeaMonkey 2.48

Status: RESOLVED FIXED

(SeaMonkey :: Release Engineering, enhancement, P1)

Description

[Edmund Wong (:ewong)]

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

We expect an actual release on tba.

Comment 1

[Edmund Wong (:ewong)]

2.48 will be spun right after 2.48b1.. 

the blocking bugs will most likely be the same as well

Comment 2

[Edmund Wong (:ewong)]

Please note.  I have transplanted the 2.48b1 required m-b patches to the m-r relbranch
(SEA_COMM510_20170330_RELBRANCH), so if there are any other necessary patches
(the c-r relbranch will be done as well), please make sure you update to
SEA_COMM510_20170330_RELBRANCH on c-r and m-r and push there, especially
with the DONTBUILD in the comment.

Comment 3

[Frank-Rainer Grahl (:frg)]

Attachment: 248commm-release.patch

All comm-beta Patches for 2.48 from 2.48 beta 1. Not tested yet.

Comment 4

[Frank-Rainer Grahl (:frg)]

Attachment: 248mozilla-release.patch

Patches from 2.48b1 for mozilla-release. Not yet tested

Comment 5

[Frank-Rainer Grahl (:frg)]

Attachment: 248mozilla-release-missing.patch

ewong, this seems to be missing from the 2.48 release branch in m-r. Everything else is there.

Comment 6

[Edmund Wong (:ewong)]

(In reply to Frank-Rainer Grahl from comment #5)
> Created attachment 8858377 [details] [diff] [review]
> 248mozilla-release-missing.patch
> 
> ewong, this seems to be missing from the 2.48 release branch in m-r.
> Everything else is there.

Ah..  I'll have that transplanted too.  Thanks

Comment 7

[Frank-Rainer Grahl (:frg)]

I just pushed the missing changes which did accidently go to the beta branch to the release branch. Weren't that many so i didn't do a merge:

https://hg.mozilla.org/releases/comm-release/rev/e544650041c730b46fdc6added7aad8b36783b85
https://hg.mozilla.org/releases/comm-release/rev/648006aa3339a8588d5471af255008cf2f236b71
https://hg.mozilla.org/releases/comm-release/rev/c21b30423012fea4ded271ff70db633dbe15a3d4
https://hg.mozilla.org/releases/comm-release/rev/f31ed651074b50355fdbc0192dfa8217da997951
https://hg.mozilla.org/releases/comm-release/rev/37c3d0aea1854db2d276cd6b3834940bc0dfa26d

I would like to include Bug 1314347 too. Will check now if it can be transplanted to 2.48.

Comment 8

[Frank-Rainer Grahl (:frg)]

Attachment: 1351984-248-configs.patch

2.48 release configs. Just build en-US de and en-GB locally. 

For l10n I changed the follwing compared to the beta:

ja-JP-mac osx
(0ca52430f89c) 51.0: sync devtools/client with en-US rev356614:749a8d32b74e
Masahiko Imanaka <[e-mail]>

Massive devtools patch for Fx 51. 

zh-CN
(d260be15e967) Pontoon: Update Chinese (zh-CN) localization of Firefox Beta

The old one was completly off. 

The l10n trees might need new tags. Please check. 

ca, fi, gl, nb_NO, tr and uk removed.

Comment 9

[Edmund Wong (:ewong)]

Comment on attachment 8881074 [details] [diff] [review]
1351984-248-configs.patch

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

Also, the contents of https://hg.mozilla.org/build/buildbot-configs/file/73d5b67525d4/seamonkey/release_config.py
needs to changed to release-comm-release.py 

So r+ with those changes.

::: seamonkey/release-comm-release.py
@@ +23,5 @@
>  releaseConfig['oldRepoPath']                = 'releases/comm-release'
>  #  Next (nightly) version info
>  #     not yet available
>  #  Repository configuration, for tagging
>  releaseConfig['skip_tag']                   = False 

Please also get rid of that trailing space I must've
added in a previous revision.

@@ +51,3 @@
>  #  L10n repositories
>  releaseConfig['l10nRepoPath']               = 'releases/l10n/mozilla-release'
> +releaseConfig['l10nRelbranchOverride']      = 'SEA_COMM510_20170330_RELBRANCH'

This needs to be ''
the RelBranchOverride is only used when we do more than one build.

Comment 10

[Frank-Rainer Grahl (:frg)]

Attachment: 1351984-248-configs-V2.patch

NITS addressed. r+ from ewong carried forward.

Comment 11

[Edmund Wong (:ewong)]

https://hg.mozilla.org/build/buildbot-configs/rev/d2a17a6a21ced5187ac262062930fe34f65adeeb
Bug 1351984 - Update configs for SeaMonkey 2.48. r=ewong

Comment 12

[Edmund Wong (:ewong)]

Attachment: [configs] fix gecko version .. [checked-in]

while c-r *is* 53, we are building 51 on a relbranch.  Instead of
adding a whole bunch of code to work around this, I opted to change
the gecko version.  We'll need to change this for 2.49.1.

Comment 13

[Edmund Wong (:ewong)]

Comment on attachment 8884487 [details] [diff] [review]
[configs] fix gecko version .. [checked-in]

to note though: this will affect or regular c-r builds (which are based
on 53).  I've manually applied this patch to the master and retriggered
the osx64 build.

Comment 14

[Edmund Wong (:ewong)]

Attachment: [tools] remove quotes from the buildID info str from *_info.txt file [checked-in]

Comment 15

[Edmund Wong (:ewong)]

Comment on attachment 8886471 [details] [diff] [review]
[tools] remove quotes from the buildID info str from *_info.txt file [checked-in]

rationale for this patch is to avoid the bump bustage when " exist in the
win32_info.txt file.  (Even if I remove it afterwards, there is a caching time
in cloudfront, so it will get the bad win32_info.txt file.)

Comment 16

[Edmund Wong (:ewong)]

Attachment: [tools] change nightly to candidates. [fix] [checked-in]

Comment 17

[Edmund Wong (:ewong)]

Attachment: [tools] fix update-verify-bump.pl to use candidates dir and not nightly

Comment 18

[Edmund Wong (:ewong)]

Attachment: [tools] fix update-verify-bump.pl to use candidates dir and not nightly [checked-in]

note to self:  qrefresh

Comment 19

[Frank-Rainer Grahl (:frg)]

Comment on attachment 8886746 [details] [diff] [review]
[tools] fix update-verify-bump.pl to use candidates dir and not nightly [checked-in]

ewong you unset the r?. If this wasn't intentional looks ok to me:)

Is this probably an old bug?
For the old releases I see:
https://archive.mozilla.org/pub/seamonkey/nightly/2.46-candidates/build9/update/win32/

which looks wrong to me.

2.48 has the partial.mar files in the update directory so the patched version should find them:
https://archive.mozilla.org/pub/seamonkey/candidates/2.48-candidates/build1/update/win32/

Comment 20

[Edmund Wong (:ewong)]

Attachment: [tools] update check_updates.sh to reflect changes in the updater binary for mac

Comment 21

[Edmund Wong (:ewong)]

(In reply to Frank-Rainer Grahl (:frg) from comment #19)
> Comment on attachment 8886746 [details] [diff] [review]
> [tools] fix update-verify-bump.pl to use candidates dir and not nightly
> 
> ewong you unset the r?. If this wasn't intentional looks ok to me:)
> 
> Is this probably an old bug?
> For the old releases I see:
> https://archive.mozilla.org/pub/seamonkey/nightly/2.46-candidates/build9/
> update/win32/
> 
> which looks wrong to me.
> 
> 2.48 has the partial.mar files in the update directory so the patched
> version should find them:
> https://archive.mozilla.org/pub/seamonkey/candidates/2.48-candidates/build1/
> update/win32/

all release candidates are placed in candidates/.  Will need to find out
where the nightly/* are being generated.

Comment 22

[Edmund Wong (:ewong)]

Attachment: [custom] use the right candidates dir (candidates instead of nightly) [checked-in]

This was actually supposed to be done with 2.46 (or even earlier.)

it's for the change-nightly-to-candidates patch.

Comment 23

[Edmund Wong (:ewong)]

Attachment: [tools] update check_updates.sh to reflect changes in mac updater binary [checked-in]

Comment 24

[Frank-Rainer Grahl (:frg)]

Comment on attachment 8886845 [details] [diff] [review]
[tools] update check_updates.sh to reflect changes in mac updater binary [checked-in]

r+

Bug 394984 changed this in toolkit for Gecko 49. Am I right that older updates run the old updater and 2.46+ the new one in Contents/MacOS/updater.app/Contents/MacOS/org.mozilla.updater so that both locations are needed?

Comment 25

[Frank-Rainer Grahl (:frg)]

Comment on attachment 8886842 [details] [diff] [review]
[custom] use the right candidates dir (candidates instead of nightly) [checked-in]

r+ and thanks

Comment 26

[Edmund Wong (:ewong)]

Win32 update verify bustage:

Files source/bin/softokn3.chk and target/bin/softokn3.chk differ
Files source/bin/softokn3.dll and target/bin/softokn3.dll differ
Files source/bin/ucrtbase.dll and target/bin/ucrtbase.dll differ
Files source/bin/uninstall/helper.exe and target/bin/uninstall/helper.exe differ
Files source/bin/updater.exe and target/bin/updater.exe differ
Files source/bin/vcruntime140.dll and target/bin/vcruntime140.dll differ
Files source/bin/wow_helper.exe and target/bin/wow_helper.exe differ
Files source/bin/xul.dll and target/bin/xul.dll differ
Contents of source/bin/distribution dir only in source or target
41885637    0 drwxr-xr-x   2 seabld   Administrators        0 Jul  02:28 source/bin/distribution/extensions
14819270  172 -rw-r--r--   1 seabld   Administrators   351314 Nov   2015 source/bin/distribution/extensions/[e-mail]
14819271  193 -rw-r--r--   1 seabld   Administrators   394064 Nov   2015 source/bin/distribution/extensions/{59c81df5-4b7a-477b-912d-4e0fdf64e5f2}.xpi
FAIL: binary files found in diff
FAIL: check_updates returned failure for WINNT_x86-msvc downloads/SeaMonkey Setup 2.39.exe vs. downloads/SeaMonkey Setup 2.48.exe: 1

so yeah..  gonna need to think about this more as it affects 2.38 binaries..

Comment 27

[Frank-Rainer Grahl (:frg)]

This rang a bell. Maybe check bug 1363711 comment 7?

Comment 28

[Edmund Wong (:ewong)]

Attachment: log for win32 update verify

Comment 29

[Edmund Wong (:ewong)]

Attachment: patcher log

Comment 30

[Nick Thomas [:nthomas] (UTC+12)]

It looks the update server is a bit misconfigured. Most of the requests to aus2-community return 2.48 build1, but the first failure in attachment 8887345 [details] gets back 2.46. Annotated and trimmmed log snippet:

# make the update request, which is on the betatest channel ??  We get back 2.46 instead of 2.48
Using  https://aus2-community.mozilla.org/update/1/SeaMonkey/2.39/20151103191810/WINNT_x86-msvc/de/betatest/update.xml?force=1
Got this response:
<?xml version="1.0"?>
<updates>
    <update type="minor" version="2.46" extensionVersion="2.46" buildID="20161213183751" detailsURL="http://www.seamonkey-project.org/releases/seamonkey2.46/">
        <patch type="complete" URL="http://archive.mozilla.org/pub/seamonkey/candidates/2.46-candidates/build9/update/win32/de/seamonkey-2.46.complete.mar" hashFunction="SHA512" hashValue="e15f
f8f7d34b032dd1e105217c06046a90ac56b8b330d9cdce5eab26ff62d5ebc414011a14857797452b04ec53904db76d80f47a9df9dc61a0eb2c66ddcf858b" size="46973305"/>
    </update>
</updates>

# grab the complete mar
Executing: ['wget.exe', '--no-check-certificate', '-nv', '-O', 'update/complete.mar', 'http://archive.mozilla.org/pub/seamonkey/candidates/2.46-candidates/build9/update/win32/de/seamonkey-2.46.complete.mar']

# grab the 'from' build installer, v2.39
Executing: ['wget.exe', '--no-check-certificate', '-nv', 'archive.mozilla.org/pub/seamonkey/releases/2.39/win32/de/SeaMonkey Setup 2.39.exe']

# grab the 'to' build installer, but it's v2.48 (this seems correct in the update verify config)
Executing: ['wget.exe', '--no-check-certificate', '-nv', 'archive.mozilla.org/pub/seamonkey/candidates/2.48-candidates/build1/win32/de/SeaMonkey Setup 2.48.exe']

So 2.39 + 2.46 mar != 2.48. If the update server returns 2.48 I suspect this will completely go away. This affects all three v2.39 locales tested.

Comment 31

[Edmund Wong (:ewong)]

(In reply to Nick Thomas [:nthomas] from comment #30)
> It looks the update server is a bit misconfigured. Most of the requests to
> aus2-community return 2.48 build1, but the first failure in attachment
> 8887345 [details] gets back 2.46. Annotated and trimmmed log snippet:

Like always, Nick, you are superbly amazing!!

The Updates step, while *green*, actually was horked up due to the fact that since I was doing the
Win32 builds manually,  I had the following in the win32_info.txt.

"buildID=<id>"


There *is* a <space>^M at the end of that line.

I didn't notice this problem. I only noticed the quotes, which is why I had some issues with
the updates part.  I fixed the quotes (but not the CR issue as it didn't cross my mind... which
it should have since this *isn't* the first time I've encountered this).

Anyway, when Nick mentioned the 'update server is a bit misconfigured', I went to aus2 and
went into 2.39's WINNT path and when I saw the list of buildIDs, that's when it clued in.
Here's what I saw:

drwxrwxr-x  27 seabld seamonkey 4096 Apr  2 21:16 20151028200458
drwxrwxr-x  28 seabld seamonkey 4096 Dec 19  2016 20151103191810
drwxrwxr-x  21 seabld seamonkey 4096 Jul 14 03:18 20151103191810 ?

Anyone notice that last entry?   Yes.  That's because of the <space>^M

So... I fixed the win32_info.txt.  Backed out the patcher config changes and update verify config
changes and retriggered the Update.  And I deleted that errant folder.

Comment 32

[Edmund Wong (:ewong)]

https://hg.mozilla.org/build/buildbotcustom/rev/6ef9db1c0e32bdc5649cc4e59a3edb67aa2fa149
Bug 1351984 - Use the right candidatesPath for release updates. r=frg

Comment 33

[Edmund Wong (:ewong)]

Attachment: [custom] need to use ShellCommand and not MockCommand

MockCommand runs the command in the mock environment which uses an old
hg version.  We need to use an updated version.  

[for post-land-review]

Comment 34

[Edmund Wong (:ewong)]

https://hg.mozilla.org/build/buildbotcustom/rev/4e74ee31bf2115c4f01d8ffc0136d2a1e5dd6a16
Bug 1351984 - use ShellCommand instead of MockCommand to use the updated hg

Comment 35

[Frank-Rainer Grahl (:frg)]

Comment on attachment 8887725 [details] [diff] [review]
[custom] need to use ShellCommand and not MockCommand

quick r+ from a train.

Comment 36

[Edmund Wong (:ewong)]

Due to the incompetence on my part, I boffed up the bouncer bug's description.  I had it go from 2.39 to
2.48; but it's actually 2.46 to 2.48.   We will need to wait until bug 1351985 to be fixed before
we can proceed.  

Sorry.

Comment 37

[Edmund Wong (:ewong)]

With 2.48 released, there's little point in having the l10n and Operation YSNP block it.