Re: unbreaking LibreOffices tests on at least release architectures

[Rene Engelhard]

Hi,

Am 18.06.23 um 10:19 schrieb John Paul Adrian Glaubitz:
> On Sun, 2023-06-18 at 09:31 +0200, Rene Engelhard wrote:
>> Also note I am not talking about the debian-ports architectures. Those I
>> forgot and I have no problems making them stay into "testsuite ran but
>> results ignored" set.
> Why did you send this mail exclusively to debian-ports then?

I (obviously) wrongly assumed  that this was the magic address which
duplicates to every port.

Must have misremembered.

>> Right now, the only architectures where the test actually work (ignoring
>> the occassional breakage on arm64 which is fixed upstream since they do
>> aarch64 flatpak builds) is amd64 and arm64.
>> (...)
>> I don't really like sweeping it under the carpet again and would
>> actually pursue the "getting those architectures removed from unstable"
>> way pointed out and (implicitely) approved/suggested by the release team...
> You want Debian to drop support for all architectures except amd64 and arm64
> because a single package doesn't pass its testsuite on the other architectures?

If the "porters" of those architectures don't care about the tests, yes,
this would be the ultimate result.

And as the release team agrees with me...


Regards,


Rene

[Jeffrey Walton]

On Mon, Jun 19, 2023 at 5:30 PM Rene Engelhard <re...@debian.org> wrote:
>
> Hi,
>
> Am 19.06.23 um 23:19 schrieb Adrian Bunk:
> > On Sun, Jun 18, 2023 at 09:31:05AM +0200, Rene Engelhard wrote:
> >> ...
> >> I won't be of much help here unfortunately, except
> >> maybe testing patches, but then again there's porterboxes
> >> ...
> > You are the only one who could realistically debug many of these.
> >
> > E.g. on armel it says:
> > Fatal exception: Signal 6
> > Stack:
> > /<<PKGBUILDDIR>>/instdir/program/libuno_sal.so.3(+0x3c2e4)[0xb6ec32e4]
> > /<<PKGBUILDDIR>>/instdir/program/libuno_sal.so.3(+0x3c534)[0xb6ec3534]
> > /lib/arm-linux-gnueabi/libc.so.6(__default_rt_sa_restorer+0x0)[0xb6ad58f0]
> > /lib/arm-linux-gnueabi/libc.so.6(+0x7f47c)[0xb6b1e47c]
> > /lib/arm-linux-gnueabi/libc.so.6(gsignal+0x14)[0xb6ad4360]
> > Aborted (core dumped)
> >
> > Fixing something like this would involve generating a backtrace,
> > and then you are likely the only person in Debian who could tell
> > what is actually going on there.
>
> Not really.
>
> > There are likely also build or debug tricks you know that a porter would
> > not know.
>
> True, I can help with those if needed.
>
> (As I already pointed out for zelenka, though it's basically setting
> some variables in rules)
>
> > Debugging something like this is only feasible with reasonable effort if
> > a porter who knows the port with its caveats debugs it together with a
> > package maintainer who knows the internals of the package.
>
> I didn't say I was not helping, I said I am of no help if it comes to
> actually fix it if it involves architecture knowledge.
>
> [...]
>
> > 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.

Related, bus errors are usually due to unaligned data accesses.
Programmers casting from one type to another when when they shouldn't,
like:

typedef unsigned char byte;
...
byte buffer[32];

readBuffer(buffer);
double d = *(double *)buffer;

That is undefined behavior because a byte buffer is a byte buffer, and
it is not a double. That can result in a bus error on some platforms.
You may get lucky and the byte buffer may be aligned for double. Or it
may not be.

In contrast, this would be Ok because the byte buffer is really a double object:

typedef unsigned char byte;
...
double d;
byte* buffer = (bytes*)&d;

readBuffer(buffer);
double dd = *(double *)buffer;

You can usually uncover them by building the package with CFLAGS=" ...
-fsanitize=undefined ... " and CXXFLAGS=" ... -fsanitize=undefined ...
". The UBsan sanitizer operates on real data. There are no false
positives.

You don't need to be a porter to build and run with sanitizers.
However, you do need an arch-specific machine. Or possibly a Debian
chroot.

Jeff

[Andreas Schwab]

On Jul 22 2023, Rene Engelhard wrote:

> Hi,
>
> Am 22.07.23 um 14:28 schrieb Andreas Schwab:
>> On Jul 22 2023, Rene Engelhard wrote:
>>
>>> Yes. _basically_. (Only with -O0 or maybe -Os as upstreams makefile says,
>>> though)
>> On openSUSE Factory, libreoffice is built with the usual compiler flags,
>> wich includes full optimisation and hardening.
>
> Which gives the smoketest test failure here I pointed out (again) in my
> other mail.

$ find /usr/lib64/libreoffice/ -name "*smoke*"
/usr/lib64/libreoffice/program/classes/smoketest.jar

How can I run that?

--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."