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: http://wiki.debian.org/GfortranTransition In case you are interested in updated, please consider subscribing to it. 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: http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=gfortran;users=debian-toolchain@lists.debian.org 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: http://buildd.debian.org/~jeroen/status/package.php?p=lapack 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: http://experimental.debian.net/build.php?arch=&pkg=lapack 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 solved). 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: http://experimental.debian.net/build.php?arch=&pkg=lam 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 solved. 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. Todo ==== 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 -- Kumar Appaiah, 458, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036
Attachment:
signature.asc
Description: Digital signature