Bug#953235: vtkplotter: autopkgtest arm64 failure: No module named 'vtkIOFFMPEGPython'
Control: severity -1 important Hi Adrian, On 07-05-2020 12:16, Adrian Bunk wrote: > On Thu, May 07, 2020 at 10:28:33AM +0200, Paul Gevers wrote: >> On 07-05-2020 10:07, Adrian Bunk wrote: >>> This is a toolchain problem affecting many packages: >>> https://sourceware.org/bugzilla/show_bug.cgi?id=25051 [...] >>> Is there a non-manual way to express that the autopkgtest must not run >>> on arm64 and powerpc64el? >> >> There is currently not even a manual way except for marking the test as >> skippable and exitting with error code 77 on unsupported architectures. >> Mind you, I don't think toolchain issues should be marked at the package >> level (but maybe you didn't mean that). > > vtkplotter: flagged for removal in 6.3 days So, let's get that issue out of the way for now. I've lowered the severity of this bug and hinted the acceptance of the failing test for now. Paul signature.asc Description: OpenPGP digital signature
Bug#953235: vtkplotter: autopkgtest arm64 failure: No module named 'vtkIOFFMPEGPython'
On Thu, May 07, 2020 at 10:28:33AM +0200, Paul Gevers wrote: >... > On 07-05-2020 10:07, Adrian Bunk wrote: > > This is a toolchain problem affecting many packages: > > https://sourceware.org/bugzilla/show_bug.cgi?id=25051 > > Do you have any rough estimate how many? >... Other bugs I can quickly find are #930039 and #945878. AFAIR I have seen maintainers adding workarounds for arm64+ppc64el FTBFS caused by this bug that did not have bugs in the BTS. #951704 looks like a similar but unrelated problem with jemalloc. > Is there any way to predict which packages are effected, Anything loading a plugin that is directly or indirectly linked with libgomp might or might not have this problem. Python C extensions are the most frequent ones. Heavy usage of Python code with C extensions tends to be in the more scientific areas of the archive, I'd guess many of these packages have no users at all on ppc64el or arm64 who would report bugs (Raspbian is armhf). python3-vtkplotter -> python3-vtk7 -> libvtk -> FFmpeg libraries -> libsoxr -> libgomp > or to detect which packages are effected? "import vtk" works, but "import vtkplotter" blows up when importing vtk. This is similar to the two different OpenSSL versions in stretch, where module load order might determine whether Apache segfaults or starts. >... > > Is there a non-manual way to express that the autopkgtest must not run > > on arm64 and powerpc64el? > > There is currently not even a manual way except for marking the test as > skippable and exitting with error code 77 on unsupported architectures. > Mind you, I don't think toolchain issues should be marked at the package > level (but maybe you didn't mean that). vtkplotter: flagged for removal in 6.3 days The big hammer would be to remove the autopkgtest... > If we can detect this failure > mode (and similar ones in the future) we can of course generate hints > based on this heuristics and have the failures ignored until the > toolchain issues are fixed. A failing arm64 or ppc64el autopkgtest log containing the string "libgomp.so.1: cannot allocate memory in static TLS block" is this bug. > Paul cu Adrian
Bug#953235: vtkplotter: autopkgtest arm64 failure: No module named 'vtkIOFFMPEGPython'
Dear Adrian, On 07-05-2020 10:07, Adrian Bunk wrote: > This is a toolchain problem affecting many packages: > https://sourceware.org/bugzilla/show_bug.cgi?id=25051 Do you have any rough estimate how many? Is there any way to predict which packages are effected, or to detect which packages are effected? > There is nothing a binary-all python module can do to fix > architecture-specific toolchain bugs. Ack. > Is there a non-manual way to express that the autopkgtest must not run > on arm64 and powerpc64el? There is currently not even a manual way except for marking the test as skippable and exitting with error code 77 on unsupported architectures. Mind you, I don't think toolchain issues should be marked at the package level (but maybe you didn't mean that). If we can detect this failure mode (and similar ones in the future) we can of course generate hints based on this heuristics and have the failures ignored until the toolchain issues are fixed. Paul signature.asc Description: OpenPGP digital signature
Bug#953235: vtkplotter: autopkgtest arm64 failure: No module named 'vtkIOFFMPEGPython'
On Fri, Mar 06, 2020 at 10:57:20AM +0100, Paul Gevers wrote: >... > However, it fails on arm64. I copied some of the output at the bottom of > this report. > > Currently this regression is blocking the migration to testing [1]. Can > you please investigate the situation and fix it? >... > https://ci.debian.net/data/autopkgtest/testing/amd64/v/vtkplotter/4281870/log.gz > > autopkgtest [12:57:24]: test python3: [--- > Processing test_actors.py script.. > Traceback (most recent call last): > File "/usr/lib/python3/dist-packages/vtk/vtkIOFFMPEG.py", line 5, in > > from .vtkIOFFMPEGPython import * > ImportError: /lib/aarch64-linux-gnu/libgomp.so.1: cannot allocate memory > in static TLS block >... This is a toolchain problem affecting many packages: https://sourceware.org/bugzilla/show_bug.cgi?id=25051 There is nothing a binary-all python module can do to fix architecture-specific toolchain bugs. Is there a non-manual way to express that the autopkgtest must not run on arm64 and powerpc64el? cu Adrian
Bug#953235: vtkplotter: autopkgtest arm64 failure: No module named 'vtkIOFFMPEGPython'
Package: python3-vtkplotter Followup-For: Bug #953235 Dodgy libgomp.so. See https://github.com/pytorch/pytorch/issues/2575
Bug#953235: vtkplotter: autopkgtest arm64 failure: No module named 'vtkIOFFMPEGPython'
Source: vtkplotter Version: 2020.2.0+dfsg1-1 X-Debbugs-CC: debian...@lists.debian.org Severity: serious User: debian...@lists.debian.org Usertags: fails-always Dear maintainers, With a recent upload of vtkplotter you added an autopkgtest, great. However, it fails on arm64. I copied some of the output at the bottom of this report. Currently this regression is blocking the migration to testing [1]. Can you please investigate the situation and fix it? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=vtkplotter https://ci.debian.net/data/autopkgtest/testing/amd64/v/vtkplotter/4281870/log.gz autopkgtest [12:57:24]: test python3: [--- Processing test_actors.py script.. Traceback (most recent call last): File "/usr/lib/python3/dist-packages/vtk/vtkIOFFMPEG.py", line 5, in from .vtkIOFFMPEGPython import * ImportError: /lib/aarch64-linux-gnu/libgomp.so.1: cannot allocate memory in static TLS block During handling of the above exception, another exception occurred: Traceback (most recent call last): File "test_actors.py", line 1, in from vtkplotter import Cone, Sphere, merge, Volume, show File "/usr/lib/python3/dist-packages/vtkplotter/__init__.py", line 30, in from vtkplotter.animation import Animation File "/usr/lib/python3/dist-packages/vtkplotter/animation.py", line 3, in import vtkplotter.utils as utils File "/usr/lib/python3/dist-packages/vtkplotter/utils.py", line 2, in import vtk, sys File "/usr/lib/python3/dist-packages/vtk/__init__.py", line 113, in from .vtkIOFFMPEG import * File "/usr/lib/python3/dist-packages/vtk/vtkIOFFMPEG.py", line 9, in from vtkIOFFMPEGPython import * ModuleNotFoundError: No module named 'vtkIOFFMPEGPython' autopkgtest [12:57:25]: test python3: ---] signature.asc Description: OpenPGP digital signature
