CXX transition: arpack++ renaming libarpack++2 to libarpack++2c2

Created an attachment (id=2695)
debdiff patch for renaming libarpack++2 to libarpack++2c2

This package probabaly can use more love, such as cleaning up the debhelper
auto-generated maintainer scripts from .diff.gz, remove useless and incorrect
dh_shlibdeps -L options, etc. But I am keeping the changes minimal for this
C++ transition patch.

        dh_shlibdeps -L libarpack++ -l debian/libarpack++2/usr/lib

still mentions the old package name.

a call to dh_clean in the clean target would not hurt ...

(In reply to comment #2)
> dh_shlibdeps -L libarpack++ -l debian/libarpack++2/usr/lib
>
> still mentions the old package name.

I noticed this, this is what I mean by "useless and incorrect dh_shlibdeps -L
options" in comment #1. This is incorrect because -L should be followed by
package name, in this case it should be libarpack++2 or libarpack++2c2. The way
it is, would have no effects on the shlib dependecies. And none of the binary
files built in this package is linked to libarpack++.so.2 anyway, so I removed
both the -L and -l options.

> a call to dh_clean in the clean target would not hurt ...

Done.

Created an attachment (id=2789)
Update debdiff patch

Full changelog:

arpack++ (2.2-3ubuntu1) breezy; urgency=low

  * C++ transition: Rename libarpack++2 to libarpack++2c2.
  * Remove useless and incorrect options for dh_shlibdeps.
  * Add dh_clean in clean target to remove debhelper generated postinst and
    postrm scripts.

 -- Ming Hua <email address hidden> Sat, 18 Jun 2005 06:25:51 -0500

FTBFS:

checking for daxpy_ in -lblas... no
you need blas.
make: *** [build] Error 1

(In reply to comment #5)
> FTBFS:
>
> checking for daxpy_ in -lblas... no
> you need blas.
> make: *** [build] Error 1

This is strange to me. arpack++ DOES build-depend on blas-dev, which contains
/usr/lib/libblas.so (a symlink to libblas.so.2). And I can build it on my
breezy chroot without any problem.

I have the following warning message in config.log though:
    /usr/bin/ld: warning: libblas.so.3, needed by
/usr/lib/gcc/i486-linux-gnu/4.0.1/../../../liblapack.so, may conflict with
libblas.so.2
and libblas.so.3 should be in refblas3 or atlas3-base (therefore we probably
need refblas3-dev or atlas3-base-dev instead of blas-dev). I remember reading
something about BLAS and ATLAS API changes last year, I'll inversigate more when
I have time (likely this weekend).

I am still curious what is the reason for this FTBFS though. Is the log of
failed build avaiable anywhere?

http://people.ubuntu.com/~lamont/buildLogs/a/arpack++/2.2-3ubuntu1/

(In reply to comment #7)
> http://people.ubuntu.com/~lamont/buildLogs/a/arpack++/2.2-3ubuntu1/

Thanks.

Looking at the build logs, it seems only it only FTBFS on powerpc. I don't know
why it can't find the libblas.so provided by blas-dev, but it seems the old
(SONAME 2) version shouldn't be used any way. Currently I can build on i386 but
get the following libblas linking

# ldd src/.libs/libarpack++.so.2.0.0 | grep blas
        libblas.so.2 => /usr/lib/libblas.so.2 (0xb78f4000)
        libblas.so.3 => /usr/lib/atlas/libblas.so.3 (0xb7351000)

which definitely looks wrong. I'll get rid of the blas-dev Build-Depends and
see first if it only links to libblas.so.3, and then if it solves the FTBFS on
powerpc.

Created an attachment (id=2895)
debdiff patch that changes Build-Depends from blas-dev to refblas3-dev

This patch changes the Build-Depends from blas-dev (libblas.so.2) to
refblas3-dev (libblas.so.3). Two of the build dependencies, lapack3-dev and
libarpack2-dev, are already depending on the new ABI (they actually depend on
atlas3-base-dev, which provides /usr/lib/atlas/libblas.so, a symlink to
/usr/lib/atlas/libblas.so.3) anyway. Now this builds on i386, doesn't have the
ugly simultaneous linking to libblas.so.2 and libblas.so.3 anymore. So I
suppose at least it won't hurt. Maybe the correct way is to drop refblas3-dev
as Build-Depends, though, since ldd shows the result library links to
/usr/lib/atlas/libblas.so.3 instead /usr/lib/libblas.so.3.

Maybe this will magically fix the FTFBS on powerpc as well? :-P

Anyway, the source packages can still be found on
http://www.mems.rice.edu/~minghua/ubuntu/.

i'll upload it, after i built it on amd64 (don't have no powerpc)

broke on both powerpc and ia64:
http://people.ubuntu.com/~lamont/buildLogs/a/arpack++/2.2-3ubuntu2/

(In reply to comment #11)
> broke on both powerpc and ia64:
> http://people.ubuntu.com/~lamont/buildLogs/a/arpack++/2.2-3ubuntu2/

The error looks exactly the same as 2.2-3ubuntu1. I am afraid I'm out of ideas
now. Without a powerpc environment, it would be almost impossible for me to
debug this.

Created an attachment (id=3147)
New debdiff patch for upstream 2.2-6

Debian upstream maintainer is facing the same FTBFS bug as well, and it seems
he's fixed it now. I don't really understand how he did it (the changes are
quite big), so I just checked that the Debian packages got the c++ transition
right, and ported the fixes for debian/rules and made 2.2-6ubuntu1. Attached
is the debdiff from 2.2-6 to 2.2-6ubuntu1. I dropped the 2.2-3ubuntu1 and
2.2-3ubuntu2 changelog entries.

If MOTUs feel these changes are too small to be worth deviating from Debian
upstream, feel free to just upload 2.2-6 from Debian, it should build fine on
all arches. I'll push my changes to Debian either way.

As always, the source packages I made are at
http://www.mems.rice.edu/~minghua/ubuntu/

The changelog for 2.2-6ubuntu1:

arpack++ (2.2-6ubuntu1) unstable; urgency=low

  * Sync with Debian's post-C++-transition package
  * Merge Ubuntu changes
    - Remove useless and incorrect options for dh_shlibdeps
    - Add dh_clean in debian/rules clean target to remove debhelper generated
      scripts

 -- Ming Hua <email address hidden> Sat, 30 Jul 2005 04:03:32 -0500

Lowering severity, as these are universe packages

done