531275 - Generate localized builds of WinCE (nightly and releases)

Status: RESOLVED FIXED

(Release Engineering :: General, defect, P2)

Description

[Armen [:armenzg]]

On bug 523856 we are going to have the ability to generate localized CABs for locales and we have to integrate that into our systems.

Starting first with nightly builds and then tackling the release infra for it.

At first we will deal with Indonesian build (id) but we can add more locales as we go and have the ability to create all-locales if requested.

Comment 1

[Armen [:armenzg]]

Attachment: [WIP] [moz2-staging] add wince entry to L10N_SLAVES

Comment 2

[Armen [:armenzg]]

Attachment: [WIP][buildbotcustom] add wince L10n nightly builder and deal with the special cases that it requires

Comment 3

[Armen [:armenzg]]

My first stab at this was not as successful as I wanted it to be. The buildbot side seems to be fine (a nightly triggers the 'id' locale run) but not the environment variables and configure arguments side of it.

Before I played with the environment variables and the configure arguments I tried to pass MOZ_PKG_PLATFORM but it made "make installers-%" not usable (I wonder if I should pushed this further). 

The problem I have been having was to get the right package names (without thinking of CABs yet). "win32" was being used as the platform and that is why I have tried using configure arguments and environment variables.

I am passing the environment variables that are used for a WinCE nightly build but I am not sure if these are needed.

For the configure arguments I added this:
 self.extraConfigureArgs =+ ['--target=arm-wince', '--enable-win32-target=WINCE']
but not sure if I have to pull more of them from http://mxr.mozilla.org/build/source/buildbot-configs/mozilla2/wince/mozilla-1.9.2/nightly/mozconfig

I will take a step back and try to modify my script to generate the "wince-arm" localized installers:
https://wiki.mozilla.org/User:Armenzg:l10n_scripts
when I do so I assume that adding dolske's patch will allow me to generate the localized CABs.

Comment 4

[Armen [:armenzg]]

Attachment: [WIP][buildbotcustom] add wince L10n nightly builder and deal with the special cases that it requires (v2)

Comment 5

[Armen [:armenzg]]

Attachment: [log] prerrortable.c(207) : error C2065: 'errno' : undeclared identifier

How does this look?
+        # special case for wince 
+        if platform is 'wince':
+            self.env.update({'MIDL':          '/d/msvs9/VC/ce/bin/x86_arm/midl.exe', \
+                             'CROSS_COMPILE': '1'})
+            self.extraConfigureArgs += ['--target=arm-wince', '--enable-win32-target=WINCE', \
+                                        '--with-wince-sdk=d:/sdks/wce500/standardsdk_500', \
+                                        '--with-windows-version=502']
+

The previous patch made me pass the "configure" step but I reach now this problem on the "make nsprpub"
> prerrortable.c(207) : error C2065: 'errno' : undeclared identifier

This is the full log:
http://tinderbox.mozilla.org/showlog.cgi?log=MozillaStaging/1259359890.1259360000.19106.gz&fulltext=1

make
 in dir e:\builds\moz2_slave\mozilla-1.9.2-wince-l10n-nightly\build/mozilla-1.9.2/nsprpub (timeout 1200 secs)

I will keep on poking next week.

Comment 6

[Justin Dolske [:Dolske]]

From IRC previously: You'll probably need some of the other flags from the nightly mozconfigs, because they affect packaging. EG, without --enable-splashscreen splash.bmp isn't added, --enable-faststart affects packaging for zips and CABs, etc.

You'll probably get a functional repack as-is, but it'll be missing some things we expect to be there.

Comment 7

[Armen [:armenzg]]

So far I know that I can't call nsprpub from *top_src_dir* as in the normal win32 Firefox scenario. It seems that it *only* works if I call it from within an objdir. The problem is that for L10n nightly repackages we don't use objdirs and we don't use a mozconfig file to specify it.

If I disable updates and I avoid running nsprpub it all succeeds and we upload these 2 files (I get the same results with or without the 2 arguments mentioned in comment 6):
firefox-3.6b5pre.id.langpack.xpi  02-Dec-2009 13:23  102K  
firefox-3.6b5pre.id.wince-arm.zip 02-Dec-2009 13:23   10M

Dolske what do I have to call to generate the localized cabs? Is it just calling "make installers-id"? Do I have to raise a MAKE_CAB flag?

Comment 8

[Justin Dolske [:Dolske]]

Yeah, that should do it. I have a note written for "make -C browser/locales installers-id ZIP_IN=firefox-blah-en-US.zip", but I think that's from before my patch in 523856 landed. 

Shouldn't need to specify anything about CABs, the repack will do both ZIP and CAB in the same pass on WinCE.

Comment 9

[Armen [:armenzg]]

We were wgettting an old en-US build and therefore the en-US repo was using an old hg revision (therefore it didn't have your changes).

Without nsprpub and disabling updates I run successfully all the way to the end.

2 things to fix:
* deal with nsprpub (look into adding an objdir to make it work)
* upload the cab as well

Comment 10

[Armen [:armenzg]]

(In reply to comment #9)
> * deal with nsprpub (look into adding an objdir to make it work)

Could anybody help me understand why for win32 I don't have trouble running "make -C nsprpub" from the top_src_dir but in the wince scenario I can't?
If anybody knows, could we fix it so I don't need to do much more?

Meanwhile I will have to look into adding the objdir and handle the change on *all* L10n repackaging steps.

Comment 11

[Armen [:armenzg]]

Passing a MOZ_OBJDIR environment variable is not working either since we don't use "make -f client.mk configure" but instead we use "sh -- ./configure list_of_options".

CCed few more people to help me think this out.

These are the options I can think of:
1) I move on to the release scenario and leave this problem for later on (since in releases we already use mozconfig files that have MOZ_OBJDIR - or at least is what I thought we do but I can't see it declared there: http://production-master.build.mozilla.org:8010/builders/win32_repack/builds/1708/steps/cat_mozconfig/logs/stdio).
2) add mozconfig usage as in the release repack factories and have an objdir so nsprpub can work
3) fix nsprpub for the wince cross-compilation scenario so we don't have to make any changes

*NOTE*: I believe we don't use an objdir after looking at this: http://mxr.mozilla.org/build/source/buildbotcustom/process/factory.py#2134. This might mean that we are not going to make any dramatic changes with the upcoming 3.6 release coming. This would also mean that we either make nsprpub or we will have to wait for WinCE L10n support for next quarter.

Comment 12

[[e-mail] (:bhearsum)]

