Ubuntu Vivid Vervet - missing required package (openjdk-8-source) about bazel HOT 20 CLOSED

Assigning to kchodorow, although it's a bit strange becayse src.zip is not referenced in jdk.BUILD.

Once that strangeness is taken care of (probably my ignorance), all this needs at most is a change in the installation instructions.

from bazel.

if we have a dependency on "bc" we should remove that dependency

from bazel.

How do you do floating point addition in a shell script? The bc dependency comes from the shell test framework. It is used to compute test durations

from bazel.

ugh. we'll have to add bc to the install instructions then.

from bazel.

Do we really need to use Python's time.time()? Why not just use http://stackoverflow.com/questions/16548528/linux-command-to-get-time-in-milliseconds and then $((end-start)) in unittest.bash?

from bazel.

Because it does not work on OSX :(

On Wed, Apr 15, 2015 at 4:04 PM Kristina [email protected] wrote:

Do we really need to use Python's time.time()? Why not just use
http://stackoverflow.com/questions/16548528/linux-command-to-get-time-in-milliseconds
and then $((end-start)) in unittest.bash?

—
Reply to this email directly or view it on GitHub
#69 (comment).

from bazel.

I mean date does not provide below seconds precision on OSX.

On Wed, Apr 15, 2015 at 4:06 PM Damien Martin-guillerez [email protected]
wrote:

Because it does not work on OSX :(

On Wed, Apr 15, 2015 at 4:04 PM Kristina [email protected] wrote:

Do we really need to use Python's time.time()? Why not just use
http://stackoverflow.com/questions/16548528/linux-command-to-get-time-in-milliseconds
and then $((end-start)) in unittest.bash?

—
Reply to this email directly or view it on GitHub
#69 (comment).

from bazel.

Okay, but Python does and we could turn the fp date it gives into an int.

from bazel.

Right you mean to get read of the bc operator. SGTM

On Wed, Apr 15, 2015 at 4:11 PM Kristina [email protected] wrote:

Okay, but Python does and we could turn the fp date it gives into an int.

—
Reply to this email directly or view it on GitHub
#69 (comment).

from bazel.

The bc dependency has been fixed and I don't think we reference src.zip anymore. Feel free to reopen if this is still broken for you.

from bazel.

I ran into the this issue on Debian 8. As suggested in the initial report, installing openjdk-8-source fixed it.

Creating Bazel self-extracting archive...
Creating a .bazelrc pointing to /home/kamal/clones/bazel/base_workspace
Extracting Bazel installation...
.......
ERROR: /home/kamal/clones/bazel/tools/jdk/BUILD:55:1: no such package 'external': Could not access /home/kamal/.cache/bazel/_bazel_kamal/e506a03857a30434de2ae69da1f93613/external/local-jdk/src.zip: /usr/lib/jvm/
openjdk-8 (No such file or directory) and referenced by '//tools/jdk:jdk'.
ERROR: /home/kamal/.cache/bazel/_bazel_kamal/install/09a5a19f6a3b956ceced818dfdee555e/_embedded_binaries/jdk.WORKSPACE:45:1: no such package 'external': Could not access /home/kamal/.cache/bazel/_bazel_kamal/e50
6a03857a30434de2ae69da1f93613/external/local-jdk/src.zip: /usr/lib/jvm/openjdk-8 (No such file or directory) and referenced by '//external:jdk-default'.
ERROR: /home/kamal/.cache/bazel/_bazel_kamal/install/09a5a19f6a3b956ceced818dfdee555e/_embedded_binaries/jdk.WORKSPACE:17:1: no such package 'external': Could not access /home/kamal/.cache/bazel/_bazel_kamal/e50
6a03857a30434de2ae69da1f93613/external/local-jdk/src.zip: /usr/lib/jvm/openjdk-8 (No such file or directory) and referenced by '//external:langtools'.
ERROR: Evaluation of query "deps((//... union //tools/jdk:jdk))" failed: errors were encountered while computing transitive closure.

from bazel.

I can confirm that Debian 8 also needs the openjdk-8-source package, due to the "src.zip" dependency. Reproduced in a Debian 8.1 64-bit VM.

Should we just add that to the docs?

from bazel.

Do we know what's depending on src.zip? We shouldn't need it.

from bazel.

+1

Also apparently we will need the ErrorProne Javac when we will ship Error Prone so we might as well drop the requirements for Java 8 if we do so.

from bazel.

0bf90f7 This commit should have removed the requirement. To be confirmed.

from bazel.

Even with this commit, the issue is still present on Debian 8.1 with openjdk-8-jdk installed, but not openjdk-8-source. Damien and I had a look at it and it looks like Debian ships a broken symlink in the package:

root@debian64:/usr/lib/jvm/java-8-openjdk-amd64# ls -l
total 20
lrwxrwxrwx 1 root root 22 May 19 15:44 ASSEMBLY_EXCEPTION -> jre/ASSEMBLY_EXCEPTION
drwxr-xr-x 2 root root 4096 Jun 11 13:29 bin
lrwxrwxrwx 1 root root 41 May 19 15:44 docs -> ../../../share/doc/openjdk-8-jre-headless
drwxr-xr-x 3 root root 4096 Jun 11 13:29 include
drwxr-xr-x 5 root root 4096 Jun 11 13:29 jre
drwxr-xr-x 3 root root 4096 Jun 11 13:29 lib
drwxr-xr-x 4 root root 4096 Jun 11 13:29 man
lrwxrwxrwx 1 root root 20 May 19 15:44 src.zip -> ../openjdk-8/src.zip
lrwxrwxrwx 1 root root 22 May 19 15:44 THIRD_PARTY_README -> jre/THIRD_PARTY_README

The src.zip symlink goes to ../openjdk-8/src.zip, which doesn't exist (it is part of the openjdk-8-source package).

The error message that I'm getting is this:

philwo@debian64:~/bazel$ ./compile.sh
INFO: You can skip this first step by providing a path to the bazel binary as second argument:
INFO: ./compile.sh build /path/to/bazel
🍃 Building Bazel from scratch...........
🍃 Building Bazel with Bazel.
.Extracting Bazel installation...
Sending SIGTERM to previous Bazel server (pid=2324)... done.
.....
ERROR: /home/philwo/bazel/tools/jdk/BUILD:65:1: no such package 'external': Could not access /home/philwo/.cache/bazel/_bazel_philwo/a69a55589c8b323f8b4d3b42a9bb5861/external/local-jdk/src.zip: /usr/lib/jvm/openjdk-8 (No such file or directory) and referenced by '//tools/jdk:jdk'.
ERROR: Loading failed; build aborted.
INFO: Elapsed time: 0.451s

Maybe we are globbing somewhere in the external repo code and it trips over the broken symlink?

from bazel.

The only glob I see is bin/*, which doesn't have any symlinks on my install (https://github.com/google/bazel/blob/5fe79331f9160ae8b37f907ddbaa5f080dfc8185/src/main/tools/jdk.BUILD and https://github.com/google/bazel/blob/5fe79331f9160ae8b37f907ddbaa5f080dfc8185/src/main/tools/jdk.WORKSPACE are the external repo code).

from bazel.

Yes but there is a reference from //tools/jdk/jdk to /usr/lib/jvm/java-8-openjdk-amd64/src.zip (probably on everything from the java home dir). It is probably under the magic of the local_repository (symlinks?). Anyway I don't think we should try to fix that one right now except fix the documentation. It is a really weird corner case and we have other priorities.

from bazel.

Oh, yeah, maybe here (if anyone wants to work on this).

from bazel.

Git HEAD doesn't suffer from the dangling "src.zip" symlink although it is still created. This issue can probably be closed now.

from bazel.