Bug#586149: Please consider the usage of update-alternatives for hdf5 libraries

2012-02-25 Thread Adam C Powell IV
Hi,

There's a better way to do this by just having different shared library
file names and sonames for each of the shared library packages.  Then
the -dev packages can conflict, while one can install multiple packages
using the different shared libraries simultaneously, not one-at-a-time
as update-alternatives would do.

Note this would also allow simultaneous install of hdf5-tools and
libhdf5-mpi-dev which is required to build several HDF5 reverse-depends,
such as med-fichier.  This represents a major regression vs. 1.8.6 and
should be fixed as soon as possible.

I'll work on a patch tomorrow and will post it to this bug.

-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Engineering consulting with open source tools
http://www.opennovation.com/


signature.asc
Description: This is a digitally signed message part
___
Pkg-grass-devel mailing list
Pkg-grass-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-grass-devel

Bug#586149: Please consider the usage of update-alternatives for hdf5 libraries

2012-02-25 Thread Adam C Powell IV
severity 586149 serious
retitle 586149 Conflict between hdf5-tools and libhdf5-mpi-dev prevents several 
packages from building
block 661301 by 586149
thanks

Hi again,

Because this causes other packages to FTBFS, it really needs to be an RC
bug.

-Adam

On Sun, 2012-02-26 at 00:12 -0500, Adam C Powell IV wrote:
 Hi,
 
 There's a better way to do this by just having different shared library
 file names and sonames for each of the shared library packages.  Then
 the -dev packages can conflict, while one can install multiple packages
 using the different shared libraries simultaneously, not one-at-a-time
 as update-alternatives would do.
 
 Note this would also allow simultaneous install of hdf5-tools and
 libhdf5-mpi-dev which is required to build several HDF5 reverse-depends,
 such as med-fichier.  This represents a major regression vs. 1.8.6 and
 should be fixed as soon as possible.
 
 I'll work on a patch tomorrow and will post it to this bug.
 
 -Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Engineering consulting with open source tools
http://www.opennovation.com/


signature.asc
Description: This is a digitally signed message part
___
Pkg-grass-devel mailing list
Pkg-grass-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-grass-devel

Re: paraview and gmsh are not installable together, hdf5-issue.

2012-02-15 Thread Adam C Powell IV
Hi Anton,

[Just addressing d-s-m since I think we're all subscribed, and adding
the HDF5 maintainers.]

On Wed, 2012-02-15 at 21:00 +0100, Anton Gladky wrote:
 Hi all,
 
 there is a problem with installing paraview and gmsh together in sid now.
 gmsh requires libpetsc3.2, which is dependent on libhdf5-openmpi-7.
 
 paraview is dependent on hdf5-7, which is conflicting with 
 libhdf5-openmpi-7.

There's a similar problem with the MED library: it build-depends on
libhdf5-mpi-dev, which depends on libhdf5-openmpi-7, and hdf5-tools,
which depends on libhdf5-7.

 Any idea how to solve it?

Given that Paraview and PETSc are basically parallel (can run on 1 CPU
but are really built for more; MED is in the same category), I think it
makes sense for them both to link with libhdf5-openmpi-7.  So if
Paraview builds with libhdf5-mpi-dev that should solve this problem --
unless it requires hdf5-tools to build like MED.

Here are two other ways to solve the problem:
  * Change the sonames of the -openmpi, -mpich[2] and -lam HDF5
libraries so libhdf5-7 does not conflict with libhdf5-openmpi-7
etc.
  * Make a new hdf5-mpi-tools package, or a set of four (one for
each MPI implementation) with a meta-package depending on the
arch-specific MPI implementation.

HDF5 team, what do you think?  I'd be happy to propose a patch for
either of the above remedies.

-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Engineering consulting with open source tools
http://www.opennovation.com/


signature.asc
Description: This is a digitally signed message part
___
Pkg-grass-devel mailing list
Pkg-grass-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-grass-devel

[DebianGIS-dev] Bug#604714: libhdf5-mpi-dev: Wrong MPI dependency on LAM platforms

2010-11-23 Thread Adam C Powell IV
Package: libhdf5-mpi-dev
Version: 1.8.4-patch1-2
Severity: important
Tags: patch

Greetings,

The libhdf5-mpi-dev package depends on libopenmpi-dev whether the
platform defaults to openmpi or lam.  This is because it checks
the /etc/alternatives symlink to mpi, which will always point to openmpi
for hdf5, because it build-depends on all of the MPI implementations,
and OpenMPI has the highest priority.

(This was my mistake in copying the old PETSc MPI rule; PETSc's build
process installs only the arch's default MPI so there's only
one /etc/alternatives candidate.)

The attached patch vs. current SVN checks the dependency of the
mpi-default-dev package instead, so it is always consistent with
mpi-defaults.

Thanks,
Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Engineering consulting with open source tools
http://www.opennovation.com/
Index: trunk/debian/changelog
===
--- trunk/debian/changelog	(revision 2951)
+++ trunk/debian/changelog	(working copy)
@@ -1,3 +1,11 @@
+hdf5 (1.8.4-patch1-3) unstable; urgency=low
+
+  [ Adam C. Powell, IV ]
+  * Correct the libhdf5-mpi-dev dependency on the default MPI version
+(closes: #6x).
+
+ --
+
 hdf5 (1.8.4-patch1-2) unstable; urgency=low
 
   [ Adam C. Powell, IV ]
Index: trunk/debian/rules
===
--- trunk/debian/rules	(revision 2951)
+++ trunk/debian/rules	(working copy)
@@ -22,7 +22,7 @@
 DEB_BUILD_GNU_TYPE  ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
 DEB_BUILD_ARCH  ?= $(shell dpkg-architecture -qDEB_BUILD_ARCH)
 
-DEFAULT_MPI=$(shell readlink /etc/alternatives/mpi | sed s/usr//g | sed s/include//g | sed s/lib//g | sed s/\\///g)
+DEFAULT_MPI=$(shell dpkg -s mpi-default-dev | grep Depends | sed s/Depends: lib// | sed s/-dev// | sed s/lam4/lam/)
 
 patch: patch-stamp
 patch-stamp:


signature.asc
Description: This is a digitally signed message part
___
Pkg-grass-devel mailing list
Pkg-grass-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-grass-devel

[DebianGIS-dev] Bug#604714: libhdf5-mpi-dev: Wrong MPI dependency on LAM platforms

2010-11-23 Thread Adam C Powell IV
Hello again,

Please discard the last patch, a better one is attached.

-Adam

On Tue, 2010-11-23 at 13:57 -0500, Adam C Powell IV wrote:
 Package: libhdf5-mpi-dev
 Version: 1.8.4-patch1-2
 Severity: important
 Tags: patch
 
 Greetings,
 
 The libhdf5-mpi-dev package depends on libopenmpi-dev whether the
 platform defaults to openmpi or lam.  This is because it checks
 the /etc/alternatives symlink to mpi, which will always point to openmpi
 for hdf5, because it build-depends on all of the MPI implementations,
 and OpenMPI has the highest priority.
 
 (This was my mistake in copying the old PETSc MPI rule; PETSc's build
 process installs only the arch's default MPI so there's only
 one /etc/alternatives candidate.)
 
 The attached patch vs. current SVN checks the dependency of the
 mpi-default-dev package instead, so it is always consistent with
 mpi-defaults.
 
 Thanks,
 Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Engineering consulting with open source tools
http://www.opennovation.com/
Index: trunk/debian/changelog
===
--- trunk/debian/changelog	(revision 2951)
+++ trunk/debian/changelog	(working copy)
@@ -1,3 +1,11 @@
+hdf5 (1.8.4-patch1-3) unstable; urgency=low
+
+  [ Adam C. Powell, IV ]
+  * Correct the libhdf5-mpi-dev dependency on the default MPI version
+(closes: #604714).
+
+ --
+
 hdf5 (1.8.4-patch1-2) unstable; urgency=low
 
   [ Adam C. Powell, IV ]
Index: trunk/debian/rules
===
--- trunk/debian/rules	(revision 2951)
+++ trunk/debian/rules	(working copy)
@@ -22,7 +22,7 @@
 DEB_BUILD_GNU_TYPE  ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
 DEB_BUILD_ARCH  ?= $(shell dpkg-architecture -qDEB_BUILD_ARCH)
 
-DEFAULT_MPI=$(shell readlink /etc/alternatives/mpi | sed s/usr//g | sed s/include//g | sed s/lib//g | sed s/\\///g)
+DEFAULT_MPI=$(shell dpkg -s mpi-default-dev | grep Depends | sed s/Depends: lib// | sed s/Depends: // | sed s/-dev// | sed s/lam4/lam/)
 
 patch: patch-stamp
 patch-stamp:


signature.asc
Description: This is a digitally signed message part
___
Pkg-grass-devel mailing list
Pkg-grass-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-grass-devel

[DebianGIS-dev] Bug#510057: Bug#510057: Consider creating default MPI version

2010-04-28 Thread Adam C Powell IV
Thank you Francesco for taking care of this!

-Adam

On Thu, 2010-04-22 at 19:00 -0400, Adam C Powell IV wrote:
 Dear Francesco,
 
 This patch has been available since early February now, and without it a
 number of packages are blocked.  Those include new packages for Salomé
 and Code-Aster, a mpi-defaults transition for Octave, and a working
 version of med-fichier.  With the freeze coming up soon, it would help a
 lot of people to get this done, as these engineering simulation packages
 could enter Debian in time for the squeeze release.
 
 Also, mpi-defaults in unstable still uses lam, so the patch is still
 current, though it won't be for long.
 
 What more do you need to make this happen?  How can I help?
 
 -Adam
 
 On Wed, 2010-02-03 at 09:29 -0500, Adam C Powell IV wrote:
  tags 510057 +patch
  thanks
  
  Hello Francesco,
  
  On Wed, 2010-01-27 at 14:28 -0500, Adam C Powell IV wrote:
   On Wed, 2010-01-27 at 20:10 +0100, Francesco P. Lovergine wrote:
That said, a patch for add mpi-defaults to current support 
is of course welcome.
   
   Okay, I will put some time into this approach (adding mpi-defaults,
   leaving the three in place) when I get some time, probably next week.
  
  I'm attaching a patch vs. current SVN which adds an extra package
  libhdf5-mpi-dev, that package is empty and depends on the default MPI
  version of libhdf5-*-dev for each platform.  It has to be Arch: any
  because it will depend on a different package for different platforms.
  
  This will provide a good migration path for squeeze: people who have
  been using a specific MPI implementation can still do so, while those
  who want to make their package depend on the default MPI version can
  have something in squeeze which should be compatible with squeeze+1.
  
  There's one problem though: mpi-defaults is about to transition from lam
  to mpich2 on platforms which don't support openmpi.  This will require a
  new mpich2 version of HDF5 to make it work.  I'd be glad to make a patch
  for that if you like.
  
  -Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Engineering consulting with open source tools
http://www.opennovation.com/


signature.asc
Description: This is a digitally signed message part
___
Pkg-grass-devel mailing list
Pkg-grass-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-grass-devel

[DebianGIS-dev] Bug#571453: hdf5: Please drop build-dependency on LAM/MPI and/or MPICH

2010-04-22 Thread Adam C Powell IV
Hi Manuel and GIS devs,

Just FYI, Manuel, Francesco has indicated that he would rather continue
to build all flavors of hdf5 for squeeze in bug 510057, so it's not
likely that this bug will be closed by the squeeze release.

That said, if 510057 is closed, it will give the reverse-depends an
mpi-defaults transition path for squeeze, which would help with the
removal of MPICH and LAM after the release...

-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Engineering consulting with open source tools
http://www.opennovation.com/


signature.asc
Description: This is a digitally signed message part
___
Pkg-grass-devel mailing list
Pkg-grass-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-grass-devel

[DebianGIS-dev] Bug#510057: Bug#510057: Consider creating default MPI version

2010-02-03 Thread Adam C Powell IV
tags 510057 +patch
thanks

Hello Francesco,

On Wed, 2010-01-27 at 14:28 -0500, Adam C Powell IV wrote:
 On Wed, 2010-01-27 at 20:10 +0100, Francesco P. Lovergine wrote:
  That said, a patch for add mpi-defaults to current support 
  is of course welcome.
 
 Okay, I will put some time into this approach (adding mpi-defaults,
 leaving the three in place) when I get some time, probably next week.

I'm attaching a patch vs. current SVN which adds an extra package
libhdf5-mpi-dev, that package is empty and depends on the default MPI
version of libhdf5-*-dev for each platform.  It has to be Arch: any
because it will depend on a different package for different platforms.

This will provide a good migration path for squeeze: people who have
been using a specific MPI implementation can still do so, while those
who want to make their package depend on the default MPI version can
have something in squeeze which should be compatible with squeeze+1.

There's one problem though: mpi-defaults is about to transition from lam
to mpich2 on platforms which don't support openmpi.  This will require a
new mpich2 version of HDF5 to make it work.  I'd be glad to make a patch
for that if you like.

-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Engineering consulting with open source tools
http://www.opennovation.com/
diff -urN debian.old/changelog debian/changelog
--- debian.old/changelog	2010-02-03 08:04:03.0 -0500
+++ debian/changelog	2010-02-03 09:27:24.0 -0500
@@ -1,3 +1,10 @@
+hdf5 (1.8.4-7) unstable; urgency=low
+
+  * Added libhdf5-mpi-dev package which simply depends on default MPI version
+of HDF5 for each platform.
+
+ -- Adam C. Powell, IV hazel...@debian.org  Wed, 03 Feb 2010 09:02:05 -0500
+
 hdf5 (1.8.4-6) unstable; urgency=low
 
   * Fixed typo in 1.8.4-4 changelog.
diff -urN debian.old/control debian/control
--- debian.old/control	2010-02-03 08:04:03.0 -0500
+++ debian/control	2010-02-03 09:27:24.0 -0500
@@ -6,7 +6,7 @@
 Build-Depends: libmpich1.0-dev (= 1.2.7-1), zlib1g-dev, lam4-dev (= 7.1.1-3.2), quilt,
  libopenmpi-dev [!arm !armel !hppa !mips !mipsel !s390 !sh4 !m68k], libjpeg62-dev | libjpeg-dev, debhelper ( 7), sed (=4.1.5), 
  gfortran, libibverbs-dev [!arm !armel !hppa !mips !mipsel !s390 !kfreebsd-i386 !kfreebsd-amd64 !hurd-i386 !sh4],
- sharutils
+ sharutils, mpi-default-dev
 Standards-Version: 3.8.3
 Homepage: http://hdfgroup.org/HDF5/
 Vcs-Browser: http://svn.debian.org/viewsvn/pkg-grass/packages/hdf5/trunk/
@@ -140,6 +140,19 @@
  This package contains development files for use with MPICH. Warning:
  the C++ interface is not provided for this version.
 
+Package: libhdf5-mpi-dev
+Section: libdevel
+Priority: extra
+Architecture: any
+Depends: ${hdf5-mpi-dev}, mpi-default-dev
+Description: Hierarchical Data Format 5 (HDF5) - development files - MPICH version
+ HDF5 is a file format and library for storing scientific data. 
+ HDF5 was designed and implemented to address the deficiencies of
+ HDF4.x. It has a more powerful and flexible data model, supports
+ files larger than 2 GB, and supports parallel I/O.
+ .
+ This package depends on the default MPI version of HDF5 for each platform.
+
 Package: libhdf5-doc
 Section: doc
 Architecture: all
diff -urN debian.old/control.in debian/control.in
--- debian.old/control.in	2010-02-03 08:04:03.0 -0500
+++ debian/control.in	2010-02-03 09:27:24.0 -0500
@@ -6,7 +6,7 @@
 Build-Depends: libmpich1.0-dev (= 1.2.7-1), zlib1g-dev, lam4-dev (= 7.1.1-3.2), quilt,
  libopenmpi-dev [!arm !armel !hppa !mips !mipsel !s390 !sh4 !m68k], libjpeg62-dev | libjpeg-dev, debhelper ( 7), sed (=4.1.5), 
  gfortran, libibverbs-dev [!arm !armel !hppa !mips !mipsel !s390 !kfreebsd-i386 !kfreebsd-amd64 !hurd-i386 !sh4],
- sharutils
+ sharutils, mpi-default-dev
 Standards-Version: 3.8.3
 Homepage: http://hdfgroup.org/HDF5/
 Vcs-Browser: http://svn.debian.org/viewsvn/pkg-grass/packages/hdf5/trunk/
@@ -140,6 +140,19 @@
  This package contains development files for use with MPICH. Warning:
  the C++ interface is not provided for this version.
 
+Package: libhdf5-mpi-dev
+Section: libdevel
+Priority: extra
+Architecture: any
+Depends: ${hdf5-mpi-dev}, mpi-default-dev
+Description: Hierarchical Data Format 5 (HDF5) - development files - MPICH version
+ HDF5 is a file format and library for storing scientific data. 
+ HDF5 was designed and implemented to address the deficiencies of
+ HDF4.x. It has a more powerful and flexible data model, supports
+ files larger than 2 GB, and supports parallel I/O.
+ .
+ This package depends on the default MPI version of HDF5 for each platform.
+
 Package: libhdf5-doc
 Section: doc
 Architecture: all
diff -urN debian.old/rules debian/rules
--- debian.old/rules	2010-02-03 08:04:03.0 -0500
+++ debian/rules	2010-02-03 09:27:24.0 -0500
@@ -22,6 +22,8 @@
 DEB_BUILD_GNU_TYPE  ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
 DEB_BUILD_ARCH  ?= $(shell dpkg

[DebianGIS-dev] Bug#510057: Consider creating default MPI version

2010-01-25 Thread Adam C Powell IV
Greetings,

Because MPICH1 and LAM are long since end-of-life, this is taking on a
new urgency.  The Debian Science team is planning to deprecate the LAM
and MPICH1 packages for squeeze, and remove them entirely for squeeze+1.
[1]  For this reason, a package built against mpi-defaults should be the
only MPI version of most packages for squeeze and moving forward.

 [1] http://lists.debian.org/debian-science/2009/11/msg00010.html

I would be happy to provide a patch to make this happen, as I did to
create the openmpi version.  If you prefer to have the current three
plus an mpi-defaults version, I would be happy to make that happen as
well, just let me know either way.

Regards,
Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Engineering consulting with open source tools
http://www.opennovation.com/


signature.asc
Description: This is a digitally signed message part
___
Pkg-grass-devel mailing list
Pkg-grass-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-grass-devel

Re: [DebianGIS-dev] [Pkg-scicomp-devel] Open MPI 1.3 related rebuilds

2009-02-06 Thread Adam C Powell IV
On Sun, 2009-02-01 at 17:05 -0600, Steve M. Robbins wrote:
 On Sun, Feb 01, 2009 at 10:52:18AM -0600, Dirk Eddelbuettel wrote:
  
  On 1 February 2009 at 00:37, Steve M. Robbins wrote:
  | Hello Dirk,
  | 
  | On Mon, Jan 26, 2009 at 09:10:04PM -0600, Dirk Eddelbuettel wrote:
  | 
  |  Open MPI 1.3, released a few days ago, recommends a rebuild of its
  |  dependencies.  
  |  
  |  Given the fairly small number of affected packages, we are hoping do 
  drive
  |  this rebuild 'informally' rather than with the full force of 
  libopenmpi-1.2
  |  and libopenmpi-1.3 libraries (which would still require rebuilds, but 
  also
  |  delays via NEW etc pp).  Details and logs of this initiative are on a 
  new
  |  wiki page at   http://wiki.debian.org/OpenMPI13Transition
  | 
  | The wiki page states that Open MPI 1.3 is not binary compatible with
  | Open MPI 1.2.  Presumably, therefore, the SONAME has changed.  
  
  Not quite. It's more complicated because of the fact that at least three
  different implementations (LAM/MPI, MPICH and MPICH2, OpenMPI) provide
  /usr/lib/libmpi.so and there is no soname encoded.
 
 That's not quite the case; the SONAME for the OpenMPI-supplied library
 is libmpi.so.0:
 
   $ objdump -p /usr/lib/libmpi.so|grep SON
 SONAME  libmpi.so.0
 
 If a program linked against libmpi.so.0 fails to run with the new
 libmpi.so.0, then either there is a bug in OpenMPI 1.3 or the SONAME
 should change.  This is not confined to relinking dependent libraries
 in Debian packages: you will also break user-built code.
 
 
  Also note that it isn't strictly incompatible. Some users of Open MPI that
  were built agains 1.2.* continue to work under 1.3.
 
 Sure, but the test for re-using an existing SONAME is
 
   Is the ABI the same, or not?
 i.e.  Does *every* program continue to run, or not?
 
 My understanding is that the answer is no.

I have to agree with Steve.  We have versioned shlib package names for a
reason, though the second of these conditions (do old programs still
run) is more important than the first (has the ABI changed at all).

If you keep the same lib package name but can't provide continuity, it's
a bug.  It's not just a matter of best practices.  Debian policy is
pretty clear about this.  (It might even be an RC bug, though I'm not
sure and don't have the time to look into policy just now...)

If upstream doesn't change their soname, the new package should use
something like -1.3 in the shlib package name.

IIRC it's not a requirement that the old and new versions be
simultaneously installable or that the soname change (e.g. compiler ABI
changes don't require this), so feel free to leave the soname as
upstream has it.

-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Engineering consulting with open source tools
http://www.opennovation.com/


signature.asc
Description: This is a digitally signed message part
___
Pkg-grass-devel mailing list
Pkg-grass-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-grass-devel

[DebianGIS-dev] Bug#473871: hdf5: Doesn't actually build openmpi libs

2008-04-01 Thread Adam C Powell IV
Package: hdf5
Version: 1.6.6-3

Greetings,

I'm afraid your rules file doesn't build openmpi libraries on the
architectures where it's supposed to, so the openmpi packages are empty.
Looking through the build logs on every architecture where it's supposed
to work (amd64, ia64, sparc, powerpc), if I search the log for
openmpi, I get the package installation, a couple of symlinks at the
top, then dh_makeshlibs at the very end, with no references to openmpi
in between.  I don't understand why this is; your system seems sound and
logical.

I realize that I'm the cause of a lot of your openmpi troubles, having
suggested this in the first place.  So I think I've come up with an
elegant solution to this problem, found in the patch.  Instead of
testing for the architecture in rules, each openmpi target just tests
for the file /usr/lib/openmpi/include/mpi.h, and if it finds it,
configures/builds/installs.  This patch works on amd64, haven't tested
it elsewhere.

The advantage of this approach is that when more arches support openmpi,
you can just adjust the arch lists in control, and rules will
automatically build the new openmpi packages.

I hope this patch meets with your approval, and solves this problem of
openmpi support once and for all.

Regards,
-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Engineering consulting with open source tools
http://www.opennovation.com/
--- hdf5-1.6.6/debian/rules~	2008-04-02 02:41:06.0 +
+++ hdf5-1.6.6/debian/rules	2008-04-02 02:40:36.0 +
@@ -18,38 +18,11 @@
 
 DEB_HOST_GNU_TYPE   ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
 DEB_BUILD_GNU_TYPE  ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
-DEB_BUILD_ARCH  ?= $(shell dpkg-architecture -qDEB_BUILD_ARCH)
 
 # To be used if binary packages were buildable on any arch
 #ARCH_FLAG=-a
 ARCH_FLAG=-s
 
-ifeq ($(DEB_BUILD_ARCH),arm)
-build_openmpi = no
-else ifeq ($(DEB_BUILD_ARCH),armel)
-build_openmpi = no
-else ifeq ($(DEB_BUILD_ARCH),hppa)
-build_openmpi = no
-else ifeq ($(DEB_BUILD_ARCH),mips)
-build_openmpi = no
-else ifeq ($(DEB_BUILD_ARCH),mipsel)
-build_openmpi = no
-else ifeq ($(DEB_BUILD_ARCH),s390)
-build_openmpi = no
-else
-build_openmpi = yes
-endif
-
-ifeq ($(build_openmpi),yes)
-configure_stamp_openmpi = configure-stamp-openmpi
-build_stamp_openmpi = build-stamp-openmpi
-install_openmpi = install-openmpi
-else
-configure_stamp_openmpi =
-build_stamp_openmpi = 
-install_openmpi =
-endif
-
 ifeq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
USE_PROD = yes
 else
@@ -80,7 +53,7 @@
 		  --enable-shared --enable-production=$(USE_PROD)
 
 
-configure: configure-stamp-debian configure-stamp-serial configure-stamp-lam $(configure-stamp-openmpi) configure-stamp-mpich
+configure: configure-stamp-debian configure-stamp-serial configure-stamp-lam configure-stamp-openmpi configure-stamp-mpich
 
 configure-stamp-debian: debian/control.in
 	cd debian  for i in *_devlib; do j=`basename $$i _devlib`; \
@@ -119,12 +92,14 @@
 
 configure-stamp-openmpi: configure-stamp-debian
 	dh_testdir
-	-mkdir debian/build-openmpi
-# configure version with lam
+# configure version with openmpi
+	if [ -e /usr/lib/openmpi/include/mpi.h ]; then \
+	mkdir debian/build-openmpi; \
 	cd debian/build-openmpi  CPPFLAGS=-I/usr/lib/openmpi/include \
 		CC=mpicc.openmpi CXX=mpic++.openmpi RUNPARALLEL=/usr/bin/mpirun.openmpi \
 		../../configure $(CONFIGURE_FLAGS) \
-		--enable-parallel=yes
+		--enable-parallel=yes; \
+	fi
 	touch configure-stamp-openmpi
 
 configure-stamp-mpich: configure-stamp-debian
@@ -138,7 +113,7 @@
 		--enable-parallel=yes
 	touch configure-stamp-mpich
 
-build: build-stamp-serial build-stamp-lam $(build-stamp-openmpi) build-stamp-mpich
+build: build-stamp-serial build-stamp-lam build-stamp-openmpi build-stamp-mpich
 
 build-stamp-serial: configure-stamp-serial
 	dh_testdir
@@ -152,7 +127,9 @@
 
 build-stamp-openmpi: configure-stamp-openmpi 
 	dh_testdir
-	$(MAKE) -C debian/build-openmpi/
+	if [ -e /usr/lib/openmpi/include/mpi.h ]; then \
+	$(MAKE) -C debian/build-openmpi/; \
+	fi
 	touch build-stamp-openmpi
 
 build-stamp-mpich: configure-stamp-mpich 
@@ -192,10 +169,12 @@
 install-openmpi: build-stamp-openmpi
 	dh_testdir
 	dh_testroot
-	-mkdir debian/build-openmpi/tmpinst
-	$(MAKE) -C debian/build-openmpi/ install prefix=$(CURDIR)/debian/build-openmpi/tmpinst/usr
+	if [ -e /usr/lib/openmpi/include/mpi.h ]; then \
+	mkdir debian/build-openmpi/tmpinst; \
+	$(MAKE) -C debian/build-openmpi/ install prefix=$(CURDIR)/debian/build-openmpi/tmpinst/usr; \
 	dh_install -p$(openmpipack) -p$(package)-openmpi-dev \
-		--sourcedir=debian/build-openmpi/tmpinst
+		--sourcedir=debian/build-openmpi/tmpinst; \
+	fi
 
 install-mpich: build-stamp-mpich
 	dh_testdir
@@ -222,7 +201,7 @@
 	dh_md5sums -i
 	dh_builddeb -i
 
-binary-arch: build install-serial install-lam $(install-openmpi) install-mpich
+binary-arch: build install-serial install-lam install-openmpi install-mpich
 	dh_testdir

[DebianGIS-dev] Bug#457080: Bug#457080: hdf5: Please add OpenMPI build

2008-03-20 Thread Adam C Powell IV
On Sun, 2008-01-13 at 15:07 -0500, Adam C Powell IV wrote:
 Hi again,
 
 On Wed, 2008-01-09 at 13:14 +0100, Francesco P. Lovergine wrote:
  On Wed, Jan 09, 2008 at 06:56:11AM -0500, Adam C Powell IV wrote:
   On Wed, 2008-01-02 at 12:34 +0100, Francesco P. Lovergine wrote:
On Mon, Dec 31, 2007 at 09:26:10PM -0500, Adam C Powell IV wrote:
 On Wed, 2007-12-19 at 11:04 -0500, Adam C Powell IV wrote:
  As OpenMPI is the successor to LAM (the LAM developers now work on
  OpenMPI), please add an OpenMPI build of hdf5.
 
 Will you accept a patch if I provide one?
 
 Cheers,
 -Adam

Sure.
   
   I put up the patch about a week ago (before this reply).  Does it look
   acceptable?  [BTW, what is DebianGIS-dev?]
   
  
  Yes, it is now integrated ini the svn repository for the next upstream
  release. It will integrate a version transition, so it is still not 
  uploaded.
  
  See http://wiki.debian.org/DebianGis
 
 Thanks again.
 
 I'm afraid there's a problem with my patch.  Please remove the file
 hdf5-H5public-openmpi.patch and the line in the debian/rules
 install-openmpi target which applies it.  It could cause breakage and
 should not be there.
 
 Sorry about that!

Just curious, any progress or timeline hints for the next upload?  (Are
you packaging 1.8.0?)  I have a some packages I'd like to upload which
use this, and would like to start to port them sooner rather than later.

That is, unless you're planning to just stick with 1.6.x for the lenny
release...

Thanks,

-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Engineering consulting with open source tools
http://www.opennovation.com/




___
Pkg-grass-devel mailing list
Pkg-grass-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-grass-devel


[DebianGIS-dev] Bug#457080: Bug#457080: hdf5: Please add OpenMPI build

2008-03-20 Thread Adam C Powell IV
On Thu, 2008-03-20 at 15:31 +0100, Francesco P. Lovergine wrote:
 On Thu, Mar 20, 2008 at 09:51:53AM -0400, Adam C Powell IV wrote:
  On Sun, 2008-01-13 at 15:07 -0500, Adam C Powell IV wrote:
   Hi again,
   
   On Wed, 2008-01-09 at 13:14 +0100, Francesco P. Lovergine wrote:
On Wed, Jan 09, 2008 at 06:56:11AM -0500, Adam C Powell IV wrote:
 On Wed, 2008-01-02 at 12:34 +0100, Francesco P. Lovergine wrote:
  On Mon, Dec 31, 2007 at 09:26:10PM -0500, Adam C Powell IV wrote:
   On Wed, 2007-12-19 at 11:04 -0500, Adam C Powell IV wrote:
As OpenMPI is the successor to LAM (the LAM developers now work 
on
OpenMPI), please add an OpenMPI build of hdf5.
   
   Will you accept a patch if I provide one?
   
   Cheers,
   -Adam
  
  Sure.
 
 I put up the patch about a week ago (before this reply).  Does it look
 acceptable?  [BTW, what is DebianGIS-dev?]
 

Yes, it is now integrated ini the svn repository for the next upstream
release. It will integrate a version transition, so it is still not 
uploaded.

See http://wiki.debian.org/DebianGis
   
   Thanks again.
   
   I'm afraid there's a problem with my patch.  Please remove the file
   hdf5-H5public-openmpi.patch and the line in the debian/rules
   install-openmpi target which applies it.  It could cause breakage and
   should not be there.
   
   Sorry about that!
  
  Just curious, any progress or timeline hints for the next upload?  (Are
  you packaging 1.8.0?)  I have a some packages I'd like to upload which
  use this, and would like to start to port them sooner rather than later.
  
  That is, unless you're planning to just stick with 1.6.x for the lenny
  release...
  
 
 Done a few hours ago, package is pending in the NEW queue.

Ah, terrific!  Thanks, hadn't looked there; good timing. :-)

-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Engineering consulting with open source tools
http://www.opennovation.com/




___
Pkg-grass-devel mailing list
Pkg-grass-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-grass-devel


[DebianGIS-dev] Bug#463393: hdf5: FTBFS: missing library libh5test-1.6.5.so.0

2008-01-31 Thread Adam C Powell IV
Package: hdf5
Version: 1.6.5-5
Severity: serious
Tags: patch

Greetings,

The binary h5perf in the hdf5-tools package requires the library
libh5test-1.6.5.so.0 which is not in any binary package.  With
hdf5-tools installed, this results in:
# /usr/bin/h5perf
h5perf: error while loading shared libraries: libh5test-1.6.5.so.0:
cannot open shared object file: No such file or directory

Because of this, dh_shlibdeps is failing:
dh_shlibdeps -phdf5-tools -Llibhdf5-serial-1.6.5-0 
-ldebian/libhdf5-serial-1.6.5-0/usr/lib
dpkg-shlibdeps: warning: debian/hdf5-tools/usr/bin/gif2h5 shouldn't be linked 
with libpthread.so.0 (it uses none of its symbols).
dpkg-shlibdeps: warning: debian/hdf5-tools/usr/bin/gif2h5 shouldn't be linked 
with libz.so.1 (it uses none of its symbols).
dpkg-shlibdeps: warning: debian/hdf5-tools/usr/bin/gif2h5 shouldn't be linked 
with libm.so.6 (it uses none of its symbols).
dpkg-shlibdeps: warning: debian/hdf5-tools/usr/bin/h5dump shouldn't be linked 
with libpthread.so.0 (it uses none of its symbols).
dpkg-shlibdeps: warning: debian/hdf5-tools/usr/bin/h5dump shouldn't be linked 
with libz.so.1 (it uses none of its symbols).
dpkg-shlibdeps: warning: debian/hdf5-tools/usr/bin/h5dump shouldn't be linked 
with libm.so.6 (it uses none of its symbols).
dpkg-shlibdeps: warning: debian/hdf5-tools/usr/bin/h52gif shouldn't be linked 
with libpthread.so.0 (it uses none of its symbols).
dpkg-shlibdeps: warning: debian/hdf5-tools/usr/bin/h52gif shouldn't be linked 
with libz.so.1 (it uses none of its symbols).
dpkg-shlibdeps: warning: debian/hdf5-tools/usr/bin/h52gif shouldn't be linked 
with libm.so.6 (it uses none of its symbols).
dpkg-shlibdeps: warning: debian/hdf5-tools/usr/bin/h5jam shouldn't be linked 
with libpthread.so.0 (it uses none of its symbols).
dpkg-shlibdeps: warning: debian/hdf5-tools/usr/bin/h5jam shouldn't be linked 
with libz.so.1 (it uses none of its symbols).
dpkg-shlibdeps: warning: debian/hdf5-tools/usr/bin/h5jam shouldn't be linked 
with libm.so.6 (it uses none of its symbols).
dpkg-shlibdeps: warning: debian/hdf5-tools/usr/bin/h5import shouldn't be linked 
with libpthread.so.0 (it uses none of its symbols).
dpkg-shlibdeps: warning: debian/hdf5-tools/usr/bin/h5import shouldn't be linked 
with libz.so.1 (it uses none of its symbols).
dpkg-shlibdeps: warning: debian/hdf5-tools/usr/bin/h5import shouldn't be linked 
with libm.so.6 (it uses none of its symbols).
dpkg-shlibdeps: failure: couldn't find library libh5test-1.6.5.so.0 needed by 
debian/hdf5-tools/usr/bin/h5perf (its RPATH is '').
Note: libraries are not searched in other binary packages that do not have any 
shlibs or symbols file.
To help dpkg-shlibdeps find private libraries, you might need to set 
LD_LIBRARY_PATH.
dh_shlibdeps: command returned error code 512
make: *** [binary-arch] Error 1

It seems dh_shlibdeps has become stricter, so this now causes FTBFS,
which is RC. :-(

Note the library is sitting right in the test directory.  Aha, it
defines PUB_LIB= so PUB_LIB=$(LIB) is ignored.  The attached patch fixes
this, and makes the install_shlib and install_devlib files more general
so it gets installed in the package.

Now the package builds, and the result is:
# /usr/bin/h5perf
No parallel IO performance because parallel is not configured

Cheers,
-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Engineering consulting with open source tools
http://www.opennovation.com/
--- hdf5-1.6.5/test/Makefile.in~	2005-07-21 14:49:03.0 +
+++ hdf5-1.6.5/test/Makefile.in	2008-01-30 23:01:19.0 +
@@ -39,7 +39,6 @@
 LIB=libh5test.la
 LIB_SRC=h5test.c testframe.c
 LIB_OBJ=$(LIB_SRC:.c=.lo)
-PUB_LIB=
 
 ## Temporary files.  These files are the ones created by setting the
 ## HDF5_NOCLEANUP environment variable and running `make test' without
--- hdf5-1.6.5/debian/install_shlib~	2008-01-30 23:58:30.0 +
+++ hdf5-1.6.5/debian/install_shlib	2008-01-30 23:59:03.0 +
@@ -1 +1 @@
-usr/lib/libhdf5*.so.*
+usr/lib/libh*.so.*
--- hdf5-1.6.5/debian/install_devlib~	2008-01-30 23:58:30.0 +
+++ hdf5-1.6.5/debian/install_devlib	2008-01-30 23:59:54.0 +
@@ -1,5 +1,5 @@
 usr/include
-usr/lib/libhdf5*.so
-usr/lib/libhdf5*.settings
-usr/lib/libhdf5*.la
-usr/lib/libhdf5*.a
+usr/lib/libh*.so
+usr/lib/libh*.settings
+usr/lib/libh*.la
+usr/lib/libh*.a
___
Pkg-grass-devel mailing list
Pkg-grass-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-grass-devel

[DebianGIS-dev] Bug#457080: Bug#457080: hdf5: Please add OpenMPI build

2008-01-13 Thread Adam C Powell IV
Hi again,

On Wed, 2008-01-09 at 13:14 +0100, Francesco P. Lovergine wrote:
 On Wed, Jan 09, 2008 at 06:56:11AM -0500, Adam C Powell IV wrote:
  On Wed, 2008-01-02 at 12:34 +0100, Francesco P. Lovergine wrote:
   On Mon, Dec 31, 2007 at 09:26:10PM -0500, Adam C Powell IV wrote:
On Wed, 2007-12-19 at 11:04 -0500, Adam C Powell IV wrote:
 As OpenMPI is the successor to LAM (the LAM developers now work on
 OpenMPI), please add an OpenMPI build of hdf5.

Will you accept a patch if I provide one?

Cheers,
-Adam
   
   Sure.
  
  I put up the patch about a week ago (before this reply).  Does it look
  acceptable?  [BTW, what is DebianGIS-dev?]
  
 
 Yes, it is now integrated ini the svn repository for the next upstream
 release. It will integrate a version transition, so it is still not 
 uploaded.
 
 See http://wiki.debian.org/DebianGis

Thanks again.

I'm afraid there's a problem with my patch.  Please remove the file
hdf5-H5public-openmpi.patch and the line in the debian/rules
install-openmpi target which applies it.  It could cause breakage and
should not be there.

Sorry about that!

-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Engineering consulting with open source tools
http://www.opennovation.com/




___
Pkg-grass-devel mailing list
Pkg-grass-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-grass-devel


[DebianGIS-dev] Bug#457080: Bug#457080: hdf5: Please add OpenMPI build

2008-01-09 Thread Adam C Powell IV
On Wed, 2008-01-02 at 12:34 +0100, Francesco P. Lovergine wrote:
 On Mon, Dec 31, 2007 at 09:26:10PM -0500, Adam C Powell IV wrote:
  On Wed, 2007-12-19 at 11:04 -0500, Adam C Powell IV wrote:
   As OpenMPI is the successor to LAM (the LAM developers now work on
   OpenMPI), please add an OpenMPI build of hdf5.
  
  Will you accept a patch if I provide one?
  
  Cheers,
  -Adam
 
 Sure.

I put up the patch about a week ago (before this reply).  Does it look
acceptable?  [BTW, what is DebianGIS-dev?]

Thanks,
-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Engineering consulting with open source tools
http://www.opennovation.com/




___
Pkg-grass-devel mailing list
Pkg-grass-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-grass-devel


[DebianGIS-dev] Bug#457080: hdf5: Please add OpenMPI build

2007-12-31 Thread Adam C Powell IV
On Wed, 2007-12-19 at 11:04 -0500, Adam C Powell IV wrote:
 As OpenMPI is the successor to LAM (the LAM developers now work on
 OpenMPI), please add an OpenMPI build of hdf5.

Will you accept a patch if I provide one?

Cheers,
-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Engineering consulting with open source tools
http://www.opennovation.com/




___
Pkg-grass-devel mailing list
Pkg-grass-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-grass-devel