1291636 - Fennec 49.0b1 single locale broken in configure

Status: RESOLVED FIXED

(Release Engineering :: Release Automation, defect)

Description

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

...
22:25:41     INFO -  checking NSPR selection... source-tree
22:25:41     INFO -  checking for gzread in -lz... yes
22:25:41     INFO -  cat: /builds/mozilla-fennec-geoloc-api.key: No such file or directory
22:25:41     INFO -  cat: /builds/adjust-sdk-beta.token: No such file or directory
22:25:41     INFO -  checking if app-specific confvars.sh exists... /builds/slave/rel-m-beta-and-api-15_rpk_7-00/build/mozilla-beta/mobile/android/confvars.sh
22:25:41     INFO -  checking for Android SDK platform version 23... /builds/slave/rel-m-beta-and-api-15_rpk_7-00/build/mozilla-beta/android-sdk-linux/platforms/android-23
...
22:25:45     INFO -  DEBUG: configure:17114: checking for ANDROID_PLAY_SERVICES_BASEMENT_AAR_RES
22:25:45     INFO -  DEBUG: configure: error: Must specify --with-adjust-sdk-keyfile when MOZ_INSTALL_TRACKING is defined!
22:25:45     INFO -  ERROR: old-configure failed
22:25:45     INFO -  *** Fix above errors and then restart with\
22:25:45     INFO -                 "make -f client.mk build"
22:25:45     INFO -  make: *** [configure] Error 1

Comment 1

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

The 'No such file or directory' errors are not new, they're present in 48.0b9 too, but
  http://hg.mozilla.org/releases/mozilla-beta/rev/ac75f8f4c01d
makes it an error now.

nalexander, should we be setting MOZ_INSTALL_TRACKING=0 on these single locale builds ? I'm unsure if there's any utility in having it set for builds that mostly get found on ftp.m.o/archive.m.o instead of Google Play. The multilocale builds do have it enabled (via /builds/adjust-sdk-beta.token copied inside mock, and picking up the MOZ_INSTALL_TRACKING=1 default at http://hg.mozilla.org/releases/mozilla-beta/file/default/mobile/android/confvars.sh#l51).

example log for single locale failure - https://archive.mozilla.org/pub/mobile/candidates/49.0b1-candidates/build2/logs/release-mozilla-beta-android-api-15_repack_1-bm72-build1-build5.txt.gz

Comment 2

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

Callek, depending on the answer to that question I'm guessing we want
  https://diff.pastebin.mozilla.org/8889109
or 
  https://diff.pastebin.mozilla.org/8889111

Comment 3

[Nick Alexander :nalexander [he/him]]

(In reply to Nick Thomas [:nthomas] from comment #1)
> The 'No such file or directory' errors are not new, they're present in
> 48.0b9 too, but
>   http://hg.mozilla.org/releases/mozilla-beta/rev/ac75f8f4c01d
> makes it an error now.

What this really means is that the l10n repacks are happening on different machine types than the builds, since this is part of the build secrets configuration.

> nalexander, should we be setting MOZ_INSTALL_TRACKING=0 on these single
> locale builds ? I'm unsure if there's any utility in having it set for
> builds that mostly get found on ftp.m.o/archive.m.o instead of Google Play.
> The multilocale builds do have it enabled (via /builds/adjust-sdk-beta.token
> copied inside mock, and picking up the MOZ_INSTALL_TRACKING=1 default at
> http://hg.mozilla.org/releases/mozilla-beta/file/default/mobile/android/
> confvars.sh#l51).

I don't think it is important for Mozilla to track installation of these single locale repacks, so some variant of https://diff.pastebin.mozilla.org/8889109 seems best.

Comment 4

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

(In reply to Nick Alexander :nalexander from comment #3)
> What this really means is that the l10n repacks are happening on different
> machine types than the builds, since this is part of the build secrets
> configuration.

Sortof. Usually different machines in the pool will do the 10 repacks and the en-US+multi build, but all have a full set of tokens in /builds. The issue is the mock environment and copying those secrets into it - there's a separate config for repacks which isn't.
 
> I don't think it is important for Mozilla to track installation of these
> single locale repacks, so some variant of
> https://diff.pastebin.mozilla.org/8889109 seems best.

I might have asked the wrong question. We're repacking the en-US build and not actually compiling again, which manes running configure so we get Makefiles/working build system, then call assorted make targets to do the repacking. From the logs it looks like MOZ_INSTALL_TRACKING only matters at compile time. In which case we just have to get through configure to repack, and it's probably best to make the tokens available and keep the jobs in sync, rather than set the pref to 0 and imply it's doing something.

This is a 48.0b9 log where the repacking is working http://archive.mozilla.org/pub/mobile/candidates/48.0b9-candidates/build1/logs/release-mozilla-beta-android-api-15_repack_1-bm74-build1-build5.txt.gz.

Comment 5

[Nick Alexander :nalexander [he/him]]

(In reply to Nick Thomas [:nthomas] from comment #4)
> (In reply to Nick Alexander :nalexander from comment #3)
> > What this really means is that the l10n repacks are happening on different
> > machine types than the builds, since this is part of the build secrets
> > configuration.
> 
> Sortof. Usually different machines in the pool will do the 10 repacks and
> the en-US+multi build, but all have a full set of tokens in /builds. The
> issue is the mock environment and copying those secrets into it - there's a
> separate config for repacks which isn't.
>  
> > I don't think it is important for Mozilla to track installation of these
> > single locale repacks, so some variant of
> > https://diff.pastebin.mozilla.org/8889109 seems best.
> 
> I might have asked the wrong question. We're repacking the en-US build and
> not actually compiling again, which manes running configure so we get
> Makefiles/working build system, then call assorted make targets to do the
> repacking. From the logs it looks like MOZ_INSTALL_TRACKING only matters at
> compile time. In which case we just have to get through configure to repack,
> and it's probably best to make the tokens available and keep the jobs in
> sync, rather than set the pref to 0 and imply it's doing something.
> 
> This is a 48.0b9 log where the repacking is working
> http://archive.mozilla.org/pub/mobile/candidates/48.0b9-candidates/build1/
> logs/release-mozilla-beta-android-api-15_repack_1-bm74-build1-build5.txt.gz.

Oh, I see.  It's not clear to me that your interpretation is correct: are we confident that things like https://dxr.mozilla.org/mozilla-central/source/toolkit/content/license.html#70 don't change at repack time?  I'm not convinced that Android strings won't change when tracking is disabled, since the set of strings should include Google Play Services strings, and those strings are only included when MOZ_INSTALL_TRACKING is set.

I think in general it's unwise to configure a repack differently than a build when we don't have to.  Do we have to?  Why don't we just align the repacker mock token store with the builder mock token store here?

Comment 6

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

Attachment: [gecko] Add tokens to mock environment for repacks

Comment 7

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

I agree, lets keep the repacks in sync with the builds.

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/1b9b075f3acf
Fennec single locale repacks broken on beta, r=Callek DONTBUILD

Comment 9

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

https://hg.mozilla.org/releases/mozilla-aurora/rev/bc44adff83a8
https://hg.mozilla.org/releases/mozilla-beta/rev/0b3d92985075

Comment 10

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/1b9b075f3acf

Comment 11

[u421692]

Verified as fixed on Firefox 49 Beta 2