[LTP] [Valgrind-developers] [RFC PATCH 1/1] LTP tests: Run without LTP_REPRODUCIBLE_OUTPUT=1
Petr Vorel
pvorel@suse.cz
Thu Mar 26 17:42:23 CET 2026
> 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
More information about the ltp
mailing list