Thomas Orozco

This is controlled by a flag (-v) — you might be passing -vvv? Try passing -vv instead? There’s also an env var (TINI_VERBOSITY) you might be setting — reduce the...

It seems likely it’s built with a vulnerable version, but note that Tini doesn’t actually use that function, let alone in the circumstances described there. I’ll try to publish updated...

> I may be wrong here, but I'm understanding the premise of defining the hash is to avoid the work of downloading. If we don't know the hash a priori,...

This is not a feature that exists in Buck2. There is buck2 clean --stale that can clean files that were produced by a previous daemon (assuming you’re using deferred materialization),...

> In short, local execution is basically a special case of remote execution, and so the hope to make local builds hermetic is just to reuse the remote path against...

Is this what you're looking for? https://github.com/facebook/buck2/blob/main/app/buck2_data/data.proto You mention the data from daemon.proto, I think this is generally not data we'd expect to be used for telemetry.

The default is that actions executed on RE get cached there implicitly, this flag only controls behaviour when actions get executed locally Internally the majority of actions execute on RE,...

> I'd actually have to call the implementation in a new rule if I wanted to attach that new provider. Is that a bad thing? That rule looks like it’d...

There’s a lot of processes in your hierarchy here. Tini sends SIGTERM to its immediate child (or the whole process group if you use the -g flag). You probably need...

What's your expectation for what `@reboot` would do? Run the job upon Supercronic starting up? (I'm a little concerned about this being potentially confusing, since that's not what you'd normally...