Re: GDCM 2.0.6 is out !
On Wed, Jun 25, 2008 at 10:18 AM, Andreas Tille <tillea@rki.de> wrote:
> On Tue, 24 Jun 2008, Mathieu Malaterre wrote:
>
>>> SVN, which is in principle the debian directory. But what should I
>>> put into SVN if debian is part of the upstream source?
>>
>> I have not the slightest idea. I'll post the question on debian-dev
>> mailing list.
>
> Well, I doubt that there is a reasonable answer on debian-devel list
> (except agreement that debian dir in upstream is not a good idea) because
> there are several teams in Debian who handle their packaging repositories
> differently. If I'm not missleaded the "git-adictives" (teams that use
> git as their version control system) tend to store the complete upstream
> source in their repository which in this case would make less trouble.
> The Debian Med team is using SVN and we agreed not to store the complete
> upstream code in the repository but only the debian directory. So it
> is rather a matter of taste of the people involved and how their cooperation
> is organised to finally get out high quality packages with one or the
> other organising of the work. It just happens that our convention somehow
> conflicts stronger with your decision to store the debian dir. ;-)
understood. I'll be happy with any other system, for now it was just
very convenient for me.
>>> If you are convinced that shipping the debian dir with upstream source
>>> is not a really clever way and want to store it rather in our SVN, just
>>> tell me and I'll grant you access.
>>
>> That's a very good question too. If you do not mind, I'll try to clear
>> a couple of things first on debian-dev.
>
> Well, you are free to discuss whatever you want on debian-devel, but
> getting access to the Debian Med SVN is just a question of asking for
> an login on alioth.debian.org and once you got the account just asking
> here for inclusion into the Debian Med team - that's not a big deal.
> Then you could maintain the debian dir in the SVN and once you are
> happy with this ask for sponsoring (also here, where chances to find
> a sponsor for this specific software are higher).
Done: malat-guest
>>> CMake Error: VTK not found. Set the VTK_DIR cmake cache entry to the
>>> directory containing VTKConfig.cmake. This is either the root of the
>>> build
>>> tree, or PREFIX/lib/vtk for an installation. For VTK 4.0, this is the
>>> location of UseVTK.cmake. This is either the root of the build tree or
>>> PREFIX/include/vtk for an installation.
>>> -- Configuring done
>>> make: *** [debian/configure-python2.4-stamp] Fehler 255
>>> dpkg-buildpackage: Fehlschlag: debian/rules build gab Fehler-Exitstatus 2
>>> error: cannot find binary, udeb or source package *.deb in dist or lab
>>> (skipping)
>>
>> In Build-Depends I have set: libvtk5-dev. There is currently an issue
>> in debian stable that prevent the build as described here:
>>
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=486794
>>
>> It should work on a debian testing and later though.
>
> I was actually doing the build on a recent testing machine.
>
>> I was not sure if
>> I had to force to a minimal version of python-vtk, since I do not know
>> when the bug will be solve.
>
> So if this bug is not yet resolved it is also in testing / unstable.
> I just read your bug report and think it is void. What you are asking
> for is fixing a non-security related problem in stable which will not
> happen. Current stable (Etch) gets no new packages included except
> a security relevant problem is detected and fixed. So your bug should
> be tagged "Fixed in testing/unstable" (and it was even before you filed
> it). So no action of the maintainer is required (perhaps educating you
> as the reporter would be nice and tagging the bug as I said above).
I see :/
>> $ svn di rules
>> Index: rules
>> ===================================================================
>> --- rules (revision 3595)
>> +++ rules (working copy)
>> @@ -54,7 +54,7 @@
>> -DGDCM_USE_SYSTEM_UUID:BOOL=ON \
>> -DGDCM_USE_SYSTEM_ZLIB:BOOL=ON \
>> -DGDCM_USE_VTK:BOOL=ON \
>> - -DVTK_DIR:PATH=/usr/lib/vtk/ \
>> + -DVTK_DIR:PATH=/usr/lib/vtk-5.0/ \
>> -DPREFERRED_PYTHON_VERSION=python$*
>> touch $@
>
> Ahh, this brings the build process a little bit further. I think there
> are more issues (seems like a missing libpng12-dev Build-Dependency ...
> I'm currently testing this). The best idea to verify such problems is
> to use pbuilder.
Never heard of this tool, will look into it ASAP.
>> I'll commit the patch to svn until I find a solution where to leave
>> those debian file.
>
> :-) Here you are just facing one of the reasons why the debian dir should
> stay outside upstream release: While your code is perfectly OK you might
> be forced to change the tarball (in principle issuing a new release) just to
> fix a problem in the Debian packaging - this is just a nuisance you put
> yourself on you as upstream developer ...
That was the main argument also raised on debian-dev.
> I also detected that you are maintaining a file debian.patch in your
> root directory of the tarball. This should be handled inside the
> debian directory using quilt (prefered) or dpatch.
>
> I decided to check in your debian directory into
>
>
> http://svn.debian.org/wsvn/debian-med/trunk/packages/gdmc/trunk/debian/?rev=0&sc=0
Ok, then if you grant me write access, my first task will be to fix
the spelling :)
gdmc -> gdcm
> have a look at my changes for debian/rules (your patch above, some changes
> in the control file, which are documented in the changelog). If I try
> pbuilder to build the package this way I get:
>
> ...
> /usr/include/python2.5/pyconfig.h:488:1: warning: "HAVE_SNPRINTF" redefined
> In file included from /tmp/buildd/gdcm-2.0.6/Source/Common/gdcmTypes.h:19,
> from
> /tmp/buildd/gdcm-2.0.6/Source/DataStructureAndEncodingDefinition/gdcmTag.h:18,
> from
> /tmp/buildd/gdcm-2.0.6/Source/DataStructureAndEncodingDefinition/gdcmDataElement.h:18,
> from
> /tmp/buildd/gdcm-2.0.6/Wrapping/Python/gdcmPythonFilter.h:18,
> from
> /tmp/buildd/gdcm-2.0.6/Wrapping/Python/gdcmPythonFilter.cxx:15:
> /tmp/buildd/gdcm-2.0.6/debian/build-python2.4/Source/Common/gdcmConfigure.h:96:1:
> warning: this is the location of the previous definition
> In file included from /usr/include/python2.5/Python.h:8,
> from
> /tmp/buildd/gdcm-2.0.6/Wrapping/Python/gdcmPythonFilter.h:22,
> from
> /tmp/buildd/gdcm-2.0.6/Wrapping/Python/gdcmPythonFilter.cxx:15:
> /usr/include/python2.5/pyconfig.h:627:1: warning: "HAVE_SYS_TIME_H"
> redefined
> In file included from /tmp/buildd/gdcm-2.0.6/Source/Common/gdcmTypes.h:19,
> from
> /tmp/buildd/gdcm-2.0.6/Source/DataStructureAndEncodingDefinition/gdcmTag.h:18,
> from
> /tmp/buildd/gdcm-2.0.6/Source/DataStructureAndEncodingDefinition/gdcmDataElement.h:18,
> from
> /tmp/buildd/gdcm-2.0.6/Wrapping/Python/gdcmPythonFilter.h:18,
> from
> /tmp/buildd/gdcm-2.0.6/Wrapping/Python/gdcmPythonFilter.cxx:15:
> /tmp/buildd/gdcm-2.0.6/debian/build-python2.4/Source/Common/gdcmConfigure.h:72:1:
> warning: this is the location of the previous definition
> make[3]: Leaving directory `/tmp/buildd/gdcm-2.0.6/debian/build-python2.4'
> make[2]: *** [Utilities/VTK/CMakeFiles/vtkgdcm.dir/all] Error 2
those are only warnings the error must have been earlier (make -j4 was
hardcoded in the rules file so it takes a couple more iteration for
make to actually stop on the error).
>
>> No problem ! Thanks for your supportive feedback, I understand you are
>> very busy, but you still manage somehow to find time :)
>
> Well, we try what we can do ... ;-)
Regards,
--
Mathieu
Reply to: