release v0.4.1 failing to compile on ubuntu 16.04 about deepvariant

[pichuan]

I tried it and I'm seeing it as well.
I wonder if this could be something outside DeepVariant. We'll take a closer look and get back to you later.

[pichuan]

This could be relevant. I'll give it a try and see.
tensorflow/tensorflow#15492 (comment)

[pichuan]

I can confirm that downgrading bazel to 0.8.1 as suggested in that comment worked for me.
Here's what I did to install an older version of bazel:

BAZEL_VERSION=0.8.1
wget https://github.com/bazelbuild/bazel/releases/download/"${BAZEL_VERSION}"/bazel-"${BAZEL_VERSION}"-installer-linux-x86_64.sh
chmod +x bazel-*.sh
./bazel-"${BAZEL_VERSION}"-installer-linux-x86_64.sh --user

Give this temporary solution a try and let me know if it works. We'll still need to fix this in a more principled way.

[pgrosu]

It might not hurt to install a Jenkins server - similar how the protobuf team does it - for continuous integration, as it also plays well with Github PRs and alleviates these simple headaches.

[david-wb]

Installing bazel 0.8.1 fixed the issue for me. It might be worth updating build-prereq.sh to install a specific version for bazel. Thanks a lot for the help

[scott7z]

The root cause here is that we are cloning a specific version of Tensorflow, while it (and other things) evolved to deal with the Bazel change. Normally, though, we don't want to just clone from TF HEAD because that can break us in other ways.

So a fix is to change settings.sh to use a more recent commit, like
export DV_TENSORFLOW_GIT_SHA="97a4c226e8a9e7c5c36fc38e2b9f8459c77abd5a"
(That compiles, but is otherwise untested.)

[pgrosu]

@scott7z Well, my feeling is that would be too much work, which could be fostered elsewhere. Unless there is a defined criteria for working off a specific revision, it is usually less of a benefit to be tied to a specific release. It'll also make the cost of supporting it too much of a headache, as the other dependencies will continue to evolve. I always prefer to simplify and feel it's more practical to push compliance of dependencies to their maintainers, while expanding on the fun part of adding community-driven features. For example, there over 1000 commits between the two SHAs, and it would be hard to keep track of so many contributions:

$ git log | grep commit | cat -n | grep '97a4c226e8a9e7c5c36fc38e2b9f8459c77abd5a\|ab0fcaceda001825654424bf18e8a8e0f8d39df2'
     1  commit 97a4c226e8a9e7c5c36fc38e2b9f8459c77abd5a
  1244  commit ab0fcaceda001825654424bf18e8a8e0f8d39df2
$

Usually more contributions to a dependency might provide us with more opportunities :)

[scott7z]

We pushed a change that pins bazel to 0.8.1. That should take care of things for now.