Closed Bug 831147 Opened 7 years ago Closed 7 years ago

Integrate apitrace into build

Categories

(Firefox OS Graveyard :: GonkIntegration, defect)

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: cjones, Assigned: vd)

References

(Blocks 1 open bug)

Details

(Whiteboard: [good first bug])

Attachments

(1 file, 9 obsolete files)

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
Whiteboard: [good first bug]
Pointer to Github pull-request
Attachment #717241 - Attachment mime type: text/plain → text/html
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?
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!
Attachment #719072 - Flags: review?(mwu)
Attachment #717241 - Flags: review?(mwu)
Attachment #717241 - Flags: review?(gsvelto)
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.
Attachment #717241 - Flags: review?(gsvelto) → review+
Attachment #719072 - Attachment is obsolete: true
Attachment #719072 - Flags: review?(mwu)
Attachment #721764 - Flags: review?(gsvelto)
Attachment #721764 - Attachment mime type: text/plain → text/html
Also install apitrace into /system/bin/apitrace and build out-of-source.
Attachment #721764 - Attachment is obsolete: true
Attachment #721764 - Flags: review?(gsvelto)
Attachment #722817 - Flags: review?(gsvelto)
Attachment #722817 - Attachment mime type: text/plain → text/html
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 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!
Attachment #722817 - Flags: review?(gsvelto) → review+
Install egltrace.so in /system/lib/apitrace/wrappers/ instead of /system/lib/
Attachment #722817 - Attachment is obsolete: true
Attachment #723380 - Flags: review+
Attachment #723380 - Attachment mime type: text/plain → text/html
Assignee: nobody → vd
Status: NEW → ASSIGNED
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.
(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?
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.
(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?
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.
Attachment #717241 - Attachment is obsolete: true
Attachment #723380 - Attachment is obsolete: true
Attachment #717241 - Flags: review?(mwu)
Attachment #727140 - Flags: review?(mwu)
Attachment #727140 - Flags: review?(gsvelto)
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?
(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?
(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.
Finally, I got this working. See https://github.com/vasild/apitrace/commit/91e28b53dfd47c683bf41c1b66e20eb540873686

Michael, what do you think?
Flags: needinfo?(mwu)
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!
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.
Flags: needinfo?(mwu)
Attachment #727140 - Attachment is obsolete: true
Attachment #727140 - Flags: review?(mwu)
Attachment #727140 - Flags: review?(gsvelto)
Attachment #740714 - Flags: review?(mwu)
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).
Merged. Thanks!
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Attachment #740714 - Flags: review?(mwu) → review+
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.
I filed "Bug 865282 - Mirror github.com/apitrace/apitrace to git.m.o" in order to get that problem resolved.
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
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
No longer blocks: 868263
Depends on: 868263
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.
Attachment #745997 - Flags: review?(mwu)
Now that bug 868263 has been resolved, is this ready to land again?
(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.
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.
Attachment #740714 - Attachment is obsolete: true
Attachment #747929 - Flags: review?(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?
Why not just fail configure.in with a helpful error message if --enable-apitrace or whatever is specified and cmake cannot be found?
(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 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.
Attachment #747929 - Flags: review?(mwu) → review+
Comment on attachment 754252 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/b2g-manifest/pull/77

review+ on behalf of mwu
Attachment #754252 - Flags: review+
Keywords: checkin-needed
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.
John, can you assist with this checkin-needed request please?
Flags: needinfo?(jhford)
master: 91da030dd85cc56ce7b43a57600f9af24c104bbf
Status: REOPENED → RESOLVED
Closed: 7 years ago7 years ago
Flags: needinfo?(jhford)
Keywords: checkin-needed
Resolution: --- → FIXED
This appears to have busted builds, since the manifest repos may not be synced to git.m.o yet.
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
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Back on master
master: 141c8be
Status: REOPENED → RESOLVED
Closed: 7 years ago7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.