Klaus Aehlig

Results 11 comments of Klaus Aehlig

> @aehlig @dslomov, your take? As you already know, I think collecting "all repositories of a kind" via `native.existing_rules()` is fine. What I'm worried about is the use of random...

As discussed, this is https://bazel-review.googlesource.com/c/bazel/+/48030 adapted to be be a skylib module. Unfortunately, I don't know how to add a test in this setting. The key property of this function...

I guess, if we allow `native.bazel_version` at all, we can as well allow it everywhere, as the [work around](https://github.com/haberman/upb/blob/bazel25/repository_defs.bzl) you use, the value is available anyway. However, before we encourage...

> You might be able to already achieve that by having some kind of separate cache that can map between Git SHA-1 and a hash function of choice, right? Whenever...

> > I wonder if we could handle git support a bit differently. For example, it's not common to store/transfer git objects (Tree or Blob) one by one. Instead, objects...

> I think @aehlig solved this problem for the repository cache. Maybe you can borrow his implementation here as well. @ittaiz, what solution are you talking about? What we have...

> Works locally on some machines. Some remarks: - At least on our CI, it seems to coincide with the java version (the older one, running on ubuntu 14.04, causing...

The error happens before RunCommand does anything. printf-debugging with the following diff ``` diff --git a/src/main/java/com/google/devtools/build/lib/runtime/commands/RunCommand.java b/src/main/java/com/google/devtools/build/lib/runtime/commands/RunCommand.java index 26dda27..e3d761f 100644 --- a/src/main/java/com/google/devtools/build/lib/runtime/commands/RunCommand.java +++ b/src/main/java/com/google/devtools/build/lib/runtime/commands/RunCommand.java @@ -14,6 +14,10 @@ package com.google.devtools.build.lib.runtime.commands;...

Further printf-debugging shows that the problem is in the way bazel is started. - In src/main/cpp/blaze_util_posix.cc b/src/main/cpp/blaze_util_posix.cc argv[n-1] consists of the octets c3 a4 c3 b6 c3 bc c3 84...

OK, so adding ``` setenv("LANG", "en_US.UTF-8", 1); setenv("LC_ALL", "en_US.UTF-8", 1); ``` in front of the the execv in src/main/cpp/blaze_util_posix.cc (and including ) the java invocation gets the arguments without information...