[Pkg-scicomp-devel] fw: gfortran transition release goal proposal

Sun Jul 22 23:16:48 UTC 2007

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: <nchip at kos.to>
> Date: Thu, 5 Jul 2007 17:17:42 +0300
> From: Riku Voipio <riku.voipio at iki.fi>
> To: debian-release at lists.debian.org
> Cc: debian-toolchain at lists.debian.org
> Subject: gfortran transition release goal proposal
> Resent-Message-ID: <HnNYQD.A.4FH.v2PjGB at murphy>
> Resent-From: debian-toolchain at lists.debian.org
> List-Id: <debian-toolchain.lists.debian.org>
> Resent-Sender: debian-toolchain-request at lists.debian.org
> 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 <riku.voipio at iki.fi> (fortran application and library
> packages) and Mathias Klose <doko at debian.org> (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 <aurel32 at debian.org>
> 
> 	* med-fichier
> 
> Steinar H. Gunderson <sesse at debian.org>
> 
> 	* pvm 	(g77 only used for example code.)
> 
> Radovan Garabik <garabik at melkor.dnp.fmph.uniba.sk> (MIA)
> 
> 	* zivot
> 
> Kurt Roeckx <kurt at roeckx.be>
> 
> 	* libtool
> 
> James R. Van Zandt <jrv at debian.org>
> 
> 	* minpack
> 	* multimix
> 
> Chris Lawrence <lawrencc at debian.org>
> 
> 	* r-noncran-lindsey
> 
> Justin Pryzby <justinpryzby at users.sf.net>
> 
> 	* 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 <camm at enhanced.com>
> 
> 	* refblas3
> 	* lapack3
> 	* lam
> 	* atlas3
> 
> Adam C. Powell, IV <hazelsct at debian.org>
> 
> 	* mpich
> 	* petsc
> 
> Debian Scientific Computing Team <pkg-scicomp-devel at lists.alioth.debian.org>
> 
> 	* ufsparse
> 
> Kevin B. McCarty <kmccarty at debian.org>
> 
> 	* cernlib
> 	* geant321
> 	* mclibs
> 	* mn-fit
> 	* paw
> 
> Paul Brossier <piem at debian.org>
> 
> 	* fftw
> 	* fftw3
> 	* k7fftwgel
> 	* k6fftwgel
> 	* p4fftwgel
> 
> Warren Turkal <wt at penguintechs.org>
> 
> 	* netcdf
> 
> Debian Octave Group <pkg-octave-devel at lists.alioth.debian.org>
> 
> 	* octave2.9
> 	* octave2.1
> 
> "Leaf" packages, that can be uploaded as soon as all their
> dependencies have been transitioned.
> 
> Christophe Prud'homme <prudhomm at mit.edu>
> 
> 	* arpack
> 
> Daniel Baumann <daniel.baumann at panthera-systems.net>
> 
> 	* lush
> 
> Michael Banck <mbanck at debian.org>
> 
> 	* mpqc
> 	* psicode
> 
> Adam C. Powell, IV <hazelsct at debian.org>
> 
> 	* pysparse
> 
> Matthias Klose <doko at debian.org>
> 
> 	* python-numarray
> 	* python-numeric
> 
> Konstantinos Margaritis <markos at debian.org>
> 
> 	* blitz++
> 
> Debian Scipy Team <deb-scipy-devel at lists.alioth.debian.org>
> 
> 	* python-numpy
> 	* python-scipy
> 
> Hamish Moffatt <hamish at debian.org>
> 
> 	* wsjt
> 
> Debian QA Group <packages at qa.debian.org>
> 
> 	* tela
> 	* libextutils-f77-perl
> 
> Henning Glawe <glaweh at debian.org>
> 
> 	* pdl
> 
> Muammar El Khatib <muammarelkhatib at gmail.com>
> 
> 	* blacs-pvm
> 	* blacs-mpi
> 	* scalapack
> 
> Nicholas Breen <nbreen at ofb.net>
> 
> 	* gromacs
> 
> Mark Hymers <mhy at debian.org>
> 
> 	* 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
> debian-toolchain at lists.debian.org list.
> 
> -- 
> "rm -rf" only sounds scary if you don't have backups
> 
> 
> -- 
> To UNSUBSCRIBE, email to debian-toolchain-REQUEST at lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster at lists.debian.org