[Debian-med-packaging] Please consider bin-NMUs of certain gfortran-using packages on mips/mipsel

[Kevin B. McCarty]

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 at gmail.com>
WWW: http://www.starplot.org/
WWW: http://people.debian.org/~kmccarty/
GPG: public key ID 4F83C751

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
Url : http://lists.alioth.debian.org/pipermail/debian-med-packaging/attachments/20080505/8aaa6168/attachment.pgp