Community Packages

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#43454 - [vtk] vtkjsoncpp.cmake adds a non-existing path to vtkjsoncpp_INCLUDE_DIRS

Attached to Project: Community Packages
Opened by Maarten de Vries (de-vri-es) - Thursday, 15 January 2015, 12:26 GMT
Last edited by Doug Newgard (Scimmia) - Tuesday, 02 June 2015, 19:26 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Ray Rashif (schivmeister)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
/usr/lib/cmake/vtk-6.1/Modules/vtkjsoncpp.cmake adds a non-existing path to vtkjsoncpp_INCLUDE_DIRS
The path in question is `/usr/include/jsoncpp'.

It is added on line 4:
set(vtkjsoncpp_INCLUDE_DIRS "${VTK_INSTALL_PREFIX}/include/vtk-6.1;/usr/include/jsoncpp")

The non-existing path is breaking an AUR package on my system (ros-indigo-pcl-ros to be precise).


Additional info:
* package version: vtk-6.1.0-7
This task depends upon

Closed by  Doug Newgard (Scimmia)
Tuesday, 02 June 2015, 19:26 GMT
Reason for closing:  Fixed
Comment by Maarten de Vries (de-vri-es) - Thursday, 15 January 2015, 12:31 GMT
Oops, how can I enter a summary after reporting the issue?
Comment by Maarten de Vries (de-vri-es) - Thursday, 15 January 2015, 12:37 GMT
Also, it seems that file is part of upstream, so this is the wrong place to report it then I guess.
Comment by Ray Rashif (schivmeister) - Wednesday, 29 April 2015, 18:26 GMT
Sorry for the delay in getting to this, but this sounds to me like bad behaviour of the program that is failing because of a non-existing path. Such issues crop up once in a while, but the reality is that paths are not guaranteed to exist.

However, there are rare times when there is no alternative, so this depends on the kind of use, i.e. it depends on which of the upstreams are willing to make a change towards this cause.
Comment by Maarten de Vries (de-vri-es) - Thursday, 30 April 2015, 16:11 GMT
It looks like it has been fixed already though. Possibly a rebuild was all that was needed?

I didn't really notice since I edited the file manually, but it now lists /usr/include instead of /usr/include/jsoncpp

Loading...