bazel: 0.24.0 -> 0.26.0 #62336

groodt · 2019-06-01T01:49:55Z

Motivation for this change

A few new versions of Bazel have been released. This bumps to 0.26.1 to stay recent.

Things done

matthewbauer · 2019-06-01T01:54:24Z

groodt · 2019-06-01T04:28:32Z

My local Darwin build error is:

In file included from src/main/cpp/blaze_util_darwin.cc:24:
/nix/store/mffyf74zc4h2wic5lwx0kyx7gvwif0c5-Libsystem-osx-10.12.6/include/pthread/spawn.h:65:34: error: unknown type name 'qos_class_t'; did you mean 'au_class_t'?
                                 qos_class_t __qos_class);
                                 ^
/nix/store/mffyf74zc4h2wic5lwx0kyx7gvwif0c5-Libsystem-osx-10.12.6/include/bsm/audit.h:176:19: note: 'au_class_t' declared here
typedef u_int32_t       au_class_t;
                        ^
In file included from src/main/cpp/blaze_util_darwin.cc:24:
/nix/store/mffyf74zc4h2wic5lwx0kyx7gvwif0c5-Libsystem-osx-10.12.6/include/pthread/spawn.h:88:34: error: unknown type name 'qos_class_t'; did you mean 'au_class_t'?
                                 qos_class_t * __restrict __qos_class);
                                 ^
/nix/store/mffyf74zc4h2wic5lwx0kyx7gvwif0c5-Libsystem-osx-10.12.6/include/bsm/audit.h:176:19: note: 'au_class_t' declared here
typedef u_int32_t       au_class_t;
                        ^
2 errors generated.

groodt · 2019-06-02T01:36:04Z

My local linux build succeeds, but tests are failing with:

src/main/tools/process-wrapper-legacy.cc:58: "execvp(external/remote_java_tools_linux/java_tools/ijar/ijar, ...)": No such file or directory

uri-canva · 2019-06-02T07:15:47Z

Here's a fix for the Darwin issue:

diff --git a/pkgs/development/tools/build-managers/bazel/default.nix b/pkgs/development/tools/build-managers/bazel/default.nix
index 3b23ca395e8..3a880541228 100644
--- a/pkgs/development/tools/build-managers/bazel/default.nix
+++ b/pkgs/development/tools/build-managers/bazel/default.nix
@@ -160,6 +160,9 @@ stdenv.mkDerivation rec {
         src/tools/xcode/realpath/BUILD \
         src/tools/xcode/stdredirect/BUILD \
         tools/osx/BUILD
+
+      # nixpkgs's libSystem cannot user pthread headers directly, must import GCD headers instead
+      sed -i -e "/#include <pthread\/spawn.h>/i #include <dispatch/dispatch.h>" src/main/cpp/blaze_util_darwin.cc

       # clang installed from Xcode has a compatibility wrapper that forwards
       # invocations of gcc to clang, but vanilla clang doesn't

groodt · 2019-06-02T07:24:06Z

Legend! Thanks @uri-canva I'll kick off a local test now. I think I'll have to fetch the java_tools_javac10_darwin-v3.1.zip as well.

I think I understand what is happening during the installCheckPhase. I've got it working if I build on Linux without Nix. Bazel downloads java_tools_javac10_linux-v3.1.zip when building the interface jars for junit4 used in the tests.

This is failing under Nix. I'm not 100% clear on how or if this should be fixed. I wonder if the whole approach to these tests may fail, given that Bazel can fetch rules remotely.

Lassulus · 2019-06-02T08:21:58Z

@GrahamcOfBorg build bazel

groodt · 2019-06-02T08:40:13Z

Success on Darwin, failure on Linux. Must be a first! 😂

I'm looking into the Linux errors. I didn't have sandbox enabled locally, so I'll do that for Linux which will hopefully help track down errors.

matthewbauer · 2019-06-03T01:10:30Z

@uri-canva Thanks! Opened this issue to track what's going on: #62555

groodt · 2019-06-03T01:53:15Z

@matthewbauer Any chance you can kick off another build. Linux only. I'm unable to run sandboxed builds in a Docker container at the moment. I've fixed the previous error with rules_sass in f1a511a

uri-canva · 2019-06-03T06:09:10Z

I suspect the Bazel tests fail on Linux because of the network sandboxing. The way the building of the tests should be done to account for that is the same way buildBazelPackage does it: first run bazel fetch as a fixed output derivation with networking enabled, then run bazel test with networking disabled.

We could rewrite the whole derivation to split it in two: first build the bootstrap bazel, then use boostrap bazel with buildBazelPackage to build and test Bazel. That also mirrors what compile.sh does.

It's a lot of work though, we might want to skip the tests on Linux in the meantime.

groodt · 2019-06-03T11:22:20Z

@Profpatsch This is now ready for review. Please kick off a build to confirm.

I expect it to pass on Darwin. Fail on Linux. I'm able to reproduce the Linux failure on my local VM.

groodt · 2019-06-03T11:27:12Z

We could rewrite the whole derivation to split it in two: first build the bootstrap bazel, then use boostrap bazel with buildBazelPackage to build and test Bazel. That also mirrors what compile.sh does.

Yes, I think given the way Bazel works, this is the only sensible solution. I think I understand what is necessary. Will that second inside buildBazelPackage be cached in the Nix store?

uri-canva · 2019-06-03T12:18:31Z

Yes, the deps derivation is separate from the build derivation and they get cached separately.

Profpatsch · 2019-06-03T12:50:53Z

So we’re skipping 0.25 alltogether? #61097

groodt · 2019-06-03T21:40:34Z

So we’re skipping 0.25 alltogether? #61097

The Bazel release cycle is too frequent to do 1:1 Nix releases. I certainly don't have time to do it. The functionality I want is in 0.26. In a week or 2 there will 0.27....

Profpatsch · 2019-06-04T10:15:37Z

@GrahamcOfBorg build bazel.tests

Profpatsch · 2019-06-04T11:02:05Z

The linux test fails.

groodt · 2019-06-04T11:14:44Z

The linux test fails.

@Profpatsch Yes, thanks, it is expected. We just wanted to confirm if it fails on CI with the same error as we get locally. It does, so that's great, we can hopefully fix it.

The failure is due to the sandbox blocking network access during the tests. Bazel isn't very good to test in this way, as rules can go and download other rules at runtime. What are your thoughts to fixing it?

Profpatsch · 2019-06-04T11:43:42Z

What are your thoughts to fixing it?

By now I’m tempted to disable the checkPhase (doCheck = false;) and rely on the manual tests we run afterwards. We can’t keep up with their (shitty) WORKSPACE stuff, they don’t really care about other build systems.

Profpatsch · 2019-06-04T12:50:03Z

The problem now is that the fetch arbitrary binaries (external/remote_java_tools_linux/java_tools/ijar/ijar) and try to execute them, we must patch those first or add their dependencies to the test environment.

uri-canva · 2019-06-04T14:29:34Z

The java tools currently live here: https://github.com/bazelbuild/bazel/tree/master/src/java_tools, but they'll move them to https://github.com/bazelbuild/java_tools eventually. We can build them from source in the nix derivation using the bootstrap bazel that should be possible to build without network access.

uri-canva · 2019-06-04T14:30:25Z

Sorry I'm just commenting and not helping much on the PR this time, I don't have enough time to dedicate to it at the moment.

uri-canva · 2019-06-04T14:32:51Z

We can also patch out some of the remote files as long as we delete the references to them: I cannot believe the rules_sass and rules_nodejs are needed for building Bazel itself, they're probably used to render the documentation.

groodt · 2019-06-05T23:17:19Z

@Profpatsch

By now I’m tempted to disable the checkPhase (doCheck = false;) and rely on the manual tests we run afterwards.

I agree that this is the best course of action for now. PR updated to reflect this. Passing locally on my Linux VM.

I'll try to find some time to submit an additional PR to change the approach of the Bazel derivation as @uri-canva is suggesting.

groodt · 2019-06-12T00:38:46Z

Great! Seems to have passed. I'll try a quick bump to 0.26.1 sometime today.

groodt · 2019-06-12T05:54:09Z

The build works locally for me on Darwin (no sandbox) and a NixOS VM (sandbox = true).

I'll update the title, description and squash the commits.

Profpatsch · 2019-06-12T11:06:24Z

Is it okay if we leave the commits as-is? I’d only squash in the fixup commits (git rebase --autosquash).

groodt · 2019-06-12T11:52:49Z

Is it okay if we leave the commits as-is? I’d only squash in the fixup commits (git rebase --autosquash).

Apologies, I think I'm too late and I've squashed it all down. In some of my other nixpkgs contributions, the reviewer was particular that I squashed everything down into a single commit with a particular commit message. Maybe that's not standard across the whole repo or is more nuanced and can be more than a single commit.

Profpatsch · 2019-06-12T12:06:50Z

Normally multiple commits for separate changes are not a problem. I’ll force-push the split commits.

`py_test` tries to download unnecessary dependencies at runtime. We can just as well run it to check the assertion. Upstream issue: bazelbuild/bazel#8575

Factor out the common parts of tests & cache the bazel self-extraction (ugh) to a common store path.

xe is such a trivial package, it should build on every platform that supports a CC compiler.

Profpatsch · 2019-06-12T12:11:50Z

Okay, I rebased to master & autosquashed the fixup commits. Will merge once it’s green again.

Profpatsch · 2019-06-12T12:54:46Z

Ah, I’m sorry, I didn’t see the bump to 0.26.1. Meh, can you push the diff as a separate PR?

kalbasit · 2019-06-12T15:48:48Z

I'm putting a quick PR together for 0.26.1.

EDIT: #63038

groodt · 2019-06-12T22:27:14Z

Thanks @Profpatsch @kalbasit

timokau · 2019-06-20T17:57:19Z

I just noticed that this changed the hash of the fetch phase of dm-sonnet. We probably have to be more careful with bazel updates in the future if we're using it in fixed output derivations.

Profpatsch · 2019-06-21T11:22:44Z

I just noticed that this changed the hash of the fetch phase of dm-sonnet. We probably have to be more careful with bazel updates in the future if we're using it in fixed output derivations.

Uuuuuuuuuuuuuuugh, I suggest we just don’t.

@timokau But for the while being, can you add a tests.downstreamPackages = { inherit <list of packages that use fetchbazel>; }?

timokau · 2019-06-21T12:45:32Z

Don't do what? Don't be careful seems like a bad idea to me ;) And we're already using it in fixed output derivations, I don't see how we could avoid that when building bazel packages.

Would that actually help? Since they're fixed output, they will just be fetched from the binary cache and therefore pass the tests even though they're broken.

kalbasit · 2019-06-22T02:51:51Z

@timokau you can probably override one of the phases of the fetcher to invalidate it's input, and force it to compile. Something like echo ${version} should do.

timokau · 2019-06-22T08:34:34Z

Interesting idea! I feel like there is a bit of a "just because you can doesn't mean that you should" going on here, but here we go: #63645

I have created a separate attribute for the derivation instead of a list, because a list wouldn't get built with nix-build -A bazel.test.

Profpatsch · 2019-06-22T10:30:45Z

Don't do what? Don't be careful seems like a bad idea to me ;) And we're already using it in fixed output derivations, I don't see how we could avoid that when building bazel packages.

Don’t ever use fixed output derivations.

timokau · 2019-06-22T11:26:57Z

How else should we fetch bazel dependencies?

I'd expect the fetch output to become deterministic between releases once bazel is stable. If it still isn't, we can look into how they differ between releases and clean up the fetch result accordingly (similar to what we do with fetchpatch).

Profpatsch · 2019-06-22T11:41:47Z

How else should we fetch bazel dependencies?

We do it like with all other (well-behaved) package managers and generate nix expressions for WORKSPACE dependencies. I already wrote a mockup hack for updating bazel proper: https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/tools/build-managers/bazel/update-srcDeps.py
But really, bazel devs should pull the stick out of their asses, provide a reasonable interface and become a nice player in the open source world.

uri-canva · 2019-06-22T13:07:51Z

Yeah Bazel is really really biased towards monorepos with full vendoring.

I think something good integration-wise can be done with resolved workspaces and provided external repositories, but both mechanisms are very much in their infancy and it's unclear how well supported they are:

https://blog.bazel.build/2018/07/09/bazel-sync-and-resolved-file.html
bazelbuild/bazel#5252

Profpatsch · 2019-06-24T14:22:17Z

Ah, yes, that’s the better way tbh. It’s a skylark file, so we should be able to cheat our way by evaling it in a python interpreter.

ofborg bot added 10.rebuild-darwin: 1-10 10.rebuild-linux: 1-10 labels Jun 1, 2019

groodt marked this pull request as ready for review June 2, 2019 01:41

