Debian Packaging - Revision history

MarcoNolden: /* Related Issues and Pull Requests on Github */

2014-12-23T10:51:34Z

Related Issues and Pull Requests on Github

← Older revision		Revision as of 06:51, 23 December 2014
Line 10:		Line 10:
	== Related Issues and Pull Requests on Github ==		== Related Issues and Pull Requests on Github ==

	https://github.com/commontk/CTK/issues/65		[RESOLVED] https://github.com/commontk/CTK/issues/65

	https://github.com/commontk/CTK/pull/158		[RESOLVED] https://github.com/commontk/CTK/pull/158

	== Working configuration ==		== Working configuration ==

2014-09-19T12:00:28Z

VTK

← Older revision		Revision as of 08:00, 19 September 2014
Line 138:		Line 138:

	CTK Visualization Core compiles with VTK 5.8, just missing one small functionality.		CTK Visualization Core compiles with VTK 5.8, just missing one small functionality.

			There is an issue with VTK linking which is not totally clear, see

			http://debian.2.n7.nabble.com/Bug-747436-libvtk6-Libraries-are-possibly-underlinked-td3249140.html

	=== QtSoap ===		=== QtSoap ===

2014-05-06T22:18:59Z

ITK

← Older revision		Revision as of 18:18, 6 May 2014
Line 105:		Line 105:

	http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724711		http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724711

			The ITK package also recently [http://anonscm.debian.org/viewvc/debian-med/trunk/packages/insighttoolkit/trunk/debian/control?r1=15674&r2=15675& added a dependency] to an older version of DCMTK. Currently we assume CTK will use the new DCMTK package which is still in experimental.

	We need ITK for the <tt>CTK_LIB_ImageProcessing/ITK/Core</tt> setting. The options are		We need ITK for the <tt>CTK_LIB_ImageProcessing/ITK/Core</tt> setting. The options are

2013-11-08T09:00:37Z

Proposed package structure

← Older revision		Revision as of 05:00, 8 November 2013
Line 68:		Line 68:
	libCTKWidgetsPlugins.so		libCTKWidgetsPlugins.so
	libCTKDICOMWidgetsPlugins.so		libCTKDICOMWidgetsPlugins.so
			...
	/usr/include/ctk/:		/usr/include/ctk/:
	# all public library headers		# all public library headers

2013-11-08T09:00:20Z

Proposed package structure

← Older revision		Revision as of 05:00, 8 November 2013
Line 68:		Line 68:
	libCTKWidgetsPlugins.so		libCTKWidgetsPlugins.so
	libCTKDICOMWidgetsPlugins.so		libCTKDICOMWidgetsPlugins.so

	/usr/include/ctk/:		/usr/include/ctk/:
	# all public library headers		# all public library headers
Line 82:		Line 83:
	ctkDICOM		ctkDICOM
	ctkCommandLineModuleExplorer		ctkCommandLineModuleExplorer

	== Open issues ==		== Open issues ==
	* CTK side		* CTK side

2013-11-06T20:16:58Z

Open issues

← Older revision		Revision as of 16:16, 6 November 2013
Line 86:		Line 86:
	* CTK side		* CTK side
	** installation of CMake files: make CTKConfig.cmake and UseCTK.cmake relocatable (after some cleanup), see also https://github.com/commontk/CTK/pull/158#issuecomment-6955188		** installation of CMake files: make CTKConfig.cmake and UseCTK.cmake relocatable (after some cleanup), see also https://github.com/commontk/CTK/pull/158#issuecomment-6955188
			*** For examples, see [https://github.com/commontk/DCMTK/commit/f461865d1759854db56e4c840991c81c77e45bb9 commontk/DCMTK@f461865d] and [https://github.com/davidsansome/python-cmake-buildsystem/commit/3f504d8be5b41086f615494517ddd2cf66f4d365 python-cmake-buildsystem@3f504d8b]
			*** CMake wiki page: http://www.cmake.org/Wiki/CMake/Tutorials/How_to_create_a_ProjectConfig.cmake_file
	** make DGraph work for external projects without a CTK source tree		** make DGraph work for external projects without a CTK source tree
	** test whether CTK CMake macros work with an installation tree depicted above		** test whether CTK CMake macros work with an installation tree depicted above

2013-11-06T18:24:56Z

Dependencies with potential problems

← Older revision		Revision as of 14:24, 6 November 2013
Line 96:		Line 96:

	== Dependencies with potential problems ==		== Dependencies with potential problems ==

			=== ITK ===

			ITK 4 in Debian has limited architecture support:

			http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724711

			We need ITK for the <tt>CTK_LIB_ImageProcessing/ITK/Core</tt> setting. The options are
			* disable the option and move the class to Slicer or other packages needing it
			* enable the option conditionally on supported platform
			* create separate packages for CTK, so most packages can be supported on all platforms

	=== DCMTK ===		=== DCMTK ===

2013-11-05T18:51:04Z

Working configuration

← Older revision		Revision as of 14:51, 5 November 2013
Line 28:		Line 28:
	CTK_ENABLE_DICOM:BOOL=ON		CTK_ENABLE_DICOM:BOOL=ON
	CTK_ENABLE_PluginFramework:BOOL=ON		CTK_ENABLE_PluginFramework:BOOL=ON
			CTK_ENABLE_Python_Wrapping:BOOL=ON
	CTK_ENABLE_Widgets:BOOL=ON		CTK_ENABLE_Widgets:BOOL=ON
	CTK_LIB_CommandLineModules/Backend/FunctionPointer:BOOL=ON		CTK_LIB_CommandLineModules/Backend/FunctionPointer:BOOL=ON

2013-11-05T15:47:09Z

Open issues

← Older revision		Revision as of 11:47, 5 November 2013
Line 92:		Line 92:
	** currently the installation paths are changed in the debian/rules files, e.g. removing the "ctk-0.1" part of the path. Is that ok or should we try to solve this as well upstream?		** currently the installation paths are changed in the debian/rules files, e.g. removing the "ctk-0.1" part of the path. Is that ok or should we try to solve this as well upstream?
	** should we wait for the 3.6.1 experimental package to enter "sid" or try to create some workarounds in CTK and/or the Debian package?		** should we wait for the 3.6.1 experimental package to enter "sid" or try to create some workarounds in CTK and/or the Debian package?
			** if the Debian rules map files from the install tree to a different directory layout in the Debian package, how is this going to play well together with CTKConfig.cmake?

	== Dependencies with potential problems ==		== Dependencies with potential problems ==

2013-11-05T14:04:00Z

Open issues

← Older revision		Revision as of 10:04, 5 November 2013
Line 91:		Line 91:
	** do we want to create separate packages for the various topics? (libctk-core, libctk-dicom, libctk-cli, ... )		** do we want to create separate packages for the various topics? (libctk-core, libctk-dicom, libctk-cli, ... )
	** currently the installation paths are changed in the debian/rules files, e.g. removing the "ctk-0.1" part of the path. Is that ok or should we try to solve this as well upstream?		** currently the installation paths are changed in the debian/rules files, e.g. removing the "ctk-0.1" part of the path. Is that ok or should we try to solve this as well upstream?
			** should we wait for the 3.6.1 experimental package to enter "sid" or try to create some workarounds in CTK and/or the Debian package?

	== Dependencies with potential problems ==		== Dependencies with potential problems ==