-
Notifications
You must be signed in to change notification settings - Fork 10.4k
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
First cut of Debian packaging #1696
Conversation
This is a faithful representation of the current version of the Google Doc with only formatting changes.
For example, whereas previously we'd have GRPC_LAT_PROF 1986206380734.095703 0x7f0b4bff7700 { 200 (nil) src/core/iomgr/tcp_posix.c 337 now we have: GRPC_LAT_PROF 1986206380734.095703 0x7f0b4bff7700 { 200(GRPC_PTAG_HANDLE_READ) (nil) src/core/iomgr/tcp_posix.c 337 Note the literal enum name in parenthesis following the tag int value.
docker images to do interop testing before submitting code c++ and java are done previously, adding ruby and node. see script tools/gce_setup/private_build_and_test.sh
Still missing: retrieving prefix from file option.
Port fling_test to it. This will be used to: - port remaining tests to Windows - enable testing what happens when servers or clients mysteriously disappear
The prefix has still to be applied per-message, and we could do forward-declarations in the generated header.
Android Dockerfile for integration test
…g-with-tls GPR_ASSERT is not an expression
…-crash Add subprocess GPR API
Source: grpc | ||
Priority: optional | ||
Maintainer: Andrew Pollock <apollock@debian.org> | ||
Build-Depends: debhelper (>= 9), zlib1g-dev, libssl-dev, libprotobuf-dev, protobuf-compiler, libgflags-dev, autoconf, automake, libtool, libgtest-dev, libgoogle-perftools-dev |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We technically don't depend on autoconf / automake / libtool for the grpc package directly. This is for building protobuf.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We technically don't depend on autoconf / automake / libtool for the grpc package directly. This is for building protobuf.
Okay I'll take them back out. I would have put them in when I was trying to build extra bits from third_party
Add missing copyright notices
…podspec Point sample app to official protobuf podspec
nullptr->shared_ptr typecast for gcc 4.4
Split gcov c/c++ into separate runs
I'd been advised to keep the "debian" directory in its own branch, i.e. "debian/sid". That way if any Ubuntu-specific modifications are required, they could go in an "ubuntu" branch. Similarly, if we have to make changes (and we will) for additional binary packages for experimental, they could live in an "experimental/sid" branch. These branches could be excluded from any tarball releases, so the packaging metadata isn't in them. Does that clarify things? |
I think I've done the necessary things to indicate that I'm a Googler, but I'm not entirely sure. |
CLAs look good, thanks! |
Let's fix this before everybody hates me.
Fix typo in README commands to compile protos!
chttp2_fake_security_invoke_large_request_test is failing consistently and I don't know why yet
László is another DD who was independently working on packaging grpc, so he can pool his efforts here. Some build-deps were added when I was trying to build protobuf3 from third_party, but they're not needed
Add two more AVD for api level 21 and 19.
Replaced std::this_thread::sleep_for for gpr_sleep_until.
I see. That makes sense. That'll cause some maintenance burden, but that's necessary. About the "failing test" commit, we do have known tests right now that are indeed failing. We can probably do a change in the Makefile to alter the notion of "make test" to only reflect that, and then have "make flaky_test" actually be the one that runs the known problematic tests. |
Also, I have created a "grpc:debian/sid" branch, so you can alter your pull request to point it there instead of grpc:master. |
Thanks for your pull request. It looks like this may be your first contribution to a Google open source project, in which case you'll need to sign a Contributor License Agreement (CLA). 📝 Please visit https://cla.developers.google.com/ to sign. Once you've signed, please reply here (e.g.
|
I'm not sure how to change the branch target, so I'll close this PR and make a new one. |
Hi,
Please find my first cut of the Debian packaging. I suggest it lives in a separate branch from the grpc code for simplicity's sake. The package builds cleanly and Lintian is happy.
This is for #662