(In reply to comment #10)
> (In reply to comment #9)
> > * deal with nsprpub (look into adding an objdir to make it work)
> 
> Could anybody help me understand why for win32 I don't have trouble running
> "make -C nsprpub" from the top_src_dir but in the wince scenario I can't?
> If anybody knows, could we fix it so I don't need to do much more?
> 
> Meanwhile I will have to look into adding the objdir and handle the change on
> *all* L10n repackaging steps.

Can you please add some more details:
* Full logs, including environment variables
* Mozconfig, if used
* Links or a paste of the exact output

Comment 13

[Armen [:armenzg]]

Other option would be not to have updates for WinCE L10n or be able to make modules/libmar without nsprpub (since I believe that is the dependency)

Comment 14

[Armen [:armenzg]]

I am going to leave staging-master03 running so you can access to all logs (since I don't see them on MozillaStaging tinderbox page).

I have not used any mozconfigs at all for today's runs.

Here is the configure step:
sh -- ./configure --enable-application=browser --with-l10n-base=../releases/l10n-mozilla-1.9.2 --enable-update-packaging --target=arm-wince --enable-win32-target=WINCE --with-wince-sdk=d:/sdks/wce500/standardsdk_500 --with-windows-version=502 --enable-splashscreen --enable-faststart

Successful run without nsprpub and no updates:
http://staging-master.build.mozilla.org:8012/builders/Firefox%20mozilla-1.9.2%20wince%20l10n/builds/51

Using no nsprpub but enabled updates (modules/libmar fails):
http://staging-master.build.mozilla.org:8012/builders/Firefox%20mozilla-1.9.2%20wince%20l10n/builds/53

Using MOZ_OBJDIR=@TOPSRCDIR@/objdir as a variable (nsprpub failed - no objdir on slave):
http://staging-master.build.mozilla.org:8012/builders/Firefox%20mozilla-1.9.2%20wince%20l10n/builds/54

Using MOZ_OBJDIR=objdir as a variable (nsprpub failed - no objdir on slave):
http://staging-master.build.mozilla.org:8012/builders/Firefox%20mozilla-1.9.2%20wince%20l10n/builds/55

If any curious releng wants to poke at this I will leave slave03 connected and the builds happen in /e/builds/slave/mozilla-1.9.2-wince-l10n-nightly/build/mozilla-1.9.2. To trigger a build I do it by passing en_revision:tip, l10n_revision:tip and locale:id.

Comment 15

[Armen [:armenzg]]

Comment on attachment 414876 [details] [diff] [review]
[log] prerrortable.c(207) : error C2065: 'errno' : undeclared identifier

bhearsum this log is still valid.

Comment 16

[Armen [:armenzg]]

Attachment: [local patch] this is what I am running

Comment 17

[[e-mail] (:bhearsum)]

I just did a run that was: in the srcdir with no MOZ_OBJDIR set, and got this error:
make[3]: Entering directory `/e/builds/slave/mozilla-1.9.2-wince-l10n-nightly/build/mozilla-1.9.2/nsprpub/pr/src/misc'
/e/builds/slave/mozilla-1.9.2-wince-l10n-nightly/build/mozilla-1.9.2/dist/sdk/bin/arm-wince-gcc -Foprerrortable.obj -c      -O2   -UDEBUG  -DMOZILLA_CLIENT=1 -DNDEBUG=1 -DXP_PC=1 -DWIN32=1 -DWINCE=1 -D_PR_GLOBAL_THREADS_ONLY=1  -DFORCE_PR_LOG -D_NSPR_BUILD_ -I/e/builds/slave/mozilla-1.9.2-wince-l10n-nightly/build/mozilla-1.9.2/dist/include/nspr -I../../../pr/include -I../../../pr/include/private  prerrortable.c
Microsoft (R) C/C++ Optimizing Compiler Version 15.00.20720 for ARM
Copyright (C) Microsoft Corporation.  All rights reserved.

prerrortable.c
prerrortable.c(151) : warning C4047: 'return' : 'const char *' differs in levels of indirection from 'int'
prerrortable.c(207) : error C2065: 'errno' : undeclared identifier
make[3]: Leaving directory `/e/builds/slave/mozilla-1.9.2-wince-l10n-nightly/build/mozilla-1.9.2/nsprpub/pr/src/misc'
make[2]: Leaving directory `/e/builds/slave/mozilla-1.9.2-wince-l10n-nightly/build/mozilla-1.9.2/nsprpub/pr/src'
make[1]: Leaving directory `/e/builds/slave/mozilla-1.9.2-wince-l10n-nightly/build/mozilla-1.9.2/nsprpub/pr'
make[3]: *** [prerrortable.obj] Error 2
make[2]: *** [export] Error 2
make[1]: *** [export] Error 2
make: *** [export] Error 2


Armen, I think you said you got this yesterday, too?
Dolske, do you have any idea how to fix this?

Comment 18

[[e-mail] (:bhearsum)]

So, I just realized that we're probably spending time unnecessarily - the only thing we're compiling for l10n builds is the mar tools (plus their dependencies). We're hitting problems because we're targeting them at Windows CE. Another option would be to stop targetting windows ce when building the tools for l10n builds - we don't ship them anyways.

I tried this and hit other problems:
http://staging-master.build.mozilla.org:8012/builders/Firefox%20mozilla-1.9.2%20wince%20l10n/builds/60/steps/configure/logs/stdio
http://staging-master.build.mozilla.org:8012/builders/Firefox%20mozilla-1.9.2%20wince%20l10n/builds/61/steps/configure/logs/stdio

Seems like every route tried leads to problems rooted in LIB/INCLUDE/SDKDIR

Comment 19

[Armen [:armenzg]]

Attachment: [env] these are the environment variables on the slave when we open "MSYS Tinderbox"

I have not managed to create nsprpub with an objdir (even though at some point I got it to work). I might have had the right environment set at that point.

I will be listing the different environment variables scenarios that I have tried.

These are the variables by default in a slave when I open msys (see attachment for full environment) (I know that msvs8 is being used instead of msvs9):
INCLUDE=d:\sdks\v7.0\\include;d:\sdks\v7.0\\include\atl;d:\msvs8\VC\ATLMFC\INCLUDE;d:\msvs8\VC\INCLUDE;d:\msvs8\VC\PlatformSDK\include;
LIB=d:\sdks\v7.0\\lib;d:\msvs8\VC\ATLMFC\LIB;d:\msvs8\VC\LIB;d:\msvs8\VC\PlatformSDK\lib;d:\msvs8\SDK\v2.0\lib;;D:\mozilla-build\atlthunk_compat
SDKDIR=d:\sdks\v7.0\
PATH=/local/bin:/d/mozilla-build/wget:/d/mozilla-build/7zip:/d/mozilla-build/blat261/full:/d/mozilla-build/python25:/d/mozilla-build/svn-win32-1.6.3/bin:/d/mozilla-build/upx203w:/d/mozilla-build/emacs-22.3/bin:/d/mozilla-build/info-zip:/d/mozilla-build/nsis-2.22:/d/mozilla-build/nsis-2.33u:/d/mozilla-build/hg:/d/mozilla-build/python25/Scripts:/d/mozilla-build/kdiff3:/d/mozilla-build/vim/vim72:.:/usr/local/bin:/mingw/bin:/bin:/d/sdks/v7.0/bin:/d/msvs8/Common7/IDE:/d/msvs8/VC/BIN:/d/msvs8/Common7/Tools:/d/msvs8/Common7/Tools/bin:/d/msvs8/VC/PlatformSDK/bin:/d/msvs8/SDK/v2.0/bin:/c/WINDOWS/Microsoft.NET/Framework/v2.0.50727:/d/msvs8/VC/VCPackages:/c/WINDOWS/system32:/c/WINDOWS:/c/WINDOWS/System32/Wbem:/d/mozilla-build/python25:/d/mercurial:/c/Program Files/Microsoft SQL Server/90/Tools/binn/:/d/sdks/tegra042/tools:/d/sdks/tegra042/platformlibs/bin/winxp/x86/release:/d/sdks/tegra042/3rdparty/bin/winxp/x86/release:/d/mozilla-build/moztools/bin

These are the ones I tried by changing msvs8 to msvs9:
export INCLUDE="d:\sdks\v7.0\\include;d:\sdks\v7.0\\include\atl;d:\msvs9\VC\ATLMFC\INCLUDE;d:\msvs9\VC\INCLUDE;d:\msvs9\VC\PlatformSDK\include;"
export LIB="d:\sdks\v7.0\\lib;d:\msvs9\VC\ATLMFC\LIB;d:\msvs9\VC\LIB;d:\msvs9\VC\PlatformSDK\lib;d:\msvs9\SDK\v2.0\lib;;D:\mozilla-build\atlthunk_compat"
export PATH="/local/bin:/d/mozilla-build/wget:/d/mozilla-build/7zip:/d/mozilla-build/blat261/full:/d/mozilla-build/python25:/d/mozilla-build/svn-win32-1.6.3/bin:/d/mozilla-build/upx203w:/d/mozilla-build/emacs-22.3/bin:/d/mozilla-build/info-zip:/d/mozilla-build/nsis-2.22:/d/mozilla-build/nsis-2.33u:/d/mozilla-build/hg:/d/mozilla-build/python25/Scripts:/d/mozilla-build/kdiff3:/d/mozilla-build/vim/vim72:.:/usr/local/bin:/mingw/bin:/bin:/d/sdks/v7.0/bin:/d/msvs9/Common7/IDE:/d/msvs9/VC/BIN:/d/msvs9/Common7/Tools:/d/msvs9/Common7/Tools/bin:/d/msvs9/VC/PlatformSDK/bin:/d/msvs9/SDK/v2.0/bin:/c/WINDOWS/Microsoft.NET/Framework/v2.0.50727:/d/msvs9/VC/VCPackages:/c/WINDOWS/system32:/c/WINDOWS:/c/WINDOWS/System32/Wbem:/d/mozilla-build/python25:/d/mercurial:/c/Program Files/Microsoft SQL Server/90/Tools/binn/:/d/sdks/tegra042/tools:/d/sdks/tegra042/platformlibs/bin/winxp/x86/release:/d/sdks/tegra042/3rdparty/bin/winxp/x86/release:/d/mozilla-build/moztools/bin"

These are the ones that dolske passed to me:
INCLUDE= C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\ATLMFC\INCLUDE;C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\INCLUDE;C:\Program Files\Microsoft SDKs\Windows\v7.0\include;
LIB=C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\ATLMFC\LIB;C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\LIB;C:\Program Files\Microsoft SDKs\Windows\v7.0\lib;
SDKDIR = C:\Program Files\Microsoft SDKs\Windows\v7.0\

As per run by buildbot (These should be *the same* as used by a WinCE build):
INCLUDE=d:\msvs9\VC\ATLMFC\INCLUDE;d:\msvs9\VC\INCLUDE;C:\Program Files\Microsoft SDKs\Windows\v6.0A\include;
LIB=d:\msvs9\VC\ATLMFC\LIB;d:\msvs9\VC\LIB;C:\Program Files\Microsoft SDKs\Windows\v6.0A\lib;
SDKDIR=D:\sdks\v6.0\
PATH=D:\mozilla-build\msys\local\bin;d:\mozilla-build\wget;d:\mozilla-build\7zip;d:\mozilla-build\blat261\full;d:\mozilla-build\python25;d:\mozilla-build\svn-win32-1.4.2\bin;d:\mozilla-build\upx203w;d:\mozilla-build\xemacs\XEmacs-21.4.19\i586-pc-win32;d:\mozilla-build\info-zip;d:\mozilla-build\nsis-2.22;d:\mozilla-build\nsis-2.33u;.;D:\mozilla-build\msys\local\bin;D:\mozilla-build\msys\mingw\bin;D:\mozilla-build\msys\bin;d:\msvs9\Common7\IDE;d:\msvs9\VC\BIN;d:\msvs9\Common7\Tools;c:\WINDOWS\Microsoft.NET\Framework\v3.5;c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727;d:\msvs9\VC\VCPackages;c:\Program Files\Microsoft SDKs\Windows\v6.0A\bin;c:\WINDOWS\system32;c:\WINDOWS;c:\WINDOWS\System32\Wbem;d:\mozilla-build\python25;d:\mozilla-build\hg;c:\Program Files\Microsoft SQL Server\90\Tools\binn\;d:\sdks\tegra042\tools;d:\sdks\tegra042\platformlibs\bin\winxp\x86\release;d:\sdks\tegra042\3rdparty\bin\winxp\x86\release;d:\mozilla-build\moztools\bin

Comment 20

[Armen [:armenzg]]

Another thing to note that this is actually turning to be the scenario that I feared the most and I have roughly spent 2 days last week and almost 3 days this week, so far. Amount of remaining time depends on how much help we get solving the nsprpub problem.

Please be aware that this is taking away from other bugs that have been planned as Q4 goals and affect the release of Fennec linux-arm, so can someone confirm this is still the right priority?

Unless we fix the nsprpub problem (hoping that's the last problem) we can't move any forward.

Comment 21

[Armen [:armenzg]]

I am handing off the VM to dolske where I have left a script called generate_wince)l10n.sh under /d/bacon based on https://wiki.mozilla.org/User:Armenzg:l10n_scripts. This script shows the way we generate repackages for L10n and will give him a base to start from.

dolske in comment 19 you can find the environment variables that you will need to fiddle with if not more.

Comment 22

[Justin Dolske [:Dolske]]

I think what's happening here is the result of not using an objdir. If I take the configuration that works on my desktop, but remove MOZ_OBJDIR, I can recreate the failure. How big of a deal would it be to change the l10n scripts to start using an objdir? They ought to be doing that anyway. [Ditto for using mozconfig, otherwise we risk having the l10n repack environment get out of sync with en-US builds.]

Specifically, it looks like the NSPR bit fails because  arm-wince-gcc isn't forcing the inclusion of mozce_shunt.h, which happens because HAVE_SHUNT isn't defined, which happens because build/wince/shunt/tools has both a Makefile.in and a Makefile... When you've got an objdir, the Makefile generated from Makefile.in ends up in the objdir, but for a srcdir build the generated Makefile clobbers the Makefile that's already there.

As a quick fix, I think we can just have libmar avoid pulling in NSPR on wince (and just hardcode the types it's using). I'll do some more testing.

Comment 23

[Armen [:armenzg]]

(In reply to comment #22)
> I think what's happening here is the result of not using an objdir. If I take
> the configuration that works on my desktop, but remove MOZ_OBJDIR, I can
> recreate the failure. How big of a deal would it be to change the l10n scripts
> to start using an objdir? They ought to be doing that anyway. [Ditto for using
> mozconfig, otherwise we risk having the l10n repack environment get out of sync
> with en-US builds.]
> 
We want to use an objdir but we want to avoid doing the change this late in the release of FF3.6. I am afraid to hit unexpected problems, the change would affect many different steps, and testing the changes would not be easy.
> 
> As a quick fix, I think we can just have libmar avoid pulling in NSPR on wince
> (and just hardcode the types it's using). I'll do some more testing.
I hope this goes well.

Comment 24

[Armen [:armenzg]]

I have triggered clobbered builds for L10n in both branches and the patches that have landed in bug 533665 have not affected the repackaging process.

I will look in the morning for the *natural* run of repackages while I retest my patches for WinCE on staging. Hopefully by Friday I will be satisfied with testing results.

Comment 25

[Armen [:armenzg]]

Attachment: [1.9.2] add the platform parameter to generate l10n nightly snippets

I have passed the "make installers" step and we have to fix the snippet generation for L10n nightlies to work for wince.

I have tested this patch for the other platforms and it works. Nevertheless, I would like it to land on mozilla-central before landing on 1.9.2 so I can be completely sure that it is safe.

Comment 26

[Armen [:armenzg]]

Attachment: [log] making libmar fails

I can't currently pass the make libmar step.

dolske could you have a look at this log?

e:\builds\slave\mozilla-1.9.2-wince-l10n-nightly\build\mozilla-1.9.2\modules\libmar\src\mar.h(44) : fatal error C1083: Cannot open include file: 'prtypes.h': No such file or directory

NOTE: I am not building nsprpub
NOTE2: I reached further than this step since I was not using at that point fresh checkouts which I am using right now.

Comment 27

[Chris Cooper [:coop] (he/him)]

(In reply to comment #26)
> e:\builds\slave\mozilla-1.9.2-wince-l10n-nightly\build\mozilla-1.9.2\modules\libmar\src\mar.h(44)
> : fatal error C1083: Cannot open include file: 'prtypes.h': No such file or
> directory
> 
> NOTE: I am not building nsprpub

prtypes.h lives under nsprpub/pr/include/.

Comment 28

[Armen [:armenzg]]

As dolske mentioned in IRC, I triggered the builds on mozilla-central and it seems that it worked.

I thought the patch had landed on 1.9.2 as well (http://hg.mozilla.org/releases/mozilla-1.9.2/rev/997d1e003a51)

Comment 29

[Armen [:armenzg]]

It seems that the slaves have behaved and it went through for 1.9.2 as well.

http://staging-stage.build.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-1.9.2-l10n/firefox-3.6b6pre.id.wince-arm.zip

The snippet generation failed though.

Comment 30

[Justin Dolske [:Dolske]]

Yeah, the patch is on 1.9.2. Hopefully whatever failed was just a glitch... The line number in the error indicates that the local tree has the patch, but the error itself indicates that WINCE wasn't #defined. Not sure how that would happen. If it happens again, let's see if we can reproduce it on bacon-vm and I can bang away at fixing it.

Also, I compared the ID-localized zip to the en-US version, contents looks as expected. Getting close! \o/

Comment 31

[Armen [:armenzg]]

Comment on attachment 417356 [details] [diff] [review]
[1.9.2] add the platform parameter to generate l10n nightly snippets

I would like to see what Nick says with regards using MOZ_PKG_PLATFORM for the l10n nightly snippets.

I would like to deploy this in mozilla-central and have it for few days before landing on 1.9.2

Comment 32

[Armen [:armenzg]]

Last night with dolske I got few builds in both branches that worked (when I spent all day with problems). Today is again the same old story.
I don't know know what is going on with these slaves.
slave03 does not build libmar with the problems I mentioned in comment 26
slave21 does not unpack because the _ABS_DIR is e:\ instead of /e/. why do we hit this? I really don't know.

I am really frustrated because these slaves are just not behaving (I have restarted them and cleaned manually). I will try to switch one of the slaves. Being build on duty is not helping.

Comment 33

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

Comment on attachment 417356 [details] [diff] [review]
[1.9.2] add the platform parameter to generate l10n nightly snippets

This looks plausible to me but I don't know this code specifically.

Comment 34

[Armen [:armenzg]]

(In reply to comment #30)
> Yeah, the patch is on 1.9.2. Hopefully whatever failed was just a glitch... The
> line number in the error indicates that the local tree has the patch, but the
> error itself indicates that WINCE wasn't #defined. Not sure how that would
> happen. If it happens again, let's see if we can reproduce it on bacon-vm and I
> can bang away at fixing it.
> 
> Also, I compared the ID-localized zip to the en-US version, contents looks as
> expected. Getting close! \o/
>
Tomorrow I will reduce the amount of time I spend doing buildduty and focus on reproducing this manually on bacon-vm in the morning because I added a different staging slave and I keep on hitting this.
I have also tried using the slaves to do win32 l10n repacks and they would be unstable (fail at unpack step and not passing configure) but they managed to give me a couple of successful runs which means that it throws away my theory that the slaves are being silly.

By the time this is taking and how much longer the release is taking I could have had time to have added the objdir and have tested it!!!! *sigh*

Comment 35

[Chris Cooper [:coop] (he/him)]

Comment on attachment 417356 [details] [diff] [review]
[1.9.2] add the platform parameter to generate l10n nightly snippets

Landed on m-c:
http://hg.mozilla.org/mozilla-central/rev/d64839cc1cc4

Comment 36

[Armen [:armenzg]]

dolske it wasn't glitches what we were having on the staging slaves and what we were seeing the log was correct. I have been playing with bacon-vm and I have not been able to make it work. WINCE is not defined for the make -C modules/libmar step!

This is what I did to cheat:
HOST_CFLAGS     = -QRarch6 -QRfpe- -TC -nologo -Fd$(HOST_PDBFILE) -DXP_WIN32 -D
P_WIN -DWINCE -D_WIN32 -DNO_X11 -D_X86_
#HOST_CFLAGS    = -QRarch6 -QRfpe- -TC -nologo -Fd$(HOST_PDBFILE) -DXP_WIN32 -D
P_WIN -DWIN32 -D_WIN32 -DNO_X11 -D_X86_
since I saw this on the log
cl -Fohost_mar_create.obj -c -TC -nologo -Fdhost_mar_create.pdb -DXP_WIN32 -DXP_WIN -DWIN32 -D_WIN32 -DNO_X11 -D_X86_ -O2 -DMDCPUCFG=\"md/_winnt.cfg\"  -I. -I. -I../../../dist/include -I../../../dist/include/nsprpub  -Ie:/builds/slave/mozilla-1.9.2-wince-l10n-nightly/build/mozilla-1.9.2/dist/include/nspr -Ie:/builds/slave/mozilla-1.9.2-wince-l10n-nightly/build/mozilla-1.9.2/dist/include/nss      -Ie:/builds/slave/mozilla-1.9.2-wince-l10n-nightly/build/mozilla-1.9.2/dist/include/nspr /e/builds/slave/mozilla-1.9.2-wince-l10n-nightly/build/mozilla-1.9.2/modules/libmar/src/mar_create.c
mar_create.c
All I can see being passed are define variables (I think it is called like that) for win32 (-DWIN32) instead of WinCE

Let me talk out loud to know what we are trying to do:
* we are trying to generate repackages for WinCE L10n
* since we couldn't get the right packaging naming (after playing with MOZ_PKG_PLATFORM) I decided adding extra configure args and extra environment variables until we got it right
* we did those change but then we couldn't get "nsprpub" to be made because we are cross-compiling (or creating the "host library" as ted mentioned on IRC)
* we cheated (just for now) by avoiding having to create nsprpub to generate libmar
* unfortunately I was not being able to generate libmar either

It is obvious that I don't know what I am doing and I need help in here.
If someone can help me fix the naming problem we could have things fixed easily (I think)

Comment 37

[Armen [:armenzg]]

Attachment: magic script to do WinCE L10n repackages

This is just for others to know what is the exact execution path I am following.

Another note, we can generate l10n repackages without libmar but we can't generate updates without it.

Comment 38

[Armen [:armenzg]]

(In reply to comment #36)
> Let me talk out loud to know what we are trying to do:
> * we are trying to generate repackages for WinCE L10n
> * since we couldn't get the right packaging naming (after playing with
> MOZ_PKG_PLATFORM) I decided adding extra configure args and extra environment
> variables until we got it right
I believe I have been able to fix the packaging naming problem and will probably be able to build nsprpub and modules/libmar since if is exactly the same logic as with normal win32 l10n repacks. If I get this working I am going to feel very embarrassed.

Comment 39

[Armen [:armenzg]]

Attachment: retrieve windows installer only if the variable is set to 1

Are we going to have a .installer.exe file for WinCE? I don't see on ftp.

I am now trying to fix the installers-% target since I don't have an installer to work with. I get a "target does not exist" for installers-% unless I remove "repackage-zip-%" from
installers-%: clobber-% langpack-% repackage-win32-installer-% repackage-zip-% (http://mxr.mozilla.org/mozilla-central/source/browser/locales/Makefile.in#261)
Even though I thought that repackage-installer-% should have given me problems.

I will continue digging into it.

I don't need help as desperately as previously in the afternoon. I feel that control is back in my hands (or at least the illusion of it).

Comment 40

[Justin Dolske [:Dolske]]

(In reply to comment #39)

> Are we going to have a .installer.exe file for WinCE? I don't see on ftp.

No. WinCE builds are only available as .zip and .cab.

Well, at least for the near future... Windows Mobile is going to be implementing a customer installer, because .CAB files are super sucky slow. It's not too bad on WinCE, but we might look at that work in the future. But don't worry about it  now.

Comment 41

[Armen [:armenzg]]

Attachment: [trunk] DISABLE_WINDOWS_INSTALLER to use with WinCE

For make-installers to work with WinCE we have to avoid having to do anything with the installers (this patch still gives the opportunity to deal with this at a later stage).

Comment 42

[Armen [:armenzg]]

Attachment: [script] this generates WinCE l10n repackages

I cheat by using -e with make installers to override the make variables with the environment variables that I export at the beginning of the script.

Please weigh in since I want to work on the buildbot changes to make it work by setting environment variables for WinCE l10n repackages and by using the option -e when doing "make installers".

If it is not clear, we are not following the approach we were heading for the last week or so in which we were trying to use configure arguments and special environment variables to setup the WinCE SDK and others.

Comment 43

[Axel Hecht [:Pike]]

Comment on attachment 418413 [details] [diff] [review]
[trunk] DISABLE_WINDOWS_INSTALLER to use with WinCE

No double if's for the same thing, please.

The entry point to disable the installer should be the same as for the en-US binary build, i.e., MOZ_PKG_FORMAT=CAB.

RETRIEVE_WINDOWS_INSTALLER should only be set if that's false, as should be the UNINSTALLER_PACKAGE_HOOK in browser/locales/Makefile.in.

Comment 44

[Armen [:armenzg]]

I am hitting this:
$ d\:\\msvs8/SmartDevices/SDK/SDKTools/cabwiz.exe Namoroka.inf
Windows CE CAB Wizard
Error: Section [Shortcuts] shortcut "Namoroka.lnk" - there is no matching target
 file "firefox.exe" for the current CPU type

Any ideas on how do I fix this?

Comment 45

[Armen [:armenzg]]

Dolske helped with the previous approach in which libmar was not being generated but I am hitting the same cab generation issues.

One way (configuring for win32 and using -e for make) or the other way (configuring for wince) I end up with the same problem that I can't generate the localized cab.

I am going to try if the script will run completely with an objdir.

Comment 46

[Justin Dolske [:Dolske]]

Attachment: Script to repack for WinCE

Running this on bacon-vm from an empty directory successfully creates a repack for me. Armen says he's switching to use a mozconfig/objdir, so that's what this does.

Comment 47

[Armen [:armenzg]]

It ended up that all we were missing was a new step "make -C build" so nsprpub could succeed. Patches to come soon.

http://staging-stage.build.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central-l10n/?C=M;O=D
[   ] firefox-3.7a1pre.id.wince-arm.complete.mar 24-Dec-2009 07:03  9.1M  
[   ] firefox-3.7a1pre.id.wince-arm.zip          24-Dec-2009 07:03   10M  
[   ] firefox-3.7a1pre.id.langpack.xpi           24-Dec-2009 07:03  101K  

complete
http://staging-stage.build.mozilla.org/pub/mozilla.org/firefox/nightly/2009/12/2009-12-21-00-mozilla-central-l10n/firefox-3.7a1pre.id.wince-arm.complete.mar
sha1
3d0b3811f87bc701cfff0def7f37f098a2d33e46
9553096
20091221003511
3.7a1pre
3.7a1pre

Comment 48

[Armen [:armenzg]]

Attachment: [configs] add wince entry to L10N_SLAVES and add l10n_platforms list to each branch

Comment 49

[Armen [:armenzg]]

Attachment: [buildbotcustom] add wince L10n nightly and dependent builders

Comment 50

[Armen [:armenzg]]

Attachment: [buildbotcustom] add wince L10n nightly and dependent builders

I attached the wrong patch.

Comment 51

[Armen [:armenzg]]

Comment on attachment 417356 [details] [diff] [review]
[1.9.2] add the platform parameter to generate l10n nightly snippets

where is approval 1.9.2?
requesting 1.9.2.1 instead.

We need this to have localized WinCE nightly updates.

I tested a nightly build on mozilla-central and I was able to update to the latest nightly and no one reported any problems with the updates.

Comment 52

[Justin Dolske [:Dolske]]

The approval192 flag is disabled, ping beltzner directly to get it approved to land.

Comment 53

[Justin Dolske [:Dolske]]

Armen: The files from comment 24 are gone now; could you spin up some builds again, so I can check to see if they're good (eg, no missing bits ala comment 6).

Comment 54

[Armen [:armenzg]]

I will take care of it in the morning.

Comment 55

[Armen [:armenzg]]

http://staging-stage.build.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-1.9.2-l10n/
http://staging-stage.build.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central-l10n/

*sigh* I had to manually upload the cab files. I will have to look into it.

I have made the cronjobs less agressive so we can keep the files a little longer.

I gave a stab to Wince L10n for releases and it should not be that difficult now that we have things a little more figured out.

Comment 56

[Armen [:armenzg]]

Attachment: [buildbotcustom] add wince L10n nightly and dependent builders

Only use mozconfig and objdir for wince since it was failing for Linux and Mac (I expected them to work since Windows worked fine). We can add the use of mozconfig and objdir for the other platforms in another occasion.

Comment 57

[Armen [:armenzg]]

Attachment: [1.9.2] upload cab files as well

Comment 58

[Justin Dolske [:Dolske]]

I took a look at the zip/cab/mar files from comment 55, comparing their contents to an en-US nightly. Looks good.

Comment 59

[Chris Cooper [:coop] (he/him)]

Comment on attachment 419139 [details] [diff] [review]
[configs] add wince entry to L10N_SLAVES and add l10n_platforms list to each branch

Is there a reason you didn't add l10n_platforms to the BRANCH_LEVEL_VARS and then append 'wince' where necessary?

Comment 60

[Armen [:armenzg]]

(In reply to comment #59)
> (From update of attachment 419139 [details] [diff] [review])
> Is there a reason you didn't add l10n_platforms to the BRANCH_LEVEL_VARS and
> then append 'wince' where necessary?
>
Exactly, for instance we don't have wince for 191.

Comment 61

[Armen [:armenzg]]

Comment on attachment 419471 [details] [diff] [review]
[1.9.2] upload cab files as well

I need landing for mozilla-central first.

Comment 62

[Chris Cooper [:coop] (he/him)]

Comment on attachment 419456 [details] [diff] [review]
[buildbotcustom] add wince L10n nightly and dependent builders

>+            # XXX rethink where this information should belong to
>+            locales = None 
>+            if platform is 'wince':
>+                locales = {'id':[]}

Where else could it go? Comments like this scare me because they imply that we haven't thought about it. Shouldn't we think about it before implementing it?

>-            if platform in ('linux','win32','macosx'):
>+            if platform in config['l10n_platforms']:
>+                # XXX hack warning
>+                # Linux and mac are not working with mozconfig at this point and this
>+                # will disable it for now

Let's avoid the XXX comments. If this is required under the current setup to make things work, then comment to that fact and file a follow-up bug to fix the system.

>+        self.objdir = ''
>+        if 'MOZ_OBJDIR' in self.env:
>+            self.objdir = self.env['MOZ_OBJDIR']
>+
>         # Mozilla subdir and objdir
>         if mozillaDir:
>             self.mozillaDir = '/%s' % mozillaDir
>             self.mozillaSrcDir = '%s/%s' % (self.origSrcDir, mozillaDir)
>         else:
>             self.mozillaDir = ''
>-            self.mozillaSrcDir = self.origSrcDir
>+            self.mozillaSrcDir = '%s/%s' % (self.origSrcDir, self.objdir)

You'll end up with a trailing slash here if self.objdir is empty. You should probably check for that to prevent unpredictable path beahior later.

>+        if self.mozconfig and self.mozconfig != '':
>+            # XXX These steps are exactly the same as what the ReleaseRepackFactory calls
>+            #     They should be moved to the parent BaseRepackFactory

Um, so what are we waiting for? Let's do that now.

Armen: if we switch to a model where both libmar and bsdiff get built automatically when we specify --enable-update-packaging (as indeed we are doing for bug 511967), does that change your implementation decisions here at all? It currently doesn't work for the CROSS_COMPILE cases like WinCE, but that's something we can fix.

Comment 63

[Armen [:armenzg]]

(In reply to comment #62)
> (From update of attachment 419456 [details] [diff] [review])
> >+            # XXX rethink where this information should belong to
> >+            locales = None 
> >+            if platform is 'wince':
> >+                locales = {'id':[]}
> 
> Where else could it go? Comments like this scare me because they imply that we
> haven't thought about it. Shouldn't we think about it before implementing it?
> 
I had thought of this (the comment is from before I thought about it) but was not sure what would be the best decision knowing that we are changing things for releases as well. This will be fixed in bug 537280.

> >-            if platform in ('linux','win32','macosx'):
> >+            if platform in config['l10n_platforms']:
> >+                # XXX hack warning
> >+                # Linux and mac are not working with mozconfig at this point and this
> >+                # will disable it for now
> 
> Let's avoid the XXX comments. If this is required under the current setup to
> make things work, then comment to that fact and file a follow-up bug to fix the
> system.
> 
We will deal with it in bug 518359.

> 
> Armen: if we switch to a model where both libmar and bsdiff get built
> automatically when we specify --enable-update-packaging (as indeed we are doing
> for bug 511967), does that change your implementation decisions here at all? It
> currently doesn't work for the CROSS_COMPILE cases like WinCE, but that's
> something we can fix.
The day that we do the switch we will have to remove making libmar twice (it currently gets added if updates are enabled). Not sure what will happen with WinCE. 


I will deal with the other two comments on the following patch.

Comment 64

[Armen [:armenzg]]

Attachment: [buildbotcustom] add wince L10n nightly and dependent builders (v2)

Addressed comments and retested the objdir change.

Comment 65

[Axel Hecht [:Pike]]

The initial comment that we'd only want indonesian is mislead.

We want all locales for WinCE.

Comment 66

[Armen [:armenzg]]

Attachment: [buildbotcustom] add wince L10n nightly and dependent builders (v2)

Removed the restriction to 'id' locale for WinCE. This means that we will build for all locales for all platforms.

Coop to ease the review here is a delta between the patch you reviewed and the current one http://pastebin.mozilla.org/693979 (I remove the 'id' restriction and deal with mozobjdir variable; the rest of the changes are just comment modifications)

Comment 67

[Chris Cooper [:coop] (he/him)]

Comment on attachment 419471 [details] [diff] [review]
[1.9.2] upload cab files as well

http://hg.mozilla.org/mozilla-central/rev/dd7687a6cbe1

Comment 68

[Armen [:armenzg]]

Comment on attachment 419139 [details] [diff] [review]
[configs] add wince entry to L10N_SLAVES and add l10n_platforms list to each branch

http://hg.mozilla.org/build/buildbot-configs/rev/596f22b540b4

Comment 69

[Armen [:armenzg]]

Comment on attachment 419586 [details] [diff] [review]
[buildbotcustom] add wince L10n nightly and dependent builders (v2) 

http://hg.mozilla.org/build/buildbotcustom/rev/9125d3fa086d

Comment 70

[Armen [:armenzg]]

Attachment: [trunk] bustage fix to upload installers

It shouldn't have been "ifeq" but "ifneq".

Comment 71

[Armen [:armenzg]]

Attachment: [1.9.2] upload cab files as well

This patch is for 1.9.2 and includes the bustage fix of attachment 419922 [details].
I will request for approval-1.9.2 when the previous patch lands and I prove that it does not add any problems.

Comment 72

[[e-mail] (:bhearsum)]

(In reply to comment #69)
> (From update of attachment 419586 [details] [diff] [review])
> http://hg.mozilla.org/build/buildbotcustom/rev/9125d3fa086d

This patch busted at least staging:
[cltbld@staging-master moz2-master]$ make checkconfig
PYTHONPATH=/tools/buildbotcustom:/tools/buildbot/lib/python2.5/site-packages:/tools/twisted/lib/python2.5/site-packages:/tools/twisted-corelib/python2.5/site-packages/:/tools/zope-interface/lib/python2.5/site-packages/ buildbot checkconfig
Traceback (most recent call last):
  File "/tools/buildbot/lib/python2.5/site-packages/buildbot/scripts/runner.py", line 924, in doCheckConfig
    ConfigLoader(configFile)
  File "/tools/buildbot/lib/python2.5/site-packages/buildbot/scripts/checkconfig.py", line 31, in __init__
    self.loadConfig(configFile)
  File "/tools/buildbot/lib/python2.5/site-packages/buildbot/master.py", line 529, in loadConfig
    exec f in localDict
  File "master.cfg", line 65, in <module>
    import mobile_master
  File "/tmp/tmphrQyJa/mobile_master.py", line 491, in <module>
  File "/tools/buildbotcustom/buildbotcustom/process/factory.py", line 5462, in __init__
    **kwargs)
  File "/tools/buildbotcustom/buildbotcustom/process/factory.py", line 1457, in __init__
    self.configure()
  File "/tools/buildbotcustom/buildbotcustom/process/factory.py", line 1492, in configure
    if self.mozconfig and self.platform is 'wince':
AttributeError: MobileDesktopNightlyRepackFactory instance has no attribute 'mozconfig'
make: *** [checkconfig] Error

Comment 73

[Chris Cooper [:coop] (he/him)]

Comment on attachment 419925 [details] [diff] [review]
[trunk] bustage fix to upload installers

http://hg.mozilla.org/mozilla-central/rev/6778246cb4f7

Comment 74

[Armen [:armenzg]]

Attachment: [buildbotcustom] if no mozconfig specified set it to None

Comment 75

[Armen [:armenzg]]

Attachment: [buildbotcustom] deals with the case were no mozconfig is passed

Comment 76

[Armen [:armenzg]]

Comment on attachment 419966 [details] [diff] [review]
[buildbotcustom] deals with the case were no mozconfig is passed

http://hg.mozilla.org/build/buildbotcustom/rev/1c6bc61ed2be

Comment 77

[Justin Dolske [:Dolske]]

(In reply to comment #65)
> The initial comment that we'd only want indonesian is mislead.
> 
> We want all locales for WinCE.

To be clear, Indonesian is the one locale our partner needs. Probably just as well to build them all for consistency, but if there were issues with that (Eg repack time), having just .id would be acceptable from that PoV.

Comment 78

[Armen [:armenzg]]

Attachment: [buildbotcustom] do not overwrite self.mozconfig set up by initialization in subclass of BaseRepackFactory

This fixes the release scenario for all platforms and wince nightly (since it is where we use mozconfig files).
This has been tested for all the mentioned scenarios and that master2.cfg's checkconfig passes.

Comment 79

[Chris Cooper [:coop] (he/him)]

Comment on attachment 420091 [details] [diff] [review]
[buildbotcustom] do not overwrite self.mozconfig set up by initialization in subclass of BaseRepackFactory

>-        self.mozconfig = mozconfig
>+        if not hasattr(self, 'mozconfig'):
>+            self.mozconfig = None 
>         if mozconfig and configSubDir and configRepoPath:

Shouldn't you be checking "if self.mozconfig and configSubDir and configRepoPath:" on this line then?

Comment 80

[Armen [:armenzg]]

Attachment: [buildbotcustom] WinCE to be the only platform making use of a mozconfig file

This fixes the problem that attachment 419966 [details] [diff] [review] was trying to fix and fixed the regression introduced by it.

Comment 81

[Chris Cooper [:coop] (he/him)]

Comment on attachment 420119 [details] [diff] [review]
[buildbotcustom] WinCE to be the only platform making use of a mozconfig file

I actually meant to insert the comment up where the mozconfig path is pieced together in __init__. The mozconfig is only used implicitly when calling "make configure," and the comment here just echoes the conditional anyway.

r+ with that change.

Comment 82

[Armen [:armenzg]]

Comment on attachment 420119 [details] [diff] [review]
[buildbotcustom] WinCE to be the only platform making use of a mozconfig file

http://hg.mozilla.org/build/buildbotcustom/rev/dfa7408e2bd9

Comment 83

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 419928 [details] [diff] [review]
[1.9.2] upload cab files as well

a192=beltzner

Comment 84

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 419471 [details] [diff] [review]
[1.9.2] upload cab files as well

a192=beltzner

Comment 85

[Armen [:armenzg]]

First batch of localized WinCE builds:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central-l10n/
Dolske could you please have a look at them to verify?

We need to land these patches on 192 for the WinCE builds to work in there:
* https://bugzilla.mozilla.org/attachment.cgi?id=417356&action=edit
* https://bugzilla.mozilla.org/attachment.cgi?id=419928&action=edit
They already have 192 approvals and they do not affect release path in case of any respins of the RC so it is safe to land.
Could we please land these as well?

I will look into the release builder for WinCE l10n.

Comment 86

[Justin Dolske [:Dolske]]

(In reply to comment #85)
> First batch of localized WinCE builds:
> Dolske could you please have a look at them to verify?

Yep, looks good!

> Could we please land these as well?

Lemme double check that it's ok with beltzner and I'll land.

Comment 87

[Mike Beltzner [:beltzner, not reading bugmail]]

(beltzner's ok with it, land away!)

Comment 88

[Justin Dolske [:Dolske]]

(In reply to comment #85)

> * https://bugzilla.mozilla.org/attachment.cgi?id=417356&action=edit
> * https://bugzilla.mozilla.org/attachment.cgi?id=419928&action=edit

Pushed, respectively, to 192:

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/108e2617aed1
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/4a3aeee1280c

Comment 89

[Armen [:armenzg]]

It is not fixed yet for the nightly part of this bug but not for the release builders.

Thanks for pushing those patches. I will check in the morning to see that we get 192 builds.

Comment 90

[Justin Dolske [:Dolske]]

BTW, does this need to land on GECKO192_20100105_RELBRANCH too, or will any 3.6 RC2 come from a new branch tag?

Comment 91

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

Depends if anything lands on default which we don't want in RC2, which probably unlikely with approvals locked down. Certainly easier for devs if we cut another branch for an rc2, avoiding having to land in two places.

Comment 92

[Armen [:armenzg]]

This is what gets executed:
if [ -d mozilla-1.9.2 ]; then 
 hg -R mozilla-1.9.2 pull -r default ;
else 
 hg clone http://hg.mozilla.org/releases/mozilla-1.9.2 mozilla-1.9.2 ;
fi
hg -R mozilla-1.9.2 update -r FIREFOX_3_6rc1_RELEASE

later on:
hg up -C -r FIREFOX_3_6rc1_RELEASE

Aside of that, wince-l10n for 1.9.2 is working. Find the builds in:
- http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-1.9.2-l10n/

Comment 93

[Armen [:armenzg]]

Attachment: [buildbot-configs] add wince to the list of platforms processed on a release

Comment 94

[Armen [:armenzg]]

Attachment: [buildbotcustom] a lot of refactoring and add what is needed for WinCE L10n release

I don't want a review for the previous patch since we don't want wince for releases for now.

On the other side, I want review on this patch since I did a lot of cleaning up and moving things into BaseRepackFactory that are shared between NightlyRepackFactory and ReleaseRepackFactory.

This does not affect Mobile repack factories.

Comment 95

[Armen [:armenzg]]

Comment on attachment 419928 [details] [diff] [review]
[1.9.2] upload cab files as well

From looking at:
http://hg.mozilla.org/releases/mozilla-1.9.2/graph
the patch should have landed in GECKO192_20100105_RELBRANCH as well. If the patch stays on "default" will it be at some point be picked up for the next minor releases? or do we have to request 1.9.2.1 approval to get it in for the next release?

Comment 96

[Robert Kaiser]

Comment on attachment 419586 [details] [diff] [review]
[buildbotcustom] add wince L10n nightly and dependent builders (v2) 

>         # Mozilla subdir and objdir
>         if mozillaDir:
>             self.mozillaDir = '/%s' % mozillaDir
>             self.mozillaSrcDir = '%s/%s' % (self.origSrcDir, mozillaDir)
>         else:
>             self.mozillaDir = ''
>-            self.mozillaSrcDir = self.origSrcDir
>+            if self.objdir is not '':
>+                self.mozillaSrcDir = '%s/%s' % (self.origSrcDir, self.objdir)
>+            else:
>+                self.mozillaSrcDir = self.origSrcDir

Why does the path to the Mozilla *source* directory suddenly include an *object* directory path? That sounds painfully wrong to me...

Comment 97

[Robert Kaiser]

Comment on attachment 419139 [details] [diff] [review]
[configs] add wince entry to L10N_SLAVES and add l10n_platforms list to each branch

>+BRANCHES['mozilla-central']['l10n_platforms'] = ['linux','win32','macosx','wince'] 

Also, could you please in the future notify me and gozer as additional users of buildbotcustom when such a change is made that has a mandatory update in configs?

Comment 98

[Armen [:armenzg]]

My apologies. This have been such fast paced decisions and changes.

With regards the objdir I can try to fix it in a following patch but do you have a suggestion of how to deal with it? (I will think about it and come with a solution)

Comment 99

[Robert Kaiser]

Actually, the l10n_platforms didn't bust us this time, I had a stupid and different bustage.

What created problems though is the mozillaSrcDir change, as I suspected. It really should point to the Mozilla source directory. What exactly was your intention by changing this? what did point to mozillaSrcDir but needs to point to an objdir actually? We probably should use some var there that points to thes the objdir and set it to the srcdir if no objdir is set.

Currently, the autoconf_js_src step fails for comm-* build as it needs to point to the *mozilla* source dir but you made it point to the origSrcDir (and those are different for us). The /locales dir is *not* inside the mozilla directory though, so that change is also wrong.
As I said, I suspect you might need an additional var instead of repurposing a var that already has a different use.

Comment 100

[Robert Kaiser]

Attachment: [buildbotcustom] bustage fix for comm-* (not for checkin)

This diff is just FYI and surely not for checkin, as it probably would break WinCE stuff, but this is the diff I needed to apply on the SeaMonkey buildmaster to undo the bustage caused by attachment 419586 [details] [diff] [review] - this should be integrated in a patch that solves the problem for all cases we have.

Comment 101

[Armen [:armenzg]]

Comment on attachment 421458 [details] [diff] [review]
[buildbotcustom] a lot of refactoring and add what is needed for WinCE L10n release

I will address the problems that Kairo is facing. The patch is already written and I will repost when I have it tested.

Comment 102

[Justin Dolske [:Dolske]]

(In reply to comment #95)
> the patch should have landed in GECKO192_20100105_RELBRANCH as well. If the
> patch stays on "default" will it be at some point be picked up for the next
> minor releases?

This missed RC2 by an hour or two, so we'll either have to:

1) do it manually (if we need such builds for 3.6.0 and RC2 is the last RC)
2) try again as an RC3 ridealong
3) do nothing, as it's already landed for 3.6.1pre so will be there for 3.6.1.

Comment 103

[Armen [:armenzg]]

Attachment: [buildbotcustom] a lot of refactoring and add what is needed for WinCE L10n release (v3)

It worked in all Firefox, mobile and release repack L10n builders.
It fixes the problems mentioned by Kairo by adding a self.mozillaObjdir in the same way that in MercurialBuildFactory.

Comment 104

[Robert Kaiser]

Comment on attachment 422227 [details] [diff] [review]
 [buildbotcustom] a lot of refactoring and add what is needed for WinCE L10n release (v3)

>-         workdir='%s/%s/%s/locales' % (self.baseWorkDir, self.mozillaSrcDir,
>+         workdir='%s/%s/%s/locales' % (self.baseWorkDir, self.mozillaObjdir,

Oops. You don't want the Mozilla objdir there, but the normal-level objdir.
e.g. for SeaMonkey, we need to end up with comm-central/suite/locales (or comm-central/objdir/suite/locales when objdir="objdir") but with your code we end up with comm-central/mozilla/suite/locales (or comm-central/mozilla/objdir/suite/locales which is even more wrong).

1) You should set |self.objdir = objdir or self.origSrcDir
2) The other one should be |self.mozillaObjdir = '%s%s' % (self.objdir, self.mozillaDir)|
3) Everywhere you call things from the *Mozilla patform*, you should use self.mozilla* directories, everywhere you call things belonging to *the application* (like locales/) you want self.origSrcDir/self.objdir.

We make this distinction because for SeaMonkey and Thunderbird, the Mozilla platform is under the mozilla/ subdirectory in the source tree, one level deeper than the application-specific code.

Does that make sense?

Comment 105

[Armen [:armenzg]]

Comment on attachment 422227 [details] [diff] [review]
 [buildbotcustom] a lot of refactoring and add what is needed for WinCE L10n release (v3)

Thanks Kairo. I will try to get your approval before requesting Chris's and Ben's.

Comment 106

[Armen [:armenzg]]

Attachment: [buildbotcustom] a lot of refactoring and add what is needed for WinCE L10n release (v4)

Addressed objdir/mozillaObjdir differentiation and Kairo was happy about the patch yesterday.
I have triggered repackages in all L10n builders on sm02. Some mobile L10n builders are currently failing on production these days. We will have to retest once more before deployment to be sure.

Comment 107

[Chris Cooper [:coop] (he/him)]

Comment on attachment 423559 [details] [diff] [review]
[buildbotcustom] a lot of refactoring and add what is needed for WinCE L10n release (v4)

Two nits:

1) Please switch to the self.addStep(ShellCommand()) syntax of adding steps. This will avoid the need to update these steps when we deploy the newer version of buildbot. (I just found this out this morning myself)

2) self.mozillaObjdir seems to be named backwards to me, given how it is put together from the other vars (self.objdir, self.mozillaDir). I'm flexible on this though...all these similarly-named vars hurt my brain.

r+ with those nits.

Comment 108

[Chris Cooper [:coop] (he/him)]

(In reply to comment #106)
> I have triggered repackages in all L10n builders on sm02. Some mobile L10n
> builders are currently failing on production these days. We will have to retest
> once more before deployment to be sure.

Armen: are these issues related to this patch, or is the cause still unknown?

Comment 109

[Axel Hecht [:Pike]]

I'm confused by the addStep comment, looking at http://github.com/djmitche/buildbot/blob/master/buildbot/process/factory.py#LC56

Comment 110

[Chris Cooper [:coop] (he/him)]

(In reply to comment #109)
> I'm confused by the addStep comment, looking at
> http://github.com/djmitche/buildbot/blob/master/buildbot/process/factory.py#LC56

That's the info I got from catlee this morning when I asked about the same thing, namely that we should avoid the self.addStep(ShellCommand, name=...) declaration in favor of self.addStep(ShellCommand(name=...)).

catlee: what's the reasoning behind this? Why does the first syntax cause us problems?

Comment 111

[Armen [:armenzg]]

(In reply to comment #108)
> (In reply to comment #106)
> > I have triggered repackages in all L10n builders on sm02. Some mobile L10n
> > builders are currently failing on production these days. We will have to retest
> > once more before deployment to be sure.
> 
> Armen: are these issues related to this patch, or is the cause still unknown?
>
Not related. The mobile L10n world was red due to package namings until yesterday. Everything looks green today.

Comment 112

[Robert Kaiser]

Comment on attachment 421828 [details] [diff] [review]
[buildbotcustom] bustage fix for comm-* (not for checkin)

obsoleting this patch as I tested Armen's new one and it works fine on the SeaMonkey buildmaster.

Comment 113

[Chris Cooper [:coop] (he/him)]

(In reply to comment #110)
> catlee: what's the reasoning behind this? Why does the first syntax cause us
> problems?

Apparently this let's us catch more errors via checkconfig rather than waiting until runtime.

Comment 114

[Robert Kaiser]

(In reply to comment #112)
> (From update of attachment 421828 [details] [diff] [review])
> obsoleting this patch as I tested Armen's new one and it works fine on the
> SeaMonkey buildmaster.

Actually, I just noticed that Armen's patch misses changing autoconf_js_src back to mozillaSrcDir, and so SeaMonkey L10n builds are failing. Could you add that small change to your patch as well?

Comment 115

[Robert Kaiser]

Oh, and in make_l10n_upload, you missed one in the other way. That's a /locales reference, it needs a self.objdir - and rm_dist_update probably wants a self.mozillaObjdir (doesn't fail, but never has anything to do if the dir is wrong).

Comment 116

[[e-mail] (:bhearsum)]

Comment on attachment 423559 [details] [diff] [review]
[buildbotcustom] a lot of refactoring and add what is needed for WinCE L10n release (v4)

>diff -r c0cc157024ea misc.py

>+    def getMozconfig(self):
>+        if hasattr(self, 'mozconfig') and self.mozconfig != '':

This seems unnecessary. Just set a default value for 'mozconfig' in __init__().

Otherwise, seems ok

Comment 117

[Armen [:armenzg]]

Attachment: [buildbotcustom] a lot of refactoring and add what is needed for WinCE L10n release (v6)

It handles all the fixes of Kairo and the comments of Bhearsum.
It has worked properly on staging for release and nightly scenarios.

Comment 118

[Armen [:armenzg]]

Comment on attachment 424639 [details] [diff] [review]
[buildbotcustom] a lot of refactoring and add what is needed for WinCE L10n release (v6)

http://hg.mozilla.org/build/buildbotcustom/rev/5979e1bb7c9a

Comment 119

[Armen [:armenzg]]

Status update:

* I have landed all I needed from this bug
* I am going to disable everything wrt to WinCE in bug 543067

If in the future we are to start WinCE we can open another bug.

Comment 120

[Serge Gautherie (:sgautherie)]

Attachment: (AAv1-CC) Copy it to comm-central [Checkin: Comment 124]

Comment 121

[Justin Wood (:Callek)]

Comment on attachment 428030 [details] [diff] [review]
(AAv1-CC) Copy it to comm-central
[Checkin: Comment 124]

its not clear to me what we are copying and why, can you please move this to a new bug. And explain there. Also Mark needs to review mail/ and calendar/ parts.

Comment 122

[Serge Gautherie (:sgautherie)]

Comment on attachment 428030 [details] [diff] [review]
(AAv1-CC) Copy it to comm-central
[Checkin: Comment 124]


(In reply to comment #121)

This simply enables the localized WinCE installer(s) upload, as is already done for WinNT. In preparation for potential/future WinCE builds in c-c.

I'll just reset the review request here.

Comment 123

[Chris Cooper [:coop] (he/him)]

Moving closed Future bugs into Release Engineering in preparation for removing the Future component.

Comment 124

[Serge Gautherie (:sgautherie)]

Comment on attachment 428030 [details] [diff] [review]
(AAv1-CC) Copy it to comm-central
[Checkin: Comment 124]


http://hg.mozilla.org/comm-central/rev/ca7294c5124c