Thanks for your reply. But IMO it is missing the point.
Maybe we should first reconsider the workflow that takes place.
An application, here Ginkgo CADx, is sort of querying CMake like "Could you
please tell
me which library is providing feature foo?" and CMake replies "Sure. It's
library
Source: vtk6
Severity: normal
Upstream released 7.0.0 in February.
On the one hand this is simply the current stable release and as such sure good
to have in
Debian anyway.
That aside this particular release is introducing changes regarding the header
files. So
including it in Debian would
Source: vtk6
Version: 6.3.0+dfsg1-1, 6.2.0+dfsg1-11.1
Severity: important
Compiling recent Ginkgo CADx against VTK on Debian testing yields two cmake
warnings which
suggest there are corresponding errors in the packaging of VTK.
> -- The imported target "vtkRenderingPythonTkWidgets" references
Source: gdcm
Version: 2.6.3-{6,5}
Severity: important
Compiling recent Ginkgo CADx against GDCM on Debian stretch yields two cmake
warnings which
suggest there are corresponding errors in the packaging of GDCM.
> -- The imported target "vtkgdcmsharpglue" references the file
>
Source: gl2ps
Version: 1.3.8-1.2
Severity: important
Current packages of GL2PS are providing a shared library libgl2ps.so.0.0.0 with
soname libgl2ps.so.0 but compiling upstream code from source yields a library
libgl2ps.so.1.3.8 with soname libgl2ps.so.1.
Problem is due to patches which were
5 matches
Mail list logo
