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
