libittp fortran transition

[Aanjhan Ranganathan]

The latest package closes http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=466047 (move to gfortran)
Some changes in build-depends have been done.

Since the package fixes a debian bug and also includes clean up, I request a exception. Complete changelog below.

Complete changelog
--------------------------

 libitpp (4.0.3-1) unstable; urgency=low

   * New upstream release.
     + zdotusub used to wrap all zdotu_ calls.
   * debian/patches:
     + Remove all patches.
   * debian/rules, debian/control:
     + quilt not used.

 -- Kumar Appaiah <email address hidden> Thu, 21 Feb 2008 15:38:56 +0530
libitpp (4.0.2-2) unstable; urgency=low

   * debian/patches/zdotu_complex_detect.diff:
     This patch has been added to use double _Complex as the return type of
     zdotu_ to work around errors in assuming direct convertibility to
     std::complex<double> of the zdotu_ function's return value.
   * debian/control, debian/rules:
     + Use quilt for patch management.
   * debian/rules:
     + Separate architecture dependent and independent build rules.

 -- Kumar Appaiah <email address hidden> Sun, 17 Feb 2008 14:48:04 +0530
libitpp (4.0.2-1) unstable; urgency=low

   * New upstream release.
   * Upload to unstable:
     + gfortran transition complete. (Closes: #466047)
   * debian/patches:
     + zdotu_fix.diff: Removed; merged upstream.
   * debian/control:
     + Don't build-depend on quilt: no longer needed.
     + Change Build-depends on doxygen to remove Debian revision.
   * debian/rules:
     + Don't use quilt.

 -- Kumar Appaiah <email address hidden> Sat, 16 Feb 2008 13:29:40 +0530

[StefanPotyra (sistpoty)]

Hm... I'm a bit sceptical: after looking at a few packages, it looks like we didn't do the gfortran transition (http://wiki.debian.org/GfortranTransition) in universe yet. Hence, I guess it only makes sense to bring this package in, if we fully do the gfortran transition.

Now, I'm entirely unsure if it's appropriate that late in the cycle, to start this transition. My gut feeling is, that it would be better to be aligned with unstable on this, but I'd like to hear what other -release members think. (And I guess pinging doko what he thinks about doing the transition might be a good idea, too).

[Kumar Appaiah (kumar-appaiah)]

While I agree with Stefan, I just wanted you to know that the gfortran transition is almost complete in Debian, and will definitely happen in Ubuntu sometime. Moreover, the Blas and Lapack which are used by doko's packages (e.g. numpy) have made the switch already.

Even if not for Hardy, I would request this bug to remain open for the next version, so that the change happens sometime later, at least.

Thanks.

Kumar

[Luke Yelavich (themuso)]

I agree, unless this transition is already under way in Ubuntu, which I don't think it is, this shouldn't be brought in until hardy+1.

[William Grant (wgrant)]

Parts of the gfortran transition have been done, and I'm in the middle of transitioning several packages that became uninstallable because of it (some universe packages were migrated by doko, others weren't - I'm not sure why). We may end up needing this later to get everything installable, but there's no point in an FFe now.

[StefanPotyra (sistpoty)]

setting back to new, as parts of the transition have already been started.

Hence I'm in favour of realigning to unstable and finishing the transition (ideally adding tasks to this bug).

Other opinions?

[Scott Kitterman (kitterman)]

Ack from me. Having started, we ought to try and finish.

[StefanPotyra (sistpoty)]

<doko> sistpoty|work: I don't care too much about it; you can try, at least it should build with gfortran, maybe you have problems on the port architectures

[StefanPotyra (sistpoty)]

looks like ~35 packages have g77 in build-depends and around the same number gfortran (there might be packages having both in it).

Given this numbers, I guess it makes the most sense to me to grant a general FFe for the fortran transition, ideally syncing as many packages as possible. Other opinions?

[Aanjhan Ranganathan (aanjhan)]

I would second that as I have seen already a couple of other packages at least being synced from Unstable for similar reasons. And if it helps in progressing the gfortran transition, I dont see a reason why this cannot get through.

[Cesare Tirabassi (norsetto)]

Seems like we are mixing two different things here.

To ack this (gfortran transition or not) I think we should at least see an hardy build log that with the new build-deps on i386/amd64 archs the package builds fine and an hardy install log to check that at least the rights deps are there.
Its a pretty standalone application, so, with a positive on that, I don't see why we should not upload it.

The gfortran transition seems to me a different issue which has been dragged in but do not really pertain to this bug report (beside the fact that yes, seems a good idea to finish it if we can for hardy).

Or am I missing something?

[StefanPotyra (sistpoty)]

Hi,

On Wednesday 12 March 2008 16:19:26 Cesare Tirabassi wrote:
> Seems like we are mixing two different things here.
>
[..]
> The gfortran transition seems to me a different issue which has been
> dragged in but do not really pertain to this bug report (beside the fact
> that yes, seems a good idea to finish it if we can for hardy).
>
> Or am I missing something?

Unless I read it wrong, you cannot easily link an application against an
untransitioned library and a transitioned one. Hence looking only at one
library (which has no rdepends, and hence is only useful for users to build
other applications with it) seems insufficient to me.

Of course we can move the discussion of the gfortran transition to a separate
bug, if you prefer.

Cheers,
    Stefan.

[StefanPotyra (sistpoty)]

gfortran transition discussion at bug 201962.

[StefanPotyra (sistpoty)]

setting to confirmed, gfortran transition general FFe accepted.

Sponsors, please also look at bug 201962 and the debian wiki page about the gfortran transition.

[Scott Kitterman (kitterman)]

This did not get done for Hardy. It will get automatically sync'ed for Intrepid, so no bug needed.

[Cesare Tirabassi (norsetto)]

This debdiff should be a good starting point for an sru.
Note that README.Debian needs to be deleted/changed too and if this go through the libitpp6 binary package needs to be removed (should be a NBS by then).

[Scott Kitterman (kitterman)]

Approved for upload to hardy-proposed by Ubuntu RM

[Cesare Tirabassi (norsetto)]

[22:05] <ScottK2> norsetto: RM has authorized upload to hardy-proposed. Please change the revision to ubuntu0.1 and the release to hardy-proposed and upload.
[22:07] <norsetto> scottk2: I'm not following that up with the usual mess of testing request etc. etc. though
[22:07] <ScottK2> K. We'll make sistpoty do that.

Package uploaded to hardy-proposed.

[StefanPotyra (sistpoty)]

heh, sure... will do that, as soon as the package is accepted into proposed ;)

[Martin Pitt (pitti)]

Accepted into hardy-proposed, please test. Also, please give this bug a more meaningful title. Thank you!

[Scott Kitterman (kitterman)]

Assigning to sistpoty since he agreed to coordinate testing. Subscribing motu-sru and unsubscribing motu-release (this was uploaded to proposed prior to the release).

[Martin Pitt (pitti)]

For the record, binary NEWed.

[StefanPotyra (sistpoty)]

hm... I'm having a hard time finding a test case that doesn't work with the old version. It still builds fine, and since the test cases are run during building, it obviously still seems to be working. Anyone any hints want I could test that doesn't work with the old version, but with the one from -proposed?

[Martin Pitt (pitti)]

My primary concern is to get a confirmation that the package still works, i. e. that it did not get completely broken during rebuild. If you can confirm that, I'm happy to move it to -updates.

[StefanPotyra (sistpoty)]

Martin, well the package has quite an extensive test-suite, which gets run during package build, so since it did build, I assume that it still works.

Nonetheless I'm not too convinced if it's a good thing to publish the update, if it won't bring us any benefits (as there's always a risk of regression). OTOH I won't keep you from publishing it of course, if you feel that it makes sense ;).

[Cesare Tirabassi (norsetto)]

The current package in hardy is uninstallable (http://qa.ubuntuwire.org/debcheck/debcheck.py?dist=intrepid&package=libitpp), therefore I think it is a good idea to publish the update.

[LaserJock (laserjock)]

The package in -proposed builds and installs fine for me.

[Martin Pitt (pitti)]

Copied to hardy-updates.