On Wed, Jun 25, 2008 at 10:18 AM, Andreas Tille <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
