fetch fails

[cruise...@gmail.com]

When fetching all with this command:

bazel fetch //...

I get the errors below at different times. This happens with an empty WORKSPACE file and .bazelrc is the default from installation.

Any Ideas on what is causing this?

ERROR: /Users/erik/src/bazel/base_workspace/tools/j2objc/BUILD:10:1: no such package '@bazel-j2objc//': In new_http_archive rule //external:bazel-j2objc the 'build_file' attribute does not specify an existing file (/Users/erik/src/java/buck/third_party/java/j2objc/BUILD.remote does not exist) and referenced by '//tools/j2objc:j2objc'.

ERROR: /Users/erik/src/bazel/base_workspace/tools/build_defs/d/BUILD:18:1: no such package '@dmd-darwin-x86_64//': error loading package 'external': The repository named '@dmd-darwin-x86_64' could not be resolved and referenced by '//tools/build_defs/d:dmd'.

[Lukács T. Berki]

I think i know, although it's hard to tell without knowing what repository you run this in.

What probably happens is that you have a j2objc rule somewhere, but you didn't copy over the third_party directory from the Bazel source tree. Which is how it should work, except it doesn't. I just sent out an internal change. Should be fixed at HEAD within about a day.

--
You received this message because you are subscribed to the Google Groups "bazel-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bazel-discus...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/b66e7912-3cb6-4405-b2ca-7d66a022c9c1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Lukács T. Berki | Software Engineer | lbe...@google.com | 

Google Germany GmbH | Maximillianstr. 11-15 | 80539 München | Germany | Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle | Registergericht und -nummer: Hamburg, HRB 86891

[cruise...@gmail.com]

I'm not sure where that rule is coming from. This is occurring on a clean bazel master with an empty project. Also the error varies:

mkdir proj && cd proj && touch WORKSPACE && bazel fetch //...

ERROR: /Users/erik/src/bazel/base_workspace/tools/build_defs/d/BUILD:18:1: no such package '@dmd-darwin-x86_64//': error loading package 'external': The repository named '@dmd-darwin-x86_64' could not be resolved and referenced by '//tools/build_defs/d:dmd'.

[Thiago Farina]

On Mon, Oct 26, 2015 at 2:15 PM, <cruise...@gmail.com> wrote:

I'm not sure where that rule is coming from.   This is occurring on a clean bazel master with an empty project.  Also the error varies:

mkdir proj && cd proj && touch WORKSPACE && bazel fetch //...

ERROR: /Users/erik/src/bazel/base_workspace/tools/build_defs/d/BUILD:18:1: no such package '@dmd-darwin-x86_64//': error loading package 'external': The repository named '@dmd-darwin-x86_64' could not be resolved and referenced by '//tools/build_defs/d:dmd'.

I think I saw the same thing, but mine was with 'bazel build' (I also saw failures with 'closure'). Looks like you are running a version of bazel that you built from source? Mine was from the installer.

--

Thiago Farina

[Thiago Farina]

Yeah, just reproduced it:

$ bazel version

Build label: 0.1.0

Build target: bazel-out/local_linux-fastbuild/bin/src/main/java/bazel-main_deploy.jar

Build time: Tue Sep 8 23:08:34 2015 (1441753714)

Build timestamp: 1441753714

Build timestamp as int: 1441753714 

$ git clone https://github.com/kchodorow/tiny-workspace.git

$ cd tiny-workspace

$ bazel build //....

..........

WARNING: Sandboxed execution is not supported on your system and thus hermeticity of actions cannot be guaranteed. See http://bazel.io/docs/bazel-user-manual.html#sandboxing for more information. You can turn off this warning via --ignore_unsupported_sandboxing.

ERROR: /home/tfarina/.bazel/base_workspace/tools/build_defs/d/BUILD:42:1: no such package '@dmd-linux-x86_64//': error loading package 'external': The repository named '@dmd-linux-x86_64' could not be resolved and referenced by '//tools/build_defs/d:druntime-import-src'.

ERROR: Loading failed; build aborted.

INFO: Elapsed time: 4.641s

-- 

Thiago Farina

[Paul Kuliniewicz]

I see the same behavior with `bazel fetch //...` failing in `tiny-workspace` and other workspaces.  I've checked out release-0.1.2 to ~/bazel, then did `./compile.sh && output/bazel run //scripts/packages:install.sh -- --user` to install it.

Oddly, if I change ".bazel" to "bazel" in the ~/.bazelrc to have it use the base_workspace in the checkout, then I don't run into the problem.  These are apparently the differences between the two directories:

% diff -bur ~/.bazel/base_workspace ~/bazel/base_workspace

Only in /home/admin/bazel/base_workspace: examples

Only in /home/admin/bazel/base_workspace/third_party/ijar: test

Only in /home/admin/bazel/base_workspace/tools: android

Only in /home/admin/bazel/base_workspace/tools/build_defs/sass: test

Only in /home/admin/bazel/base_workspace/tools/build_defs/scala: test

Only in /home/admin/bazel/base_workspace/tools/build_rules/rust: test

diff -bur /home/admin/.bazel/base_workspace/tools/defaults/BUILD /home/admin/bazel/base_workspace/tools/defaults/BUILD

--- /home/admin/.bazel/base_workspace/tools/defaults/BUILD      1980-01-01 00:00:00.000000000 +0000

+++ /home/admin/bazel/base_workspace/tools/defaults/BUILD       2015-10-26 20:06:56.652000000 +0000

@@ -0,0 +1,2 @@

+# At runtime, a package is synthesized in memory that corresponds

+# the command-line flag settings.

Could this be an issue with the installer not setting ~/.bazel up correctly?

--

You received this message because you are subscribed to the Google Groups "bazel-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bazel-discus...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/CAFenBsb2a%3DWONzd0tX%3Dt-hGQUrrdyYfcDw0gUyu4ezogo7sX_g%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Paul Kuliniewicz

Security Engineer at Braintree

[Lukács T. Berki]

TL;DR: Use "bazel fetch -- //... -//tools/..." as a workaround for now.

Yuck, this is not good and is an ugly interaction between a recent bugfix I did and the fact that we still need to have the Skylark code in the main repository. John should finish that work Any Minute Now, and then this will go away.

The reason is that Bazel had a bug that made it not descend into symlinks when evaluating target patterns like //... . I fixed that, but a lot of Skylark languages require things in the WORKSPACE file to work, and thus, you can't simply load //... without additions to the WORKSPACE file. Until now, this hasn't been a problem because tools was a symlink and thus //... accidentally didn't descend into it, but now that that bug is fixed, "fetch //..." doesn't quite work.

I'll do the necessary tweaks to lay this issue to rest as soon as John changes that allow Skylark files not to be in the main repository are online.

[Thiago Farina]

On Tue, Oct 27, 2015 at 8:54 AM, Lukács T. Berki <lbe...@google.com> wrote:

TL;DR: Use "bazel fetch -- //... -//tools/..." as a workaround for now.

I'm still having problems. I have switched to Java 8 and Bazel 0.1.1.

 

$ cd ~/tiny-workspace

$ bazel fetch -- //... 

ERROR: /home/tfarina/.bazel/base_workspace/tools/build_defs/d/BUILD:18:1: no such package '@dmd-linux-x86_64//': error loading package 'external': The repository named '@dmd-linux-x86_64' could not be resolved and referenced by '//tools/build_defs/d:dmd'.

ERROR: /home/tfarina/.bazel/base_workspace/third_party/java/j2objc/BUILD:29:1: no such package '@bazel-j2objc//': In new_http_archive rule //external:bazel-j2objc the 'build_file' attribute does not specify an existing file (/home/tfarina/tiny-workspace/third_party/java/j2objc/BUILD.remote does not exist) and referenced by '//third_party/java/j2objc:annotations'.

ERROR: /home/tfarina/.bazel/base_workspace/third_party/java/j2objc/BUILD:34:1: no such package '@bazel-j2objc//': In new_http_archive rule //external:bazel-j2objc the 'build_file' attribute does not specify an existing file (/home/tfarina/tiny-workspace/third_party/java/j2objc/BUILD.remote does not exist) and referenced by '//third_party/java/j2objc:jre_emul_lib'.

ERROR: Evaluation of query "deps((//... union //tools/jdk:jdk))" failed: errors were encountered while computing transitive closure.

$ bazel version

Build label: 0.1.1

Build target: bazel-out/local_linux-fastbuild/bin/src/main/java/bazel-main_deploy.jar

Build time: Thu Oct 15 20:15:14 2015 (1444940114)

Build timestamp: 1444940114

Build timestamp as int: 1444940114

$ javac -version

javac 1.8.0_66

--

Thiago Farina

[Kristina Chodorow]

Specify -//tools/... and -//third_party/...

--

You received this message because you are subscribed to the Google Groups "bazel-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bazel-discus...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/CAFenBsb%3D_minCGircGyB1j%2BoOPr_eMBYqfYM4gLrCuuD8un1yQ%40mail.gmail.com.

[Thiago Farina]

On Wed, Oct 28, 2015 at 5:36 PM, Kristina Chodorow <kcho...@google.com> wrote:

Specify -//tools/... and -//third_party/...

Fails too, but with a different error:

$ bazel fetch -- //... -//tools/... -//third_party/...

ERROR: Error while parsing 'deps(//... union -//tools/... union -//third_party/... union //tools/jdk:jdk)': syntax error at '- //tools/... union' 

--

Thiago Farina

[mian.has...@gmail.com]

> ERROR: /Users/erik/src/bazel/base_workspace/tools/build_defs/d/BUILD:18:1: no such package '@dmd-darwin-x86_64//': error loading package 'external': The repository named '@dmd-darwin-x86_64' could not be resolved and referenced by '//tools/build_defs/d:dmd'.

This is definitely also happening to me. Any updates on a fix or workaround?

[Thiago Farina]

Lukács was able to work around this for me. He told me that this is known to fail due to some issues with external repository support and that John Field is working on it already.

The workaround is to use ':all' instead of "//..."

So the following now works (for future reference as it might help others that are having the same problem as me):

$ git clone https://github.com/kchodorow/tiny-workspace.git

$ cd tiny-workspace

$ bazel build :all

Thanks!

--

Thiago Farina

[Paul Gross]

This workaround doesn't seem to work at the top level of our project. We have a bunch of subdirectories each with their own BUILD file. At the top level:

% bazel build :all

INFO: Found 0 targets...

INFO: Elapsed time: 0.396s, Critical Path: 0.00s

% bazel query :all

INFO: Empty results

If I cd into one of them, then :all seems to work in that project.

Is there an ETA on the fix? For now, we have frozen our project at an old version of bazel so we can use //... to build everything.

Thanks,

Paul

--

You received this message because you are subscribed to the Google Groups "bazel-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bazel-discus...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/CAFenBsYU8%3DPvttUUemZxkztAHtz7XzXRb2bFJPJusPuovxmydw%40mail.gmail.com.

[Brian Silverman]

That workaround only gets the targets at the top level package, which is what you're seeing.

For now, I've got `bazel build //...` working by reverting b10157f88e8c2903d73712f0d5887b8b204d2bd9 and making sure nothing sets --package_path to include the bazel tools repository. Popular places for --package_path to be set are the ~/.bazelrc install.sh installs and /etc/bazel.bazelrc from the .deb package.

Still anxiously awaiting label-based loads though so I can undo that and also undo my psuedo-reverts to work around #429.

FYI, the relevant bugs for this issue I can find are #594 and #421. I remember a third one but I can't find it now...

To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/CAMXKpGAHKxZvPU22Fe8PR51%3DKM%3DvT%3DvrqVQP_gGvgfxG2frkWA%40mail.gmail.com.

[Damien Martin-guillerez]

Just a quick update on that one:

As soon as load statement using label is activated (because it is now using label under the hood thanks to John), we will remove every think from the package path.

Note that we could probably already remove everything from the package_path, Bazel default tooling is in the @bazel_tools local repository now.

To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/CAP01z6%2Bh%2BKZ3h%3DbGj7Y%2BEju%2BizDgis1gbNyfdh6w0VKYbsjtRw%40mail.gmail.com.

[Lukács T. Berki]

Actually, with Nathan's hack that allows one to blacklist a directory by adding a file called DONT_FOLLOW_SYMLINKS_WHEN_TRAVERSING_THIS_DIRECTORY_VIA_A_RECURSIVE_TARGET_PATTERN to it, we can make this work by adding that file to base_workspace/tools. Let me send out a quick CL so that I do at least some meaningful work today...