bazel 7.1 -> 7.3 #338264

flurie · 2024-08-29T20:49:30Z

Description of changes

Bazel 7.1.2 -> 7.3.1

Things done

Walking through this in some detail:

Take a built Bazel 7.3, patch it, and wrap it in FHS. I found just patching did not work, but I'm not sure if it needs both at once?
Use bootstrap Bazel to vendor all deps with bazel vendor for a fixed-output derivation. Eliminate any parts that are not reproducible but do not affect the output.
Build Bazel with as little change to the existing drv as possible. To prevent it from fetching things due to timestamps on the marker files, I pin every repo it has in VENDOR.bazel. To enable offline builds, we need to set --repository_disable_download, not --nofetch. Also, for some reason py_binary rules were building python zips, so I had to add --nobuild_python_zip.

More serious gaps:

Haven't updated tests. I imagine those will change in the same way so it might be nice either to get out of the bootstrap first or have a single wrapper for the bootstrap that we can use to create Bazel offline drvs, maybe even replacing buildBazelPackage? One thing I don't know is how well bazel vendor performs when you aren't as all-in on bzlmod as Bazel's own build.
Related to above issue, if bazel vendor is hard to use as a standard deps fetch more generally, should we consider keeping Bazel 7.3 as a separate package for now and moving forward with replacements for things that can use it? That's the only reason I have kept them separate for now.
No darwin testing. But my understand is that the darwin build is already pretty broken/not practically usable, even though it builds?

Add a 👍 reaction to pull requests you find important.

flurie · 2024-08-29T20:52:26Z

pkgs/development/tools/build-managers/bazel/bazel_73/test_source_sort.patch

This is the only new patch introduced here. The others are all copied straight from the existing bazel_7 drv.

pkgs/top-level/all-packages.nix

flurie · 2024-08-29T21:38:22Z

I'm going to hold off on the by-name migration until we come to a decision about whether or not to replace the existing bazel_7.

pkgs/development/tools/build-managers/bazel/bazel_73/default.nix

emilazy · 2024-08-30T15:07:12Z

Is the reason to have this as a separate package just getting fetching to work properly? If that can be solved it seems better to update the main Bazel package rather than carrying around multiple versions indefinitely.

Nits:

Package name should be bazel_7_3.
Commit message subject should be bazel_7_3: init at 7.3.0, or bazel: 7.1.2 -> 7.3.0 if it gets merged in (that way ofborg will build it in CI).

flurie · 2024-08-30T16:49:17Z

Is the reason to have this as a separate package just getting fetching to work properly? If that can be solved it seems better to update the main Bazel package rather than carrying around multiple versions indefinitely.

Thank you, I realize I didn't really provide any specifics here. Changing how deps are fetched shouldn't be a big deal normally, but we are giving up a good bit of control over resolution and fetching, and I don't fully trust that the new method will remain correct or stable over time. The previous method of fetching used to be able to resolve everything necessary to build the package outside of using Bazel directly. Unfortunately, some changes to how Bazel resolves deps broke our method of resolution and fetching essentially for good. This comment has a summary of the problem and links to a more detailed discussion.

Bazel does not guarantee reproducibility in its fetches, so using Bazel to fetch its deps means taking on some level of risk. I don't want to preclude that this is stable enough to use going forward, and I don't want a problem to mean that we no longer have a working Bazel 7 package. These concerns might not be enough to warrant having a separate package, but I wanted to make them known and get others' perspectives.

Nits:

* Package name should be `bazel_7_3`.

* Commit message subject should be `bazel_7_3: init at 7.3.0`, or `bazel: 7.1.2 -> 7.3.0` if it gets merged in (that way ofborg will build it in CI).

👍 I will make these changes if we end up sticking with a new package here.

emilazy · 2024-08-30T16:53:11Z

No worries, I’m not keeping track of Bazel so I’m just missing the context here :)

Seems like we’ll have to bite the bullet at some point, right, unless Bazel 7.1 is going to remain a viable platform forever? Or someone else could write a deterministic fetcher tailored to our purposes; I know that’s been done for Node.js.

flurie · 2024-08-30T17:25:49Z

Your perspective even without the additional context is valuable, because it tells me this probably does not clear the bar for needing to split the package further. I'm now leaning toward upgrading the existing package in place.

Bazel tends to do big feature development in minor versions while gating them behind flags that are disabled by default, and a lot of major version changes are simply flipping the flags to enable the feature by default, so minor versions can come with big feature updates on their own. It would be okay for us to have separate minor versions, I believe, if that were something we absolutely needed to do, but I'm more certain that we don't need to do it in this case.

I think a better fetcher might be a preferable solution in the long run simply because we care a lot more about the reproducibility of deps, but I thought it was more important to have a working Bazel 7.3 since we had to skip over 7.2. It's also possible that we see less volatility with the deps for this package in particular, but I am also thinking about a way forward for things like buildBazelPackage that have a prescribed-enough deps fetch that it should work out of the box for most people. This has been and continues to be a common pain point for building Bazel packages with nix, and a custom fetcher is probably optimal, but I'm afraid it will be a lot of work, and it is hard to have a good development loop for these gigantic FODs that are difficult or impossible to decompose.

emilazy · 2024-08-30T17:38:52Z

It’s okay to maintain separate versions for a time if required to do a migration. For instance, are there existing in‐tree packages using Bazel that would be broken by the fetcher changes (e.g. because they have dependency hashes that would be invalidated)? In that case it’d definitely be best to add another version for now until we can sort things out. If everything in Nixpkgs should otherwise keep working, I think it’s okay to go from one suboptimal situation to another, perhaps with a release note.

(And yeah, I’m a big FOD blob hater, personally! But they can be hard to forgo without checking huge lock files into Nixpkgs, depending on the ecosystem…)

malt3 · 2024-08-30T17:40:46Z

I'm now leaning toward upgrading the existing package in place.

I share that sentiment.

I think a better fetcher might be a preferable solution in the long run […] This has been and continues to be a common pain point for building Bazel packages with nix, and a custom fetcher is probably optimal, but I'm afraid it will be a lot of work, and it is hard to have a good development loop for these gigantic FODs that are difficult or impossible to decompose.

I think a fetcher that is stable over many Bazel versions requires upstream support. Ideally a built in feature like bazel vendor, but it outputs a list of fetchurl / http_archive / a JSON lockfile instead of creating a vendor_dir. If we can get something implemented upstream (and add tests upstream) we can expect it to be less brittle.

flurie · 2024-09-04T16:58:48Z

I think these changes are pretty well localized to the Bazel derivation itself, so I do think this is fine to upgrade in place.

I've switched to Bazel 7.3.1 and did not find any issues after updating the hashes.

I'm going to mark this as ready for review while recognizing that the tests have not been updated yet.

flurie · 2024-08-30T19:59:04Z

pkgs/development/tools/build-managers/bazel/bazel_7/default.nix

@@ -117,8 +100,126 @@ let
      unzip
      which
      zip
+      runJdk


this might not be necessary (was from an attempt to wrap the bootstrap Bazel with JAVA_HOME)

flurie · 2024-08-30T20:00:27Z

pkgs/development/tools/build-managers/bazel/bazel_7/default.nix

    ];

+  # Bootstrap an existing Bazel so we can vendor deps with vendor mode


This is the salient portion of the changes made to get this working with Bazel 7.3 via vendor mode.

Were we using a binary bootstrap before, or is this a new change? I thought that Bazel always required itself to bootstrap, so it’d help me if you could explain the differences from the previous situation.

Currently it seems like this would restrict Bazel to x86_64-linux only, which would be unfortunate. Would keeping the old Bazel around to build this one provide us a source‐based bootstrap path, or would we just be using a different binary bootstrap?

Bazel does require itself to bootstrap as part of its own build, but we now need a version of Bazel 7.3 that we can use prior to building Bazel 7.3 in order to be able to run bazel vendor for the FOD that fetches the deps.

We should be able to bootstrap all combinations of darwin/linux and x86_64/arm64. We can certainly do that for linux, though I don't have an arm64-linux machine readily available. My understanding with the darwin derivation is that it builds but is essentially unusable, but I don't have the experience to confirm this. I'd be okay with delisting darwin support as long as people with this experience can verify that understanding.

One thing I'm not certain about: we need the bootstrap without an existing Bazel >= 7.3, but is there a way to get rid of it once we've done an initial bootstrap?

This now should work for all supported platforms, though I haven't tested it on all of them yet.

Thanks, I understand better now. Am I correct in thinking that previously we did not need a binary blob bootstrap Bazel and now we do, and that there is no way to use the old from‐source Bazel to bootstrap the new one? That is unfortunate, but not something we really have control over. You should set at least meta.sourceProvenance on the bootstrap Bazel accordingly.

That is correct, at least for the approach I've taken to vendor the deps. However, once we have a working Bazel 7.3 cached, is there a way for us to use that instead? It's not obvious to me how, but I figured there might be a way to eliminate the external bootstrap after the fact.

You should set at least meta.sourceProvenance on the bootstrap Bazel accordingly.

done 6338bd3

We have the bootstrap tools tarballs, but those are for things that are required to rebuild the standard environment. I think it wouldn’t make much sense in this case, because the provenance would be essentially the same: we’re trusting the opaque blob to produce a new opaque blob for us, so there’s no point pretending that “laundering” it through Hydra produces something we can confidently say was bootstrapped cleanly from the original source code.

dmivankov · 2024-09-08T20:30:59Z

@ofborg build bazel_7

dmivankov · 2024-10-14T13:04:37Z

pkgs/development/tools/build-managers/bazel/bazel_7/default.nix

-, enableNixHacks ? false
-, version ? "7.1.2"
+  enableNixHacks ? false,
+  version ? "7.3.1",


7.3.2 is also available now

And 7.4.0

emilazy · 2024-10-18T19:09:43Z

Sorry for forgetting about this. The ofborg failure looks like a build sandbox thing, maybe. The default setting on macOS (used by Hydra) is to leave it disabled, but ofborg uses the sandbox since it‘s building stuff from random users on the internet.

emilazy · 2024-10-18T19:13:23Z

BTW, this isn‘t directly related to this PR but I thought I should note it down for others in case I don‘t get around to handling it: Bazel 5 is leaving security support two months into 24.11, and only one package uses it, so it should probably get dropped before release.

flurie · 2024-10-19T19:59:15Z

Ah it looks like the HOME override doesn't work for darwin because it uses a different default output root. If I specify the output root, it fails on this:

error: builder for '/nix/store/aqz2kvg46ra3fwaaklls2li5972lsddw-bazelDeps.drv' failed with exit code 37;
       last 17 log lines:
       > Running phase: unpackPhase
       > unpacking source archive /nix/store/c4y3gq577yvjgy6nn90qmx9x501jz15c-bazel-7.3.1-dist.zip
       > source root is .
       > Running phase: patchPhase
       > applying patch /nix/store/jghsrq93v25j6d6zkizx8ilbzpc544ac-test_source_sort.patch
       > patching file src/test/shell/bazel/list_source_repository.bzl
       > Running phase: updateAutotoolsGnuConfigScriptsPhase
       > Running phase: configurePhase
       > Running phase: buildPhase
       > here!
       > /private/tmp/nix-build-bazelDeps.drv-0/bazel_src
       > here too!
       > Extracting Bazel installation...
       > Starting local Bazel server and connecting to it...
       > Server crashed during startup. Now printing /private/tmp/nix-build-bazelDeps.drv-0/output_root/1f90a375f58569e8f4bcdc6145ad9689/server/jvm.out
       > OpenJDK 64-Bit Server VM warning: Options -Xverify:none and -noverify were deprecated in JDK 13 and will likely be removed in a future release.
       > FATAL: CHECK failed: (suspend_state.connect_port) != (0):
       For full logs, run 'nix log /nix/store/aqz2kvg46ra3fwaaklls2li5972lsddw-bazelDeps.drv'.
error: 1 dependencies of derivation '/nix/store/mr55lglaq7wd95hvc04v8yxa7n9cy5nd-bazel-7.3.1.drv' failed to build

which appears to be related to this open issue that we have fixed with a patch. Unfortunately, it looks like we can't build Bazel 7 on darwin with sandboxing turned on if we want to use this bootstrapping method. I see a couple immediate options:

accept that this won't build in a sandbox on darwin, get some others to confirm that it builds/runs in darwin without sandboxing
fork Bazel and build a release with the patch applied that we can use to bootstrap our Bazel build

There may be some better/more nuanced options as well.

DolceTriade · 2024-10-20T00:16:39Z

Don't we already "fork" bazel by applying our hermeticity patches? Sounds more like an advertising problem? The issue was reported in 2023 and hasn't gained much traction since then.

Assuming the patch is just to disable the functionality to not sleep while a build is running, it seems worthwhile to get bazel 7.3 in Nix?

I wonder if we could also modify that code to simply make it "best effort" as in, if the power API calls fail, just continue on and hope for the best?

DolceTriade · 2024-10-20T01:26:08Z

Also, I tried building your branch on OSX and I got this:

❯ nix build .#pkgs.bazel_7
error: builder for '/nix/store/203zp1rhskwf6nfgpg4l4s3dh9hlbj5k-bazelDeps.drv' failed with exit code 2;
       last 25 log lines:
       > ERROR: An error occurred during the fetch of repository 'bazel_tools~cc_configure_extension~local_config_cc':
       >    Traceback (most recent call last):
       >        File "/private/var/tmp/_bazel__nixbld2/1f90a375f58569e8f4bcdc6145ad9689/external/bazel_tools/tools/cpp/cc_configure.bzl", line 91, column 33, in cc_autoconf_impl
       >              configure_unix_toolchain(repository_ctx, cpu_value, overriden_tools)
       >   File "/private/var/tmp/_bazel__nixbld2/1f90a375f58569e8f4bcdc6145ad9689/external/bazel_tools/tools/cpp/unix_cc_configure.bzl", line 387, column 46, in configure_unix_toolchain
       >                overriden_tools["ar"] = _find_generic(repository_ctx, "libtool", "LIBTOOL", overriden_tools)
       >   File "/private/var/tmp/_bazel__nixbld2/1f90a375f58569e8f4bcdc6145ad9689/external/bazel_tools/tools/cpp/unix_cc_configure.bzl", line 310, column 32, in _find_generic
       >           auto_configure_fail(msg)
       >       File "/private/var/tmp/_bazel__nixbld2/1f90a375f58569e8f4bcdc6145ad9689/external/bazel_tools/tools/cpp/lib_cc_configure.bzl", line 112, column 9, in auto_configure_fail
       >               fail("\n%sAuto-Configuration Error:%s %s\n" % (red, no_color, msg))
       > Error in fail:
       > Auto-Configuration Error: Cannot find libtool or LIBTOOL; either correct your path or set the LIBTOOL environment variable
       > ERROR: no such package '@@bazel_tools~cc_configure_extension~local_config_cc//':
       > Auto-Configuration Error: Cannot find libtool or LIBTOOL; either correct your path or set the LIBTOOL environment variable
       > ERROR: /private/var/tmp/_bazel__nixbld2/1f90a375f58569e8f4bcdc6145ad9689/external/rules_pkg~/pkg/private/tar/BUILD:45:10: @@rules_pkg~//pkg/private/tar:build_tar depends on @@bazel_tools~cc_configure_extension~local_config_cc//:cc-compiler-darwin_arm64 in repository @@bazel_tools~cc_configure_extension~local_config_cc which failed to fetch. no such package '@@bazel_tools~cc_configure_extension~local_config_cc//':
       > Auto-Configuration Error: Cannot find libtool or LIBTOOL; either correct your path or set the LIBTOOL environment variable
       > ERROR: Analysis of target '//src:bazel_nojdk' failed; build aborted: Analysis failed
       > INFO: Elapsed time: 7.130s
       > INFO: 0 processes.
       > ERROR: Build did NOT complete successfully
       > Loading: 325 packages loaded
       > ERROR: Fetching some target dependencies failed with errors: Analysis of target '//src:bazel_nojdk' failed; build aborted: no such package '@@bazel_tools~cc_configure_extension~local_config_cc//':
       > Auto-Configuration Error: Cannot find libtool or LIBTOOL; either correct your path or set the LIBTOOL environment variable
       > Loading: 325 packages loaded
       >
       For full logs, run 'nix log /nix/store/203zp1rhskwf6nfgpg4l4s3dh9hlbj5k-bazelDeps.drv'.