groodt requested a review from Profpatsch as a code owner June 2, 2019 01:41

groodt force-pushed the bazel-0.26.0 branch from 7b6248b to b3abbe4 Compare June 5, 2019 23:14

kalbasit mentioned this pull request Jun 6, 2019

bazel: 0.24.0 -> 0.25.1 #61097

Closed

10 tasks

groodt changed the title ~~bazel: 0.24.0 -> 0.26.0~~ bazel: 0.24.0 -> 0.26.1 Jun 12, 2019

groodt force-pushed the bazel-0.26.0 branch from 302a35f to a079bfb Compare June 12, 2019 06:00

groodt and others added 5 commits June 12, 2019 14:09

bazel: 0.24.0 -> 0.26.0

dd2a0f6

bazel: move the python test to py_binary

44f97b5

`py_test` tries to download unnecessary dependencies at runtime. We can just as well run it to check the assertion. Upstream issue: bazelbuild/bazel#8575

bazel.tests: prebuild the bazel self-extraction to speed up test

629c050

Factor out the common parts of tests & cache the bazel self-extraction (ugh) to a common store path.

bazel: run the tests on all supported platforms

5d238e4

xe: platforms.linux -> platforms.all

7bae5c6

xe is such a trivial package, it should build on every platform that supports a CC compiler.

Profpatsch force-pushed the bazel-0.26.0 branch from a079bfb to 7bae5c6 Compare June 12, 2019 12:10

Profpatsch merged commit cc62736 into NixOS:master Jun 12, 2019

Profpatsch changed the title ~~bazel: 0.24.0 -> 0.26.1~~ bazel: 0.24.0 -> 0.26.0 Jun 12, 2019

timokau mentioned this pull request Jun 20, 2019

python.pkgs.dm-sonnet: update bazel fetch hash #63587

Merged

10 tasks

bazel: 0.24.0 -> 0.26.0 #62336

bazel: 0.24.0 -> 0.26.0 #62336

Conversation

groodt commented Jun 1, 2019 • edited Loading

Motivation for this change

Things done

matthewbauer commented Jun 1, 2019

groodt commented Jun 1, 2019 • edited Loading

groodt commented Jun 2, 2019 • edited Loading

uri-canva commented Jun 2, 2019 • edited Loading

groodt commented Jun 2, 2019

Lassulus commented Jun 2, 2019

groodt commented Jun 2, 2019

matthewbauer commented Jun 3, 2019

groodt commented Jun 3, 2019

uri-canva commented Jun 3, 2019 • edited Loading

groodt commented Jun 3, 2019

groodt commented Jun 3, 2019

uri-canva commented Jun 3, 2019

Profpatsch commented Jun 3, 2019

groodt commented Jun 3, 2019

Profpatsch commented Jun 4, 2019

Profpatsch commented Jun 4, 2019

groodt commented Jun 4, 2019

Profpatsch commented Jun 4, 2019

Profpatsch commented Jun 4, 2019

uri-canva commented Jun 4, 2019

uri-canva commented Jun 4, 2019

uri-canva commented Jun 4, 2019

groodt commented Jun 5, 2019

groodt commented Jun 12, 2019

groodt commented Jun 12, 2019

Profpatsch commented Jun 12, 2019

groodt commented Jun 12, 2019

Profpatsch commented Jun 12, 2019

Profpatsch commented Jun 12, 2019

Profpatsch commented Jun 12, 2019 • edited Loading

kalbasit commented Jun 12, 2019 • edited Loading

groodt commented Jun 12, 2019

timokau commented Jun 20, 2019

Profpatsch commented Jun 21, 2019

timokau commented Jun 21, 2019

kalbasit commented Jun 22, 2019

timokau commented Jun 22, 2019

Profpatsch commented Jun 22, 2019

timokau commented Jun 22, 2019

Profpatsch commented Jun 22, 2019

uri-canva commented Jun 22, 2019

Profpatsch commented Jun 24, 2019

groodt commented Jun 1, 2019 •

edited

Loading

groodt commented Jun 1, 2019 •

edited

Loading

groodt commented Jun 2, 2019 •

edited

Loading

uri-canva commented Jun 2, 2019 •

edited

Loading

uri-canva commented Jun 3, 2019 •

edited

Loading

Profpatsch commented Jun 12, 2019 •

edited

Loading

kalbasit commented Jun 12, 2019 •

edited

Loading