Re: unbreaking LibreOffices tests on at least release architectures

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.

There are likely also build or debug tricks you know that a porter would 
not know.

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.


On Mon, Jun 19, 2023 at 12:04:45AM +0200, Kurt Roeckx wrote:
>...
> Do you think Debian doesn't have any developers/porters anymore?
>...

For porters that's actually close to being true.

There were times when porter numbers for a release architecture were 
numbers like 6 or 9.

No release architecture in bookworm had more than 2 porters.

No porters were required on amd64, the number of distinct people who are 
listed as porter for one or more of the 8 other bookworm release 
architecture is 5 DDs and 2 non-DDs.


On Sun, Jun 18, 2023 at 09:31:05AM +0200, Rene Engelhard wrote:
>...
> For riscv64 I already pointed that out in the thread starting at
> https://lists.debian.org/debian-riscv/2023/06/msg00000.html, but for the
> other architectures there is the mail now. riscv64 is different because
> the failures are even more big than any other down below and it's actually a
> new architecture anyway.
>
> 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.
>
> 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.
>
> With various different 32-bit, endian and whatever else breakage
> ppopping up the other architectures constantly were moved in the set
> where the testsuite was run but the results were ignored. For s390x,
> where the macros tests hangs it even was in the set where the tests even
> were not ran, since a hang then also ends up in
> "E: Build killed with signal TERM after 150 minutes of inactivity".
>
> This was sweeping under the carpet for sure, but this was needed due to
> it being a release architecture :(
>...

For such a complex package I would expect 32bit breakage in every 
release if upstream no longer tests on 32bit.

The pragmatic option would be to run only a smoketest for build success 
on architectures not tested by upstream.


cu
Adrian