[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

gfortran transition update

Dear Debian Toolchain,

Since I have been tracking the transition a bit, I would like to take
this opportunity to update you with the current status of some
packages involved in the gfortran transition, and give you a TODO list
for remaining things.

Bugs and other details
To avoid having to look elsewhere, please follow the following:

1. Update your details on packages, and some tips you may have for
helping the transition on the following Wiki page:


In case you are interested in updated, please consider subscribing to

2. Please tag all the transition related bugs with the Usertag
gfortran under the Username debian-toolchain@lists.debian.org. A
current list of bugs is available here:


More bugs are to be filed, but most of the important packages are
covered there.

Lapack and Blas
As Camm had already prepared packages of gfortranized Blas and Lapack,
with some effort, they are now in unstable. The BLAS version is in
sync with the latest upstream release, as I managed to repackage
it. As for Lapack, thanks to Matthias, the package is in unstable,
though we might be facing some build problems (failure on s390
already, though I suspect gcc...). The latest status can be seen here:


I have also prepared a new upstream release package based on the
upload above, and Matthias has uploaded it to experimental. The logs
may be seen here:


Main knot
It is worth noting that mpich now builds using gfortran, and is now in
NEW (See http://bugs.debian.org/195509 for how the problem was

Riku has uploaded an NMU of lam to experimental, with a package
rename, though the lam4-dev retains its name to allow for binNMUs in
unstable. The build status of the same is available here:


suitesparse (and other packages which involve Octave) will be taken
care of by the Debian Scientific Computing Team and the Debian Octave
Group respectively. Patches are ready, and pending an soname issue
with suitesparse (unrelated to this transition), the problem is

Most of the other main packages can follow after these packages get
through to sid, I guess.

Leaf packages
For most of these packages, I have tried preparing patchs, and I found
that it usually involves the following:

1. Build-Depend on gfortran if -lgfortran is needed (works, but may
   not be the best way?).
2. Ensure gfortran is found by passing F77=gfortran (or --with-fc gfortran)
   to the ./configure script.

For those packages which seemed too big or tough, I just filed the
bugs and left the patching. Please do file bugs and produce patches
for packages which can start moving to the gfortran based library
dependencies. Again, the BTS page and the Wiki should serve as a
reference and coordinating point.

Atlas - New upstream release. The unfortunate fact is that upstream
has significantly changed their build system and code, which in
essence, makes it very tough to adapt to the old Debian
packaging. Another difficult aspect is the fact that the current Atlas
is heavily patched and it may be tough to evaluate architecture
specific changes which the package may warrant. It would be very nice
if Camm (or someone who knows the Atlas build system) could come up with
packages for Atlas, which can be tested in time for Lenny.

Other than this, please help out by testing the packages and informing
the maintainers of quirks which appear, so that the transition can be
made smooth.

(Maybe Riku and Matthias want to add some more points here).

Thanks for bearing with me! Comments and suggestions welcome.

Kumar Appaiah,
458, Jamuna Hostel,
Indian Institute of Technology Madras,
Chennai - 600 036

Attachment: signature.asc
Description: Digital signature

Reply to: