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
