Olek, Great work!Yeah. I will rebase the branch. As only the latest point release is supported by upstream, I would do the 4.1.0 one (or soon-to-be-released 4.2.0 [1]).
By the way, I put some effort into porting Bazel to Alpine Linux (a musl libc distro) in the last few weeks. The upstream supports glibc only, which makes the port a bit more urgent as otherwise Alpine users have no way to use Bazel at all. glibc executables are not runnable on Alpine, so that allows me to isolate the prebuilt executables. I made a bunch of patches [2] to make it possible to build a two-stage Bazel port that passes "java", "cpp" and "py" tests with arbitrary JDK from the system (8-16). The patches should be useful to Debian port as well.
Thanks, Jesse. [1]: https://github.com/bazelbuild/bazel/issues/13558 [2]: https://github.com/alpinelinux/aports/tree/master/testing/bazel4 On 8/16/2021, Olek Wojnar wrote:
Happy bullseye release, everyone!With development on bookworm open, this seems like a good time to talk about the plan for this development cycle. For ease of discussion, here's a convenient numbered list. :)1) I have uploaded the two completed Bazel packages (bazel-platforms and bazel-skylib) to unstable. They are now available for anything else that needs them.2) I updated the Meta page [1] a few weeks ago to include what I currently believe the build dependencies to be for all of the Bazel components. This should be helpful for people who want to package something but are not sure in which order things need to be packaged. Please let us all know if anything there seems incorrect! I've discovered a couple "surprise" dependencies as I've been working.3) Speaking of packaging coordination, note that the Phase 2 wiki page [2] has the install locations for all of the components. As for point 2, please let us all know if any of those seem incorrect or illogical!4) I have not thought through what the layout should look like if we ever need to package more than one version of a Bazel component. A few of us have put some thought into how we could package multiple major versions of Bazel simultaneously [3] but different versions of components may be necessary as well. We should talk about this in a separate thread.5) The bazel-bootstrap 3.5.1+ds-4 package is *still* in the NEW queue. I'm hopeful that it will be approved soon now that bullseye is done. The only change in that version is the new -source "binary" package to use with building bazel-stardoc and others.6) Jesse, could you please rebase the 4.0.0 and 4.1.0 bazel-bootstrap branches you created onto HEAD? I'd like to merge those into master as soon as the -4 package clears NEW. That way we'll be using the 4.x versions which is what we'll eventually be packaging for the full bazel-4 package.7) On that topic, I've realized that there are quite a few extra branches around in the bazel-bootstrap repo. Most of them are mine. I'm going to try cleaning up some of the branches which I used for early testing since they are effectively obsolete at this point.Did I miss anything? Anything else that we need to talk about? Hope everyone had a great weekend!-Olek[1] https://salsa.debian.org/bazel-team/meta <https://salsa.debian.org/bazel-team/meta> [2] https://salsa.debian.org/bazel-team/meta/-/wikis/Workplan-Part-2 <https://salsa.debian.org/bazel-team/meta/-/wikis/Workplan-Part-2> [3] https://salsa.debian.org/bazel-team/meta/-/wikis/Workplan-Part-3#long-term-plan <https://salsa.debian.org/bazel-team/meta/-/wikis/Workplan-Part-3#long-term-plan>
Attachment:
OpenPGP_0xA102C2F15053B4F7.asc
Description: OpenPGP public key
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature