GDCM 2.0.6 is out !

[malat]

I have just release GDCM 2.0.6. See link for more info:

http://gdcm.sourceforge.net/wiki/index.php/GDCM_Release_2.0#GDCM_2.0.6

I have completely rework the debian/* files so the package should be a
valid debian package out of the box.

Let me know if you find anything wrong,

Thanks,
--
Mathieu


 GDCM 2.0.6

    * Introduce the gdcm::PythonFilter (draft)
    * Fix compilation issue with mingw32 compiler on win32
    * Fix padding issue for UI
    * Add support for multiframes J2K
    * Initial support for writing compressed lossless JPEG & reversible J2K
    * vtkGDCMImageWriter would use the same UID for both Series and
Study (fixed).
    * New: vtkGDCMPolyDataReader for reading ContourData from RTSTRUCT objects
    * BUG: gdcm::Global would initialize Dicts & Defs too late
resulting in trashed structure at read time when called from multiple
threads at the same time.
    * BUG: Could not parse some PAPYRUS 3.0 file
    * BUG: would write Rescale Slope/Intercept for no-grayscale image
    * ENH: renomarlize Direction Cosines when needed.
    * BUG: Fix seg fault when Pixel Representation was missing
    * BUG: Would not rewrite correctly some invalid Philips images.
See also CheckBigEndianBug dev tool.
    * ENH: Adding debian configure files to generate proper debian
package (duplicate effort outside cmake for now).
    * ENH: Adding 3 news executable: gdcmorthoplanes, gdcm2vtk and gdcmscene
    * ENH: gdcmviewer has now an angle widget, contour widget and
balloon rep (just for fun).
    * BUG: vtkGDCMThreadedImageReader better support for ProgressEvent
and multi threads.

Release:

    * http://sourceforge.net/project/showfiles.php?group_id=137895&package_id=197047&release_id=609097


--
To UNSUBSCRIBE, email to debian-med-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Andreas Tille]

On Tue, 24 Jun 2008, Mathieu Malaterre wrote:

> I have just release GDCM 2.0.6. See link for more info:
>
> http://gdcm.sourceforge.net/wiki/index.php/GDCM_Release_2.0#GDCM_2.0.6
>
> I have completely rework the debian/* files so the package should be a
> valid debian package out of the box.

Many thanls for keeping us informed.  I'll just have a look onto this.
I don not remember whether I mentioned in previous mails that keeping
the debian directory in the upstream source is depreciated for several
reasons.  If you are interested I could try to assemble a list of
several postings on Debian related lists.  Another problem I'm currently
facing by this approach is that Debian Med packaging policy says that
only the difference to the upstream source should be kept in Debian Med
SVN, which is in principle the debian directory.  But what should I
put into SVN if debian is part of the upstream source?

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.

> Let me know if you find anything wrong,

I tried to build the package and got:

...
-- Looking for _stricmp
-- Looking for _stricmp - not found
-- Looking for _strnicmp
-- Looking for _strnicmp - not found
-- Looking for _snprintf
-- Looking for _snprintf - not found
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)


I guess the reason might be a missing build depends (but this is just a wild guess).

I'm really happy about your obvious and continuos interest in the Debian Med project
and I hope that we now can really stort working on this.  Even if I'm currently
overloaded with DebConf stuff perhaps some volunteers might start working together
with you.

Kind regards

           Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to debian-med-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Rudi Cilibrasi, Ph.D.]

Small English note:

"depreciate" means to "lower in value" whereas
"deprecate" means "to disrecommend or to recommend against something"

Best regards,

Rudi


--
To UNSUBSCRIBE, email to debian-med-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[malat]

Hi Andreas,

On Tue, Jun 24, 2008 at 10:17 PM, Andreas Tille <tillea@...> wrote:

> On Tue, 24 Jun 2008, Mathieu Malaterre wrote:
>
>> I have just release GDCM 2.0.6. See link for more info:
>>
>> http://gdcm.sourceforge.net/wiki/index.php/GDCM_Release_2.0#GDCM_2.0.6
>>
>> I have completely rework the debian/* files so the package should be a
>> valid debian package out of the box.
>
> Many thanls for keeping us informed.

np

>  I'll just have a look onto this.
> I don not remember whether I mentioned in previous mails that keeping
> the debian directory in the upstream source is depreciated for several
> reasons.  If you are interested I could try to assemble a list of
> several postings on Debian related lists.

No that's fine, I believe you.

>  Another problem I'm currently
> facing by this approach is that Debian Med packaging policy says that
> only the difference to the upstream source should be kept in Debian Med
> 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.

> 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.

>> Let me know if you find anything wrong,
>
> I tried to build the package and got:
>
> ...
> -- Looking for _stricmp
> -- Looking for _stricmp - not found
> -- Looking for _strnicmp
> -- Looking for _strnicmp - not found
> -- Looking for _snprintf
> -- Looking for _snprintf - not found
> 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 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.

> I guess the reason might be a missing build depends (but this is just a wild
> guess).

I am not clear how in the world I manage to do it, but I used an
incorrect path to UseVTK.cmake. The debian file: gdcm/debian/rules
should be modified this way:

$ 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 $@


I'll commit the patch to svn until I find a solution where to leave
those debian file.

> I'm really happy about your obvious and continuos interest in the Debian Med
> project
> and I hope that we now can really stort working on this.  Even if I'm
> currently
> overloaded with DebConf stuff perhaps some volunteers might start working
> together
> with you.

No problem ! Thanks for your supportive feedback, I understand you are
very busy, but you still manage somehow to find time :)


Regards,

--
Mathieu


--
To UNSUBSCRIBE, email to debian-med-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[malat]

Andreas,

On Tue, Jun 24, 2008 at 10:17 PM, Andreas Tille <tillea@...> wrote:

> On Tue, 24 Jun 2008, Mathieu Malaterre wrote:
>
>> I have just release GDCM 2.0.6. See link for more info:
>>
>> http://gdcm.sourceforge.net/wiki/index.php/GDCM_Release_2.0#GDCM_2.0.6
>>
>> I have completely rework the debian/* files so the package should be a
>> valid debian package out of the box.
>
> Many thanls for keeping us informed.  I'll just have a look onto this.
> I don not remember whether I mentioned in previous mails that keeping
> the debian directory in the upstream source is depreciated for several
> reasons.  If you are interested I could try to assemble a list of
> several postings on Debian related lists.  Another problem I'm currently
> facing by this approach is that Debian Med packaging policy says that
> only the difference to the upstream source should be kept in Debian Med
> SVN, which is in principle the debian directory.  But what should I
> put into SVN if debian is part of the upstream source?
>
> 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.

Apparently with the newer format any debian/ directory will simply be discarded:

http://www.mail-archive.com/debian-devel@.../msg261687.html

So that should answer your question: simply pretend my initial work on
those debian/* files does not exist. If you are happy with how I wrote
those debian/* files, then yes I could upload them on your SVN server.

Thanks,
--
Mathieu


--
To UNSUBSCRIBE, email to debian-med-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Andreas Tille]

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. ;-)

>> 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).

>> 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).
In any case

> $ 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.

> 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 ...

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

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


> 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 ... ;-)

Kind regards

         Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to debian-med-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[malat]

On Wed, Jun 25, 2008 at 10:18 AM, Andreas Tille <tillea@...> 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


--
To UNSUBSCRIBE, email to debian-med-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Andreas Tille]

On Wed, 25 Jun 2008, Mathieu Malaterre wrote:

> understood. I'll be happy with any other system, for now it was just
> very convenient for me.

Sure.  That's why I tried to explain patiently why a think which might
be convenient for the first time mighht cause problems.  It is no shame
in it if you as a Debian newcomer handle things this way.  My suggestion
would be to release another point release without this dir and all things
are fine.

> Done: malat-guest

... is now a member of Debian-Med team and have commit permissions.

> Never heard of this tool, will look into it ASAP.

It is very useful because it builds in a clean chroot system.  You
have no chance to forget build dependencies which are often installed
opn developer machines and thus the build works on the local developer
machine.  Pbuilder has a clean chroot with very basic packages, installs
all Build dependencies automatically and then tries to compile.  If a
build fails because a build-depends is missing you will immediately
notice.  Moreover you can build against different distributions when
maintaining a stable / testting / unstable / whatever pbuilder chroot.

>> 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

Uhmm, sorry.  I'm so addicted to mc that I alsways tend to spell the
combination of 'c' and 'm' as "mc" - please forgive me even future misspellings
of this. ;-)  And, for sure, I fixed the problem caused ba me myself ...

> 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).

Ahh, OK, I trust you will be able to fix this problem because you know the
code at best ...

Kind regards

         Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to debian-med-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[malat]

On Wed, Jun 25, 2008 at 11:22 AM, Andreas Tille <tillea@...> wrote:

> On Wed, 25 Jun 2008, Mathieu Malaterre wrote:
>
>> understood. I'll be happy with any other system, for now it was just
>> very convenient for me.
>
> Sure.  That's why I tried to explain patiently why a think which might
> be convenient for the first time mighht cause problems.  It is no shame
> in it if you as a Debian newcomer handle things this way.  My suggestion
> would be to release another point release without this dir and all things
> are fine.
>
>> Done: malat-guest

Thanks !

> ... is now a member of Debian-Med team and have commit permissions.
>
>> Never heard of this tool, will look into it ASAP.
>
> It is very useful because it builds in a clean chroot system.  You
> have no chance to forget build dependencies which are often installed
> opn developer machines and thus the build works on the local developer
> machine.  Pbuilder has a clean chroot with very basic packages, installs
> all Build dependencies automatically and then tries to compile.  If a
> build fails because a build-depends is missing you will immediately
> notice.  Moreover you can build against different distributions when
> maintaining a stable / testting / unstable / whatever pbuilder chroot.

Nice ! when writing the control file, I was wondering how did people
manage to list all dependencies properly.

>>>
>>> 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
>
> Uhmm, sorry.  I'm so addicted to mc that I alsways tend to spell the
> combination of 'c' and 'm' as "mc" - please forgive me even future
> misspellings
> of this. ;-)  And, for sure, I fixed the problem caused ba me myself ...

cool.

>> 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).
>
> Ahh, OK, I trust you will be able to fix this problem because you know the
> code at best ...

Yup :)
could someone please give a crash course on how this whole thing works ?
I have been reading the section:

Using subversion to group-maintain packages
http://wiki.debian.org/DebianMed


So on my machine this means:

  cd /tmp
  svn co svn+ssh://malat-guest@.../svn/debian-med/
  alias svn-b='svn-buildpackage -us -uc -rfakeroot --svn-ignore'
  cd debian-med/trunk/packages/gdcm/trunk
  svn-b

I am getting:

...
        tagsDir: /tmp/debian/debian-med/trunk/packages/gdcm/tags
        tagsUrl:
svn+ssh://malat-guest@.../svn/debian-med/trunk/packages/gdcm/tags
        trunkDir: /tmp/debian/debian-med/trunk/packages/gdcm/trunk
        trunkUrl:
svn+ssh://malat-guest@.../svn/debian-med/trunk/packages/gdcm/trunk
dpkg-checkbuilddeps
fakeroot debian/rules clean || debian/rules clean
dh_testdir
dh_testroot
rm -f debian/configure*stamp debian/build*stamp
rm -rf debian/build*
dh_clean
/tmp/debian/debian-med/trunk/packages/gdcm/build-area/gdcm-2.0.6
exists, renaming to
/tmp/debian/debian-med/trunk/packages/gdcm/build-area/gdcm-2.0.6.obsolete.0.879016953361319
mkdir -p /tmp/debian/debian-med/trunk/packages/gdcm/build-area/gdcm-2.0.6/debian
 cp --parents -laf debian/libvtkgdcm-dev.install debian/control
debian/libgdcm2.docs debian/copyright debian/python-gdcm.install
debian/pycompat debian/libgdcm2.install <10 more arguments>
dpkg-buildpackage -us -uc -rfakeroot
dpkg-buildpackage: source package is gdcm
dpkg-buildpackage: source version is 2.0.6
dpkg-buildpackage: source changed by Andreas Tille <tille@...>
dpkg-buildpackage: host architecture amd64
dpkg-buildpackage: source version without epoch 2.0.6
 fakeroot debian/rules clean
dh_testdir
dh_testroot
rm -f debian/configure*stamp debian/build*stamp
rm -rf debian/build*
dh_clean
 dpkg-source -b gdcm-2.0.6
dpkg-source: warning: unknown information field `Vcs-Svn' in input
data in general section of control info file
dpkg-source: warning: unknown information field `Homepage' in input
data in general section of control info file
dpkg-source: warning: unknown information field `Vcs-Browser' in input
data in general section of control info file
dpkg-source: warning: unknown information field `Dm-Upload-Allowed' in
input data in general section of control info file
dpkg-source: building gdcm in gdcm_2.0.6.tar.gz
dpkg-source: building gdcm in gdcm_2.0.6.dsc
 debian/rules build
dh_testdir
[ -d /tmp/debian/debian-med/trunk/packages/gdcm/build-area/gdcm-2.0.6/debian/build-python2.4
] || mkdir /tmp/debian/debian-med/trunk/packages/gdcm/build-area/gdcm-2.0.6/debian/build-python2.4
cd /tmp/debian/debian-med/trunk/packages/gdcm/build-area/gdcm-2.0.6/debian/build-python2.4
&& cmake /tmp/debian/debian-med/trunk/packages/gdcm/build-area/gdcm-2.0.6
-DCMAKE_INSTALL_PREFIX="/usr" \
                -DCMAKE_C_COMPILER="/usr/bin/cc" \
                -DCMAKE_C_FLAGS="-g -Wall -O2" \
                -DCMAKE_SKIP_RPATH=ON \
                -DCMAKE_VERBOSE_MAKEFILE=ON \
                -DGDCM_BUILD_APPLICATIONS=ON \
                -DGDCM_BUILD_SHARED_LIBS=ON \
                -DGDCM_WRAP_PYTHON=ON \
                -DGDCM_BUILD_TESTING:BOOL=OFF \
                -DCMAKE_BUILD_TYPE:STRING=Release \
                -DGDCM_USE_SYSTEM_EXPAT:BOOL=ON \
                -DGDCM_USE_SYSTEM_UUID:BOOL=ON \
                -DGDCM_USE_SYSTEM_ZLIB:BOOL=ON \
                -DGDCM_USE_VTK:BOOL=ON \
                -DVTK_DIR:PATH=/usr/lib/vtk-5.0/ \
                -DPREFERRED_PYTHON_VERSION=python2.4
CMake Error: The source directory
"/tmp/debian/debian-med/trunk/packages/gdcm/build-area/gdcm-2.0.6"
does not appear to contain CMakeLists.txt.
Specify --help for usage, or press the help button on the CMake GUI.
make: *** [debian/configure-python2.4-stamp] Error 254
Command dpkg-buildpackage -us -uc -rfakeroot failed in
/tmp/debian/debian-med/trunk/packages/gdcm/build-area/gdcm-2.0.6, how
to continue now? [Qri?]:
Aborting.
...

I am on a debian stable machine, do I need to simply update
dpkg-source from testing ?

Thanks,

--
Mathieu


--
To UNSUBSCRIBE, email to debian-med-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[malat]

I see, I need to implement the missing rule in 'rules':

get-orig-source:
        . debian/get-orig-source


On Wed, Jun 25, 2008 at 12:01 PM, Mathieu Malaterre
<mathieu.malaterre@...> wrote:

> On Wed, Jun 25, 2008 at 11:22 AM, Andreas Tille <tillea@...> wrote:
>> On Wed, 25 Jun 2008, Mathieu Malaterre wrote:
>>
>>> understood. I'll be happy with any other system, for now it was just
>>> very convenient for me.
>>
>> Sure.  That's why I tried to explain patiently why a think which might
>> be convenient for the first time mighht cause problems.  It is no shame
>> in it if you as a Debian newcomer handle things this way.  My suggestion
>> would be to release another point release without this dir and all things
>> are fine.
>>
>>> Done: malat-guest
>
> Thanks !
>
>> ... is now a member of Debian-Med team and have commit permissions.
>>
>>> Never heard of this tool, will look into it ASAP.
>>
>> It is very useful because it builds in a clean chroot system.  You
>> have no chance to forget build dependencies which are often installed
>> opn developer machines and thus the build works on the local developer
>> machine.  Pbuilder has a clean chroot with very basic packages, installs
>> all Build dependencies automatically and then tries to compile.  If a
>> build fails because a build-depends is missing you will immediately
>> notice.  Moreover you can build against different distributions when
>> maintaining a stable / testting / unstable / whatever pbuilder chroot.
>
> Nice ! when writing the control file, I was wondering how did people
> manage to list all dependencies properly.
>
>
>>>>
>>>> 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
>>
>> Uhmm, sorry.  I'm so addicted to mc that I alsways tend to spell the
>> combination of 'c' and 'm' as "mc" - please forgive me even future
>> misspellings
>> of this. ;-)  And, for sure, I fixed the problem caused ba me myself ...
>
> cool.
>
>>> 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).
>>
>> Ahh, OK, I trust you will be able to fix this problem because you know the
>> code at best ...
>
> Yup :)
> could someone please give a crash course on how this whole thing works ?
> I have been reading the section:
>
> Using subversion to group-maintain packages
> http://wiki.debian.org/DebianMed
>
>
> So on my machine this means:
>
>  cd /tmp
>  svn co svn+ssh://malat-guest@.../svn/debian-med/
>  alias svn-b='svn-buildpackage -us -uc -rfakeroot --svn-ignore'
>  cd debian-med/trunk/packages/gdcm/trunk
>  svn-b
>
> I am getting:
>
> ...
>        tagsDir: /tmp/debian/debian-med/trunk/packages/gdcm/tags
>        tagsUrl:
> svn+ssh://malat-guest@.../svn/debian-med/trunk/packages/gdcm/tags
>        trunkDir: /tmp/debian/debian-med/trunk/packages/gdcm/trunk
>        trunkUrl:
> svn+ssh://malat-guest@.../svn/debian-med/trunk/packages/gdcm/trunk
> dpkg-checkbuilddeps
> fakeroot debian/rules clean || debian/rules clean
> dh_testdir
> dh_testroot
> rm -f debian/configure*stamp debian/build*stamp
> rm -rf debian/build*
> dh_clean
> /tmp/debian/debian-med/trunk/packages/gdcm/build-area/gdcm-2.0.6
> exists, renaming to
> /tmp/debian/debian-med/trunk/packages/gdcm/build-area/gdcm-2.0.6.obsolete.0.879016953361319
> mkdir -p /tmp/debian/debian-med/trunk/packages/gdcm/build-area/gdcm-2.0.6/debian
>  cp --parents -laf debian/libvtkgdcm-dev.install debian/control
> debian/libgdcm2.docs debian/copyright debian/python-gdcm.install
> debian/pycompat debian/libgdcm2.install <10 more arguments>
> dpkg-buildpackage -us -uc -rfakeroot
> dpkg-buildpackage: source package is gdcm
> dpkg-buildpackage: source version is 2.0.6
> dpkg-buildpackage: source changed by Andreas Tille <tille@...>
> dpkg-buildpackage: host architecture amd64
> dpkg-buildpackage: source version without epoch 2.0.6
>  fakeroot debian/rules clean
> dh_testdir
> dh_testroot
> rm -f debian/configure*stamp debian/build*stamp
> rm -rf debian/build*
> dh_clean
>  dpkg-source -b gdcm-2.0.6
> dpkg-source: warning: unknown information field `Vcs-Svn' in input
> data in general section of control info file
> dpkg-source: warning: unknown information field `Homepage' in input
> data in general section of control info file
> dpkg-source: warning: unknown information field `Vcs-Browser' in input
> data in general section of control info file
> dpkg-source: warning: unknown information field `Dm-Upload-Allowed' in
> input data in general section of control info file
> dpkg-source: building gdcm in gdcm_2.0.6.tar.gz
> dpkg-source: building gdcm in gdcm_2.0.6.dsc
>  debian/rules build
> dh_testdir
> [ -d /tmp/debian/debian-med/trunk/packages/gdcm/build-area/gdcm-2.0.6/debian/build-python2.4
> ] || mkdir /tmp/debian/debian-med/trunk/packages/gdcm/build-area/gdcm-2.0.6/debian/build-python2.4
> cd /tmp/debian/debian-med/trunk/packages/gdcm/build-area/gdcm-2.0.6/debian/build-python2.4
> && cmake /tmp/debian/debian-med/trunk/packages/gdcm/build-area/gdcm-2.0.6
> -DCMAKE_INSTALL_PREFIX="/usr" \
>                -DCMAKE_C_COMPILER="/usr/bin/cc" \
>                -DCMAKE_C_FLAGS="-g -Wall -O2" \
>                -DCMAKE_SKIP_RPATH=ON \
>                -DCMAKE_VERBOSE_MAKEFILE=ON \
>                -DGDCM_BUILD_APPLICATIONS=ON \
>                -DGDCM_BUILD_SHARED_LIBS=ON \
>                -DGDCM_WRAP_PYTHON=ON \
>                -DGDCM_BUILD_TESTING:BOOL=OFF \
>                -DCMAKE_BUILD_TYPE:STRING=Release \
>                -DGDCM_USE_SYSTEM_EXPAT:BOOL=ON \
>                -DGDCM_USE_SYSTEM_UUID:BOOL=ON \
>                -DGDCM_USE_SYSTEM_ZLIB:BOOL=ON \
>                -DGDCM_USE_VTK:BOOL=ON \
>                -DVTK_DIR:PATH=/usr/lib/vtk-5.0/ \
>                -DPREFERRED_PYTHON_VERSION=python2.4
> CMake Error: The source directory
> "/tmp/debian/debian-med/trunk/packages/gdcm/build-area/gdcm-2.0.6"
> does not appear to contain CMakeLists.txt.
> Specify --help for usage, or press the help button on the CMake GUI.
> make: *** [debian/configure-python2.4-stamp] Error 254
> Command dpkg-buildpackage -us -uc -rfakeroot failed in
> /tmp/debian/debian-med/trunk/packages/gdcm/build-area/gdcm-2.0.6, how
> to continue now? [Qri?]:
> Aborting.
> ...
>
> I am on a debian stable machine, do I need to simply update
> dpkg-source from testing ?
>
> Thanks,
>
> --
> Mathieu
>

--
Mathieu


--
To UNSUBSCRIBE, email to debian-med-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...