error: 1 dependencies of derivation '/nix/store/62zfamx14j7077q22arbyywwc3s6cnch-bazel-7.3.1.drv' failed to build

After making this change:

diff --git a/pkgs/development/tools/build-managers/bazel/bazel_7/default.nix b/pkgs/development/tools/build-managers/bazel/bazel_7/default.nix
index 703f25e34..27746585a 100644
--- a/pkgs/development/tools/build-managers/bazel/bazel_7/default.nix
+++ b/pkgs/development/tools/build-managers/bazel/bazel_7/default.nix
@@ -35,6 +35,7 @@
   # Apple dependencies
   cctools,
   libcxx,
+  libtool,
   sigtool,
   CoreFoundation,
   CoreServices,
@@ -188,6 +189,7 @@ let
         unzip
         runJdk
         bazelForDeps
+        libtool
       ];
       configurePhase = ''
         runHook preConfigure

It built on OSX for me. Testing on an M1 Mac

alexflurieagility · 2024-10-20T18:56:02Z

Don't we already "fork" bazel by applying our hermeticity patches? Sounds more like an advertising problem? The issue was reported in 2023 and hasn't gained much traction since then.

Yes, the problem is that, in order to use bazel vendor to vendor the deps to build Bazel with a frozen set of deps, one must already have Bazel >= 7.3, and the bootstrap Bazel we fetch in order to do that is missing our patch.

After making this change:
It built on OSX for me. Testing on an M1 Mac

Thank you, I will add that in!

boltzmannrain · 2024-10-26T19:17:31Z

pkgs/development/tools/build-managers/bazel/bazel_7/default.nix

+        --tool_java_runtime_version=local_jdk_21 \
+        --java_runtime_version=local_jdk_21 \


Suggested change

--tool_java_runtime_version=local_jdk_21 \

--java_runtime_version=local_jdk_21 \

--tool_java_runtime_version=remotejdk_21 \

--java_runtime_version=remotejdk_21 \

It seems to not affect the vendor results, but might be cleaner to specify a hermetic toolchain rather than host toolchain?

though there's more use of local_jdk and patching related to that, so maybe local_jdk fits better

Given that this is using the bootstrap bazel, I agree that your suggestion might be preferable, but isn't it using a hermetic toolchain we bring into the env instead?

boltzmannrain · 2024-10-26T19:19:03Z

pkgs/development/tools/build-managers/bazel/bazel_7/default.nix

