Hi Jason, On 2026-04-28 at 07:23-04:00, Jason Conroy wrote: > Nguyễn Gia Phong <[email protected]> writes: > > On 2026-04-27 at 16:38+02:00, Gabriel Wicki wrote: > > > Starting this is not much more than introducing errors > > > (and the relevant messages) in the substitute* function, > > > pushing these changes to a branch, asking QA to start building > > > and investigating, no? > > > > I support this course of action. > > I'd be curious to hear from those who are deeply familiar with the > QA infrastructure, but I suspect that errors scattered across > thousands of build logs are an inconvenient signal to consume. If > those errors were compiled into a dashboard, then sure, but that > seems like a project unto itself.
https://data.qa.guix.gnu.org/revision/COMMIT/blocking-builds serves this exact purpose IMHO. On 2026-04-28 at 07:23-04:00, Jason Conroy wrote: > Nguyễn Gia Phong <[email protected]> writes: > > On 2026-04-27 at 15:27-04:00, Jason Conroy wrote: > > > rebind substitute* to substitute**, rebuild, and fix errors. > > > > IIUC this entails modify (and rebuild) each package using it > > to opt in. It does not seem economical given most calls > > requires no modification. > > Ok, but on the other hand any change to substitute* (even just > adding error output) would also affect its module's hash and > trigger a rebuild. And then we would rebuild again when the > warn-on-error implementation was updated to fail-on-error. If we're going with opt-out, we will have 1 complete rebuild for the change to substitute*, then for each failing layer we fix all blocking builds at once and have 1 partial rebuild. With opt-in, we will have 1 complete rebuilds at the end, before which 1 partial rebuild for each passing layer. This assume someone analyzes the package graph to do this in the most efficient way (bottom-up and balanced layers). Alternatively, we can edit substitute* to warn and aggregate the warnings from the build log to see which substitution from which package is problematic, remove and create issues for each of them, and switch for fail-on-error. This needs to be done in the build farm (hopefully) due to low availability and performance of the public API. BTW subsitute* are visible as imported modules (via package-arguments or origin-modules), so opting in cannot be done per-module but per-package. Cheers, Phong
