Closed
Bug 1351984
(SM2.48)
Opened 8 years ago
Closed 7 years ago
Tracking bug for build and release of SeaMonkey 2.48
Categories
(SeaMonkey :: Release Engineering, enhancement, P1)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: ewong, Assigned: ewong)
References
()
Details
Attachments
(13 files, 3 obsolete files)
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
frg
:
review+
|
Details | Diff | Splinter Review |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
frg
:
review+
|
Details | Diff | Splinter Review |
(deleted),
patch
|
frg
:
review+
|
Details | Diff | Splinter Review |
(deleted),
patch
|
frg
:
review+
|
Details | Diff | Splinter Review |
(deleted),
text/plain
|
Details | |
(deleted),
text/plain
|
Details | |
(deleted),
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.
Assignee | ||
Comment 1•8 years ago
|
||
2.48 will be spun right after 2.48b1..
the blocking bugs will most likely be the same as well
Assignee | ||
Updated•8 years ago
|
Assignee | ||
Updated•8 years ago
|
Assignee | ||
Comment 2•8 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.
Comment 3•8 years ago
|
||
All comm-beta Patches for 2.48 from 2.48 beta 1. Not tested yet.
Comment 4•8 years ago
|
||
Patches from 2.48b1 for mozilla-release. Not yet tested
Comment 5•8 years ago
|
||
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•8 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)
Comment 7•7 years ago
|
||
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.
Depends on: 1314347
Comment 8•7 years ago
|
||
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•7 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+
Comment 10•7 years ago
|
||
NITS addressed. r+ from ewong carried forward.
Attachment #8881074 -
Attachment is obsolete: true
Attachment #8881161 -
Flags: review+
Assignee | ||
Comment 11•7 years ago
|
||
https://hg.mozilla.org/build/buildbot-configs/rev/d2a17a6a21ced5187ac262062930fe34f65adeeb
Bug 1351984 - Update configs for SeaMonkey 2.48. r=ewong
Assignee | ||
Comment 12•7 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•7 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 14•7 years ago
|
||
Assignee | ||
Comment 15•7 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 | ||
Comment 16•7 years ago
|
||
Assignee | ||
Comment 17•7 years ago
|
||
Assignee | ||
Updated•7 years ago
|
Attachment #8886744 -
Attachment description: [tools] change nightly to candidates. → [tools] change nightly to candidates. [fix]
Assignee | ||
Updated•7 years ago
|
Attachment #8886745 -
Flags: review?(frgrahl)
Assignee | ||
Comment 18•7 years ago
|
||
note to self: qrefresh
Attachment #8886745 -
Attachment is obsolete: true
Attachment #8886745 -
Flags: review?(frgrahl)
Comment 19•7 years ago
|
||
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 20•7 years ago
|
||
Assignee | ||
Comment 21•7 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•7 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•7 years ago
|
Attachment #8886831 -
Flags: review?(frgrahl)
Assignee | ||
Updated•7 years ago
|
Attachment #8886842 -
Flags: review?(frgrahl)
Assignee | ||
Comment 23•7 years ago
|
||
Attachment #8886831 -
Attachment is obsolete: true
Attachment #8886831 -
Flags: review?(frgrahl)
Attachment #8886845 -
Flags: review?(frgrahl)
Comment 24•7 years ago
|
||
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 25•7 years ago
|
||
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•7 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..
Comment 27•7 years ago
|
||
This rang a bell. Maybe check bug 1363711 comment 7?
Assignee | ||
Comment 28•7 years ago
|
||
Assignee | ||
Comment 29•7 years ago
|
||
Updated•7 years ago
|
Attachment #8887345 -
Attachment mime type: text/x-log → text/plain
Updated•7 years ago
|
Attachment #8887351 -
Attachment mime type: text/x-log → text/plain
Comment 30•7 years ago
|
||
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•7 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•7 years ago
|
||
https://hg.mozilla.org/build/buildbotcustom/rev/6ef9db1c0e32bdc5649cc4e59a3edb67aa2fa149
Bug 1351984 - Use the right candidatesPath for release updates. r=frg
Assignee | ||
Updated•7 years ago
|
Attachment #8884487 -
Attachment description: [configs] fix gecko version .. → [configs] fix gecko version .. [checked-in]
Assignee | ||
Updated•7 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•7 years ago
|
Attachment #8886744 -
Attachment description: [tools] change nightly to candidates. [fix] → [tools] change nightly to candidates. [fix] [checked-in]
Assignee | ||
Updated•7 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•7 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•7 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•7 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•7 years ago
|
||
https://hg.mozilla.org/build/buildbotcustom/rev/4e74ee31bf2115c4f01d8ffc0136d2a1e5dd6a16
Bug 1351984 - use ShellCommand instead of MockCommand to use the updated hg
Comment 35•7 years ago
|
||
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•7 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•7 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
Closed: 7 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.
Description
•