+        (cd bazel_src; ${bazelForDeps}/bin/bazel --server_javabase=${runJdk} mod deps --curses=no;
+        ${bazelForDeps}/bin/bazel --server_javabase=${runJdk} vendor src:bazel_nojdk \


Suggested change

(cd bazel_src; ${bazelForDeps}/bin/bazel --server_javabase=${runJdk} mod deps --curses=no;

${bazelForDeps}/bin/bazel --server_javabase=${runJdk} vendor src:bazel_nojdk \

(cd bazel_src; ${bazelForDeps}/bin/bazel --batch --server_javabase=${runJdk} mod deps --curses=no;

${bazelForDeps}/bin/bazel --batch --server_javabase=${runJdk} vendor src:bazel_nojdk \

Noticed that without fhs wrapping build would fail on bazel daemonizing itself. Daemon mode shouldn't be required for this vendoring target, also in some cases it's easier to capture logs in batch mode

boltzmannrain · 2024-10-26T19:20:43Z

pkgs/development/tools/build-managers/bazel/bazel_7/default.nix

+  # A FOD that vendors the Bazel dependencies using Bazel's new vendor mode.
+  # See https://bazel.build/versions/7.3.0/external/vendor for details.
+  # Note that it may be possible to vendor less than the full set of deps in
+  # the future, as this is approximately 16GB.


Suggested change

# the future, as this is approximately 16GB.

# the future, as this is approximately 0.9GB.

For me it amounts to 840-870MB 🤔

At the time that was written, it was vendoring the entire build rather than just the required targets.

boltzmannrain · 2024-10-26T19:22:35Z

pkgs/development/tools/build-managers/bazel/bazel_7/default.nix

+  # the future, as this is approximately 16GB.
+  bazelDeps =
+    let
+      bazelForDeps = if stdenv.hostPlatform.isDarwin then bazelBootstrap else bazelFhs;


Suggested change

bazelForDeps = if stdenv.hostPlatform.isDarwin then bazelBootstrap else bazelFhs;

bazelForDeps = bazelBootstrap;

with --batch it seems that bazelBootstrap works fine, not sure how exactly was daemon mode failing without the wrapper.

But also wrapper doesn't add any extra dependencies and looks like a no-op, at the very least it'd be nice to add a comment on why add FHS wrapper, and why not on MacOS.

I'm happy to get rid of the explicit FHS env if we don't need it, especially since we can't use it on darwin either way. Not sure if we should make this change right before it gets merged, though?

I didn't try to run it on ofborg or hydra so maybe less time risk in merging current version and look into simplifying later

boltzmannrain · 2024-10-26T19:34:31Z

For some reason I'm hitting

ERROR: /build/bazel_UkqwKL5c/out/external/rules_java~~toolchains~remote_java_tools/BUILD:154:10: Creating runfiles tree bazel-out/aarch64-opt-exec-ST-fad1763555eb/bin/external/rules_java~~toolchains~remote_java_tools/ijar_cc_binary.runfiles [for tool] failed: build-runfiles failed: error executing <shell command> command 

...  java.io.IOException: Cannot run program "/build/bazel_UkqwKL5c/archive/build-runfiles" (in directory "/build/bazel_UkqwKL5c/out/execroot/_main"): error=2, No such file or directory: java.io.IOException: Cannot run program "/build/bazel_UkqwKL5c/archive/build-runfiles" (in directory "/build/bazel_UkqwKL5c/out/execroot/_main"): error=2, No such file or directory

on aarch64-linux when building bazel_7, will try to debug later

boltzmannrain · 2024-10-26T19:35:50Z

pkgs/development/tools/build-managers/bazel/bazel_7/default.nix

+        else if stdenv.hostPlatform.system == "aarch64-darwin" then
+          "sha256-E6j31Sl+aGs6+Xdx+c0Xi6ryfYZ/ms5/HzIyc3QpMHY="
+        else
+          # x86_64-darwin


technically it may cover other platforms too, like riscv or something

That is not a supported platform. I would be happy to take a vendor sha for i686, but since I think it is unlikely that people are waiting to be able to run Bazel >= 7.3 via Nix on a Raspberry Pi, I don't want to gate merging this PR, which has been outstanding for months, on its inclusion.

What I meant is it's ok to only support most popular platforms, but there are more direct ways to express it:

here instead of "else # assume x86_64-darwin" do "else if ...darwin case... else fail"

and/or platforms meta attribute https://ryantm.github.io/nixpkgs/stdenv/meta/#var-meta-platforms

Ah I understand, you're right, I can make that change.

boltzmannrain · 2024-10-26T19:37:00Z

pkgs/development/tools/build-managers/bazel/bazel_7/default.nix

+        }
+      else
+        fetchurl {
+          # stdenv.hostPlatform.system == "aarch64-darwin"


also here it assumes there's only 4 possible platform combinations

See my comment above.

boltzmannrain · 2024-11-01T14:43:26Z

For some reason I'm hitting

ERROR: /build/bazel_UkqwKL5c/out/external/rules_java~~toolchains~remote_java_tools/BUILD:154:10: Creating runfiles tree bazel-out/aarch64-opt-exec-ST-fad1763555eb/bin/external/rules_java~~toolchains~remote_java_tools/ijar_cc_binary.runfiles [for tool] failed: build-runfiles failed: error executing <shell command> command 

...  java.io.IOException: Cannot run program "/build/bazel_UkqwKL5c/archive/build-runfiles" (in directory "/build/bazel_UkqwKL5c/out/execroot/_main"): error=2, No such file or directory: java.io.IOException: Cannot run program "/build/bazel_UkqwKL5c/archive/build-runfiles" (in directory "/build/bazel_UkqwKL5c/out/execroot/_main"): error=2, No such file or directory

on aarch64-linux when building bazel_7, will try to debug later

extra info is that with breakpointHook

$ cntr exec ls /
build  dev  etc  nix  proc  tmp  var

there seems to be no /bin/sh and that makes build-runfiles from https://github.com/bazelbuild/bazel/blob/master/scripts/bootstrap/compile.sh#L334 fail 🤔

Shouldn't be a blocker I guess, if it works on Hydra let it work, if not maybe add aarch64-linux to "badPlatforms" for now

boltzmannrain

Personally don't see why not merge it even in current shape and bump&improve further later

ZHF is also starting so any regressions might be good to address during that campaign

layus

LGTM.

Bootstrapping from a binary tarball seems more reliable than everything we tried before.

Not updating tests is okay. They are cumbersome to update, and do not really work anyway. What we need is a maintained toy/example/test project that is nix/NixOS compatible. Not aware of any right now.

I plan to merge this on Thursday unless there is some hard blocker discovered in the meantime.

flurie · 2024-11-06T21:50:32Z

@layus might sound odd, but I wonder if we could use some examples/tests from rules_nixpkgs?

Some of the unresolved suggestions are simple/straightforward. Should I go ahead and make these changes ahead of merge?

DolceTriade · 2024-11-11T20:55:45Z

Will this still be merged on Thursday?

layus · 2024-11-12T14:24:14Z

@flurie I am just trying to be helpful by providing the ability to merge, and a reminder that it does not need to be perfect to be useful. I will merge as-is, but changes in another PR are obviously welcome.

dimatosaurus · 2024-11-12T15:01:46Z

Can we maybe also bump it to 7.4? Update of the version seems not to cause problems from a first test.

boltzmannrain · 2024-11-12T15:27:44Z

Can we maybe also bump it to 7.4? Update of the version seems not to cause problems from a first test.

#355457 waiting for the build

flurie mentioned this pull request Aug 29, 2024

Update request: bazel_7 7.1.2 → 7.3.x #318833

Closed

1 task

flurie commented Aug 29, 2024

View reviewed changes

ofborg bot added the 8.has: package (new) This PR adds a new package label Aug 29, 2024

ofborg bot requested review from aherrmann, avdv, groodt, mboes, olebedev, uri-canva and ylecornec August 29, 2024 21:21

ofborg bot added 10.rebuild-darwin: 1-10 10.rebuild-linux: 1-10 labels Aug 29, 2024

ofborg bot added 10.rebuild-darwin: 1 10.rebuild-linux: 1 labels Aug 29, 2024

This comment was marked as resolved.

Sign in to view

malt3 reviewed Aug 30, 2024

View reviewed changes

pkgs/development/tools/build-managers/bazel/bazel_73/default.nix Outdated Show resolved Hide resolved

flurie force-pushed the flurie/bazel_73 branch 2 times, most recently from bf0c877 to 7b90c79 Compare September 4, 2024 16:55

flurie marked this pull request as ready for review September 4, 2024 16:58

flurie requested a review from Profpatsch as a code owner September 4, 2024 16:58

flurie commented Sep 4, 2024

View reviewed changes

musjj mentioned this pull request Oct 5, 2024

fcitx5-mozc: 2.26.4220.102 -> 2.30.5544.102 #346680

Merged

13 tasks

dmivankov reviewed Oct 14, 2024

View reviewed changes

add libtool to darwin bazel deps

097532a

boltzmannrain reviewed Oct 26, 2024

View reviewed changes

boltzmannrain approved these changes Nov 1, 2024

View reviewed changes

wegank added the 12.approvals: 1 This PR was reviewed and approved by one reputable person label Nov 1, 2024

layus approved these changes Nov 5, 2024

View reviewed changes

wegank added 12.approvals: 2 This PR was reviewed and approved by two reputable people and removed 12.approvals: 1 This PR was reviewed and approved by one reputable person labels Nov 6, 2024

wegank added 12.approvals: 1 This PR was reviewed and approved by one reputable person and removed 12.approvals: 2 This PR was reviewed and approved by two reputable people labels Nov 6, 2024

layus merged commit 3da7d28 into NixOS:master Nov 12, 2024
31 checks passed

@@ @@ -117,8 +100,126 @@ let @@
                     unzip
                     which
                     zip
+                    runJdk

		];

		# Bootstrap an existing Bazel so we can vendor deps with vendor mode

		--tool_java_runtime_version=local_jdk_21 \
		--java_runtime_version=local_jdk_21 \

		(cd bazel_src; ${bazelForDeps}/bin/bazel --server_javabase=${runJdk} mod deps --curses=no;
		${bazelForDeps}/bin/bazel --server_javabase=${runJdk} vendor src:bazel_nojdk \

	# the future, as this is approximately 16GB.
	# the future, as this is approximately 0.9GB.

	bazelForDeps = if stdenv.hostPlatform.isDarwin then bazelBootstrap else bazelFhs;
	bazelForDeps = bazelBootstrap;

bazel 7.1 -> 7.3 #338264

bazel 7.1 -> 7.3 #338264

Conversation

flurie commented Aug 29, 2024 • edited Loading

Description of changes

Things done

Choose a reason for hiding this comment

flurie commented Aug 29, 2024

This comment was marked as resolved.

emilazy commented Aug 30, 2024

flurie commented Aug 30, 2024

emilazy commented Aug 30, 2024

flurie commented Aug 30, 2024

emilazy commented Aug 30, 2024

malt3 commented Aug 30, 2024

flurie commented Sep 4, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dmivankov commented Sep 8, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

emilazy commented Oct 18, 2024 • edited Loading

emilazy commented Oct 18, 2024

flurie commented Oct 19, 2024

DolceTriade commented Oct 20, 2024

DolceTriade commented Oct 20, 2024

alexflurieagility commented Oct 20, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

boltzmannrain commented Oct 26, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

boltzmannrain commented Nov 1, 2024

boltzmannrain left a comment

Choose a reason for hiding this comment

layus left a comment

Choose a reason for hiding this comment

flurie commented Nov 6, 2024

DolceTriade commented Nov 11, 2024

layus commented Nov 12, 2024

dimatosaurus commented Nov 12, 2024

boltzmannrain commented Nov 12, 2024

flurie commented Aug 29, 2024 •

edited

Loading

emilazy commented Oct 18, 2024 •

edited

Loading