Re: [LTP] [Valgrind-developers] [RFC PATCH 1/1] LTP tests: Run without LTP_REPRODUCIBLE_OUTPUT=1

[Petr Vorel <pvorel@suse.cz>]

> On  Wed  2026-03-25  14:57 , Petr Vorel wrote:
> > > Hi!
> > > > > > That sounds reasonable to me.  Which one would you prefer to
> > > > > > keep?  I'm inclined to suggest keeping LTP_REPRODUCIBLE_OUTPUT
> > > > > > and dropping LTP_QUIET but no really strong preference on my
> > > > > > side.  Thoughts?

> > > > > Maybe we can finally implement proper debug levels in LTP. E.g. hide
> > > > > TINFO and TWARN messages with debug level 0 and default to debug level
> > > > > 1. With debug level 2 we would show TDEBUG as well and with debug level
> > > > > 3 we would show TDEBUG messages for library too.

> > > > That would require running valgrind tests with something like
> > > > debug level -1 ;) because what LTP_REPRODUCIBLE_OUTPUT actually
> > > > does is that it hides testrun specific output like e.g. testrun
> > > > specific addresses, temporary file names etc.

> > > The LTP_REPRODUCIBLE_OUTPUT would have to stay, but the LTP_QUITE would
> > > have been replaced by different debug levels.

> > I thought just remove LTP_QUITE and control everything with
> > LTP_REPRODUCIBLE_OUTPUT.

> Sounds fine, Petr.  For Valgrind testing, the functionality of
> both LTP_REPRODUCIBLE_OUTPUT and LTP_QUIET is useful.  But
> there's no need to control the two features independently.
> Merging the functionality under one controlling env var works
> perfectly fine from the Valgrind testsuite perspective.

I prefer to keep LTP_REPRODUCIBLE_OUTPUT as variable name (with merged
functionality of both). 1) We have LTP_ENABLE_DEBUG, so one would expect
LTP_ENABLE_DEBUG and LTP_QUIET are mutually exclusive.
2) IMHO it's more about the reproducibility of the results.

Kind regards,
Petr

> Thanks,
> Martin

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp