Hi Release Team, as I mentioned previously [1], a bug in gfortran 4.3 [2,3] caused some FORTRAN code using SIN() / COS() functions to be miscompiled on mips and mipsel with -O1 or greater. Thanks to Jakub Jelinek and Matthias Klose, this bug should now be fixed in version 4.3.0-4 of Debian's gfortran-4.3 package. The following source packages in "main" were built with gfortran-4.3 prior to 4.3.0-4 and appear to be affected by the bug. Could you please consider scheduling bin-NMUs of these packages, with a dep-wait on gfortran-4.3 4.3.0-4? # a bin-NMU is apparently only needed on mips: apbs/0.5.1-2 # a bin-NMU appears to be needed on both mips and mipsel: abinit/5.3.4.dfsg-3 atlas/3.6.0-21.4 blacs-mpi/1.1-28 blacs-pvm/1.1-19 fasianoptions/260.72-4 lapack/3.1.1-0.4 mn-fit/5.13-6 octave2.1/1:2.1.73-19 octave3.0/1:3.0.1-2 python-scipy/0.6.0-11 saods9/4.0b7-2 scalapack/1.8.0-2 wsjt/5.9.7.r383-1.2 The following packages in "contrib" and "non-free" also appear to be affected, but I don't know whether packages in those sections can be automatically bin-NMUed. Therefore I also CC their maintainers. Please keep them in CC regarding this question. # In contrib (only on mips; ifeffit has never been built on mipsel) ifeffit/2:1.2.10a-4 # Note: a newer version of ifeffit, 2:1.2.10a-5, needs to be built on # mips anyway so there is no point in doing a bin-NMU of ifeffit. # In non-free on both mips and mipsel: pgplot5/5.2.2-14 raster3d/2.7s-1 scilab/4.1.2-4 # Note: a newer version of scilab, 4.1.2-5, needs to be built on # mips and mipsel anyway so there is no point in doing a bin-NMU of # scilab. The above lists are based on re-running my script from [1], plus manual review of the buildd logs for packages that are newer than they were at the time of my previous email. Uninteresting caveats: It is conceivable there could be a few false positives (for binaries that combine FORTRAN and C code and use sincos() within the C portion) but I think this is unlikely and not worth the trouble to weed them out. There may also be a couple other false positives for packages whose buildd logs were not available but which were already built with gfortran-4.3 4.3.0-4. But it shouldn't hurt anything to do a bin-NMU in either of those cases. Finally, note that I would not have detected any source package that is affected but which builds only object files (*.o), static libraries, and/or binaries statically linked against libm or libgfortran. Again, I think it's unlikely that there exists such a source package. [1] http://lists.debian.org/debian-release/2008/04/msg00267.html [2] http://gcc.gnu.org/PR35662 [3] http://bugs.debian.org/476427 best regards, -- Kevin B. McCarty <kmccarty@gmail.com> WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751
Attachment:
signature.asc
Description: OpenPGP digital signature