Re: unbreaking LibreOffices tests on at least release architectures
On Mon, Jun 19, 2023 at 11:29:34PM +0200, Rene Engelhard wrote:
>...
> Am 19.06.23 um 23:19 schrieb Adrian Bunk:
>...
> > For such a complex package I would expect 32bit breakage in every
> > release if upstream no longer tests on 32bit.
> Indeed, though at least for 32bit *build* issues they keep fixing them if I
> report them.
> > The pragmatic option would be to run only a smoketest for build success
> > on architectures not tested by upstream.
>
> And have Format->Character in Impress crash with Bus error like on mipsel?
> That doesn't sound too good for basic quality.
>
> There is a "smoketest" but it does just basic start. open, close stuff. Not
> even basic usage.
Let's be realistic regarding the available options, because the one you
want is not available.
You want every !a*64 architecture to have a porter spending time on
fixing libreoffice.
And thinking this through, since regressions in new upstream versions
are expected to be frequent you want new upstream versions of libreoffice
blocked from testing migration by any regression on one architecture
until a porter for this architecture has fixed the regression.
A new architecture like riscv64 might have enough porters for fixing
issues once or for some limited duration. That's it.
For each architecture you have the options:
1. declare libreoffice good enough on this architecture, or
2. don't build libreoffice on this architecture
There is no third option that architectures will provide porters fixing
your package all the time.
There are several other packages of comparable complexity, size and
testsuite (e.g. mozjs* or rustc). For a successful build they are using
either just a smoketest, or a maximum number of tolerable testsuite
failures.
> Regards,
>
> Rene
cu
Adrian
Reply to: