Malte Poll

> What I would like to see first is a clear specification of what supporting go.work actually means, considering that each Bazel module in the dependency graph could have its...

Relevant upstream issue: https://github.com/protocolbuffers/protobuf/issues/13618 It looks like things are beginning to move! Thank you to everyone involved ❤️

I would also be happy to help out with improving the situation but I would need some indication if this is an issue that rules_perl wants to solve.

I think there are two ways to solve this: - build a fully static version of perl with something like musl libc - ship all or most of the dynamic...

> I wonder if we make it more obvious how perls toolchains is configured and let nix people just give it a nixos attribute instead I'm afraid I don't understand...

@GregBowyer thanks for this detailed explanation. If at all possible I would like to make the Bazel workflow not depend on nix / `rules_nixpkgs`, although it does seem like a...

I think I'll support my own fork of [`relocatable_perl`](https://github.com/malt3/relocatable-perl) and [`rules_perl`](https://github.com/malt3/rules_perl/tree/staticperl) for now. I also created [release artifacts](https://github.com/malt3/relocatable-perl/releases/tag/5.36.0.1-pre) that offer a statically linked perl toolchain. I only need perl to...

Comment

I found something: the variable `steps.vars.outputs.DEPLOY` was not set to true. This is why the release with artifacts was never triggered: https://github.com/uutils/coreutils/actions/runs/7596318857/job/21112947690#step:6:135 This is the case since the CICD workflow...

Do you think it is possible to either fix the release artifacts for v0.0.24 manually or do a new release soon?