Closed Bug 512300 Opened 15 years ago Closed 15 years ago

Do fake FF3.6b1 release to test l10n changes (this is not official fake release of beta 1)

Categories

(Release Engineering :: General, defect, P3)

defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: joduinn, Assigned: armenzg)

References

Details

(Whiteboard: [l10n])

Attachments

(1 file, 2 obsolete files)

Axel has landed some changes recently to l10n.mk on mozilla-1.9.2. We'd like to make sure these fix the release automation woes we hit in FF3.5.2, before we go landing these same changes back into FF3.5.x...
bhearsum pointed out that FF3.6b1 is better choice, as that is the next planned release, and beta will contain l10n builds!
Summary: Do fake FF3.6a2 release → Do fake FF3.6b1 release
Whiteboard: [l10n]
Blocks: 489313
No longer blocks: 489313
Blocks: 511510
Assignee: nobody → armenzg
No longer blocks: 511510
Status: NEW → ASSIGNED
Priority: -- → P2
Blocks: 511460
The release on 3.6b1 will not work until we stop calling generate-snippet.py. Filed bug 515177 to track this and blocked until it is fixed.
Depends on: 515177
Regardless of the l10n work a beta release won't work until bug 514466 gets fixed for the Mac en-US build. I used this workaround https://wiki.mozilla.org/Releases/Firefox_3.6a1/BuildNotes#Build.2FRepack
Depends on: 514466
Priority: P2 → P3
Summary: Do fake FF3.6b1 release → Do fake FF3.6b1 release to test l10n changes (this is not official fake release of beta 1)
How are we doing here? We might have a code freeze for 3.6 Beta 1 next week.
I have not been able to pass even once http://staging-master.build.mozilla.org:8010/builders/win32_repack?numbuilds=50

I hope this tells you something because I have no idea:
./nspr.res finished
rm -f nspr4.dll
link -nologo -DLL -SUBSYSTEM:WINDOWS -MANIFEST:NO -LIBPATH:"e:/builds/slave/win32_repack/build/mozilla-1.9.2/memory/jemalloc/crtsrc/build/intel" -NODEFAULTLIB:msvcrt -NODEFAULTLIB:msvcrtd -DEFAULTLIB:mozcrt19 -OUT:"nspr4.dll" -DEBUG -OPT:REF -MAP   advapi32.lib wsock32.lib winmm.lib ./prvrsion.obj io/./prfdcach.obj io/./prmwait.obj io/./prmapopt.obj io/./priometh.obj io/./pripv6.obj io/./prlayer.obj io/./prlog.obj io/./prmmap.obj io/./prpolevt.obj io/./prprf.obj io/./prscanf.obj io/./prstdio.obj threads/./prcmon.obj threads/./prrwlock.obj threads/./prtpd.obj linking/./prlink.obj malloc/./prmalloc.obj malloc/./prmem.obj md/./prosdep.obj memory/./prshm.obj memory/./prshma.obj memory/./prseg.obj misc/./pralarm.obj misc/./pratom.obj misc/./prcountr.obj misc/./prdtoa.obj misc/./prenv.obj misc/./prerr.obj misc/./prerror.obj misc/./prerrortable.obj misc/./prinit.obj misc/./prinrval.obj misc/./pripc.obj misc/./prlog2.obj misc/./prlong.obj misc/./prnetdb.obj misc/./prolock.obj misc/./prrng.obj misc/./prsystem.obj misc/./prthinfo.obj misc/./prtpool.obj misc/./prtrace.obj misc/./prtime.obj io/./prdir.obj io/./prfile.obj io/./prio.obj io/./prsocket.obj misc/./pripcsem.obj threads/./prcthr.obj threads/./prdump.obj threads/./prmon.obj threads/./prsem.obj threads/combined/./prucpu.obj threads/combined/./prucv.obj threads/combined/./prulock.obj threads/combined/./prustack.obj threads/combined/./pruthr.obj md/windows/./ntmisc.obj md/windows/./ntsec.obj md/windows/./ntsem.obj md/windows/./ntinrval.obj md/windows/./ntgc.obj md/windows/./w95thred.obj md/windows/./w95io.obj md/windows/./w95cv.obj md/windows/./w95sock.obj md/windows/./win32_errors.obj md/windows/./w32ipcsem.obj md/windows/./w32poll.obj md/windows/./w32rng.obj md/windows/./w32shm.obj md/windows/./w95dllmain.obj  ./nspr.res
LINK : fatal error LNK1104: cannot open file 'mozcrt19.lib'
make[2]: Leaving directory `/e/builds/slave/win32_repack/build/mozilla-1.9.2/nsprpub/pr/src'
make[2]: *** [nspr4.dll] Error 80
make[1]: Leaving directory `/e/builds/slave/win32_repack/build/mozilla-1.9.2/nsprpub/pr'
make[1]: *** [export] Error 2
make: *** [export] Error 2
This log comes from:
http://staging-master.build.mozilla.org:8010/builders/macosx_repack/builds/1299/steps/make_installers_locale/logs/stdio

