Bug 1351984 (SM2.48)

Tracking bug for build and release of SeaMonkey 2.48

RESOLVED FIXED

Status

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

(URL)

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

Description

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

We expect an actual release on tba.
(Assignee)

Updated

2 years ago
Depends on: 1351985
(Assignee)

Updated

2 years ago
No longer depends on: 1221342
(Assignee)

Comment 1

2 years ago
2.48 will be spun right after 2.48b1.. 

the blocking bugs will most likely be the same as well
(Assignee)

Updated

2 years ago
No longer depends on: 1329379, 1336312, 1350805, 1351987
(Assignee)

Comment 2

2 years ago
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)
(Assignee)

Comment 6

2 years ago
(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)
(Assignee)

Comment 9

2 years ago
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
(Assignee)

Updated

2 years ago
Depends on: 1379343
(Assignee)

Comment 12

2 years ago
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.
(Assignee)

Comment 13

2 years ago
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.
(Assignee)

Comment 15

2 years ago
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.)
(Assignee)

Updated

2 years ago
Attachment #8886744 - Attachment description: [tools] change nightly to candidates. → [tools] change nightly to candidates. [fix]
(Assignee)

Updated

2 years ago
Attachment #8886745 - Flags: review?(frgrahl)
(Assignee)

Comment 18

2 years ago
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+
(Assignee)

Comment 21

2 years ago
(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.
(Assignee)

Comment 22

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

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

Updated

2 years ago
Attachment #8886831 - Flags: review?(frgrahl)
(Assignee)

Updated

2 years ago
Attachment #8886842 - Flags: review?(frgrahl)
(Assignee)

Comment 23

2 years ago
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+
(Assignee)

Comment 26

2 years ago
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?
(Assignee)

Comment 28

2 years ago
(Assignee)

Comment 29

2 years ago
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.
(Assignee)

Comment 31

2 years ago
(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.
(Assignee)

Comment 32

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

Updated

2 years ago
Attachment #8884487 - Attachment description: [configs] fix gecko version .. → [configs] fix gecko version .. [checked-in]
(Assignee)

Updated

2 years ago
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]
(Assignee)

Updated

2 years ago
Attachment #8886744 - Attachment description: [tools] change nightly to candidates. [fix] → [tools] change nightly to candidates. [fix] [checked-in]
(Assignee)

Updated

2 years ago
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]
(Assignee)

Updated

2 years ago
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]
(Assignee)

Updated

2 years ago
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]
(Assignee)

Comment 33

2 years ago
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)
(Assignee)

Comment 34

2 years ago
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+
(Assignee)

Comment 36

2 years ago
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.
(Assignee)

Comment 37

2 years ago
With 2.48 released, there's little point in having the l10n and Operation YSNP block it.
Assignee: nobody → ewong
Status: NEW → RESOLVED
Last Resolved: 2 years ago
No longer depends on: 1231349, 1254401
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.