Hi Laszlo,
both protobuf and grpc have now RC issues in unstable for months. Here
is one more issue requiring a new protobuf upstream version in unstable.
I asked you in the past to maintain these within a team, it's not the
first time that these and other libraries maintained by you are lagging
in unstable, that they are blocking other people. Please consider doing
that, and finally prepare uploads for unstable.
Thanks, Matthias
On 9/23/26 17:14, PaulLiu wrote:
Hi Vladimir,
We would like to upgrade bazel-bootstrap to 9 at some point. But currently
it is not doable because the protobuf version is too old in Debian unstable.
The protobuf in Debian right now is just suitable for 7. Not 8 or 9.
Otherwise I've already upgraded it.
In the meantime, I think we could check if it is possible to backport it to
bazel 7.
For example, android-cuttlefish needs bazel 8 at least. But we still build
it with bazel-bootstrap (which is 7) right now.
The major difference between 7 and 8 is that 8 has something called
"macro(...)". So you can check if the rules are using that. And how many
times it uses it.
If it uses too many macro(...) then we should give up. But if it only uses
it a few times, here is the patch for it.
https://github.com/google/android-cuttlefish/commit/6ff0b89070e7fe71c21a9db5a61ad27a7c75f5d1
As you can see in this commit we tried to implement a macro(...) for bazel
7 if macro is not available.
In android-cuttlefish we also have smaller patches that port bazel-8 to
bazel-7 too. So if the change is not huge, this might be a temporary
solution. Until we get bazel-8 or 9 uploaded to Debian.
Versioned packages for bazel are good but I'm not sure what is the correct
way to maintain those different versions right now. Because bazel-rules-*
also need to bind to certain bazel versions. If you look into bazel-rules-*
you'll see that those are not the latest too. I tried to pick the version
released around 2023 so that they won't use macro(...).
Upgrading bazel-rules-* to the latest version you'll see it break the
builds just because of macro(...).
Yours,
Paul
On Wed, Sep 23, 2026 at 10:31 AM Vladimir Petko <
[email protected]> wrote:
Hi Emmanuel,
Thank you!!!!!!
I did come across the paper that describes an interesting approach. It
claims that we can have reproducible results by having the LLM harness
generate refactoring recipes[1] rather than directly patching the
source code. This also saves tokens, as a single recipe (such as
dropping all instances of the dokka plugin) can be applied across
multiple packages.
I was also wondering if moving from maven.rules / maven.ignoreRules
to publishing relocation POMs could simplify things. This allows the
agent to work directly with the prepared Maven repository and the
source tree without struggling with the Gradle plugin that rewrites
the artifact coordinates.
The Kotlin DSL requires Kotlin that requires Intellij IDEA Platform
that requires Bazel. Bazel was recently upgraded to 7.7.1 (which is a
great news) , but we need 9 for Intellij IDEA ;( Since those are not
backwards compatible I was wondering if the goal is to have 9 as the
bazel-bootstrap or we will need a versioned package?
Best regards,
Vladimir
[1] https://huggingface.co/papers/2606.24446
