On Sun, Jul 22, 2007 at 01:19:14AM +0300, Riku Voipio wrote:
> Hi,
>
> The proposal to transition from the outdated g77 to gfortran did
> not result any comments. Which rises the suspicion that the maintainers
> of affected packages are not reading debian-release or debian-toolchain.
>
> If you have suggestions, critique, or you are busy but accept NMU'ing
> your packages for gfortran transition.. please speak now.
>
> Some of the packages gfortran transition affects are also affected by
> the long double transition. This includes atleast the following fortran
> packages:
>
> lam, atlas3, fftw3, hdf5, mpich1.0, petsc, pdl
>
> Therefor, I think it would make sense to start g77 -> gfortran
> transition promptly, to avoid transitioning same packages twice.
>
Hi all,
fftw3 changed to gfortran in the last upload, after a discussion on the
BTS with Warren Turkal and upstream Steven Johnson (see #392301).
I will prepare uploads for the long double issue and for fftw2. I might
need sponsoring as my new key is waiting to get into the ring.
Am I wrong assuming {k6,k7,p4}fftwgel are not affected as they are i386
only?
thanks, piem
> --
> "rm -rf" only sounds scary if you don't have backups
> Old-Return-Path: <[EMAIL PROTECTED]>
> Date: Thu, 5 Jul 2007 17:17:42 +0300
> From: Riku Voipio <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: gfortran transition release goal proposal
> Resent-Message-ID: <[EMAIL PROTECTED]>
> Resent-From: [EMAIL PROTECTED]
> List-Id: <debian-toolchain.lists.debian.org>
> Resent-Sender: [EMAIL PROTECTED]
> Resent-Date: Thu, 5 Jul 2007 14:18:23 +0000 (UTC)
>
> G77 to Gfortran Transition
>
> We would like to present the G77 to gfortran transition as a Lenny
> release goal. The Debian developers responsible for the transition
> are Riku Voipio <[EMAIL PROTECTED]> (fortran application and library
> packages) and Mathias Klose <[EMAIL PROTECTED]> (toolchain packages).
>
> * Why do we need one
>
> Upstream did release the last version of the g77 frontend with
> GCC-3.4. gfortran 4.2 is now considered a viable replacement for g77.
> However, code must not link at the same time against -lg2c and
> -lgfortran. To allow partial upgrades we need to rename all library
> packages built with g77 and linked against g2c when they are rebuilt
> with gfortran.
>
>
> Once the transition is completed, we are able to remove GCC-3.4 from
> the distribution (gpc needing an update for GCC-4.1 as well).
>
> * Actions
>
> If your package build-depends on g77, you need to adjust your
> build-depends from g77 to gfortran. If you build-depend on a library
> package containing a shared library linked against libg2c, wait until
> all of these libraries are rebuilt with gfortran. Tighten the
> build-depends on those lib*-dev packages to the first version built
> with gfortran.
>
> If your package provides a library that exports fortran functionality,
> it needs to be renamed. The recommended suffix for the new package
> name is "gf". If your package is affected by also by the long double
> transition, you can choose whichever suffix for your library.
>
> For example, lapack3 is now:
>
> Package: lapack3
> Binary: lapack3, lapack3-test, lapack3-dev, lapack3-pic, lapack3-doc
> Build-Depends: debhelper (>= 4), g77, refblas3-dev
>
> should become:
>
> Package: lapack3
> Binary: lapack3gf, lapack3-test, lapack3-dev, lapack3-pic, lapack3-doc
> Build-Depends: debhelper (>= 4), gfortran, refblas3-dev (>= <first version
> built with gfortran)
>
> * Caveats
>
> Some of the command line options supported by g77 have been dropped. You
> can usally just drop them.
>
> On ia32 and amd64, you might need to use the -ffloat-store option for
> gfortran to achieve identical behaviour with floating points. This was
> at least the case for refblas3.
>
> * Affected packages
>
> For the trivial packages, which build-depend on g77 but do not use or
> provide fortran libs, replace g77 with gfortran in build-depends and
> upload.
>
> Aurelien Jarno <[EMAIL PROTECTED]>
>
> * med-fichier
>
> Steinar H. Gunderson <[EMAIL PROTECTED]>
>
> * pvm (g77 only used for example code.)
>
> Radovan Garabik <[EMAIL PROTECTED]> (MIA)
>
> * zivot
>
> Kurt Roeckx <[EMAIL PROTECTED]>
>
> * libtool
>
> James R. Van Zandt <[EMAIL PROTECTED]>
>
> * minpack
> * multimix
>
> Chris Lawrence <[EMAIL PROTECTED]>
>
> * r-noncran-lindsey
>
> Justin Pryzby <[EMAIL PROTECTED]>
>
> * saods9
>
> The main knot to open is refblas3 -> lapack3 -> atlas3. It expands
> with scalapack, octave, netcdf, mpich and lam.. Then, a bunch of python
> packages, python-numpy, python-numeric etc need these as well. The actual
> details of upload order are still under work.
>
> Camm Maguire <[EMAIL PROTECTED]>
>
> * refblas3
> * lapack3
> * lam
> * atlas3
>
> Adam C. Powell, IV <[EMAIL PROTECTED]>
>
> * mpich
> * petsc
>
> Debian Scientific Computing Team <[EMAIL PROTECTED]>
>
> * ufsparse
>
> Kevin B. McCarty <[EMAIL PROTECTED]>
>
> * cernlib
> * geant321
> * mclibs
> * mn-fit
> * paw
>
> Paul Brossier <[EMAIL PROTECTED]>
>
> * fftw
> * fftw3
> * k7fftwgel
> * k6fftwgel
> * p4fftwgel
>
> Warren Turkal <[EMAIL PROTECTED]>
>
> * netcdf
>
> Debian Octave Group <[EMAIL PROTECTED]>
>
> * octave2.9
> * octave2.1
>
> "Leaf" packages, that can be uploaded as soon as all their
> dependencies have been transitioned.
>
> Christophe Prud'homme <[EMAIL PROTECTED]>
>
> * arpack
>
> Daniel Baumann <[EMAIL PROTECTED]>
>
> * lush
>
> Michael Banck <[EMAIL PROTECTED]>
>
> * mpqc
> * psicode
>
> Adam C. Powell, IV <[EMAIL PROTECTED]>
>
> * pysparse
>
> Matthias Klose <[EMAIL PROTECTED]>
>
> * python-numarray
> * python-numeric
>
> Konstantinos Margaritis <[EMAIL PROTECTED]>
>
> * blitz++
>
> Debian Scipy Team <[EMAIL PROTECTED]>
>
> * python-numpy
> * python-scipy
>
> Hamish Moffatt <[EMAIL PROTECTED]>
>
> * wsjt
>
> Debian QA Group <[EMAIL PROTECTED]>
>
> * tela
> * libextutils-f77-perl
>
> Henning Glawe <[EMAIL PROTECTED]>
>
> * pdl
>
> Muammar El Khatib <[EMAIL PROTECTED]>
>
> * blacs-pvm
> * blacs-mpi
> * scalapack
>
> Nicholas Breen <[EMAIL PROTECTED]>
>
> * gromacs
>
> Mark Hymers <[EMAIL PROTECTED]>
>
> * kst
>
> * Risks
>
> - MIA or inactive maintaintainers
>
> React with timely NMU's
>
> - Slow NEW que
>
> Renames require visit in NEW. run packages via experimental first
> to avoid breaking sid for long times?
>
> - Upstream support
>
> gfortran-4.2 upstream seems enthusiastic about letting g77 to it's
> rest, so good support is expected. Individual fortran software might
> be quite old upstreams can be inactive.
>
> - gfortran-4.2 on ports
>
> There is a risk that both gfortran upstream finds it uninteresting
> to fix bugs in strange ports, while porters remain uninterested in
> fortran. It needs to be shown to people that major parts of debian
> still have dependencies to fortran packages.
>
> * Feedback and Further discussion
>
> In case we have missed something, you have some sugestions or other
> feedback for the release goal proposal, please use the
> [EMAIL PROTECTED] list.
>
> --
> "rm -rf" only sounds scary if you don't have backups
>
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
