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
Reply to: