831147 - Integrate apitrace into build

Status: RESOLVED FIXED

(Firefox OS Graveyard :: GonkIntegration, defect)

Description

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Setting up the apitrace client library is a PITA [1].  Devs have to duplicate a bunch of compiler setup that the b2g build system does already.

We should add
 - apitrace as a b2g subrepo
 - give it some Android.mk love
 - build and install it by default in "userdebug" and "eng" builds

[1] https://wiki.mozilla.org/B2G/Debugging_OpenGL

Comment 1

[Vasil Dimov [:vd]]

Attachment: Pointer to Github pull request: https://github.com/mozilla-b2g/b2g-manifest/pull/53

Pointer to Github pull-request

Comment 2

[Vasil Dimov [:vd]]

The above patch does the "- apitrace as a b2g subrepo" part.

About the "- give it some Android.mk love" part:

I guess that a new Anroid.mk should be planted into external/apitrace/ which will instruct the build process to compile apitrace.

Apitrace is naturally configured using cmake and compiled with make, i.e. something like "cmake ... && make ..." should be run in external/apitrace.

One approach would be to rewrite the cmake logic into an Anroid.mk logic, but apitrace/CMakeLists.txt is already 424 lines. That will cause big maintenance overhead in the future when apitrace/CMakeLists.txt is changed upstream.

Another approach is to run cmake&&make from external/apitrace/Anroid.mk.

Better ideas?

Comment 3

[Vasil Dimov [:vd]]

Attachment: Compile apitrace by ./build.sh apitrace

The attached patch hooks the apitrace config&compile into "./build.sh apitrace". It is a kind of hack, any ideas on how to better integrate this are welcome!

Comment 4

[Gabriele Svelto [:gsvelto] (PTO)]

Comment on attachment 717241 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/b2g-manifest/pull/53

Looks good to me, I've tried a build with both patches applied and it works fine.

I'll leave Michael comment on the other patch but in general your approach seems a good starting point. You'll only have to find a way to make it integrate transparently in eng and userdebug builds so that apitrace is properly copied in the system image when the build is finished.

Comment 5

[Vasil Dimov [:vd]]

Attachment: Pointer to Github pull request: https://github.com/mozilla-b2g/B2G/pull/219

Comment 6

[Vasil Dimov [:vd]]

Attachment: Pointer to Github pull request: https://github.com/mozilla-b2g/B2G/pull/220

Also install apitrace into /system/bin/apitrace and build out-of-source.

Comment 7

[Vasil Dimov [:vd]]

To test those patches:

git clone git://github.com/vasild/B2G.git
cd B2G
GITREPO=git://github.com/vasild/b2g-manifest BRANCH=master ./config.sh emulator-or-whatever
./build.sh as usual

Comment 8

[Gabriele Svelto [:gsvelto] (PTO)]

Comment on attachment 722817 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/B2G/pull/220

The patch is looking good. If you can make it so that egltrace.so is installed under /system/lib/apitrace/wrappers instead of /system/lib so that the apitrace binary picks it up automatically it would be best. If it cannot be done in a simple way let's merge this patch as is and open a follow-up bug for that. Anyway this is excellent work, congrats!

Comment 9

[Vasil Dimov [:vd]]

Attachment: Pointer to Github pull request: https://github.com/mozilla-b2g/B2G/pull/221

Install egltrace.so in /system/lib/apitrace/wrappers/ instead of /system/lib/

Comment 10

[Michael Wu [:mwu]]

platform_build is not a good place to put in build integration of a specific package. We should really just have an Android.mk to do this instead.

Comment 11

[Gabriele Svelto [:gsvelto] (PTO)]

(In reply to Michael Wu [:mwu] from comment #10)
> platform_build is not a good place to put in build integration of a specific
> package. We should really just have an Android.mk to do this instead.

The way he devised the patch it sits comfortably in the main B2G repo instead of platform_build and I think it blends in nicely with the build system: the external repo is pulled like other projects and then it's patched up so that it has its specific Android.mk. The mechanism for applying "vendor" patches seemed fine for this. Did you think of a different approach?

Comment 12

[Michael Wu [:mwu]]

Oh I was looking at some old patch then.

The vendor patch mechanism is not acceptable for general use. Forking and patching is one alternative, though the best case here would be to push an Android.mk upstream.

Comment 13

[Gabriele Svelto [:gsvelto] (PTO)]

(In reply to Michael Wu [:mwu] from comment #12)
> The vendor patch mechanism is not acceptable for general use. Forking and
> patching is one alternative, though the best case here would be to push an
> Android.mk upstream.

That would be optimal indeed but would require a non-trivial amount of work. One road we might follow would be to merge these patches so that we get this functionality easily integrated now; then file follow-up bugs to fork apitrace into our repos, add the necessary bits (Android.mk), and finally adjust the manifest to point to it and remove the vendor-patching. What do you think?

Comment 14

[Vasil Dimov [:vd]]

Attachment: Pointer to Github pull request: https://github.com/mozilla-b2g/b2g-manifest/pull/63

Clone apitrace from github.com:vasild/apitrace instead of github.com:apitrace/apitrace. The former is forked from the latter and has Android.mk added.

This way we do not need to copy the Android.mk file to the apitrace directory after cloning it from github.

Comment 15

[Michael Wu [:mwu]]

This integration via Android.mk is what we want, though the current mechanism could use some improvement. This downloads the ndk to interface with the current Android build system, but we can directly use the toolchain we already have. We have easy access to the correct toolchain via $(TARGET_TOOLS_PREFIX), and we should be able to tell cmake to use those tools instead of using heuristics to pick out programs from an NDK download.

I was looking at https://github.com/apitrace/apitrace/blob/master/cmake/toolchain/android.toolchain.cmake and it looks like we could strip out most of it and leave the parts that set the CMAKE_* variables. How does that sound?

Comment 16

[Vasil Dimov [:vd]]

(In reply to Michael Wu [:mwu] from comment #15)
> This integration via Android.mk is what we want, though the current
> mechanism could use some improvement. This downloads the ndk to interface
> with the current Android build system, but we can directly use the toolchain
> we already have. We have easy access to the correct toolchain via
> $(TARGET_TOOLS_PREFIX), and we should be able to tell cmake to use those
> tools instead of using heuristics to pick out programs from an NDK download.

Yeah, I tried using the already present NDKs but no luck:

1. If ANDROID_NDK is to be set in the env of cmake, then the code in apitrace/cmake/toolchain/android.toolchain.cmake looks for the following directories, which do not exist in B2G NDKs:

${ANDROID_NDK}/platforms/android-*, e.g.:
${ANDROID_NDK}/platforms/android-9

${ANDROID_NDK}/toolchains/*, e.g.:
${ANDROID_NDK}/toolchains/arm-linux-androideabi-4.4.3

Those are present in http://dl.google.com/android/ndk/android-ndk-r8-linux-x86.tar.bz2, but for some reason are not present in none of:

B2G/ndk
B2G/prebuilt/ndk
B2G/development/ndk

Why is the layout different?

2. If ANDROID_STANDALONE_TOOLCHAIN is to be used, then it fails because it searches for ${ANDROID_STANDALONE_TOOLCHAIN}/sysroot/usr/include/android/api-level.h, but our file is located in B2G/prebuilt/ndk/android-ndk-r8/platforms/android-9/arch-arm/usr/include/android/api-level.h, doh!
 
> I was looking at
> https://github.com/apitrace/apitrace/blob/master/cmake/toolchain/android.
> toolchain.cmake and it looks like we could strip out most of it and leave
> the parts that set the CMAKE_* variables. How does that sound?

I tried that today. Extracted all the CMAKE_ and ANDROID* variables from BUILD/CMakeCache.txt (from a previous successful invocation of cmake with the downloaded NDK archive) and ran cmake again with all those variables set with -D..., but it fails miserably:

--- cut ---
cmake \
-DCMAKE_AR:PATH='/B2G/external/apitrace/android-ndk-r8/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-ar' \
-DCMAKE_ASM_COMPILER:PATH='/B2G/external/apitrace/android-ndk-r8/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-gcc' \
-DCMAKE_BUILD_TYPE:STRING='' \
-DCMAKE_COLOR_MAKEFILE:BOOL='ON' \
-DCMAKE_CXX_COMPILER:FILEPATH='/B2G/external/apitrace/android-ndk-r8/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-g++' \
-DCMAKE_CXX_FLAGS:STRING='-fPIC -Wno-psabi -frtti -fexceptions' \
-DCMAKE_CXX_FLAGS_DEBUG:STRING='-marm -Os -finline-limit=64 -fno-strict-aliasing -fno-omit-frame-pointer -DDEBUG -D_DEBUG' \
-DCMAKE_CXX_FLAGS_MINSIZEREL:STRING='-Os -DNDEBUG' \
-DCMAKE_CXX_FLAGS_RELEASE:STRING='-mthumb -O3 -fomit-frame-pointer -DNDEBUG' \
-DCMAKE_CXX_FLAGS_RELWITHDEBINFO:STRING='-O2 -g' \
-DCMAKE_C_COMPILER:FILEPATH='/B2G/external/apitrace/android-ndk-r8/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-gcc' \
-DCMAKE_C_FLAGS:STRING='-fPIC -Wno-psabi -fexceptions' \
-DCMAKE_C_FLAGS_DEBUG:STRING='-marm -Os -finline-limit=64   -fno-strict-aliasing -fno-omit-frame-pointer -DDEBUG -D_DEBUG' \
-DCMAKE_C_FLAGS_MINSIZEREL:STRING='-Os -DNDEBUG' \
-DCMAKE_C_FLAGS_RELEASE:STRING='-mthumb -O3   -fomit-frame-pointer -DNDEBUG' \
-DCMAKE_C_FLAGS_RELWITHDEBINFO:STRING='-O2 -g' \
-DCMAKE_EXE_LINKER_FLAGS:STRING='-Wl,-z,nocopyreloc' \
-DCMAKE_EXE_LINKER_FLAGS_DEBUG:STRING='' \
-DCMAKE_EXE_LINKER_FLAGS_MINSIZEREL:STRING='' \
-DCMAKE_EXE_LINKER_FLAGS_RELEASE:STRING='' \
-DCMAKE_EXE_LINKER_FLAGS_RELWITHDEBINFO:STRING='' \
-DCMAKE_EXPORT_COMPILE_COMMANDS:BOOL='OFF' \
-DCMAKE_INSTALL_PREFIX:PATH='/usr/local' \
-DCMAKE_LINKER:PATH='/B2G/external/apitrace/android-ndk-r8/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-ld' \
-DCMAKE_MAKE_PROGRAM:FILEPATH='/usr/bin/make' \
-DCMAKE_MODULE_LINKER_FLAGS:STRING='' \
-DCMAKE_MODULE_LINKER_FLAGS_DEBUG:STRING='' \
-DCMAKE_MODULE_LINKER_FLAGS_MINSIZEREL:STRING='' \
-DCMAKE_MODULE_LINKER_FLAGS_RELEASE:STRING='' \
-DCMAKE_MODULE_LINKER_FLAGS_RELWITHDEBINFO:STRING='' \
-DCMAKE_NM:PATH='/B2G/external/apitrace/android-ndk-r8/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-nm' \
-DCMAKE_OBJCOPY:PATH='/B2G/external/apitrace/android-ndk-r8/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-objcopy' \
-DCMAKE_OBJDUMP:PATH='/B2G/external/apitrace/android-ndk-r8/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-objdump' \
-DCMAKE_PROJECT_NAME:STATIC='apitrace' \
-DCMAKE_RANLIB:PATH='/B2G/external/apitrace/android-ndk-r8/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-ranlib' \
-DCMAKE_SHARED_LINKER_FLAGS:STRING='' \
-DCMAKE_SHARED_LINKER_FLAGS_DEBUG:STRING='' \
-DCMAKE_SHARED_LINKER_FLAGS_MINSIZEREL:STRING='' \
-DCMAKE_SHARED_LINKER_FLAGS_RELEASE:STRING='' \
-DCMAKE_SHARED_LINKER_FLAGS_RELWITHDEBINFO:STRING='' \
-DCMAKE_SKIP_INSTALL_RPATH:BOOL='NO' \
-DCMAKE_SKIP_RPATH:BOOL='NO' \
-DCMAKE_STRIP:PATH='/B2G/external/apitrace/android-ndk-r8/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-strip' \
-DCMAKE_USE_RELATIVE_PATHS:BOOL='OFF' \
-DCMAKE_VERBOSE_MAKEFILE:BOOL='FALSE' \
-H. -B/tmp/a1

...

-- Check for working C compiler: /B2G/external/apitrace/android-ndk-r8/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-gcc -- broken
CMake Error at /usr/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake:52 (MESSAGE):
  The C compiler
  "/B2G/external/apitrace/android-ndk-r8/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-gcc"
  is not able to compile a simple test program.

  It fails with the following output:

   Change Dir: /tmp/a1/CMakeFiles/CMakeTmp

  

  Run Build Command:/usr/bin/make "cmTryCompileExec2099992909/fast"

  /usr/bin/make -f CMakeFiles/cmTryCompileExec2099992909.dir/build.make
  CMakeFiles/cmTryCompileExec2099992909.dir/build

  make[1]: Entering directory `/tmp/a1/CMakeFiles/CMakeTmp'

  /usr/bin/cmake -E cmake_progress_report
  /tmp/a1/CMakeFiles/CMakeTmp/CMakeFiles 1

  Building C object
  CMakeFiles/cmTryCompileExec2099992909.dir/testCCompiler.c.o

  
  /B2G/external/apitrace/android-ndk-r8/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-gcc
  -fPIC -Wno-psabi -fexceptions -o
  CMakeFiles/cmTryCompileExec2099992909.dir/testCCompiler.c.o -c
  /tmp/a1/CMakeFiles/CMakeTmp/testCCompiler.c

  Linking C executable cmTryCompileExec2099992909

  /usr/bin/cmake -E cmake_link_script
  CMakeFiles/cmTryCompileExec2099992909.dir/link.txt --verbose=1

  
  /B2G/external/apitrace/android-ndk-r8/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-gcc
  -fPIC -Wno-psabi -fexceptions
  CMakeFiles/cmTryCompileExec2099992909.dir/testCCompiler.c.o -o
  cmTryCompileExec2099992909 -rdynamic

  
  /B2G/external/apitrace/android-ndk-r8/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/../lib/gcc/arm-linux-androideabi/4.4.3/../../../../arm-linux-androideabi/bin/ld:
  crtbegin_dynamic.o: No such file: No such file or directory

  collect2: ld returned 1 exit status
--- cut ---

What do I miss?

Comment 17

[Michael Wu [:mwu]]

(In reply to Vasil Dimov [:vd] from comment #16)
> (In reply to Michael Wu [:mwu] from comment #15)
> > This integration via Android.mk is what we want, though the current
> > mechanism could use some improvement. This downloads the ndk to interface
> > with the current Android build system, but we can directly use the toolchain
> > we already have. We have easy access to the correct toolchain via
> > $(TARGET_TOOLS_PREFIX), and we should be able to tell cmake to use those
> > tools instead of using heuristics to pick out programs from an NDK download.
> 
> Yeah, I tried using the already present NDKs but no luck:
> 
> Why is the layout different?
> 

I think the NDK available from google is actually generated from a number of places rather than being sourced from a single directory.

> 2. If ANDROID_STANDALONE_TOOLCHAIN is to be used, then it fails because it
> searches for
> ${ANDROID_STANDALONE_TOOLCHAIN}/sysroot/usr/include/android/api-level.h, but
> our file is located in
> B2G/prebuilt/ndk/android-ndk-r8/platforms/android-9/arch-arm/usr/include/
> android/api-level.h, doh!
>  
> > I was looking at
> > https://github.com/apitrace/apitrace/blob/master/cmake/toolchain/android.
> > toolchain.cmake and it looks like we could strip out most of it and leave
> > the parts that set the CMAKE_* variables. How does that sound?
> 
> I tried that today. Extracted all the CMAKE_ and ANDROID* variables from
> BUILD/CMakeCache.txt (from a previous successful invocation of cmake with
> the downloaded NDK archive) and ran cmake again with all those variables set
> with -D..., but it fails miserably:
> 
> /B2G/external/apitrace/android-ndk-r8/toolchains/arm-linux-androideabi-4.4.3/
> prebuilt/linux-x86/bin/../lib/gcc/arm-linux-androideabi/4.4.3/../../../../
> arm-linux-androideabi/bin/ld:
>   crtbegin_dynamic.o: No such file: No such file or directory
> 
>   collect2: ld returned 1 exit status
> --- cut ---
> 
> What do I miss?

I believe that check is actually disabled when using the android toolchain cmake -

https://github.com/apitrace/apitrace/blob/master/cmake/toolchain/android.toolchain.cmake#L763

include( CMakeForceCompiler ) prevents the compiler from trying to compile a simple test program, which we shouldn't care about anyway since we're trying to build a library.

crtbegin_dynamic.o is available via TARGET_CRTBEGIN_DYNAMIC_O - see https://github.com/mozilla-b2g/platform_build/blob/master/core/combo/TARGET_linux-arm.mk#L230 . This files defines most of the important platform specific toolchain pieces.

Comment 18

[Vasil Dimov [:vd]]

Finally, I got this working. See https://github.com/vasild/apitrace/commit/91e28b53dfd47c683bf41c1b66e20eb540873686

Michael, what do you think?

Comment 19

[Vasil Dimov [:vd]]

Hello,

There is further progress here, take a look at this Android.mk:

https://github.com/vasild/apitrace/blob/master/Android.mk

it uses the B2G's NDK. If it looks fine to you then I will ask the apitrace dev to copy it into apitrace and then integrating apitrace into B2G would only be a matter of adding git://github.com/apitrace/apitrace.git to the manifest XML files!

Comment 20

[Michael Wu [:mwu]]

Looks pretty good! If you can get this into upstream apitrace, it would be perfect. However, if they don't want it, we can still include this in the manifest.

Comment 21

[Vasil Dimov [:vd]]

Attachment: Pointer to Github pull request: https://github.com/mozilla-b2g/b2g-manifest/pull/70

Comment 22

[Vasil Dimov [:vd]]

Android.mk is included in upstream apitrace now.

I updated the patch that includes git://github.com/apitrace/apitrace.git in the XML manifests to the latest version of the tree (pull request 70).

Comment 23

[Michael Wu [:mwu]]

Merged. Thanks!

Comment 24

[Michael Wu [:mwu]]

Backed out on otoro.xml, emulator.xml, and pandaboard.xml - our infrastructure choked on the new repo and remote. It's a new feature apparently.

Comment 25

[Vasil Dimov [:vd]]

I filed "Bug 865282 - Mirror github.com/apitrace/apitrace to git.m.o" in order to get that problem resolved.

Comment 26

[Michael Wu [:mwu]]

I backed this out entirely due to bug 868263. This should work out of the box with the toolchains we have, or at the very least, should not break builds.

https://github.com/mozilla-b2g/b2g-manifest/commit/3a9ab0abe3e213e9fbdf0726b0c7de7a424f91ce

Comment 27

[Ben Kelly [:bkelly, not reviewing]]

Attachment: Pointer to Github pull request: https://github.com/mozilla-b2g/B2G/pull/237

Pointer to Github pull-request

Comment 28

[Ben Kelly [:bkelly, not reviewing]]

Comment on attachment 745997 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/B2G/pull/237

Add cmake dep to bootstrap-mac.sh.

Comment 29

[Ben Kelly [:bkelly, not reviewing]]

Comment on attachment 745997 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/B2G/pull/237

Pull request landed in master:

https://github.com/mozilla-b2g/B2G/commit/b783afb4cc94780c435340313493acb65371def7

Comment 30

[Ben Kelly [:bkelly, not reviewing]]

Now that bug 868263 has been resolved, is this ready to land again?

Comment 31

[Vasil Dimov [:vd]]

(In reply to Ben Kelly [:bkelly] from comment #30)
> Now that bug 868263 has been resolved, is this ready to land again?

Almost!

There was another problem because of which this was partially reverted before you hit the r7 vs r8 issue. The other problem is that some build scripts take the remotes from the manifests and replace them with other remotes, pointing to git.mozilla.org. github.com/apitrace/apitrace.git was not mirrored and this broke things.

Now apitrace is mirrored properly (see Bug 865282). We need to get a change into http://hg.mozilla.org/build/mozharness/configs/b2g/releng-eng.py like this:

--- cut ---
diff --git a/configs/b2g/releng-eng.py b/configs/b2g/releng-eng.py
--- a/configs/b2g/releng-eng.py
+++ b/configs/b2g/releng-eng.py
@@ -84,10 +84,11 @@ config = {
     "repo_remote_mappings": {
         'https://android.googlesource.com/': 'https://git.mozilla.org/external/aosp',
         'git://codeaurora.org/': 'https://git.mozilla.org/external/caf',
         'https://git.mozilla.org/b2g': 'https://git.mozilla.org/b2g',
         'git://github.com/mozilla-b2g/': 'https://git.mozilla.org/b2g',
         'git://github.com/mozilla/': 'https://git.mozilla.org/b2g',
         'https://git.mozilla.org/releases': 'https://git.mozilla.org/releases',
         'http://android.git.linaro.org/git-ro/': 'https://git.mozilla.org/external/linaro',
+        'git://github.com/apitrace': 'https://git.mozilla.org/external/apitrace',
     },
 }
--- cut ---

After the above (or similar) is landed we can land the apitrace changes to the manifests again. For those I have replayed the apitrace addition to the latest manifests in git://github.com/vasild/b2g-manifest.git, and will create a pull request after we deal with releng-eng.py.

Comment 32

[Vasil Dimov [:vd]]

I just checked that the change to http://hg.mozilla.org/build/mozharness/configs/b2g/releng-eng.py has already been made!

Will create a pull request for the manifest changes shortly.

Comment 33

[Vasil Dimov [:vd]]

Attachment: Pointer to Github pull request: https://github.com/mozilla-b2g/b2g-manifest/pull/74

Comment 34

[Michael Wu [:mwu]]

I think there's one more thing - apitrace requires cmake, and we don't have cmake on our build systems as far as I know. Since this is for very specific users, I think we can just make building apitrace conditional on having cmake somewhere in the path. How does that sound?

Comment 35

[(no longer active)]

Why not just fail configure.in with a helpful error message if --enable-apitrace or whatever is specified and cmake cannot be found?

Comment 36

[Michael Wu [:mwu]]

(In reply to :Ehsan Akhgari (needinfo? me!) from comment #35)
> Why not just fail configure.in with a helpful error message if
> --enable-apitrace or whatever is specified and cmake cannot be found?

The apitrace build is not part of the gecko build, so configure.in isn't involved.

Comment 37

[Michael Wu [:mwu]]

Comment on attachment 747929 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/b2g-manifest/pull/74

Marking this r+ to get it off my review list. Just make sure we have that cmake checking so tbpl doesn't burn and that my nit in the pull request is addressed.

Comment 38

[Vasil Dimov [:vd]]

Attachment: Pointer to Github pull request: https://github.com/mozilla-b2g/b2g-manifest/pull/77

Comment 39

[Vasil Dimov [:vd]]

Comment on attachment 754252 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/b2g-manifest/pull/77

review+ on behalf of mwu

Comment 40

[Vasil Dimov [:vd]]

Note to committer: I have not tested this on all platforms. If Try can be used for B2G, then it would be nice to push there first.

Comment 41

[Ryan VanderMeulen [:RyanVM]]

John, can you assist with this checkin-needed request please?

Comment 42

[John Ford [:jhford] CET/CEST Berlin Time]

master: 91da030dd85cc56ce7b43a57600f9af24c104bbf

Comment 43

[Aki Sasaki (not active)]

This appears to have busted builds, since the manifest repos may not be synced to git.m.o yet.

Comment 44

[John Ford [:jhford] CET/CEST Berlin Time]

This change was backed out because the vcs syncing tool is not currently able to handle new repositories being added to the manifest without releng/it setup.

There is nothing that I know of that points to this code being a problem or broken, this is an infrastructural need to back out.

Backout commit: dccb04f190218a2dac3f552ac9fea84ddc976d8a

Comment 45

[John Ford [:jhford] CET/CEST Berlin Time]

Back on master
master: 141c8be