Protobuf 21.2

[ezzieyguywuf]

Note: Starting with
v21.0-rc1,
protobuf is using a new versioning scheme.

Signed-off-by: Wolfgang Sanyer [email protected]

• Have you followed the guidelines for contributing?
• Have you ensured that your commits follow the commit style guide?
• Have you checked that there aren't other open pull requests for the same formula update/change?
• Have you built your formula locally with brew install --build-from-source <formula>, where <formula> is the name of the formula you're submitting?
• Is your test running fine brew test <formula>, where <formula> is the name of the formula you're submitting?
• Does your build pass brew audit --strict <formula> (after doing brew install --build-from-source <formula>)? If this is a new formula, does it pass brew audit --new <formula>?

---

This is a duplicate of #105661, where I accidentally deleted my branch b/c I
thought the PR was merged - or rather, I accidentally deleted my branch and then
the PR was closed and then I thought the PR was merged.

[carlocab]

Btw, the extra commits are not unrelated. We need them to avoid breaking dependents when we ship the new version of protobuf.

[ezzieyguywuf]

Btw, the extra commits are not unrelated. We need them to avoid breaking dependents when we ship the new version of protobuf.

ah hah, yea I sort of deduced that but thanks for clarifying that for me.

[carlocab]

Rebased again. Forgot the CI-linux-self-hosted label.

[cho-m]

With new version scheme, do we know how upstream will update protobuf-all tarball when only a single language runtime is updated? Is it going to be modified in-place and trigger checksum issues in Homebrew?

If I understand correctly, the upstream's version scheme is to allow them to keep the same version (e.g. 21.2) while independently modifying a language version (e.g. update Python from 4.21.2 to 5.21.2).

---

On side note, this will hit same issue we saw in other PR #99843 (comment).

Upstream has closed issues related to this so might need to manually pass NDEBUG to dependents that use the particular header:

• ABI may depend on NDEBUG protocolbuffers/protobuf#9947
• Linking error when building with new 3.21.1 version protocolbuffers/protobuf#10163

[ezzieyguywuf]

With new version scheme, do we know how upstream will update protobuf-all tarball when only a single language runtime is updated? Is it going to be modified in-place and trigger checksum issues in Homebrew?

I imagine this would trigger a minor or patch version bump - from the news item

The minor and patch versions, however, will remain coupled

so even if only one language has a small tweak, all languages get a new release with a new sha.

You can see this (sort of) with the changes from v21.0 to v21.1. Note that although only the C++ and Python languages received changes (so two languages, not one like in your question), all languages received a version bump.

If I understand correctly, the upstream's version scheme is to allow them to keep the same version (e.g. 21.2) while independently modifying a language version (e.g. update Python from 4.21.2 to 5.21.2).

Yes I think you're understanding this correctly.

[carlocab]

Will need rebasing after #105756 is merged (leave that to me).

Failures in formulae modified here (let's ignore dependents for now):

All macOS

brew install --verbose --build-bottle protobuf-c
brew install --verbose --build-bottle bloaty
brew install --verbose --build-bottle libphonenumber
brew install --verbose --build-bottle mosh
brew install --build-from-source protobuf-c
brew install --only-dependencies --verbose --build-bottle netdata
brew install --verbose --build-bottle netdata
brew install --verbose --build-bottle percona-xtrabackup
brew test --verbose protoc-gen-grpc-web

And on Monterey (both ARM and Intel)

brew test --verbose ola

Linux

brew install --verbose --build-bottle libphonenumber
brew install --verbose --build-bottle percona-xtrabackup
brew test --verbose protoc-gen-grpc-web

---

percona-xtrabackup is a bug in the formula; it's installing files that conflict with percona-server. @Bo98, did you mention that you knew how to fix this?

Less sure about the rest. Presumably, a number of the --build-bottle failures will be fixed by passing -DNDEBUG.

[carlocab]

Formulae affected by the NDEBUG-dependent definition of ~InternalMetadata:

• protobuf-c
• bloaty
• mosh
• netdata
• ola

libphonenumber is erroring out with

  /tmp/libphonenumber-20220713-64831-eg9ry8/libphonenumber-8.12.44/_deps/abseil-cpp-src/absl/base/policy_checks.h:79:2: error: "C++ versions less than C++14 are not supported."
  #error "C++ versions less than C++14 are not supported."
   ^

Not sure what's going on with protoc-gen-grpc-web:

  ==>Testing protoc-gen-grpc-web
  ==>protoc test.proto --plugin=/usr/local/Cellar/protoc-gen-grpc-web/1.3.1_1/bin/protoc-gen-grpc-web --js_out=import_style=commonjs:. --grpc-web_out=import_style=typescript,mode=grpcwebtext:.
  protoc-gen-js: program not found or is not executable
  Please specify a program using absolute path or make sure the program is available in your PATH system variable
  --js_out: protoc-gen-js: Plugin failed with status code 1.

[cho-m]

Not sure what's going on with protoc-gen-grpc-web:

  ==>Testing protoc-gen-grpc-web
  ==>protoc test.proto --plugin=/usr/local/Cellar/protoc-gen-grpc-web/1.3.1_1/bin/protoc-gen-grpc-web --js_out=import_style=commonjs:. --grpc-web_out=import_style=typescript,mode=grpcwebtext:.
  protoc-gen-js: program not found or is not executable
  Please specify a program using absolute path or make sure the program is available in your PATH system variable
  --js_out: protoc-gen-js: Plugin failed with status code 1.

From grpc/grpc-web#1251, looks like protoc-gen-grpc-web may not work with current protobuf as upstream says to use 3.20.1 instead.

This PR may be blocked until we get a release for https://github.com/protocolbuffers/protobuf-javascript

[carlocab]

grpc/grpc-web#1251

This PR may be blocked until we get a release for https://github.com/protocolbuffers/protobuf-javascript

Looks like 3.20.1 isn't affected by this problem. We might want to consider updating to that in the meantime. I think that should be enough to unblock mobile-shell/mosh#1210, which seems to be what prompted this PR.

Or, does it make sense to add https://github.com/protocolbuffers/protobuf-javascript as a resource to protoc-gen-grpc-web? Or maybe even to protobuf?

[cho-m]

Looks like 3.20.1 isn't affected by this problem. We might want to consider updating to that in the meantime. I think that should be enough to unblock mobile-shell/mosh#1210, which seems to be what prompted this PR.

I guess one option is to finish #99843 (3.20.1) and then rebase this PR to continue 21.2 update. Most of failures in that PR are probably the same as what we see here.

---

Or, does it make sense to add https://github.com/protocolbuffers/protobuf-javascript as a resource to protoc-gen-grpc-web? Or maybe even to protobuf?

One related question is how many users would be impacted by missing Javascript functionality (as seen by users commenting in protobuf repo issue: protocolbuffers/protobuf-javascript#127).

New Javascript runtime repo is still showing version as 3.20.1 https://github.com/protocolbuffers/protobuf-javascript/blob/main/package.json#L3. Haven't actually checked on how it is supposed to be built/used.

[cho-m]

Based on last commit in repo (PR: protocolbuffers/protobuf-javascript#1), it doesn't seem possible to build yet.

[carlocab]

Based on last commit in repo (PR: protocolbuffers/protobuf-javascript#1), it doesn't seem possible to build yet.

...oh. That's unfortunate.

[carlocab]

ARM builds are green.

Also, we may want to migrate this to using CMake at some point:

protocolbuffers/protobuf#10209 (comment)
protocolbuffers/protobuf#9392 (comment)

[carlocab]

All builds are 🍏. Only dependent tests running on 11 and 12.

[carlocab]

It's a little weird that we need this, since I always thought that CMAKE_BUILD_TYPE=Release already added -DNDEBUG to C[XX]FLAGS.

It turns out that this is only true for CMAKE_C_FLAGS:

❯ cat CMakeLists.txt
cmake_minimum_required(VERSION 3.20)
project(flags C)
message(STATUS "CMAKE_C_FLAGS_RELEASE = ${CMAKE_C_FLAGS_RELEASE}")
message(STATUS "CMAKE_CXX_FLAGS_RELEASE = ${CMAKE_CXX_FLAGS_RELEASE}")
❯ cmake .
-- The C compiler identification is AppleClang 13.1.6.13160021
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /Library/Developer/CommandLineTools/usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- CMAKE_C_FLAGS_RELEASE = -O3 -DNDEBUG
-- CMAKE_CXX_FLAGS_RELEASE =
-- Configuring done
-- Generating done
-- Build files have been written to: /var/folders/kb/pf4wbfc512z47l56g5072l900000gn/T/tmp.KkoU3ADrCO

[carlocab]

Ah, no, it's definitely there:

❯ cat CMakeLists.txt
cmake_minimum_required(VERSION 3.20)
project(flags C CXX)
message(STATUS "CMAKE_C_FLAGS_RELEASE = ${CMAKE_C_FLAGS_RELEASE}")
message(STATUS "CMAKE_CXX_FLAGS_RELEASE = ${CMAKE_CXX_FLAGS_RELEASE}")
❯ cmake .
-- The C compiler identification is AppleClang 13.1.6.13160021
-- The CXX compiler identification is AppleClang 13.1.6.13160021
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /Library/Developer/CommandLineTools/usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /Library/Developer/CommandLineTools/usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- CMAKE_C_FLAGS_RELEASE = -O3 -DNDEBUG
-- CMAKE_CXX_FLAGS_RELEASE = -O3 -DNDEBUG
-- Configuring done
-- Generating done
-- Build files have been written to: /var/folders/kb/pf4wbfc512z47l56g5072l900000gn/T/tmp.KkoU3ADrCO

[BrewTestBot]

@carlocab has triggered a merge.

[ezzieyguywuf]

Thank you everyone who helped with this!