patch 1 of 2

sent 85421600 bytes  received 5120 bytes  8992286.32 bytes/sec
total size is 85393652  speedup is 1.00
"disk1" unmounted.
diskimages-helper: DI_kextDriveGetRequest returned 0x00000025 (37) ((os/kern) object terminated).
"disk1" ejected.
+ rsync -a /builds/slave/macosx_repack/build/mozilla-1.9.2/browser/locales/../../dist/unpack.tmp/Firefox.app firefox
rsync: link_stat "/builds/slave/macosx_repack/build/mozilla-1.9.2/browser/locales/../../dist/unpack.tmp/Firefox.app" failed: No such file or directory (2)
rsync error: some files could not be transferred (code 23) at /SourceCache/rsync/rsync-30/rsync/main.c(717)
make: *** [/builds/slave/macosx_repack/build/mozilla-1.9.2/browser/locales/../../dist/l10n-stage/Firefox/Firefox.app/Contents/MacOS] Error 23
Attachment #401298 - Attachment mime type: application/octet-stream → text/plain
As Axel pointed out the mac problem has to do with having used an en-US nightly to test (yes, I was suggested to wget an en-US nightly to test) which has to do with PRETTY_NAMES.

I will clobber later tonight, retrigger the en-US builds now that my recreated repos are off the correct sourceRevision and properly branched and tagged.
(In reply to comment #5)
> How are we doing here? We might have a code freeze for 3.6 Beta 1 next week.
>
The initial thought was to do a fake release to see that the patches for l10n.mk were good in 1.9.2 and then port it to 1.9.1.

I think bhearsum or nthomas would be better to do a real beta fake release than me so I am not sure if a separate bug should be filed to keep track of that.
Another problem that I have found is that the upload step for windows has succeeded (en-US) but the candidates folder does not contain it:
http://staging-stage.build.mozilla.org/pub/mozilla.org/firefox/nightly/3.6b1-candidates/build1/
(In reply to comment #12)
> Another problem that I have found is that the upload step for windows has
> succeeded (en-US) but the candidates folder does not contain it:
> http://staging-stage.build.mozilla.org/pub/mozilla.org/firefox/nightly/3.6b1-candidates/build1/

Please look harder, http://staging-stage.build.mozilla.org/pub/mozilla.org/firefox/nightly/3.6b1-candidates/build1/unsigned/
Attachment #401298 - Attachment is obsolete: true
Attachment #401303 - Attachment is obsolete: true
Attachment #401303 - Attachment mime type: application/octet-stream → text/plain
OK at this point I have verified that the mac problem is unexistant once you have the real release builds rather than renamed nightly builds.

The remaining problems are:
* Bug 514466 -  "uploadsymbols target fails when for certain filenames" which is waiting for 1.9.2 and 1.9.1.4 approvals
* The failing "make nsprpub" step for windows (I will check if the step succeeds for nightly builds in these 2 staging machines)
Depends on: 517544
All done here Armen ? Do you need anything from the repo's at hg.m.o/users/stage-ffxbld, or files in staging-stage:.../firefox/nightly/3.6b1-candidates ?
Blocks: 518495
Everything is done in here.
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.