James Addison wrote:
> I've opened a merge request[1] to explore this error-treatment approach; it
> lacks useful error messaging so far, but I'll attempt to add that soon.
In your enthusiasm I think you neglected to included the actual "[1]"
URL later in your mail. However, allow me to do that
Hi Chris, Vagrant,
On Tue, 27 Feb 2024 at 17:44, Vagrant Cascadian
wrote:
>
> On 2024-02-27, Chris Lamb wrote:
> >> * Update reprotest to handle a single-disabled-varations-value as a
> >> special case - treating it as vary and/or emitting a warning.
>
> Well, I would broaden this to include
Vagrant Cascadian wrote:
> This almost makes me want to entirely deprecate --variations, and switch
> to recommending "--vary=-all,+whatever" or "--vary=-all
> --vary=+whatever" instead of ever using --variations.
This is also a very tempting option. I mean, if we're going to emit an
error (ie.
On 2024-02-27, Chris Lamb wrote:
>> * Update reprotest to handle a single-disabled-varations-value as a
>> special case - treating it as vary and/or emitting a warning.
Well, I would broaden this to include an arbitrary number of negating
options:
--variations=-time,-build_path
That seems
Hi James,
Great post, thank you. So, I'm in two minds re. the way forward:
> * Update reprotest to handle a single-disabled-varations-value as a
> special case - treating it as vary and/or emitting a warning.
On whether to magically/transparently fix this, needless to say, it's
considered bad
Hello,
A few hundred packages that use reprotest in Salsa-CI appear to be
misconfigured; the remainder of this message explains the problem, and
asks for help figuring out what to do.
Context
---
The reprotest[1] utility tests reproducibility of .deb package builds
by performing two
