Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rename bazel/third_party/protobuf/3.2.0 #3486

Closed
abergmeier-dsfishlabs opened this issue Aug 1, 2017 · 2 comments
Closed

Rename bazel/third_party/protobuf/3.2.0 #3486

abergmeier-dsfishlabs opened this issue Aug 1, 2017 · 2 comments
Assignees
Labels
P3 We're not considering working on this, but happy to review a PR. (No assignee) type: bug

Comments

@abergmeier-dsfishlabs
Copy link
Contributor

Description of the problem / feature request / question:

At least as of 0.5.2, protobuf is >= 3.3.0 so please rename the directory.

Environment info

  • Bazel version (output of bazel info release): 0.5.2
@buchgr buchgr self-assigned this Aug 2, 2017
@buchgr buchgr added the P3 We're not considering working on this, but happy to review a PR. (No assignee) label Aug 2, 2017
@buchgr
Copy link
Contributor

buchgr commented Aug 2, 2017

It's true that we don't use 3.2.0. We use protobuf at a random commit + a custom patch. This patch has been merged into protobuf mainline a week ago and we can upgrade protobuf to the next release as soon as there is one.

bazel-io pushed a commit that referenced this issue Aug 4, 2017
#3486

BES and Remote Execution have separate implementations of gRPC channel
creation, authentication and TLS. We should merge them, to avoid
duplication and bugs. One such bug is #3640, where the BES code had a
different implementation for Google Application Default Credentials.

RELNOTES: The Build Event Service (BES) client now properly supports
Google Applicaton Default Credentials.
PiperOrigin-RevId: 164253879
buchgr added a commit that referenced this issue Aug 7, 2017
#3486

BES and Remote Execution have separate implementations of gRPC channel
creation, authentication and TLS. We should merge them, to avoid
duplication and bugs. One such bug is #3640, where the BES code had a
different implementation for Google Application Default Credentials.

RELNOTES: The Build Event Service (BES) client now properly supports
Google Applicaton Default Credentials.
PiperOrigin-RevId: 164253879
buchgr added a commit that referenced this issue Aug 11, 2017
#3486

BES and Remote Execution have separate implementations of gRPC channel
creation, authentication and TLS. We should merge them, to avoid
duplication and bugs. One such bug is #3640, where the BES code had a
different implementation for Google Application Default Credentials.

RELNOTES: The Build Event Service (BES) client now properly supports
Google Applicaton Default Credentials.
PiperOrigin-RevId: 164253879
buchgr added a commit that referenced this issue Aug 21, 2017
#3486

BES and Remote Execution have separate implementations of gRPC channel
creation, authentication and TLS. We should merge them, to avoid
duplication and bugs. One such bug is #3640, where the BES code had a
different implementation for Google Application Default Credentials.

RELNOTES: The Build Event Service (BES) client now properly supports
Google Applicaton Default Credentials.
PiperOrigin-RevId: 164253879
buchgr added a commit that referenced this issue Aug 22, 2017
#3486

BES and Remote Execution have separate implementations of gRPC channel
creation, authentication and TLS. We should merge them, to avoid
duplication and bugs. One such bug is #3640, where the BES code had a
different implementation for Google Application Default Credentials.

RELNOTES: The Build Event Service (BES) client now properly supports
Google Applicaton Default Credentials.
PiperOrigin-RevId: 164253879
bazel-io pushed a commit that referenced this issue Aug 25, 2017
Baseline: 6563b2d

Cherry picks:
   + d4fa181:
     Use getExecPathString when getting bash_main_file
   + 837e1b3:
     Windows, sh_bin. launcher: export runfiles envvars
   + fe9ba89:
     grpc: Consolidate gRPC code from BES and Remote Execution. Fixes
     #3460, #3486
   + e8d4366:
     Automated rollback of commit
     496d3de.
   + 242a434:
     bes,remote: update default auth scope.
   + 793b409:
     Windows, sh_bin. launcher: fix manifest path
   + 7e4fbbe:
     Add --windows_exe_launcher option
   + 91fb38e:
     remote_worker: Serialize fork() calls. Fixes #3356
   + b79a9fc:
     Quote python_path and launcher in
     python_stub_template_windows.txt
   + 4a2e17f:
     Add build_windows_jni.sh back
   + ce61d63:
     don't use methods and classes removed in upstream dx RELNOTES:
     update dexing tools to Android SDK 26.0.1
   + 5393a49:
     Make Bazel enforce requirement on build-tools 26.0.1 or later.
   + 5fac03570f80856c063c6019f5beb3bdc1672dee:
     Fix --verbose_failures w/ sandboxing to print the full command
     line
   + f7bd1acf1f96bb7e3e19edb9483d9e07eb5af070:
     Only patch in C++ compile features when they are not already
     defined in crosstool
   + d7f5c12:
     Bump python-gflags to 3.1.0, take two
   + 3cb136d:
     Add python to bazel's dockerfiles

New features:

  - Do not disable fully dynamic linking with ThinLTO when invoked
    via LIPO options.

Important changes:

  - Ignore --glibc in the Android transition.
  - Remove --experimental_android_use_singlejar_for_multidex.
  - nocopts now also filter copts
  - The Build Event Service (BES) client now properly supports
    Google Applicaton Default Credentials.
  - update dexing tools to Android SDK 26.0.1
  - Bazel Android support now requires build-tools 26.0.1 or later.
  - Fix a bug in the remote_worker that would at times make it crash on Linux. See #3356
  - The java_proto_library rule now supports generated sources. See #2265
@abergmeier-dsfishlabs
Copy link
Contributor Author

Seems like this was fixed in master.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P3 We're not considering working on this, but happy to review a PR. (No assignee) type: bug
Projects
None yet
Development

No branches or pull requests

3 participants