Bug 1351984 (SM2.48)

Tracking bug for build and release of SeaMonkey 2.48

RESOLVED FIXED

Status

enhancement
P1
blocker
RESOLVED FIXED
2 years ago
2 years ago

People

(Reporter: ewong, Assigned: ewong)

Tracking

SeaMonkey 2.48 Branch
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

()

Attachments

(13 attachments, 3 obsolete attachments)

27.30 KB, patch
Details | Diff | Splinter Review
13.96 KB, patch
Details | Diff | Splinter Review
5.96 KB, patch
Details | Diff | Splinter Review
5.83 KB, patch
frg
: review+
Details | Diff | Splinter Review
481 bytes, patch
Details | Diff | Splinter Review
953 bytes, patch
Details | Diff | Splinter Review
6.67 KB, patch
Details | Diff | Splinter Review
1.19 KB, patch
frg
: review+
Details | Diff | Splinter Review
2.30 KB, patch
frg
: review+
Details | Diff | Splinter Review
2.07 KB, patch
frg
: review+
Details | Diff | Splinter Review
8.06 MB, text/plain
Details
5.06 MB, text/plain
Details
1.74 KB, patch
frg
: review+
Details | Diff | Splinter Review
This is a tracking bug for Build and Release of SeaMonkey 2.48

We expect an actual release on tba.
Depends on: 1351985
No longer depends on: SM2.39
2.48 will be spun right after 2.48b1.. 

the blocking bugs will most likely be the same as well
No longer depends on: 1329379, 1336312, 1350805, 1351987
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.
All comm-beta Patches for 2.48 from 2.48 beta 1. Not tested yet.
Patches from 2.48b1 for mozilla-release. Not yet tested
ewong, this seems to be missing from the 2.48 release branch in m-r. Everything else is there.
Flags: needinfo?(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
Flags: needinfo?(ewong)
Depends on: 1364977
Depends on: 1368277
Posted patch 1351984-248-configs.patch (obsolete) — Splinter Review
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 <chimantaea_mirabilis@yahoo.co.jp>

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.
Attachment #8881074 - Flags: review?(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.
Attachment #8881074 - Flags: review?(ewong) → review+
NITS addressed. r+ from ewong carried forward.
Attachment #8881074 - Attachment is obsolete: true
Attachment #8881161 - Flags: review+
No longer depends on: 1312353
Depends on: 1379343
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 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 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.)
Attachment #8886744 - Attachment description: [tools] change nightly to candidates. → [tools] change nightly to candidates. [fix]
Attachment #8886745 - Flags: review?(frgrahl)
note to self:  qrefresh
Attachment #8886745 - Attachment is obsolete: true
Attachment #8886745 - Flags: review?(frgrahl)
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/
Attachment #8886746 - Flags: review+
(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.
This was actually supposed to be done with 2.46 (or even earlier.)

it's for the change-nightly-to-candidates patch.
Attachment #8886831 - Flags: review?(frgrahl)
Attachment #8886842 - Flags: review?(frgrahl)
Attachment #8886831 - Attachment is obsolete: true
Attachment #8886831 - Flags: review?(frgrahl)
Attachment #8886845 - Flags: review?(frgrahl)
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?
Attachment #8886845 - Flags: review?(frgrahl) → review+
Comment on attachment 8886842 [details] [diff] [review]
[custom] use the right candidates dir (candidates instead of nightly) [checked-in]

r+ and thanks
Attachment #8886842 - Flags: review?(frgrahl) → review+
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/inspector@mozilla.org.xpi
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..
This rang a bell. Maybe check bug 1363711 comment 7?
Posted file patcher log
Attachment #8887345 - Attachment mime type: text/x-log → text/plain
Attachment #8887351 - Attachment mime type: text/x-log → text/plain
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.
(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.
Attachment #8884487 - Attachment description: [configs] fix gecko version .. → [configs] fix gecko version .. [checked-in]
Attachment #8886471 - Attachment description: [tools] remove quotes from the buildID info str from *_info.txt file → [tools] remove quotes from the buildID info str from *_info.txt file [checked-in]
Attachment #8886744 - Attachment description: [tools] change nightly to candidates. [fix] → [tools] change nightly to candidates. [fix] [checked-in]
Attachment #8886746 - Attachment description: [tools] fix update-verify-bump.pl to use candidates dir and not nightly → [tools] fix update-verify-bump.pl to use candidates dir and not nightly [checked-in]
Attachment #8886842 - Attachment description: [custom] use the right candidates dir (candidates instead of nightly) → [custom] use the right candidates dir (candidates instead of nightly) [checked-in]
Attachment #8886845 - Attachment description: [tools] update check_updates.sh to reflect changes in mac updater binary → [tools] update check_updates.sh to reflect changes in mac updater binary [checked-in]
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]
Attachment #8887725 - Flags: review?(frgrahl)
https://hg.mozilla.org/build/buildbotcustom/rev/4e74ee31bf2115c4f01d8ffc0136d2a1e5dd6a16
Bug 1351984 - use ShellCommand instead of MockCommand to use the updated hg
Comment on attachment 8887725 [details] [diff] [review]
[custom] need to use ShellCommand and not MockCommand

quick r+ from a train.
Attachment #8887725 - Flags: review?(frgrahl) → review+
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.
With 2.48 released, there's little point in having the l10n and Operation YSNP block it.
Assignee: nobody → ewong
Status: NEW → RESOLVED
Closed: 2 years ago
No longer depends on: operation_babelfish, operation_ysnp
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.