On Wed, 2010-02-17 at 11:59 +0100, Andre Espaze wrote:
> > I think this is getting into the technical details, so it is probably
> > not so interesting to the debian-science list. I'm afraid I can't
> > figure out a way to set up an account on ww.python-science.org; if you
> > can let me know how then I'll go ahead and use that.
> A message with your first and last names needs to be send to:
> nicolas.chauvat@logilab.fr
> However Nicolas just told me that Sylvestre would prefer to use the
> Debian tracking system. Do you know where should I move the work from
> http://www.python-science.org/project/salome-packaging?
Until salome is uploaded into Debian, it will not be possible to use the
bug tracking system for individual issues. At this point, the only
"bug" in Debian is that salome isn't there -- #457075. :-)
> > In the meantime, I'd like to let you know how to build the versions of
> > dependencies I'm using.
> >
> > I don't know why the med-fichier tests are failing with HDF5 1.8.4. To
> > build my patched hdf5 package for Debian, you can do the following (in a
> > Debian unstable chroot):
> >
> > apt-get source hdf5
> > rm -rf hdf5-1.8.4/debian
> > svn co svn://svn.debian.org/svn/pkg-grass/packages/hdf5
> > cp -a hdf5/trunk/debian hdf5-1.8.4/
> > wget 'http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=27;filename=hdf5-default-mpi.patch;att=1;bug=510057' -O hdf5-default-mpi.patch
> > cd hdf5-1.8.4/
> > patch -p0 < ../hdf5-default-mpi.patch
> > dpkg-buildpackage
> >
> > Install the resulting .deb packages, particularly libhdf5-mpi-dev which
> > should depend on libhdf5-openmpi-dev. Then you can build the latest
> > med-fichier using:
> >
> > git clone http://git.debian.org/git/debian-science/packages/med-fichier.git -b master
> > cd med-fichier
> > git-buildpackage
> >
> > It should all build correctly. At this point, does this version of
> > med-fichier pass or fail the tests?
> All the tests pass, that is really great.
Excellent! I'm glad to hear it. I sent my patches to med-fichier
upstream, and they let me know they have already included my changes
into their 3.0.0 version under development.
> I would like to add such
> documentation do the salome.git repo, inside the debian directory. I
> have added the following ticket:
> http://www.python-science.org/ticket/1403
> that will certainly move.
Good point. I haven't used the Debian Science Wiki, perhaps that's a
good place to put such documentation at this point.
> > You can get and build my latest salome package by the same "git clone"
> > command but substitute salome for med-fichier. It still needs a lot of
> > tweaking before it is ready to upload into Debian unstable. And first
> > the patched HDF5 package needs to go in, along with the new med-fichier.
> I have succeeded to build salome at revision
> 181964c525693f410d01646a616e5d94f05c7c9d but I got only KERNEL and GUI
> running out of the box at the end. I plan to investigate on the GEOM
> runtime problem first, is it allright for you?
Yes. But please try re-cloning it, I have made a lot of progress, and
some things might work now that didn't before. I think your tickets
1398, 1400 and 1402 are fixed now.
My suspicion is that the geom issue might due to incorrect directory
usage for the OpenCascade data files. I've just added tests for their
location in check_cas.m4, and will change
KERNEL/bin/appliskel/env.d/envProducts.sh to use the new CAS_LIBDIR and
CAS_DATADIR variables accordingly (will need to move it to
envProducts.sh.in and have configure generate the .sh file).
I believe all of this should work using both the standard OpenCascade
build method and the Debian package, so the resulting patch should be
acceptable to upstream. Please let me know if you see anything which
does not satisfy this goal.
> Then I have some questions regarding the packaging workflow. My main
> problem is that running::
>
> git-buildpackage --git-ignore-new
>
> cleans everything and start from scratch. By the way I had to add
> the '--git-ignore-new' option but did not understand why. I finally use:
>
> ./debian/rules build
>
> for building everything after small changes. And:
>
> ./debian/rules install
>
> for then testing the updated version in debian/tmp.
git-buildpackage is very strict about having a pristine tree at the
start of the build. I have only just finished getting "fakeroot
debian/rules clean" to restore the tree to the original state so it will
work properly.
The workflow should go something like this:
1. git-buildpackage (which applies the patches and builds)
2. If it doesn't finish building, fix build issues, using quilt to
apply changes to the right patches (see below). Keep using make
and make install until it works, then finish package building
using fakeroot debian/rules binary
3. Install and test the package, and fix details, again using quilt
to apply changes to the right patches.
4. fakeroot debian/rules clean
5. quilt pop -a
6. rm -rf .pc
7. Commit changes to the local git repository, which should only be
in the debian directory. (This can also be done after 2 or 3 if
it's easier to separate out the changes into multiple commits at
that step.)
8. Go back to step 1 and try again. If git-buildpackage doesn't
work, there's something wrong with the clean process.
> The step that I
> did not find is how to apply the series of patch once I pull from
> http://git.debian.org/git/debian-science/packages/salome.git
> Reading:
> http://www.debian.org/doc/maint-guide/ch-build.en.html#s-completebuild
> I did not find the tool. I first thought about the dpatch candidate but
> the command is not installed on my system so I wonder how git-buildpackage
> works.
This package uses the quilt system to manage its patches, which is
becoming the most popular way to do so. Its documentation is in the
file /usr/share/doc/quilt/quilt.html with a nice summary in the
file /usr/share/doc/quilt/README.source .
I like it because it is very easy to put specific changes in the right
patches using quilt, and to manage interactions between patches.
Regards,
Adam
--
GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6
Engineering consulting with open source tools
http://www.opennovation.com/
Attachment:
signature.asc
Description: This is a digitally signed message part