I have made ebuilds for vtk-cvs, vtkdata-cvs, cmake-cvs and vtknightlydoc. They are all modifications of the currently available ebuilds. I split vtkdata-cvs off from vtk-cvs as I could not work out how to put two cvs checkouts in one ebuild. I split vtknightlydoc off because I could not get it installed from the vtk-cvs ebuild. The vtknightlydoc ebuild is actually a very poor ebuild because the file changes daily so the md5 sum is always changing so to get it work you have to keep redoing the digest which is far from ideal - any suggestions would be most welcome. Finally I added a qt USE flag to the vtk-cvs because there is now a QVTK widget distributed with vtk. Reproducible: Always Steps to Reproduce: 1. 2. 3.
Created attachment 52083 [details] vtk-cvs ebuild
Created attachment 52084 [details] vtkdata-cvs ebuild
Created attachment 52085 [details] vtknightlydoc ebuild
Created attachment 52086 [details] cmake-cvs ebuild cmake cvs is need for the cmake support in the kdevelop-3.1.92 to work
I am sorry I did not really provide enough information about VTK initially - it is my main development library and sometimes I forget that most people have not heard of it. VTK is the visualization toolkit - on my system I have installed it in media-gfx - it is a scientific visualization library. Cmake is a cross platform make tool developed by the developers of ctk - I put it in dev-util. Kdevelop beta has some support for it - actually it is more true to say it has support for kdevelop. Anyway I suspect that the KDE team were not the right people to assign the bug to - I am not sure who is maybe gentoo-science for the vtk parts. I don't actually know if it matters - I am just hoping to clear up any confusion I generated. Chris
Created attachment 54372 [details] vtk-cvs-4.5.0.ebuild This is an improved ebuild for vtk-cvs - it now builds the python bindings correctly
>Anyway I suspect that the KDE team were not the right people to assign the bug to True.
.
But as you can read in our ebuild policy -> http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=3&chap=1#doc_chap3 cvs ebuilds should be the rare exception and there are more than enough general packages in the tree, which are not as good supported as they should. Who needs cvs ebuilds, is (or should be) able to care for them himself.